They point at the need for foundations. A business case that sets clear objectives. Well-crafted requirements to transform these objectives into measurable deliverables. Estimates that are backed by some sort of reality. Roles and responsibilities. The right team. Risk management. Planning.
All good stuff. (And how rarely we have it all). But this list misses something. By the time we have any of this stuff, the project has long since started. A ‘project kick-off’ might still be useful, but it’s a reforming point, a pause for reflection, not a starting point.
In my experience, projects generally start with the spark of an idea. Someone picks up this idea and explores it. They build support for it – sell it to executives, test its feasibility in informal discussions with technical specialists, talk to suppliers about pricing, research the market.
Eventually they have wide enough buy-in to justify a little budget for further research and more detailed planning. They may sponsor a prototype or some customer research. A business case begins to emerge.
A good sponsor then uses this case to build formal organisational support. They can now start to go through the process of obtaining a project budget (with all the trade-offs that involves). They can assign a project team. This team then builds out all that other good stuff – the requirements analysis, the risk register, the detailed estimates and plans.
Somewhere along the way, everyone recognises that a new project has begun.
This process can take months, even years. The timespan isn’t necessarily indicative of the quality of the original idea – good ideas can fall on fallow ground, their sponsor struggling to keep them alive until fashion swings their way.
Weak ideas can capture the interest of powerful people, garnering lavish resources before they’re well enough framed to be exploited effectively.
From this perspective, project start-up isn’t about clarity and rigour. It’s about politics and negotiation, uncertainty and dogged persistence.
The iron triangle of project management – time, budget, scope – is far from fixed. We adjust it as we learn more about what’s possible, both technically and in the political context of our organisation.
And projects aren’t built on firm foundations. They’re built on fuzziness, on willingness to accept weakly understood risks, on the chance of winning great, but uncertain, rewards.
At some point in time we write clear objectives, firm budgets and specific timelines around all this. This fixes our attention on a single bright spot in a very fuzzy universe. Our project team then shoots for that star.
But the surrounding fuzziness never goes away. A good team is aware of this. They keep a constant watch for signs that the fuzziness is intruding. They’re prepared to change course as they learn more. They maintain lines of communication to the original stakeholders, regularly renegotiating objectives and resources as required.
To do this, they need to be told about the fuzz. The kick-off that pretends all uncertainty has gone, that deals only in clarity and firm commitments, serves them ill. It tells them little about the options and trade-offs that were explored in that long, ill-defined lead-in. It tells them even less about what scope for adjusting constraints and boundaries still remains.
More than this, our teams need to be given a mandate to renegotiate:
As you learn more about the market, check whether the product still fits its needs. As you learn more about the technology, check whether we’ve settled on the right solution. As you learn more about the realities of implementation, check whether the timeline and budget remain feasible. If not, come back and renegotiate.
Good project managers take this as read. Good sponsors support them to do so.
But most of us are merely average. We find it easier to struggle with intractable technologies than to step back and think about alternatives. Easier to pay lip service to the original objectives than to enter into tough negotiations. We need support to do the right thing.
For our projects to succeed, it’s not enough to kick them off well. Indeed, it’s almost impossible to kick them off well. They start out in fuzziness and ill-defined roles and political fudge. That’s the nature of projects.
Over time, we build clarity. We draw a boundary around the fuzz, help people focus on distinct goals. But this is often little more than a construct, a line we’ve drawn for convenience – the fuzz still exists in the technologies, markets, politics and risks that our teams must deal with.
Our projects would end better if we accepted this fundamental fuzziness in their beginnings.