Recently somebody asked on a forum “when is Scrum not working?” This lead me to the question “when is a project successful?” Traditionally, you can measure the success of a project by checking the respect of the scope, schedule and budget at the delivery of the application. In this situation, the burden is more on project managers and developers: they have to estimate the user requests and deliver on these estimates. This requires the mostly complete definition of the requirements at the beginning of project. Every change is the subject to negotiation as it could cause a change in either the budget or the schedule. In this situation, people might be more judging the capacity of people to estimate… or better to protect themselves from unexpected problems. I am sure that many of you have heard: “Take your initial estimate and multiply them by two before communicating them to your project manager or end-user”. A more business-oriented definition of a successful project is based on the delivery of value, the faster the better. In this case, the success of a project could normally be assessed only after the delivery of the application, assessing its return on investment (ROI). The concept of business value might be also implicitly present in the traditional project approach, but its mindset is more strictly focused on the project management results than the creation of value.
Besides this theoretical framework, the concept of value is often not really considered in software development approaches. Developers might have to estimate each feature, but you rarely see estimates for the value of the feature. The user story format “as a… I want… so that I can…. ” could add a “for a value of… ” that could improve the visibility of a project. An estimate being an estimate, they should be checked with the reality 3,6 or 12 months after delivery. I am sure that not many of us have witnessed this type of validation in their company. To be honest, this is also because it could be difficult to distinguish if an increase in sales is due to the revamping of a web site or a clever marketing campaign that was run at the same time. There are also many ways to define the value of a project. Twitter could be considered a successful software product and the company valuation is supposed to be defined in billions, but its profits so far are currently lower that the venture capital invested in it. Should the value of Twitter be based on the price you can sell the company stock or on its current ROI?
Aside of the raw numbers, human factors are also important for the success of software development projects. Project managers know that it is better to optimize value than trying to maximize it. Before the project, you have to buy the approval of all stakeholders. This might lead to include in the scope some content that could have limited business value but is considered as a “pet feature” by a powerful manager. In large organizations, to ensure end-user acceptance and avoid that the software will be used as the scapegoat for fighting organizational change, you have to define the scope around what could be accepted by employees and not always only on what you think could deliver the best business value.
All these practical issues with defining value will make it always easier to judge a project on its own “hard” budget and schedule numbers. This shouldn’t prevent to introduce the concept of value during its planning phase, especially when you have to discuss the scope of the project and in which order requirements should implemented.