Many companies don’t treat business-critical programs as if they’re strategic at all; they’re frequently lumped together and managed the same way as any other initiative.
Too often, companies naïvely believe that a functional organisation structure is capable of executing a business-critical program.
But it’s such a thorny subject, let’s explore the question a bit . . . .
Why do businesses need a separate organisation to run a business-critical program? Why can’t the normal functional structure manage them alongside business-as-usual?
After all, the functional organisation has been around for a long time. Everyone understands how they work; it’s the way most people have been trained.
Why do you need to do anything special?
There’s no doubt that companies can run certain types of program within the functional structure – but they’re mostly straightforward.
If a business is not complex and can pass the baton smoothly between functions, without dropping it, these programs don’t need any special treatment. The business-as-usual organisation (BAU) can handle uncomplicated programs with relative ease.
Programs fall into two classes – regular and complex; there’s really not much in between.
This is a key distinction that gets missed time and time again.
Many companies have got to grips with regular programs, but they still make a mess of complex, business-critical ones. Two-thirds of them still fail – despite increased investment in project and program education programmes.
“Regular” doesn’t mean programs aren’t demanding; they’re just more common and predictable. The routines are well-rehearsed and each function knows exactly what to do.
The term “complex” is so widely abused that when an authentic, business-critical program does come along, companies don’t normally even think they should organise differently.
If all programs are treated the same, confusion thrives. This simple oversight triggers a chaotic chain of execution madness that is incredibly difficult to stop.
Programs are called “business-critical” because they’re complex and cutting-edge; typically, the future of the business depends on them.
They are complex because it hasn’t been done before – although flawed comparisons are often made with programs the business has run previously. But many of these vanish under closer scrutiny. They’re also more unpredictable and riskier due to the sheer number of “unknowns.”
Execution speed is fundamental to success. And while functional organisations might figure out what to doin the long run, they are notoriously one-paced.
By which time, it’s usually game over. Too little – too late.
It’s rare to find an executive who wouldn’t say that his function can do almost anything.
This is instinctive – but really bad judgement. You can’t equate the capability of two or three rock stars at the top of a function with the capability of an entire team – but many senior managers do.
These managers overlook one critical fact: lots of people in every function don’t have the most primitive management skills for the crushing demands business-critical work.
It’s probably not their fault – but that’s beside the point.
On top of that, business-critical programs must be done alongside delivering excellence in ongoing operations.
Doing both – and doing them well – through the functional organisation is a pipedream.
Functional organisations are creaking at the seams – and permanently in cost-cutting mode.
How can it make sense to dump one or more, game-changing programs on top of their normal workload – which invariably includes tough cost-cutting challenges – and not expect serious consequences?
It’s a simple question, but many companies try to do exactly this.
So, let’s consider a few points about functional organisations structures…
First, they were designed one hundred years ago by Ford and General Motors – for repeatability and predictability. They were never designed for tackling business-critical programs. Back then, the stresses and strains of today’s business–critical programs could not have been imagined.
Second, there are basic contradictory clashes between normal business operations and business-critical programs. No matter how much senior management like to skate around the problem, these collisions are inescapable and guarantee the two are always in conflict.
Management practice in normal business functions has almost nothing in common with the management principles for running business-critical programs.
That’s why functions quickly run into a brick wall with any program that’s not regular or “run-of-the-mill.”
Some executives argue passionately that it “ought to be possible” to run complex programs alongside BAU. This is “drive-by” management. Theoretical drivel based on little more than gut-feelings, half-truths and misconceptions – mostly from people who have never successfully done it before.
Day-to-day tactical work always overshadows the change agenda.
Unless programs are run separately from normal operations, business-as-usual is king. It gets top priority; that’s a fact.
Programs are starved of critical resource and essential change work is put on the back-burner. Teams are just too busy with other “do-it-now” work.
If programs are truly business-critical, you simply can’t expect to get program work done with fragments of people’s time. This is a feature of running business-critical programs alongside BAU.
Executive management constantly turns a blind eye to this, unintentionally or otherwise. It’s a fantasy, plain and simple.
Compounding the problem, organisational choices for business-critical programs are made by managers who don’t have enough experience – or understand the practical execution challenges nearly as well as they should.
The critical question to ask is what type of program are you running?
Is it regular or complex? Is it time-critical and cutting edge?
If it really is a regular program, go ahead and run it through the functional structure. You should succeed.
If it’s a complex business-critical program, don’t kid yourself that you can run it through BAU – and get the results you want.
You need a separate standalone team, a capable leader with its own resources, unconstrained by BAU management practices.
You can’t get transparency from groups with blurred accountabilities.
Specifically, when you run a business-critical program with fragments of people’s time, it’s impossible to understand who is working on what.
Executive teams must be in a position to make informed decisions on priorities and resource allocation -with transparent data, not bafflegab.
Transparency on business-critical programs comes from separate, standalone teams with true accountability.
If you want to avoid pointless trouble, ask the right question. Don’t skate over it.
Is your program regular or business-critical?
You take a major step toward celebrating a rare program success – if you answer this question frankly and honestly. Crucially, you have to act decisively on the information. You need a fudge-free organisation solution.
Quite simply, organisation choices for business-critical programs do have a dramatic impact on financial results. To succeed, business-critical programs should be run separately from the functional structure.
Each program requires a tailor-made team, a custom organisational model – and a dedicated, standalone plan.
So save yourself a ton of trouble, torment and tears and get those program organisation decisions right – before you start.
A great strategy doesn’t always mean great results. Download Mentor’s eBook “The Mentor Edge” if you want to jump-start your execution efforts.