Definition Of Project Failure

Lots of wiki topics, like DeathMarchProject and XpFailures, talk about "failed projects", and there is a lot of literature indicating that the majority of software projects are "failures".

What constitutes "failure"? How can I tell if I've been part of a failed project? I've been involved in several projects that (a) went over budget, (b) were delivered late, and (c) didn't make the customer happy. But I've never heard any of them actually called "failures". Our company is still in business, everybody gets bonuses and raises, and the customers keep coming back.

--KrisJohnson

Well, it could be considered that the DefinitionOfProjectFailure is the opposite of the DefinitionOfProjectSuccess. --RandyStafford

Another definition - The company lost 20 million (They had planned on making 120 million, but they only made 100 million!)

A lot of literature seems to regard failure as any cost or schedule overrun, or feature/capability/spec not delivered to the customer. A project that is a day late, but ships (and makes money) is treated the same way as a project which blows out the schedule, gets cancelled, and never realizes a dime's worth of revenue (or improved productivity, for in-house projects). Usually, the folks promoting this definition of failure have some SilverBullet to sell...

A couple metrics for project success/failure. Some are binary, some are quantitative, some are qualitative. Many may be influenced by outside factors. Some are not direct indicators, but probably have a strong correlation.

Actual development time vs. projected development time.
Actual cost vs projected cost
Project deployed/introduced, or cancelled?
Revenue, profit, or productivity gains realized, vs projected
Customer/user satisfaction
Affect on reputation of company/department/project team
Were project staff rewarded (promoted, given bonuses), punished (sacked, demoted, given paycuts), or neither?

Often, perception changes over time. One project I worked on was, when it shipped, regarded by management as a failed project. Several months late, and over-budget, and with some initial quality problems. Quite a few team members were LaidOff (not directly due to the project--the layoff was imposed due to budget constraints--but the project team bore the brunt of the layoffs within the department), and the ProjectManager was pressured to resign (which was a great loss for the department, in my humble opinion).

But guess what? The product is a hit with customers, and has been a key moneymaker for the department. Management opinion of the project seems to have softened quite a bit.

Product success is not the same as project success, then. I've seen the reverse a number of times -- the project was regarded as a success, delivered in acceptable time and cost etc, but the product of the project didn't realize the benefits. Otherwise known as "the operation was a success but the patient died." I've met project managers who genuinely think that the role of the project manager is merely to ensure the operation succeeds.

Many corporate project structures encourage that thinking. In many places, a project ends when it is deployed/transferred to manufacturing, etc. Further work on the product either a) requires a new project, often with its own C/B analysis, or b) is performed by a separate "service" or "sustaining" department. Even in more "enlightened" corporations, the project team is off the hook at some point--after all, the people who do one project are needed for the next project.

Another factor is that the successful execution of a project, from design to deployment, is largely under the project team's control. Success in the marketplace, on the other hand, is highly dependent on many different factors (the economy, the competition) which are wholly beyond the project team's control.

Engineering Principle #12: Nothing succeeds like success. In other words, it's not really a success if you have to redefine the objective. A project that's late, over-budget, or fails to deliver the promised product free of errors has not met its objective -- it's a failure. After fixing the "initial quality problems", the product may perform well enough to be successful, but the project itself was still a failure. The development team can't take credit for the product concept. --MarcThibault

On the other hand, what if the original goals were overly aggressive or impossible, and the stakeholders changed the goals upon realizing this? There are many example of projects which are a net positive to the sponsoring organization, but which had cost overruns or schedule slips. Success or failure? Probably depends on whom you talk to.

On one project I was recently on, the project was well over budget and nearly half a year late. After it was done (even before it was done), several folks around here lost their jobs. The product that was developed? It's one of our biggest sellers and a most reliable CashCow?. Sometimes, a project can both succeed and fail.

Well, it's reasonable for project managers to think their role is just to make sure "the operation succeeds." It's all anyone asks of them.

A project manager who lets himself be brow-beaten into an impossible situation needs to find another vocation. I've taken on the odd dragon-slaying, but it was voluntary, knowing that I had a team that would walk on water if the stakes were high enough.

I've been a marketing manager and there's no way I'd let engineering second-guess me on features. I've also been a R&D manager, and if my management wanted something built, and it was feasible with the time and resources available--that's what they'd get. If I thought they were insane, I'd tell them so, but unless they stopped me, they got what they wanted, on time and on budget.

This takes us to Engineering Principle #1: The truth comes out in the product. Sometimes the truth is that we should never have built the product. --mt