There are several reasons why many IT initiatives fail, and one of the key reasons is that intangible benefits are not included in the business case, hence they are not measured during and after implementation. Using the 80-20 rule, intangible benefits generally represent 80% of the economic and strategic value of IT portfolios and initiatives. Nonetheless, IT executives are usually reluctant to add intangible benefits to the justification of an IT project, since the realization of this type of benefits many times depends on several external factors such as market behavior and economics, or internal factors that are not under the control of IT.

Understand the Magnitude of the Benefit

The first key to realize the importance of adding intangible benefits to the justification is to understand the magnitude of each of these benefits. How many business areas use applications developed and maintained by IT? How many application errors will be reduced through good communication and collaboration between Dev and Ops? How much downtime do users currently experience from application errors? The result of these and other related calculations will certainly be a large number; therefore the magnitude of such a benefit, yet intangible, justifies its inclusion in the business case.

Identify Causes of the Benefit

It is true that there are many other factors (internal and external) that will affect business productivity, following on our example of a DevOps intangible benefit; however, it can certainly be influenced to a high degree by the work that is done between Dev and Ops, as the outcome of this relationship is a key input to the business areas. For this reason, the agility and collaboration culture enabled through DevOps will be a cause for achieving the effect—the realization of the intangible benefit that no one wants to commit to.

Identify the Benefactors

Who will be responsible for the cause? Now this is something we can measure and commit to! It is possible to identify the stakeholders who will be responsible and ultimately accountable for ensuring that the flow of information between Dev and Ops meets the projected goals, (and for ensuring that software releases are deployed in less time, and the list of causes can continue), and we know that if this is achieved, the effect—increasing business productivity—has higher chances of being achieved. There is indeed some uncertainty in the relationship between the cause and the effect, but this uncertainty by no means prevents the identified causes from having some impact on the effect.

Manage Organizational Change

Once the stakeholders responsible for the causes are identified, the next step is to make them accountable for those goals. At this stage many people will show resistance, which is normal in every project, and it’s nothing more than resistance to change. Bringing people together and making them accountable from the start of the project will make resistance to change evident and that will provide an opportunity to manage that change.

Measure the Causes Towards the Benefits

The last link in the chain is to define metrics (SLAs) and measurement methods that will provide you with reliable information about the achievement of the goals (causes) that, if met, will most likely lead to the achievement of the intangible benefit.

History has shown that a good number of IT projects fail to realize the expected business value. Now, and in the future of the digital age—with agile, innovation, IoT, and digital initiatives—unless intangible benefits are estimated and measured, a higher percentage of projects will fail to realize the expected benefits.