Build your program team for what you can’t predict
Many large transformation programs that run into trouble started with a weak link in their program team.
The challenge is that you never know where the gap will be until it’s already impacting delivery
One program might struggle with poorly defined business requirements, another doesn’t hold the vendor properly to account, or a third fails to engage stakeholders outside the program effectively. Even with strong upfront planning, transformation programs face constant and unpredictable challenges, and when these gaps emerge, they often lead to delays and significant cost.
At ConceptSix we are often called in to a program once the gap has become obvious, with a remit to focus on the specific issue that emerged – but the program is already months behind.
The traditional response is reactive
You identify the gap and move to fill it. You start recruiting or procuring, wait weeks or months to onboard, then spend more time getting them up to speed on your specific program context. Or, you’re stuck handing more of the program to your primary implementation partner who can ramp up quickly, which increases commercial risk and puts all your eggs in one basket. The issue is you’re always playing catch-up.
You can’t predict upfront which capability will become your bottleneck, so you can’t hire for it in advance; or maybe you did predict it, but a key team member left or was reprioritised. In complex programs the environment can shift fast, and what looked like a solid team structure six months ago suddenly has a glaring hole – and by the time that hole has consumed your focus and you’ve fixed it, another has usually appeared.
The answer
To combat these risks, build flexible capacity into your program from the start.
This means having adaptable resources who can shift focus based on where the actual need emerges. You can do this in one of two ways:
- Find an over-qualified candidate for a key role such as lead architect, program manager, product owner or PMO lead, with an intent of leaning on their broader expertise when you need it.
One pattern we saw work well on a large client program was an overqualified lead architect, with an extra junior architect to keep things ticking along any time the lead needed to stretch into other parts of the program.
- Engage a strategic program delivery partner, independent of your primary implementation vendor. They can cover a range of roles day to day (many traditional roles in PMO, stakeholder/change, design, architecture are well suited), with the capacity to flex into other domains when the need arises. This can also bring the benefit of accessing high-quality talent that may otherwise not be applying for the roles directly in a program, including at very senior levels.
Either way, the key is that they already have program context. They understand your organisation, goals, constraints and personalities, and likely already have relationships with key executive, so they can move quickly without the ramp-up penalty of external hires.
Both of these options are insurance policies, so they will cost more than allocating full-time staff into the roles. However, with the burn rate of a large program, a couple months of delay will very quickly cost far more than a modest increase in key talent through the life of the program.
The programs we see succeed always have a tight core team that is highly capable, flexible and with enough capacity to lean in fast on any curve ball the program faces.
How this works in practice
In practice, this looks like having someone spot a gap in your data migration approach and immediately shift to lead that workstream, or recognising that your vendor engagement needs strengthening and pivoting to drive those negotiations.
Instead of a three-month hiring process, you have capable hands on deck within days. The value isn’t just speed, it’s the peace of mind for program leadership knowing that when (not if) a capability gap emerges, there’s already a solution in the room who understands the broader program.
The real shift here is moving from “fixing problems” to “building resilience.”
Rather than viewing flexible capability as a backup plan, treat it as a fundamental part of how you structure large programs. In an environment where you can’t predict every challenge, the teams that succeed are the ones designed to adapt.