Do you know what it means to handover to BAU? BAU equals ‘Business As Usual’ by the way.
I find that IT teams usually don’t handover to BAU because they are too caught up in the doing associated with the project.
Project teams focus on delivering the project and lose sight of who will take responsibility when the project ends.
Perhaps project teams don’t see handover to BAU as their responsibility.
Mind you, I will qualify that statement by saying that the development teams that work on the project don’t need to be interested.
Development teams won’t be involved in the BAU state. It is only if they will play a role in support once the system goes live that it is important for them to be involved in and understand the handover.
There are certain things that need to be in place to make a system run smoothly on a day-to-day operational basis. Support processes also need to function when day one of BAU commences.
Here are some tips:
1. Ensure that everyone involved has clear roles and responsibilities
This is a critical step. I have found that people who need to be managing a piece of the process, often don’t know about it until it’s too late. Staff usually find out they are responsible when there is an incident and the system falls over.
Get the key stakeholders together in a room. Walk them through the process of what it means to be in a Business As Usual state. Ensure that they understand, even document, their roles and responsibilities. That way it is very clear who is responsible for what.
2. Make sure the right communication channels are in place
When project activities return to BAU you are no longer reporting to your Project Control Board. The Business Owner is often forgotten.
The Business Owner is the key stakeholder for before, during AND after the project.
Your business owner is still critical and needs to be in the loop from a communication perspective so that they can let the business (in its many forms from internal staff to external customers) know if and when something goes wrong.
The Business Owner needs to understand if the system is operating the way that they envisaged in their business case.
They need to be able to track the benefits. If they aren’t kept in the loop, how is it possible for them to do that?
3. Have your support model documented and agreed
My two previous posts have discussed different aspects of support models. It is really important that a well thought out and documented support model is in place, with all of the key people who are going to provide BAU support signing it off, fully understanding what is required of them. This ties in with point one above.
4. Have a UAT testing plan in place for any system changes/modifications that might take place post go live
It is important to consider how the business is going to be comfortable with any future changes, bug fixes or enhancements that will be made to the system once it goes live.
Have the business involved in User Acceptance Testing (UAT). They will gain an understanding of the system functionality and what the system provides.
Business staff will understand how the system should function. When new code or change are made after the project is complete they will be able to tell if they work correctly.
5. Define escalation paths
It is important to have clear escalation paths defined and understood. There must be a path back to the business owner. There must also be a way for technical issues to be escalated to the appropriate team/person when needed.
If you have these five things in place, you can expect that your business will be reasonably happy with the handover to BAU (Business As Usual) support state.