Once your project is complete, you need to hand over its products, deliverables, or processes to the operational Business as Usual team. This means you need to create, document, and deliver an orderly transition to Business as Usual (BAU).
This article describes the outline for how to do this and how to create and execute a BAU Transition model or BAU Support Model, to define how the project deliverables will be supported in BAU.
Your priority is to maintain, as far as possible, the smooth operational running that should characterize business as usual. If your transition causes disruption, this can increase costs, reduce revenues, and harm staff confidence, customer perceptions, and therefore, your reputation.
I cannot over-stress the importance of building user confidence in your transition and support plan. The principles I discuss in this video are highly relevant.
The structure of this article is very simple. To help with this, we will consider:
It’s always good to start by defining our terms. So, what do we mean by the phrase ‘transition to Business as Usual’? Well, let’s start with what is…
The term ‘Business as Usual’ covers all your regular, standard, day-to-day operations. We use the term to distinguish these from:
So, Business as Usual sees:
Projects are not Business as Usual. But the new products, processes, or approaches they create need to become part of BAU. However, any change in BAU can cause resistance and disruption. Staff, customers, and business partners may not understand the changes, they might resist them, or they may simply need to make adjustments to accommodate them. This is the transition to Business as Usual.
And this transition requires three key things:
You will also need to prepare users for the changes that will arise from the transition. This is all about Change Management.
This is an area I have covered elsewhere. So, rather than repeat myself, let me refer you to my recommended Watch and Reading list:
Every situation will, of course, be different. Context is everything! However, the details are likely to depend, more than anything, on what you are transitioning. For example:
Therefore, the following sections will necessarily cover a generic process from which you can build out your own plan for your transition to Business as Usual. The sections are:
For a summary of this article…
There are two sides to the development process: project and operations. There are also two sides to the transition: before and after.
As a result, it makes sense that there are:
Each one will manage their own part of the process. But it is by working together and with regular communication that they make the transition work.
Between the Project Management and the Transition Manager, your first step will be to tap into the knowledge, experience, and wisdom of stakeholders. They will be able to help you to understand the challenges of the transition to BAU, and to start to develop plans. This will involve a lot of:
Among the stakeholders you consult should be:
The outcome will be to develop your Transition Plan…
In putting together your BAU Transition plan, there will be a lot of questions to answer, to generate the levels of confidence you’ll want. But the biggest concern you will have is the risk.
You are entering into an uncertain endeavor, with a potential impact on critical business operations. So, let’s start with some of the questions to consider:
Look at these primary resources:
But there are plenty of other elements to build into your transition plan, such as:
When you have a plan – and have tested it by subjecting it to a critical review by colleagues – present your plan for your Sponsor, Client, or Project Board’s approval.
Your stakeholders – or some of them – will be at the sharp end of the transition to Business as Usual. So, you need to prepare them well. And, guess what this means? Excellent communication. As always, your stakeholder engagement process involves:
In many transitions to Business as Usual, training of users is an essential consideration. If it is for you, then your outline process will be:
Whatever you created, whether it is a service, a product, a process, or some software, you will need to test it thoroughly, before making the transition of incorporating it into your BAU operation.
The final tier of testing is User Acceptance Testing (UAT). And we have a video, ‘What is User Acceptance Testing?’ https://youtu.be/sGwm4p9sGPI which covers the different tiers of testing, including alpha and beta testing – all the way up to UAT.
This final acceptance testing should answer the question, ‘are you sure you are ready?’ That is, do the products or processes meet acceptance criteria and quality standards?
If they do, you need to:
This allows you to move toward the next step…
Is the project ready? And, is the business ready?
You need to make a clear Go/No-go decision. And you must support it with a robust, accountable decision process.
And, once again, you need to communicate the status to those who need to know.
Before you finally start your transition, you may want to conduct one or more:
Now you are ready to trigger the actual transition process. This will include:
And, you guessed it, you need to communicate the status to those who need to know.
Project Handover feels like a big milestone. But it is also more of a process than a milestone, so there is a lot to get right. For more information, check out our article, Ultimate Project Handover Guide: What You Need to Know.
The essential documentation you need is to secure sign-off of transition of responsibilities from Project to BAU.
As you may expect, the transition to Business as Usual is not the end of the transition process! Among other things, you’ll need to expect:
As always, I welcome your comments below and will respond to any thoughts or questions.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.