I want to pick up on the previous post about shifting from a supply constrained to a value constrained business IT model. I think this shift in paradigm about the IT resource is one of the most critical for getting out of Level 2 and into Level 3 Business-IT Maturity.
In the lower stages of Business-IT maturity, initiatives get approved without much formality around business justification in the form of a business case. IT acts as order takers – “if the business wants it, we will build it,” up to the point (quickly reached!) where demand exceeds supply. At that point, we might set up steering committees and prioritization mechanisms, but in the end, it’s the project sponsors with the most clout who get their projects approved.
To get out of Level 1, most IT shops typically implement some kind of business case mechanism to put some formality around the proposing of IT investments, and to enable a more rational approach to prioritization. At first, the business case is all about helping to make the go/no go investment decision. This is better than the order-taking, or “squeaky wheel” model, but, frankly, not much!
At some point in mid to upper Level 2, the business case shifts from an approval/prioritization tool to a value realization tool. Formerly, you put stuff in the business case that you hoped would help get it approved, but you knew nobody would ever look at the case once approval was gained. There really was little to no accountability for the case, or consequence, or even learning that takes place about hte quality of the estimates and assumptions that went into the case. As a value realization tool, on the other hand, the estimates are taken very seriously, and accountability is now placed around achieving the forecast benefits. Of course, the ability to tightly link business benefits to a given project is very tricky in all but the simplest cases. It becomes somewhat more reasonable to link business benefits to programs, rather than to projects, as programs are, by definition, oriented towards business outcomes. (See earlier post on Projects, Programs, and Portfolios.)
Even then, the linkage of any given program to specific business benefits is tough. At low Level 2 Business-IT maturity, the challenge of benefit estimating and linking seems really difficult, so people shy away from trying. At higher Level 2, there is somehow an acknowledgement that it is tough, and that really we need to think in terms of cause and effect value chains, and “trails of evidence.” Moreover, the act of thinking this through (at business case development) and engaging the appropriate stakeholders in figuring out the cause-effect chains and trails of evidence is the real key – an act that in of itself brings better clarity, buy-in, ownership for the results (i.e., the value to be realized) and with all that, a better likelihood that the value will be realized. We will get more into this notion of cause-effect chains, and trails of evidence in a subsequent post.