When I started out as a project manager on UK government projects in the early 2000s, we had a list. The Office of Government Commerce had published eight common causes of project failure. Every project was expected to be checked against it before it began. Was there clear ownership at a senior level, with enough authority to make decisions? Were the right stakeholders engaged, including the ones who could cause trouble later if they were left out?
What it didn’t include was complexity. Checking a project against the list wouldn’t prompt you to ask whether it was complex, or what that might mean for how you planned it.
What makes a project complex?
Since then, complexity has been recognized as a factor in whether projects succeed. The Project Management Institute (PMI) published a practice guide on it in 2014.
It’s worth being clear about what complex means here, because it isn’t the same as complicated. PMI describes a complex project as one with lots of parts that depend on each other (tasks, people, technology, pressures from outside) and that interact in ways you can’t fully predict.
A complicated project can be solved with enough effort, expertise and resources. A complex one needs you to notice what’s changing and adapt as you go.
That difference matters more now, because complex projects have become the norm. Earlier this year, PMI surveyed project professionals about the work they’re leading. Almost all of them (97%) had managed at least one complex project in the past year. 81% said their projects are becoming more complex.
Nearly a third of complex projects (31%) didn’t deliver their full intended benefits, more than twice the rate for projects overall.
Complex and complicated projects need different thinking. If you plan a complex project as though it’s only complicated, you can do everything carefully and still get it wrong.
A carefully crafted plan that couldn’t work
On my first big project, I planned a nationwide rollout of a new system after a much smaller pilot had gone well. I assumed the full rollout would be the same as the pilot, only more complicated. So I planned it carefully: region by region. The implementation team moved across the country, training staff and managing each go-live as they went.
What I hadn’t understood was that offices in each region shared staff to cover vacations and sick leave. Training everyone in a region at once would have left those offices unable to function for weeks. The pilot had been too small to show that. The first steering committee to review the plan immediately pointed it out.
The business gave me someone who understood how the offices actually worked, and we started again. The new plan had teams criss-crossing the country and doubling back. The last office to go live, twelve months later, was in the same region where we’d started.
What made my assumptions hard to catch is that they didn’t look wrong. The pilot had gone well, but it could only tell us about the conditions it ran in. I didn’t think to ask anyone who knew how the offices worked, because I didn’t know there was anything to ask. Even when the problem was pointed out, it didn’t make sense to me at first.
The deadline didn’t move. It was still 101 offices in twelve months, which would have been far easier if we could have rolled out across the country in a single wave. Instead, every cost, every staffing assumption and every dependency had to be worked out again. We needed a much larger implementation team. Those teams then needed to cover for each other through illness and leave, just like the offices did. We hit the target, but only just.
When the plan needs to change
Most of us plan from what has worked before. That may be whether a pilot, a previous project or the way something ran in another part of the organization. That experience is valuable, but it can only tell us about the conditions it came from. When the conditions change, some of what we’re planning around becomes an assumption. We often won’t know which parts until something doesn’t fit.
On a complex project, new information will keep turning up, and the plan has to change with it. My first plan was thrown out, and the project was better for it. Projects get into trouble when new information is set aside to keep things on track. Or when people keep quiet because changing course feels like admitting failure.
If you lead or sponsor a project, how your people handle that moment depends a lot on how you respond to it. If you treat a revised plan as a setback, people will hold on to the old one long after it has stopped working.