The Sudden Realisation: "My Project's Going Live"
By Duncan Haughey | minute read
Over the years as a project manager, I've come across a project phenomenon I call, The Sudden Go-Live Realisation. It occurs when the customer realises their project is coming towards its conclusion and is about to go-live. The product they have worked on for months, sometimes years, is rolling out in front of their bosses, peers and members of the public.
This sudden realisation sparks mild panic, "are we ready" they ask. "Is the quality good enough and what if it doesn't work?" The fear of the unknown raises its head. "Will my boss be pleased and what happens if she doesn't like it?" The result of all these questions and doubt is finishing touches. A last-minute push to add improvements to the product. These cost time and money, as this work was not envisaged or planned for at the beginning of the project.
As people rush around making changes the risk of having problems with the go-live increase. Have the last-minute changes been tested thoroughly? Will they conflict with anything else? Have we taken our eye off the ball and lost sight of the big picture while polishing our product?
The best way to avoid problems caused by last-minute changes is not to make them in the first place. Sounds obvious but, it is not always possible, and you may need to make changes depending on the seniority of people asking for them. What is important is to follow a rigorous change control process to ensure all changes are properly reviewed and tested before implementation.
Reinforce Your Change Control Process
Explain to your customer that last-minute change doesn't mean cutting corners. Most people understand the need for testing before making a change. If they don't accept this principle, your only choice is to ensure they bear all the risk. Tell them if it goes wrong, you can't be held accountable. This approach usually causes them to think again and agree to follow your change control process.
A typical change control process goes through these steps:
- Document the change (the customer writes down their requirements).
- Assess the change (the project manager looks at the viability of the change with the project team and provides feedback to the customer).
- Plan the change (if the project manager accepts the change he or she creates a detailed plan for design and implementation).
- Develop a back-out plan (the project team develops a plan to remove the change should it fail or cause problems).¹
- Build and test (the project team carry out the work and test the change).
- User acceptance test (the customer tests and accepts the change).
- Implement (the project team rolls out the change).
- Final review (if satisfied the customer signs off the change and the project manager closes the request).
By following this process, you will make sure you minimise the risk of problems at go-live.
Develop a Detailed Go-Live Plan
In addition to change control, you need a robust go-live plan at a detailed level. Often, project plans have one or two lines for go-live, especially since they are usually created at the start of a project, long before anyone thinks about go-live in detail. Your plan will list all of the tasks needed to go-live.
A typical go-live plan has the following:
- Detailed deployment plan
- Detailed back-out plan
- Any change freezes needed
- Communication plan
- Resource plan
- A task-based timeline
Customers often get cold feet before go-live. It's up to you as project manager to reassure them and convince them everything will be alright. Having proper change control and a well thought-out go-live plan will help minimise the risk at launch.
¹ It's important to have a back-out plan for any changes you make. Not planning for an implementation failure can leave you with significant problems if you are unable to return to the last 'good state'. Should the change fail or need removing, execute the back-out plan that you created before implementation.