If you work in or around any project, program or portfolio, you‘ll hear the word “interdependency” casually tossed around like driftwood. There’s nothing quite like a shallow chit-chat about program interdependencies…
..meetings where people exchange meaningful glances with each other intended to give the impression they are on the ball.
Every meeting is not like that – but, unfortunately, many of them are.
Like many words in English, the term ‘interdependency’ is a fat word.
Just like “governance” and “plans” they are wide open to misinterpretation. Fat words mean very different things to many different people.
Interdependencies are an enormous source of confusion. Judging by the number of programs that nosedive, it’s one of the most neglected areas in program execution.
People simply don’t take as much interest in vital work, if they are not directly responsible for delivering it. Illuminating expressions like “you’ll have to ask them. We’re not doing that, they are” are commonplace.
One essential condition for success on any business-critical program is interdependency management.
Considering the impact it has, it’s surprising how few Program Directors list dependency management in their top five priorities for successful execution.
Anyone working on a program has a view about what the word interdependency means. Most understand there’s a critical and “dependent” connection between something they are doing and at least one other program – but usually more. These could be inside or outside the business.
Typically, programs get together to discuss these connections. They work out who the “supplier” is and who the “receiver” is. They talk to the relevant program manager, describe what needs to be done, agree the budgets and timescales – and that’s usually enough.
Conversations like this take place every day. But the majority of these programs are finite initiatives that may or may not cut across organisations; the interdependencies are routine and well-known. The choreography is well-rehearsed.
Program portfolios have very different features.
Portfolios are usually connected with transformation. They include a bunch of programs and projects with multi-level interdependencies which are always business-critical. Complicating matters, transformation work is poles apart from routine programs businesses run every day.
Unlike discrete well-defined programs, portfolio interdependencies aren’t precise or well-understood – at least at the outset.
While senior management’s understanding of relationships between interdependent programs can be somewhat superficial, the detailed execution work involved isn’t. You shouldn’t expect people to read between the lines.
Putting abstract and simplistic labels on interdependencies means one thing. They’re not anywhere close to being executable.
Looking at dependencies from a “hundred-thousand-feet” means some critical connections may be taken too lightly.
Worse, some may be completely overlooked for many months.
The key distinction between transformation portfolios and routine programs is this. Initial transformation program plans always lack the clarity and firmness of the routine stuff, simply because the work is brand-new. There is no trustworthy program baseline.
If you want to build a Channel Tunnel – and you’ve actually built one before – you will have a reliable “reference-class” baseline for your program. There will be a good set of planning assumptions and metrics on which to build a program plan.
But how many transformation programs are in this category?
There simply aren’t any reliable reference-class baselines for transformation programs.
If you have one, you’re more likely to be “putting lipstick on the pig” rather than leading a revolution.
We know transformation program plans take time to develop, evolve and mature. What’s critical is to migrate program planning assumptions from “wild guess” territory to “educated guesses” then to “informed estimates” and on to “reliable forecasts” – before we can have any confidence in delivering financial results.
It takes time to get to a reliable program baseline with trustworthy dates and numbers.
Donald Rumsfeld famously said there are “known unknowns” and “unknown unknowns.” Transformation is mostly about managing these; they all need to be bottomed out and it’s the main reason interdependency management is so tricky.
Program planning is iterative; interdependency management is too. The big difference between the two is: program planning is typically directly controlled by a Program Director. Planning and delivery of interdependencies is done by programs elsewhere – in many cases, by third parties outside the company.
Because planning and delivery work is performed by others, interdependency management receives a lot less “heat and light” than internal-program activities.
A tell-tale sign that interdependencies are not well-managed is this.
Ask any Program Director how confident they are in delivering their plans. If the reply is something like “totally confident, provided Programs A and B and Suppliers D and E meet all their commitments to me; then everything will be perfect.”
This is what’s called a “clue” – and it’s not good news.
The follow-up questions of course should be “Will they actually meet their commitments to you, how do you know” and “what, specifically, will you do if they don’t?”
The type of answers you get to these questions always shed light on the true state of any program. It’s not enough for a Program Director to claim they’ve “called them out” to other programs.
It’s an unpardonable sin of omission.
One of the biggest challenges in pulling an executable program plan together is identifying all the activities and events required to deliver a successful result. Some Program Directors avoid challenging interdependency estimates from other programs for political and cultural reasons.
They’re delighted to offload a “poison chalice” to another program and forget about it, temporarily at least. Or perhaps the “supplying” Program Director was his boss in the past and he knows any argument over estimates would be forcefully driven back.
These dreary dance steps are often repeated with external suppliers where it’s safe to assume shortcuts were taken just to win the bid. It can take some time to “get under the hood” and find out what’s really going on in third-party businesses.
This is a mistake colossal.
Program Directors must make sure external dependencies are professionally managed.
No matter where the work is done – or who is doing it. Interdependencies have to be managed. Playing the “blame game” because suppliers – internal and external – haven’t met their commitments to a program is simply an abdication of management responsibility.
So, what should be done?
All programs in a portfolio should place valid “dependencies” on each other.
This should be a formal process; dependencies should first be discussed, then described – in writing – as “statements of work” by the placing program, indicating when the deliverable is needed.
The “supplying” program should evaluate the work; assess its feasibility, answer key questions like – do they actually have the skills and resources to do the work?
With all questions answered, they then make an offer to the placing program. The offer shows exactly what work will be done, when it will be delivered, what the costs will be – and, crucially, what management arrangements have been made to handle it.
Often, there’s a mismatch between what’s needed and what’s offered
. . . . and these differences need to be worked through and resolved.
But once discrepancies have been settled, the actual interdependency work plans should be managed with the same vigorous control given to all plans.
This doesn’t happen nearly enough.
Interdependency reviews frequently suffer from gratuitous “happy talk.” There’s not enough candour; too much syrup – and not enough citrus.
Dealing with third party dependencies is similar.
Suppliers should submit detailed plans that support their original bids. This is not as easy as it seems for two reasons. There’s always a time lapse between the original bid and program kick-off – during which many things can change.
On top of that, most initial supplier plans are fairly thin – often overlooking critical intersections with other key programs.
How can you stop a portfolio from being infested with Stupid?
It’s not easy – but it’s VERY important. Let’s remind you of something valuable, hopeful and optimistic.
Anyone who is smart and skilled in anything was once ignorant about it.
Replacing ignorance with know-how on interdependency management can be done by observation, learning lessons from history and obtaining quality help.
It’s a choice.
Interdependencies – and failure to manage them – can “kill” a program portfolio and often do.
Why not put the structure and the disciplines in place to manage them as they should be? Why not appoint someone with experience and wisdom to help manage all the interdependencies in the program portfolio?
This is not a time to give someone an “opportunity” to see what they’re made of. Wisdom trumps ignorance and naiveté every time.
Now there’s a thought…
We would love to hear from you.
Do you recognise any of the challenges mentioned? Have we missed anything? Do you have examples of the good, the bad and the ugly you are willing to share?
Please let us know at: email@example.com