{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

Our projects would end better if we accepted the fundamental fuzziness in their beginnings.

Projects often end badly. They go out with a skyful of fireworks, finger-pointing and blame. Why doesn’t the site perform adequately?  Where’s all the functionality we expected? Where has all the time, and budget, gone?

Some people say this is because we start projects so poorly.

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.

Graham Oakes

Published 3 January, 2014 by Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is contributor to Econsultancy.

43 more posts from this author

Comments (2)

Neale Gilhooley

Neale Gilhooley, MD at Evolution Design Ltd

Good points made above. In the desire to win a pitch/tender it is all to easy to do more than you ought to and start giving away the business which is just ever more free consultancy if the project does not actually take off.

Also it's easy to please the Client and make changes and additions without giving a concrete additional cost.

During rush projects the priorities change and at the end the Client can forget the do it now/at all costs panic, later to revert to invoice checking mode including the not on the purchase order query.

almost 3 years ago

Sarah Alder

Sarah Alder, Managing Director at Cranmore Digital Consulting Ltd

What a great post Graham, thank you. It might turn out to be one of life's great unanswerable questions - when does a project actually start.

All those discussions, casual conversations, they create an impression of "the project" and it's very easy to get to a situation where something that was discarded early on is still seen by some people as "the benefit" the project will deliver. I thought the post was worth reading for that alone but then when I read the last section about embracing fuzziness I thought that was an even better point.

Projects are hard work, but taking the time to reflect a little on the processes is really useful. Thanks for doing that and for sharing it.

almost 3 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.