Definition Of Project Success

The best DefinitionOfProjectSuccess I've ever heard is attributed to AlistairCockburn: "the software ships, and if they had it to do over again, everybody would want to everything the exact same way." (Forgive me, Alistair, if I've bungled the quote.) -- RandyStafford

One may never work on a successful project. It's hard to imagine wanting to do something the exact same way. There's always something to do better. If the customer buys it and doesn't return it, that could be termed success at a company level. At a personal level a different set of criteria is used.

These are the definitions of "success" and "failure" used in an informal SoftwareProjectSuccessSurvey:

Unqualified Success: The software went into production use by its intended end users and was valued. If it was a product, it sold. The quality was sufficient, the delivery timely enough, and the cost in control.

Qualified Success: The software went into production use or sold, but was not valued highly or did not sell well. Abandonment of the software by its users occurred or was likely. The quality, development time, or development cost left something to be desired.

Failure: The software was never delivered or sold. The project value did not justify its cost to its sponsors.

Another Measurement: The software is still in use by someone other than you more than two years from its first ship date. Even by that generous measure, we might be surprised by the proportion of failures we've all worked on.

Enabling Success: A software project that is never delivered or sold can be an unqualified success from several perspectives. If it attracts investor interest and cash, enabling a startup to drop the prototype and "do it right".

If you would do the next project exact the same way as this one, this means you haven't learned anything from it. Don't let that happen!

They say you learn more from failures than from successes, but successes can be learning experiences as well. Proving that a new idea does work is at least as valuable as learning that it does not work. Recognizing the value of failures is important, but when people start saying that their "failures" are really "successes", then they are being very silly.

The definition of unqualified success above is one that would probably not satisfy all project stakeholders. Some factors that would qualify such a success are:

Will our organization get repeat business from the customer?
Is our organization getting good word-of-mouth from this project?
Did we advance the organization's or the industry's state of the art?
Is the product better than that of competitors?
Was anyone killed or seriously injured?
Did any key personnel quit or burn out?
Did we get better profit from this project than we would have by devoting the resources to other projects?
Is the software maintainable and extensible?
Have any political or marketing problems arisen?
Is the result a net good for the whole world or advancing another higher purpose?

On a personal level, my definition of project success is based upon these criteria:

Did I have fun?
Did I learn anything important?
Am I proud of my work?

If I can answer "yes" to at least two of the three, it is a personal success. If not, then I probably didn't use my time wisely. -- KrisJohnson

I have a very strict DefinitionOfProjectSuccess, somewhat based on Alistair's quote at the top of the page, and a lot based on Alistair's theory of SoftwareDevelopmentAsaCooperativeGame. It helps if you pretend you have a time machine.

The project DeliversValue? to the person or organization paying for it. They wouldn't travel back in time and fund a different project instead.
The project doesn't degrade QualityOfLife for the people involved in producing it. They wouldn't travel back in time and transfer to a different project.

-- JimLittle