Where does the business value go?

Every IT project delivers new or adapted functionality that helps the commissioning organization to perform according to their own ambitions and standards. This performance can be measured quantitatively and/or qualitatively. The customer support team uses one or more IT systems that help them help the customer in a way that results in a good customer satisfaction mark, in customer retention (which usually is cheaper than customer acquisition) and in new customers via positive mouth-to-mouth advertisement. Therefore, it makes a lot of sense to validate each project proposal (in agile terminology: epic) with a business case. A business case provides the value-focus on change. Which performance improvement do we pursue, measured in metrics that reflect the current (as-is) and the pursued (to-be) business value, or in short: the benefits. Who are the stakeholders, and how important are these benefits to them? What alternative solutions are or can be made available for realizing these benefits, and which solution serves the stakeholders best? And what are the disbenefits of that solution? During the project start-up, many things are still uncertain. In the business case, these uncertainties are handled as assumptions. Over time uncertainties may become certainties or the other way around. By maintaining the business case it remains possible to steer the project towards maximum benefits realization, or in other words: the project delivers the most valuable result possible. And the business case guides the implementation of the project result, so the usage of the project result leads to an optimal realization of the pursued benefits. So, it’s quite stunning that no business cases are being developed for many projects, and that the business cases that are being developed in many cases do not contain the aspects mentioned above, but only reflect the cost of the project and some indication of foreseen financial benefits. Also, business cases are often not maintained after the project has been approved. And, generally, business cases are not shared with the teams that develop the solution. So, then where does the business value go that needs to be improved with the project result? If the business case owner is lucky, alert and/or represented well by other people, the business value improvement is integrated into the architecture and the design of the solution, thus becoming the implicit value compass of all other project activities such as building, testing and implementing. In all other cases, the project quickly turns into a slot machine. Every week money is invested, but you have no control over the return of that investment. And when, by the end of the project or later, the question rearises if the project result is enabling us to realize the benefits, the answer in many cases is: partially, but we also have functionality that we don’t need (anymore) and the necessary functionality doesn’t enable the pursued value creation as much as we expected it would. According to many, the silver bullet solution for this is to work according to the agile philosophy. Because the agile teams define the pursued business value for each sprint. However, agile teams that are not being equipped with the business case information, cannot work wonders on behalf of the business case owner. Often, they must work with the alternative to the business case: the implicit business case. This means the business case owner knows the benefits she pursues and doesn’t (let someone) put this into writing but shares it verbally. That information is bound to be incomplete every time it is discussed, and changes to what has been said before cannot possibly be shared with all people involved. Also, all of this information is bound to be ambiguous. So, if you are not a gambling person: (let someone) develop the business case of the project!