A few weeks ago, someone brought my attention to an article from Robert Naegle, Research VP from Gartner, asking what my thoughts were.
The article is entitled 7 Rules for Demonstrating the Value of IT. If my interpretation is right, the article’s intent is to help IT executives develop a compelling story about the value of digital initiatives—in other words, how to gain buy-in and investment money from non-IT business stakeholders for technology initiatives . The goal is indeed laudable since many technical initiatives have very little business appeal.
So I looked at the seven suggestions, and they triggered a few reflections, which I share below. Be warned, however, that these thoughts are often distant from Gartner and Naegle’s intent. My plan is to invite you to think much deeper…
Rule #1 – “Remember that the IT stakeholder always determines value”
This rule hammers the fact that the business stakeholder that finances the endeavour is the owner of the resulting benefits of the digital investment. What is interesting in this proposal is this sentence : “IT stakeholders and consumers, not the provider/producers, determine what is of value.” This was a thought-provoking sentence for me, as I explain below.
Nobody Own the Systems
Yes, the value is provided to the one who pays for it and thus should be identified by them. If a highway, commercial building or residential house is built, the value is for whomever asked for it. That’s the way it works in most fields. Taxpayers want to travel faster, promoters want rental revenue from commercial floor space and a family wants a happy nest. But what about ownership of what is built? Highways are the property of the people through constituency. Commercial buildings and homes always have an owner. What’s missing in most organizations where a single IT department is the provider of all digital-related services is a clearly defined owner of the information system asset. In my book, I describe in more detail the conflict of roles in corporate IT, taking the construction industry as an example to show that those who built something are not owning it—and that’s healthy. The issue in all organizations I’ve dealt with is that ownership is far from clear. Business people pay for digital systems and surely use them, but they feel that, since the beast was created by IT people, they kind of own those. IT people, on the other side, know they must maintain the beast, enhance it and ensure that it operates correctly. But since business people asked for the beast and use it they are the ones that kind of own it. Within such a weak responsibility model, only one thing is sure: these creations are not managed as assets.
Provider in the Great Divide and Cost Center
The statement reminds us that in the model in place in most organizations, not only is there a clear division between IT People and Business People, but it also implies that the IT part is viewed as a provider, a team of geeks at the service of the organization. In my series of podcasts called Radical Change in Corporate IT, eight out of nine interviewed experts stated that if anything has to change, it’s the great divide between business and technology. That’s 88% of them. But IT being at the service of the rest of the organization has more insidious effects: it makes the whole IT organization a cost centre. This is not just an accounting detail. It has a profound impact on behaviors. Being dependent on yearly budgets—like any other cost centre—makes getting money a central concern for IT people. That’s why IT people are very good at getting money, spending it and reporting on spending, but mediocre at best at understanding value and creating it. That’s why Gartner wants IT people not to forget that “[the] stakeholder always determines value.” How could it be otherwise?
The author further confirms the provider status of the IT arm by reminding that “[…] IT is likely to stay focused on delivering technology or platforms[…]”. When your mission is to deliver technology –based systems and that your main performance measures are to deliver on-time and on-budget, understanding business value is bound to be distant from your core competencies.
Rule #2 – “Note that all outcomes are not equally valued.”
It is sound to remind ourselves that not all digital initiatives have the same business payback and thus, they should be assessed from that angle. That’s a wise business reflex. The sentence “[…] rank their business priorities…then align IT resources to deliver the prioritized outcomes” is also a reminder of the point made above that IT is often viewed as a provider of technology, not value.
Rule #3 – “Build two value narratives, for operating and transforming.”
This a very important distinction to make. The operating side of IT is very different than the change side. As such, different metrics must be applied. The nature of the two halves of corporate IT is such that the operating side has benefitted from increasing standardization over the past decades, to the point where performance can truly be benchmarked and compared between organizations. This has led to the progressive externalization of services where only the highly customized services are still sourced internally.
An important difference between the two sides of corporate IT is that the operation half is well measured, and always quantitatively. Standardization of services leads to externalization, which leads to standard measures of performance, which are used to compare providers. It creates a virtuous spiral of performance improvement.
For the change side, the eternal “on-time and on-budget” continues to reign as the only quantitative measure of achievement. Again, that’s not surprising since business value is a measure that the IT arm is unable to gauge with hard numbers. It’s risky to externalize a service that is not well measured: if it wasn’t measured before externalization, what performance can you ask for? The corollary is that if it isn’t measured, it’s probably not performant.
Rule #4 – “Measure IT’s impact on stakeholders’ objectives, not IT effort expended or resources consumed.”
This rule is further detailed as “Measure IT’s impact on mission or contribution to business outcomes and avoid metrics that communicate effort, work or technical output.”
Good luck with this one. This fourth rule seems to be based on fallacious interpretations of the nature and competencies found in most corporate IT teams.
How can the “impact of IT” be measured? Could it be something like 50% of the objective attainment was provided by IT? What about 100% tech projects—would that be measured as 100% of attainment of a business objective that is often not understood by business stakeholders? How would you measure the fact that on a given project, business objectives have been attained 6 to 12 months later than expected because of IT project delays? Would that be a negative impact on the year-end scorecard? Until impact can be measured, the best we can do is to piggyback on business objectives. At the end of a project, IT would declare victory, having had a “positive impact on achieving this or that.” And if the business objective is not reached, then what? IT would probably refer to a “great collaboration” despite a business goal that wasn’t achievable.
Although I am in complete agreement that effort, work or technical output are often inadequate measures for non-tech stakeholders, they are nonetheless the only things that IT stakeholders know how to measure quantitatively. They will continue to diligently gather data on these items because that’s what they do. Additionally, since business stakeholders do not understand what the work really is or if the output is big or small, excellent or mediocre, they will continue to ask for universal measures they can grasp: money and time.
Rule #5 – “Align IT costs to the business services they enable.”
I couldn’t be happier to see organizations where “ […] IT costs are linked to the business services and capabilities that IT delivers.” It is however a non-trivial task to collect project and operating costs and assign them in a fair manner to the right capabilities. It is in the nature of digital systems to often spread across many business areas.
Organizations over the years are building systems that often have a total cost of ownership in the hundreds of millions of dollars. Despite such huge investments and a lifecycle than spans decades, it is hard to find the true business owner of these assets. Once the cost-gathering is aligned, and not only to capabilities and services but also digital assets, organizations will be in a much better position to implement asset management practices of the same rigour found in other areas. Think of highways, hydro power plants or commercial aircrafts: they are assets and managed as such. For more on this subject, refer to this article.
Rule #6 – “Communicate IT value in the language of the stakeholder.”
I cannot agree more. The world of computers and programs is very, very hard to understand if you haven’t been educated in software engineering, computer systems and the like. Everything is virtual. All interactions ultimately occur in the guts of microchips under the form of minute electrical impulses.
But it is not the responsibility of business stakeholder to get an IT education. For computer-related things—as well as any other field of work for that matter—conveying the meaning of technical concepts in layperson’s terms is the responsibility of those that hold the tech knowledge.
This is not an easy task and sometimes requires lots of imagination to find the right imagery or analogies. But it can be done, and technical staff can be educated on how to communicate technical information in understandable ways.
Rule #7 – “Ensure those who fund IT understand its contribution to their objectives.”
This rule title is somewhat misleading with respect to the content. The author rather writes about engaging “[…]economic buyers early in the value definition process.” And “Make spend justification and value definition a collective effort between IT and key stakeholders.”
It is common wisdom to make sure that investment decisions aren’t made in a vacuum. All organizations I’ve worked with have an investment technology process in place with similar objectives but much variation in the depth coverage and tools used. This triggered a few additional thoughts.
Given the astronomic amounts of money that organizations spend each year in IT, isn’t it time for the adoption of a cross-industry standard for digital investment governance? I’ve been close to these investments in five different industries, and although the technical work being done is highly variable, the process for identifying, qualifying, costing, evaluating and monitoring digital projects and investment remains the same. Best practices adoption would not hurt. Furthermore, when a critical mass of organizations use the same standard, it opens the door to benchmarking. Wouldn’t you love to be able to compare notes about your digital investments with others using comparable measures?
Collaboration is the key point behind this rule. Conversely, the divide between “business” and “IT,” especially when the latter is organized into a single-counter model, is one of the greatest impediments to effective collaboration. As suggested in this article by Joe Peppard, the whole idea of an IT department that serves the rest of the organization should be questioned.
I believe it should be radically changed.
Final Thoughts
One last observation I have on the article is focused on the following declaration: “Gartner predicts that through 2027, CIOs who implement these seven rules will be 75% more successful in elevating their strategic contribution to their organizations’ missions and increase approval rates for funding requests by 30% over current levels.”
The use of such numbers suggests that Gartner collects data on something as elusive as the “strategic contribution” of CIOs. The best they might do is to survey CIOs’ own perception of their strategic contribution, which is a very different thing. The prediction also suggests that there is a causality relation between the application of these rules and strategic contribution—which I doubt very much has ever been demonstrated.
For a deeper dive into these subjects and many more, I invite you to check out my book or follow my master class, 12 Truths About Corporate IT. Or just email me; it would be my pleasure to hear from you.