Everyone involved in any kind of business will be used to functional organisational structures. They are very much ‘the norm’. However, while their purpose is efficiency, these structures can be problematic.
People who have grown up with such an approach often find it difficult to conceive of anything different. The fear of change gets them stuck, and they dismiss the need for anything special.
This is one of the biggest underlying reasons for poor program delivery, or worse still, complete collapse. The same issues happen over and over again.
Too fixated on the status quo
Organisations can put as much effort into their program projects as they like, but many are still destined for failure. The reason is that management teams are too inflexible – they make rough and ready organisation decisions, simply because they fit with the status quo.
Instead, they should take time to look closer at what’s needed, on a case-by-case basis; to see past the obvious and drill down into the details. This is especially important when the program in question is business-critical, and when it’s something out-of-the-ordinary.
Two types of program
While all programs are different, the majority fall into two distinct categories: regular and complex. Most organisations are at ease with basic, straightforward programs, but business-critical programs are an entirely different matter – one that should not be ducked.
It’s a common assumption that ‘regular’ means easy, and that’s not true. These programs are still demanding, but they’re also more common, and for that reason, better understood.
Business-critical programs mostly fall into the complex class. They have more moving parts – and have many more touch points across the organisation. They also have a significant bearing on the organisation’s future business. They’re difficult and expensive to build, but the rewards are greater.
It’s all relative.
To get the most from these business-critical programs – or in some cases anything at all – companies must work quickly and be agile. Execution speed is fundamental to success.
Business-critical or business-as-usual?
Functional structures have been around for more than a century, and they do serve purposes. More than anything, they offer predictability; the idea is that when processes become standardised, so too do the results. And back in the early 20th century, it definitely worked.
Back then, however, the stresses and strains of business-critical programs – which as we now know are anything but predictable – weren’t even imaginable. It’s quickly become clear that general management practice has little in common with the management principles needed to successfully run complex and crucial programs. The differences between the two means that clashes are inevitable, and collapse is more likely.
These clashes take many forms. So often, for example, programs that are deemed by senior management to be absolutely crucial are, somewhat bafflingly, starved of resources – they don’t get the attention they need. Management teams are simply too busy to give them the time needed, and the end product suffers greatly as a result.
What we end up with is a situation where business-as-usual (BAU) always wins. Senior management see BAU it as being too precious to stray from, and over time, program work shudders to a halt. The little time that has been spent on the program is wasted, along with any investments made.
A time for change
Most businesses lack a recognisable process for program execution. The few manuals and guidelines that do exist are rarely used as anything more than door stops and paperweights. For some reason they’re not seen as important. But, unless you can describe what you’re doing, you don’t understand it.
At present, boards put so much into theoretical strategies and approaches, but fail to give nearly as much attention to the execution. They don’t ask senior management the crucial questions: what type of program are we running? What are the expectations, and are they realistic? How complex is this likely to be?
If the answers suggest this is a straightforward, ‘regular’ program, go ahead as you are. Otherwise, don’t kid yourself that the BAU approach is sufficient – you need a separate standalone team with a capable leader and its own resources. Most importantly, it should operate freely, without having to consider BAU management practices.
Why the standalone approach works
It’s true that for a business to adjust its working approach, senior management must understand the reasons.
In this case, the reasons are particularly strong.
First and foremost, transparency is crucial to program success – and that’s something you don’t get with the business-as-usual method. When you have large groups of people, all with limited time and blurred accountabilities, it becomes difficult – or in some cases impossible – to get a decent view of exactly what’s going on at any given time.
You might have half of someone’s time, for example, but which half is it? And who decides what takes priority? Usually it’s the line manager as opposed to the program manager, meaning normal BAU processes will always come first.
The clarity that comes with having the program removed from BAU and properly defined as a process, with complete transparency, creates powerful confidence. It’s conducive to rapid and effective decision-making, which in turn is essential to your program’s success.
Getting to this point may seem daunting, but the first step is taken by just answering one question: is the program regular or complex? The answer should determine what rules you play by from here on in.
Download our ebook “The Mentor Edge” to get more tips on choosing the right approach to program delivery.