HaulerGuy
|
Posted - 2004.05.18 10:52:00 -
[1]
Edited by: HaulerGuy on 10/06/2004 15:07:26 Edited by: HaulerGuy on 10/06/2004 15:02:56 Edited by: HaulerGuy on 18/05/2004 10:56:07 I manage an internet based system that is mission critical, has many complex changes applied, with several thousand users globally in a very crowded solution space where customers can easily walk.
I wish to present my thoughts on some changes to your release process that could reduce some of the negative client experience that has been associated with previous releases / patches. These are based on my experiences in this area and are not to be taken as my view of the perfect approach, they are merely suggestions which I hope could make things better for me the customer. This is not a rant, this is what I see as the issues and how I feel they could be addressed.
Scheduling Give 7 days notice - people will have time to plan around the downtime. Target a time period when system usage is at it's lowest to reduce the amount of customer disatisfaction.
Estimating Be conservative - allocate significantly larger time windows for the work that is being executed than best case scenarios suggest, as something always comes up to disrupt the plan. From a client perspective it is far better to receive a message saying the system is back early than one stating that it will be down longer. This also avoids the tidal wave of logins and associated heavy system load when the system comes back.
Reviewing Hold post implementation reviews - when unexpected issues are encountered state to clients afterwards what the issues were ( which you do ) and more importantly what is being done to ensure if they are encountered in the future how their disruptive affects will be mitigated ( if possible ). One specific area here which I think needs more focus is the fact that after most major upgrades in the last few months there always seemed to be large numbers of people getting stuck in systems for the first few hours after the restart, further restarts of the system then were required during the next 8 - 12 hours to resolve this issue, can this be be examined to determine how this can be avoided for the next large patch ?
Communicating If a large duration implmentation is being carried out what I normally do is have several milestone reporting points in the plan, eg "We are 1 hour into the upgrade and we are 20 minutes behind schedule" etc, that way people's expectations are managed, rather that them not finding out about delays until the scheduled restart time. It does not require significant effort from the implementation manager to update a release status page once every hour or two and it reduces the negative client feedback considerably in my experience.
Exit Strategy If your implementation plan does not survive contact with reality and things really are going badly, ( what I do is make a call to back out if I am more than 30% over my schedule, depending on my confidence level on resolving the issue). I always have a detailed exit strategy with a time estimate on how long it will take to get the system back to the way it was before it was messed with it.
Apologies if this has been raised before.
Thanks for your time.
|