I was recently asked a question about the size a change window should be. “we don’t want to ask for something too long as we want the business to approve the outage window we need for this, on the other hand we want to make sure that we have enough time to complete all the work and ensure we hand the systems back over to the business in the time that we had agreed to.”This discussion reminded me of a Star Trek episode where a Mr. Scott was face to face with his 24th century engineering counterpart Mr La Forge. The discussion was of a similar flavor revolving around a system repair and went along these lines…
La Forge – I told the captain that it would be done in an hour
Scotty – how long would it really take?
La Forge – an hour!
Scotty – you didn’t tell him how long it would really take did you?
La Forge – of course I did
Scotty – Ah Laddie, you’ve got a lot to learn if you want people to think you are a miracle worker
While we are not looking for the business to think of us as miracle workers we do want them to have confidence that we are able to implement the changes to systems in the agreed to time while also making sure that they are not rushed and completed successfully.
This can be hard to do in the beginning when we don’t have a baseline for reference. The key is to document the work in the change record. For example the implementation part went quicker than expected but the testing took longer than we thought. Making note of these with some commentary will allow you to schedule changes more appropriately down the road. Make sure that you also think about how long a roll back might take or if none is possible the time to restore through other activities. When the change is done we should be able to say, we had more time than we needed, or next time we might want to have an extra hour ion the change window as we cut that one pretty tight.
There may also be instances where we need to take a change that is planned and where possible separate it into smaller more manageable pieces. Like on Star Trek they are making sure that critical functionality remains available so they look to change one thing at a time. Your business services are also looking to have the same level of availability. Implementing many things in a change may have not only timing issues but if something is not working as it did in test there may be diagnosis challenges.
At the end of the day we want to ensure successful deployments through planning wherever we can and build in contingencies for the few things we have not planned for. Working with your business to identify their needs as well as ensuring their service is in a maintained state can be a balancing act but this is where top communication skills come into play to manage that relationship.
That's a great episode and a great context for a conversation around managing changes. Well done!
Thanks Ken, I couldn't resist having seen this episode on tv the other day