Balancing the Business as Usual (BAU) and Project Work of a Development Team

by Guy Gershoni

The struggle is to balance the pressing short term needs of the business with the more strategic medium to long term strategy/goals of the company.  I have worked on development teams that have got bogged down in Business as Usual (BAU) work and other development teams that have got lost, by focusing only on project work.

How to balance BAU (Business as Usual) work with project-based work?  The right balance between BAU and project-based work continually changes, but neither should ever be neglected for too long.  Too much BAU work can limit the vision of the team and lead to the team fixing symptoms rather than root causes, exposing the business to strategic risks.  Too much project work can disconnect the team from customer and business problems/needs.

Doing BAU work has advantages and risks, just like project work. Let's dive deeper into what we mean by these terms and how to recognise when we might need to adjust the kind of work the team is engaged in.

Defining BAU and Project Work

Before we talk about balancing BAU and project work, we need to clarify what they mean.

Business as Usual (BAU) work is the work that you didn't know you were going to do at the start of the day/week/month plus the routine work your team does all the time.  There is no business case, budget or oversight from PMO/project manager.  Depending on the maturity of your organisation, BAU work should not exceed a specified amount of effort, i.e. if the "BAU" work could take six weeks of effort, then it needs to become project work.

Examples of BAU work include:

  • Generating regular reports for the broader company
  • Preparing environments and portals for onboarding of new customers
  • Preparing demos for presales work
  • Fixing minor issues
  • Helping Customer Service team with customer enquiries

Project work is work that is planned.  It has gone through various gates to ensure the work has value, and everyone knows why we are doing it and what the expected outcomes will be.   Project work tends to be larger and more involved than BAU work, so internal and external resources and budget need to be organised and approved.

Examples of project-based work:

  • Product Development
  • Transformations and uplifts
  • BAU work that requires more resources and rigour than usual, i.e. onboarding of a significant client.

The team that delivers a project may be formed for the project and disbanded afterwards.  For this article, we will assume that the team is long-lived and does both project and BAU work.

Balancing BAU and Project Work

Too much BAU work can lead the team into a state where:

  • Becomes stuck in a local optimum
  • Understand the customer's problems but also listens to their solutions

When we do BAU work, we develop a great sense of purpose.  Each day brings immediate challenges that can be quickly resolved and satisfy an internal/external customer's need.  After knocking over these short term issues, we go home with a sense of accomplishment and satisfaction, which can become addictive.

Focusing on only short term works means we could get stuck in a local optimum.  We get better and more efficient in our area but, because we are only looking around our small patch, we may be missing a much better opportunity.  We may also be unaware of changing market/competition.

Team can be stuck in a local optimum if they are too focused on BAU work

Mixing in some longer term project work where the team can reflect, experiment, deliver and review can help them see beyond the local optimum.  In information technology, using the right tool, framework or methodology can save an enormous amount of time.  The technology landscape is continually evolving, so devoting a bit of time to try something new can yield massive benefits.

Another danger with too much BAU work is developing such a close relationship with customers that you not only listen to their problems but also listen to their solutions.  Each customer will have their ideas about how to fix their problems and getting lost in that forest usually ends up either a very fragile, monolithic system that is trying to do everything for everyone.  Or an unwieldy number of unique systems, one or more for each customer, that become impossible to maintain and improve.

Too much project work can also be hazardous.  I have worked in several companies where we went from one long term strategical project to another, burning money and opportunities as we went.  Because we didn't spend much time with the customer solving their problems, we either ran out of money before we could deliver or delivered a system that eventually got turned off.

It is too easy to think you know the customer, you understand their problems, and you know what they would like you to do.  But until you spend time with your customer's and iterate through your work with them, you are making wild guesses.

A balance between BAU and project work is when the team cares about the customer.  Instead of using abstract personas, they talk about real customers.  They love helping the customer but are also dedicated to building a better solution for the business.  They regularly discuss the kind of issues customers are having, operational/business issues and emerging opportunities.  Then the team plan out discrete projects they can work while continuing to service BAU work.

Pushing BAU Work Out of the Development Team

A lot of BAU work is either routine and can be automated or, with the development of some internal/external tooling, be pushed out to other teams.

On one project, senior management wanted daily progress reports.  We spent a day rigging up our build server to generate a flashy report based on the state of BDD tests in the software.  Before a sprint began, we wrote a high-level outline of the functionality that would be developed during the Sprint.  Each business function on the report showed up blue.  Then actual tests would be written for that functionality, which would now come up as red because the code hadn't been written/completed.  When all the code for a business function was written, and tests passed, it would come up as green.

Since developing a comprehensive BDD suite was already a requirement of the project, engineers didn't need to spend any extra time generating the report and management got a URL which they could visit to see progress in real time.

On other projects, we mined systems like Jira and HPQC to generate various required reports automatically.  Most systems have report generation capabilities and APIs, so on a Friday afternoon, you can either put together a script to create the report or at least grab the data and groom it for easier report generation.

Sometimes the team gets bogged down doing ad hoc work for customers or the support team:  cancelling orders in the database, trying to find the state of a consignment, updating addressing information etc.  These tasks may exist because a system doesn't have the functionality available for customers or internal teams to resolve the issues themselves.

Keeping track of how much time is spent doing these ad hoc BAU activities can then help build a case for developing features to facilitate self-service.  If three weeks of work can save one week a month for the team, then that sounds like a good ROI.  It also helps keep the group engaged and focused on building a better product rather than keeping afloat.

Motion vs Progress

It is easy to confuse movement with progress.  The team may have been flat out all week working on stuff.  They had resolved several issues raised by customers and internal teams, so feel it has been a productive week.  But if no work has been done to improve the underlying system or permanently remove some BAU work from the team's plate, then has the team made any progress?

A development team should be striving to remove routine work from their plate constantly.  This work never ends, because as the team adds new features and functionality, new operational work is created.  As a feature proves itself popular and matures, effort needs to be made to remove the routine work it generates from the development team so they can focus on the next feature/product.

What is BAU work? Business as usual (BAU) work is unplanned work that can happen unexpectedly or regularly.  It is usually relatively small and doesn't have a set budget.  BAU work includes tasks like generating a regular report, answering support enquiries or setting up a product for a customer.

What is project work? Project work is planned work that happens for a set period and usually has some dedicated resources and personnel.  Projects have well-defined outcomes and typically have a fixed budget with related oversight.  Project work includes activities like onboarding of significant clients, new product development and system uplifts.