When you are running any form of migration, integration, upgrade, or indeed any project that touches a live business process, there will always be a battle between BAU 1 and the project. This battle can be over resources, vendor time, budget, or even something as core as system uptime. Inevitably, there will be a debate about who gets their stuff first.
The default position is usually that BAU takes precedence. A production issue always wins against everything else. However, if you are managing either BAU or the project, you must remember that every priority comes with a consequence. This is the part that often gets overlooked.
For example, a BAU team might say, “We’ve got a production issue, we need the developers to drop everything,” or “We need to cancel the weekend outage because we have to work through it.” It makes no difference what the specific request is. The key point is that even when one side’s priority is accepted, it is often assumed by that side that there will be no consequence or no cost for exercising that priority.
When this happens, you will often need to have the awkward but necessary conversation: “Yes, we’ll all pile into the BAU problem, but this will have the following knock-on effects.” I would strongly advise anyone running projects to be crystal clear on this at the time. People have very short memories about these things, and later you will hear questions such as “Why is your project late?” or “Why has BAU been impacted?” Without a proper paper trail, it becomes very hard to justify the outcome.
So when you have a situation where one side’s work must take priority, acknowledge it, accept it, and then record the consequence. Provide a bill, whether that is measured in lost time, extra budget, or a revised delivery date. It is the only way to maintain fairness and transparency between BAU and project work.
- Business as usual [↩]