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, because they are to caught up in the doing associated with the project. They have been so focused on delivery of all of the pieces for the system change, that they don’t think about what it means to handover or transition to BAU.
Mind you, I will qualify that statement by saying that usually the development teams that work on the project don’t need to be interested. Often times they 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.
So, what is going to be required so that the system that has been developed or changed, will run smoothly and all of the associated support processes operate in a straight-through manner 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
Often times when things go into BAU and you are no longer reporting to your Project Control Board the business owner gets forgotten. They are the key stakeholder for project delivery, but once things become BAU it is as if they are no longer important. Wrong perspective. 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 it’s many forms from internal staff to external customers) know if and when something goes wrong. They need 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 who and 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. The business will usually want to be involved in User Acceptance Testing (UAT) so that they are comfortable that nothing is broken when new code or change code is put in place.
5. Ensure that escalation paths are defined
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.