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
Scotty – how long would it really take?
Scotty – you didn’t tell him how long it would really take
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.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
Labels: BRM, Change Management, ITIL, ITSM