'Go Live' and Beyond

Crisis Management

'Go live' should be the high point of an implementation. Expectations will be high as the process of switching from the old system to the new kicks in. Months of thorough preparation, planning, coordination and management should finally pay off. The reality is not as pretty as that and go live is all too often chaotic and calls for crisis management.

Managing crises at this stage is entirely different to the normal project management that moves the project through the earlier stages. Events happen very quickly and the ability to respond just as quickly is crucial to success. Consequently, crisis management must be planned as for any other critical factor.

All of the risks when going live, as throughout the project, must be envisaged, identified and documented in advance together with actions to either eliminate or minimise the effect of these so that they can be acted upon urgently. Our infoKit on Risk Management looks at some of the techniques you might use for this purpose. Communication plans and issue reporting mechanisms must also be devised and documented in advance.

It is vitally important that go live causes as little disruption to the day-to-day business operations as possible. Problems at this time become magnified and can undoubtedly damage the organisation's reputation with any or all stakeholders, sometimes irreparably. Poor project management and lack of communication at this time can ruin an otherwise faultless implementation.

The clear message for all is 'expect go live to be a crisis'. It is rarely the case that the new technology will work exactly as it is meant to - i.e. as expected or required - at the first attempt. The best training course in the world and the most comprehensive of testing procedures are no substitute for the 'hands-on' experience of the system running 'live' with all the idiosyncrasies of the local implementation. Very often early production runs uncover 'unique' bugs that no other customer has experienced, as the hardware, software and configuration bundle can often be unique to a customer for complex systems. Swift action is commonly required to tweak the new production system to eliminate or alleviate such problems.