A lot has been said about the differences in organisational construct when tackling a particular project versus dealing with the business as usual (BAU) tasks associated with running your firm.

What methodology works best? Do you fully embrace Agile or are you wedded to Waterfall ? Or do you implement a blend of the two and benefit from a mixed output as a result, like most organisations?

Whatever method you use, when the goal is achieved (or shelved) there’s invariably a time in every change project where the team members go their separate ways, back to either BAU activities or to saddle up and ride again onto the next project. The famous cross functional teams we’ve heard so much about in recent times tend to dissolve back into the organisation only to be called upon when the next business case gets its funding approved.

Increasingly however, more and more organisations are living in a world of slush as they move from one change to the next; if you like, a world of Change as Usual (CAU). If you’re not prepared for slush and depending on its consistency, it can either be extremely hard-going and slippery, or it is very messy and you end up with wet feet!

Embracing CAU is key, in our view. When we approach any ‘change project’, we don’t have a milestone where we “hand over to BAU – job done”. Instead we embed CAU processes and ways of working at the very start of the engagement.

The Harvard Business Review (HBR) published an article in 2017, All Management is Change Management which stated that:

Leaders should view change not as an occasional disruptor, but as the very essence of the management job.

During a recent digital change project that we led for a bank that starting slush position we first walked into was very hard going. The ability to get digital product out to customers was met with fundamental challenges around the ability to gain consensus on functional priorities, the development cycle, the route to live and finally the question of budget. Historically, all those planets had to align for anything to get done. They rarely aligned.

The very first quick win was to instil a sense of backlog prioritisation and to create the fora within which this was achieved. This “project” had a scope for sure; we had a set of goals from which a business case was approved, but we realised that CAU is the new normal and the fora created to prioritise further incremental changes would have to be enduring. Very quickly, not only the “project team members” but the wider organisation were immediately invested and contributing to the definition of future changes. The process by which these changes were prioritised was now clear.

Equally clear was also how those priorities were elaborated and then taken through a development process. Again, the wider organisation hopped on board and contributed within the fora as each requirement on the backlog was moved along the development life cycle.

Route to live was a little trickier (it was a bank after all with all the legacy overhead that this entailed), but once this was proven, the third inhibitor was cracked.

This left the budget question. Making a case for budget is a lot easier when you have a set of prioritised business asks with a view of effort required to take the idea through the development pipeline to live. That’s not to say budget is always then available, but it makes the justification a lot easier to articulate when you’ve got your collective act together.

What were the lessons learned? Embed CAU as soon as possible. Treat your “project” as though it never ends or indeed, as though it never started.