Meaning of BAU

Caught in the BAU versus project trap

When is a project not a project, when it’s a Business As Usual activity.

I was involved in a very interesting situation in the past month whilst working as the Project Manager and Change Manager on an initiative which I would call BAU.  It felt like being caught in the BAU versus project trap, an age old argument that occurs in most organisations.

I was asked to support a Procurement specialist with transitioning the outcome of a tender process in which it was decided to change vendors for service provision.

My view of this initiative was that it was a ‘Business As Usual’ (BAU) event and the reason why I was needed was because of the size of the change impact on the business.  It is very valid to have a change manager involved in these BAU type activities which do impact largely on the business.

What happened though was that the project competency got involved and decided that this transition should be considered a ‘project’ and therefore needed all of the project rigour around it, including at one stage the writing of a full business case.

It felt to me like doing work that had already been done.  The procurement team have a full and detailed tender process in place in which they had fully documented their business recommendations for transitioning vendors.  This had already been signed off as the way forward, by the Senior Executives (and business owners), so why re-do things just to tick a box in the project space.

I happily set up the project structure around the initiative, which included a full Action, Risk and Issues register.  We were in the process of developing a full project schedule, which required detailed input from both the incoming and outgoing vendors, and developed a Project Management Plan so that the use of resources could be fully justified.  I initiated the right process for engaging IT resources, and tracking their time cost against the initiative too.

All of this meant that it was easy to develop the required reporting that we were being asked to produce (the standard part of project world).

I naturally also developed the detailed change management documents too, items such as the Change Management Plan and Change Impact Assessment.

The rigour and work involved in ensuring that scope was clearly defined, and budget and resources correctly allocated; reporting for both Senior Management and Program Delivery was in place and all documentation was developed and signed-off.  As there was also a change of process for the business involved, this was also fully documented with requirements and related SLA.

What I was interested in was the concept that this should have been considered a ‘project’ and not as a BAU activity with the project rigour laid over it.

I felt as though we were being asked to go over and above the requirements of a BAU activity when what we had done in putting the project governance on the project was well and truly above the standard practice in this space.

I agree that by doing what we did, the whole transition would and was managed better.  Risks were highlighted and mitigated in the correct way.  It felt as though there was clearer understand and definition of scope and issues that were seen.

Consider then in these types of BAU activities where it is appropriate to overlay some of the project governance features such as the registers and monitoring so that you have a little more structure in the way that these types of transition activities are carried out.

I don’t advocate the need to go overboard just for the sake of ensuring that project management tick boxes are ticked.  That wastes everyone’s time and adds no value at all.  Only do what does add value and control and clarity to the process.



Written by Karen Munro

*Photo courtesy of Stuart Miles from