I was reading an interesting discussion on LinkedIn titled What are the TOP reasons that explain Failed I.T. Projects? and the answers seemed to cluster around issues of requirements, scope creep and such.
I think the an answer is that at the outset projects don’t define the correct metric for success – a metric I’ll call “Time to Money”. It is a way for a team to think about what the are doing every step of the way and a criterion to differentiate between different alternatives. It is different from “Time to Value” as outlined in Nello Franco’s post, but in lots of ways quite similar.
The only thing that matters for a software project is whether people will “buy” the result, and how quickly you can get to a result they will buy. For commercial end user projects this can be measured in actual currency, for other projects “buying” means that users are willing to expend their time and resources in order to use the results from the project.
If no one will “buy it” then the project has failed. I use the term result since the the end result of a project isn’t always a product, but if it makes it easier just replace the term result with the term product.
I think this is a great metric to use during every phase of a project. If the team really focuses on the “Time to Money” then it will have a successful project and will ask itself the right questions every step along the way – e.g.What do we need to make it as easy as possible to buy the result? How do we turn users to be evangelists? Will an additional feature cause (more) people to buy the result? Will a delay effect the number of people that will buy the result? and so on.