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.
There are two types of project failure. You need to manage them differently.
Projects fail. Lots of them. We don't really know how many, as the statistics vary widely. And most of the statistics are pretty dubious.
They’re gathered using questionable sampling methods. They define failure ambiguously.
And their authors generally have a vested interest in talking up failure rates. They sell solutions to avoid project failure. If there weren’t many failures, they wouldn't have a job. (I call it the project failure industry. hey need to create the perception of failure).
Nonetheless, I think it’s fair to say that lots of projects do fail.
The best time to review a project is probably months ago, when all seemed well.
It doesn't look good. The project has missed a major milestone. The team is working seven-day weeks. The project manager is off with stress-related illness. Quality has gone out the window.
And as for our customer, not at all happy.
We need to find out what’s really going on. It’s time to schedule a project review.
Managing complexity is tough. Especially if you can't agree on where the complexity lies.
Sometimes decisions are easy.
You have the data you need. You know what you want to achieve. You know how things work – if we do this, then that will happen. So you connect the dots, make the decision, and all is well.
Make the same decision often enough, and you’ll define a standard, even a 'best practice'.
People talk a lot about agile processes, but it’s the agile decisions that really count.
How does your organisation make decisions?
This is a dangerous question. I’ve asked it a lot recently, and got some unprintable replies.
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.
Product and service development is all about risk. We take on a range of market, design and technical risks in order to gain rewards – new products, better conversion rates, increased market share, improved margins, etc.
Sometimes, however, the risks win. Projects fail for a whole host of reasons: our aspirations run ahead of the technology; we fail to find a commercially feasible solution to design challenges; our competition beats us to the punch. The list is almost endless.
And too many items on that list are entirely manageable. Poor internal communication. Ill-defined scope. Failure to engage key stakeholders. Unrealistic estimates. The project management literature has been calling out such risks for decades.
We know how to solve these problems. We just don’t do it.
That’s the real failure on many of our projects: we fail to see and manage the basic stuff.
Project 'failure' is political. It’s about power. People with power get to define budgets and deadlines, to approve specifications, to assign teams. Thus they define the boundary between success and failure. Go outside the boundary, and your project fails.
The problem with politics is that it fuzzes our vision. We tend to see what we want to see rather than what’s really going on. That means we miss the early signs of failure.
And that, of course, increases the risk of catastrophic failure. If you spot the early warning signs, you have time to fix things before they become critical, before problems propagate. Miss those signs, and you sail blithely across the boundary of failure, never to return.
So it’d be nice to have some clear indicators that my project is heading into trouble. I can’t give you a magic formula, but here are some of the signs that make me nervous:
Insurance premiums are a source of information: they tell us a lot about the real risk level attached to an activity.
What’s the difference between a project and a bungee jump?
They’re both a leap into the unknown. But at least you can get insurance for the bungee jump.
There are two types of project failure. Failure due to inherent risk is OK: it's the other side of the risk/reward trade-off.
Our real problem is all the unnecessary failure that surrounds our projects.
Projects don't come about through some law of nature. They're a mental construct we've created to help ourselves manage our work.
I spend most of my time on projects.I’ve worked on projects to build e-commerce systems, projects to build and update websites, projects to create new products, even projects to define the way we do projects within an organisation.
The idea of a project as the fundamental unit of work is pretty pervasive within our industry. Many organisations structure themselves almost entirely around the portfolio of projects that they are undertaking.
And a large industry, think of PRINCE2 and the PMI and various other project management bodies, has emerged solely to service the interests of projects and project managers.
But how real are these projects?