The steering committee for a big core-system program meets once a month. The program manager walks through the status deck: milestones completed, budget on track, overall status green. There are a few questions about integration risk and whether the release date is still good. The answers are reassuring. The committee accepts the report and moves on.
A year or so in, usually around the start of integration testing, status goes yellow and then red. The committee gets a lot more involved. But by then the options are limited to pushing the date, cutting scope, adding people, or some combination of the three.
The committee had the authority to change course all along. What it didn’t have was information it could act on. Status was green during the months when there were still real choices, and it went red after those choices were gone.
Worse still, the IT leaders call what they’re doing “agile.” There are cross-functional teams, sprints, and user stories. The vendor has all the Scrum and SAFe certifications. But none of that, no matter how well it’s executed, really addresses the core problem.
The green status reports weren’t lying, exactly. No one was consciously hiding problems.
The underlying problem is that the work isn’t structured to reveal risks (and options) early.
And, as a result, green didn’t mean what everyone thought it meant. Green status sounds like “the project is healthy.” In practice, it means, “things are going the way we expected.” That’s not the same thing.
We make a distinction between work that’s complicated and work that’s complex. For the complicated, you can gather the data, analyze it and make a plan. Traditional project management and business analysis is optimized for this space. With complex work, you naturally learn about the problem and the solution as you do the work, so they require an experimental, iterative approach.
Some common sources of complexity:
- new technology
- new customer segments or markets
- new problems to solve
- anything that depends on the future preferences and behaviors of people
- dependencies on other teams or vendors
- integrating systems
- big problems or solutions that are hard to get your head around
- volatile external factors like weather, regulation, or fast-changing market conditions
The kind of big initiatives that get steering committees usually have a full menu of these factors. They’re highly complex.
But most project plans put the complicated work first and the complex work later. It’s partly a natural tendency to start with what you know and partly that the complex work often seems to depend on the complicated work, so that order feels logical.
The trouble is, the complex work carries both the lion’s share of the initiative’s value and the bulk of the risk. Saving that for later, defers impact and learning, often until it’s too late.
“But we’re agile. We’re doing PI planning and 2-week sprints.” Doesn’t help. Short iterations on complicated work just means more opportunities to tell yourself that things are going as expected. If anything, that makes the problem worse because it reinforces the illusion that everything’s fine.
The fix is this: Move the complex work first.
Test the key assumptions right away. Prove that the core value proposition works. Show that those systems can actually be integrated. Let the vendor demonstrate their solution does what their sales team claimed…in your environment.
Identifying and addressing the core complexity from the beginning lets you earn green on the status reports instead of assuming it.
With this approach, steering committees are enabled to actually steer. Tackling complexity early means discoveries happen early, while there are still options to respond.
Whether you’re in the middle of a multi-year initiative or just making plans for one to start in 2027, we can help you shape the work to resolve complexity as soon as possible. Schedule a free consultation with us to talk it through.
Last updated