Are We Ready To Go Live? Considerations for Project leaders

by Nicki Carruth | Jan 8, 2024 | Project Assurance

Go-live – is there anything quite as scary for a project manager and steering committee than to commit to finally releasing your project into the wild? No matter how many times a business delivers projects, that moment of ‘going live’ always comes with a few worries. That’s normal, but it’s also a time deserving of celebration and satisfaction. In this article we take a closer look at some of the aspects to project go live that if done well, can make this whole scenario more positive than anything.

Defining go-live for your project

What does going live look like? For a technology project, this is perhaps more black and white – the developed platform or software being released to the end user. For other projects it could mean opening a new facility, a completion of a fit out or the signing of an agreement. While the subject matter varies greatly between projects, having an agreed statement of what go-live involves can prevent nasty surprises for anyone later.

Defining go-live can benefit the project and business by

Informing the preparation of resources and processes to support the go-live and any changes it brings.
Providing time for final quality assurance and testing.
Ensures other requirements from across the business have a clear deadline to deliver such as legal sign off.
Allows leaders across the business to prepare their teams.
Creating a defined before/after state that helps to measure the performance of the project and the effectiveness of its outcomes/deliverables.

Reviewing milestones and acceptance criteria

In an ideal world, knowing when go-live is imminent will be a matter of checking a project tool with up-to-date progress. Each milestone should have been satisfied, with go-live being the final chapter of the project to complete. For software or other IT-based projects, acceptance criteria should be carefully reviewed to ensure they’re all met. If not, gaps either need to be addressed or be subject to discussion between the steering committee, stakeholders and the project team as to why this particular requirement won’t be delivered for go-live. This isn’t uncommon, and the nature of digital and IT products means a feature left out now can always be added in after an initial launch.

If there’s an absence of milestone progress reporting, there’s a bit more work to be done to check progress and capture this before going live. Without it, a project’s outcomes may not deliver what they’ve been tasked with, and further work will be needed. The problem here, among time and budget implications, is that a project may have been considered ‘finished’ before these deficiencies are identified, requiring the organisation to determine if a new project is required to address these. For many organisations, this outcome could be considered project ‘failure’ – something our team and assurance work aims to help businesses avoid.

Meeting quality assurance standards

Quality assurance gives a project and organisation that peace of mind that it’s met the strategic objective it’s designed to. But QA should ideally be engaged from the very start (business case). This way, each stage of the project runs smoothly and issues are addressed before they grow too large. Regardless of when QA is brought into a project however, that function is highly recommended before committing to going live. Take it from us, it’s less stressful addressing issues before the project outputs hit the end user or broader business!

User / team training

Training and involving those in the business that will be using or supporting the project’s deliverable (e.g. a new customer relationship management system) should start happening months in advance of any go-live date, even if actual training is just in time for go-live. This not only equips the user with the information they need to make it a success, but can also build advocates for the project’s deliverable, helping to encourage its adoption across the organisation.

Developing training or onboarding documentation and programmes can be quite involved, and can require specialist expertise like technical writers to do well. The business broadly will need to factor in the resource impact for training time, too.

Any concerns that the business isn’t ready to use or succeed with the delivered product should be addressed before committing to launch.

Involving your stakeholders in the go-live process

If you think a debate about scope can get heated, imagine what going live without full knowledge of your stakeholders can be like. The last thing any leader in the business wants to contend with is change they or their team weren’t ready for.

Part of good governance is to communicate with all key people properly. There are few downsides to giving too much notice as well. While milestones to date might have been signed off, that final launch date is where the rubber hits the road; if there are any outstanding issues that a stakeholder hasn’t been involved with, only to discover these when live, it can be a trying time for everyone involved.

Help your stakeholders manage the project launch on the front foot, and they are invaluable to a smooth roll out – after all, many will likely be responsible for entire business units.

Mitigating your risks

Risks should be mitigated throughout the duration of the project, with any high risk items being carefully managed as they are identified. By go-live, there shouldn’t be any outstanding high risks that were captured at the start or early in the project. If there are still risks that could impact the successful launch or adoption of the project’s deliverables, they need to be mitigated as much as possible. It’s typically much cheaper to address these before the project is wound up than after.

It’s not realistic to eliminate every risk inside a business and projects are no different. That’s why mitigation strategies will include contingency plans in case these risks eventuate. Being prepared if it happens is better than hoping it doesn’t.

Technology projects – a roll back plan in place?

While a company restructure or a large infrastructure project is virtually impossible to go back on without real damage, IT projects are a bit different. A well-planned IT project will involve ‘roll-back’ contingency plans so that if the solution is released and doesn’t perform as expected or presents a major issue, the business can walk back the change to revert to the original system.

While this is certainly not a great scenario to navigate, it’s much better than taking the leap of faith only to find out it wasn’t ready – with no option to turn back. So if you’re involved in a technology-based project, make sure there’s a roll-back plan.

Better still, modern-day IT initiatives will often be ‘soft-launched’ and rolled out to a subset of the intended audience while keeping everyone else on the legacy solution. This enables the business and project team to get the solution live, but at reduced cost and risk so that any unexpected hiccups can be resolved before the business relies upon it at scale.

Communicating with the business

Giving the wider business plenty of runway to prepare for any changes can really help reduce the disruption at go live. Everyone who’ll be affected by the project’s outcomes should know when go live is happening and what it means for their role. Similarly, customers or those external to the organisation should be adequately informed before the launch date.

Communications should be short, sharp and to the point, and it’s better to reinforce messages over a period of time, rather than rely on one single email. Also consider who the communications come from – senior leadership may release a business-wide message, but lean on business unit leaders to tailor comms to suit their teams’ needs.

Does it need to be a big red button, or are you better to break the project down into less scary chunks?

Part of what makes a go live decision so fraught with anxiety is due to the built up high stakes nature of the project. Those initiatives that take years to complete have a lot riding on them. While this is simply required in some instances, much of the time a big project could have been split up into smaller, more manageable projects. There are plenty of benefits to this, including:

Each project has a smaller budget but it’s insulated from what might happen in other projects before or after.
Structured properly, the business can see more progress, more often. This not only helps give confidence for leadership, but can keep staff motivated and engaged.
Getting sign off and agreement on scope can be more straightforward.

You can read more about breaking projects down in our full article.

Talk to us about assurance for your project before go-live

Our team provides expert project assurance services drawing on decades of high-stakes project experience and application of internationally-recognised methodologies. We provide you the tools and processes to give your project the best chance of success. Chat to us to learn more about how we can help your organisation.