One of my colleagues, Karen Rubenstrunk, is a principal advisor for our CIO Executive Program. I’ve known Karen for close to 20 years; she is a superior CIO coach. Recently, we found ourselves discussing the challenges CIOs have communicating business value. Here is Karen’s point of view:
If you’ve been around tech management as long as I have, at some point you’ve had the conversation that keeps on giving (like heartburn): how to better communicate the value of technology to the business.
Like me, I’m sure you’ve continued to wonder why we keep having this conversation over and over and over.
At a recent CIO Group Member Meeting, I found myself drawn into this conversation yet again — and being the lone dissenter in the room about what to do about it. While we kept talking about which new technologies or recent economic trends were making the task of communicating value so difficult, I’ve learned that the real problem isn’t technical, it’s personal: CIOs need to focus on perceptions and invest in the power of personal relationships with business peers.
Perceptions Drive Value
Technology’s perceived value to the institution is directly related to the maturity of the relationship between technology management and other functional managers and their teams, and that relationship is built on two fundamental perceptions: 1) the business’ perception of its dependence on technology, and 2) the business’ perception of technology management competence (see figure below).
Mobile device management is a fully commoditized market. In the strictest definition of MDM, the available functionality is limited to those application programmer interfaces that are made available by the operating system vendor (Google or Apple). There is very little that traditional MDM offerings can do to differentiate themselves from the other 100+ vendors in the market. This causes significant price pressure on the offerings. Value for MDM is rapidly approaching zero. As we have seen over the past year-and-a-half, core MDM component offerings have been continuously lowering their prices in an attempt to maintain market share. There is a transition by the major MDM players to expand well beyond the traditional "wipe," "lock," and "locate" concepts available to them into more advanced technologies such as content and collaboration systems, security components at the network and application layer, as well as partnerships and integrations with secondary market offerings. These features have value. MDM at its core does not.
I think it's about time someone came out and said it. Just like Dobby from the Harry Potter books, MDM should be free. I've been telling all of the vendors that I work with that if they don't put out their MDM offering in a freemium model very shortly, the other vendors will beat them to the punch. Traditional MDM offerings are a land grab for enterprise market share and should be used as an upsell or wedge into more advanced and differentiable offerings. I predict that in the next 6 to 9 months we will see most, if not all, of the leading MDM vendors giving away their core functionality.
Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. That is a totally different perspective from “I need to keep control of my team’s productivity to make sure that we stick to our estimated costs, scope, and project dates.” Of course, the interest in cost is never going away, but app-dev leaders today have a great chance to enhance their conversation with executives and business stakeholders and add value to the conversation.
However, as the recent research I just published, Agile Metrics That Matter, proves, while some of the most advanced Agile teams do use new progress, quality, efficiency, and value/benefits metrics (these to a lesser degree), some software development industry luminaries have worked and are working on new methods to measure value in software development. But it’s still early days!
I’d like to summarize here some good old practices on establishing metrics that count together with some of the new findings of the research:
I help hundreds of technology buyers each year to understand the impact of technology changes on their software contracts, but I also get questions from software providers about how best to price their products. Some are bringing new products to market and want to know how to maximize revenue, while others are struggling with obsolete metrics such as per processor and want to update their pricing for the modern mobile, cloudy world. The answer is usually to find licensing metrics that make their pricing value-based while balancing simplicity and fairness. The more value a customer gets from your product, the more they should be willing to pay for it. If you make your pricing too simple then you won't match value sufficiently closely, which will cause you to price yourself out of some deals and leave money on the table in others. If, OTOH, you try to match value too precisely you risk making your pricing so complicated that buyers will reject it, and you, completely.
For example, suppose you have a product that will help people do their jobs better, so you decide that charging for each user will be a good approximation for value. The potential problem is that not everyone will use your product the same, in terms of depth of functionality and/ or frequency of access. Your single per user price will be unfair to companies with long tails of light, infrequent users, for whom you'll therefore be too expensive. Conversely your pricing will be unfair to you when the customer is mostly power users. To make your pricing fairer you could have different prices for different categories of user, but then you risk being criticized for being too complex.
I just wrote a paper on the value of information security. Please see the paper here. It is something I have thought about for a long time. Information security as a technical discipline but someone has to pay for all this fun we are having. My assumption is that as Willie Sutton is quoted as saying "Go where the money is...and go there often.” Today where organized crime and nation states are going is to information. It is amazingly easy to monetize certain kinds of information. There is a buyer for everything that hackers can steal. The impact to business has been debated for some time and we go to great lengths to perform risk assessments. What we don't do such a good job of is monetizing that risk.
Consider this. If we can monetize the information asset, we should be able to monetize the risk to that asset. The key to monetizing risk is knowing the value of the asset at risk. Different systems for risk assessment have been in place for some time. They all seem to revolve around professional judgment. My argument is that using a combination of threat modeling (war planning) plus simple asset monetization will allow us to monetize risk. The results will not be perfect, but they should be directionally correct. As Doug Hubbard says it is better to be directionally correct than specifically wrong.
There is no doubt that Agile growth in the market is significant, and the growing daily number of inquiries I’ve been getting on Agile from end user organizations in 2012 gives me the impression that many are moving from tactical to strategic adoption. Why’s that? Many reasons, and you can read about them in our focused research on Agile transformation on the Forrester website. But I’d like to summarize the top five reasons from my recent research “Determine The Business And IT Impact Of Agile Development” :
Quality was the top — quite astonishing, but both the survey we ran across 205 Agile “professional adopters” and the interviews across some 21 organizations confirmed this. My read is that this is about functional quality.
Change was second to quality. We live in an era where innovation strives and organizations are continuously developing new apps and projects. But your business does not necessarily know what it needs or wants upfront. The business really appreciates the due-course changes that Agile development allows, as they enable the business to experiment and try out various options so it can become more confident about what is really right for the organization. Cutting edge cutting edge systems-of-engagement (Mobile, Web-facing, Social-media, etc) require lots of Change in due course.
I’m a sucker for good, biting humor, and in the spirit of Stephen Colbert’s Medals of Fear that he gave to a few distinguished souls (the press, Mark Zuckerberg, Anderson Cooper) at the rally in Washington D.C., I would like to hand a medal to the U.S. State Department for its 1999 publication of a country-by-country set of "Y2K" warnings — “End of Days” scenarios and solutions — for Americans doing business in 194 nations. I would give another medal to IPv6, the most drawn-out killer technology to date — and one that has had the longest run at trying to scare everyone about the end of IPv4. At Forrester, we are starting to see the adoption freighter slowly turning via the number of inquiries rolling in; governments accelerating their adoption with new mandates; vendors including IPv6 in their solutions; and the Number Resource Organization escalating its announcements about the depletion of IPv4 addresses (only 5% left!). To add to the drama, vendors are in the process of creating IPv4 address countdown clocks to generate buzz and differentiation. These scare tactics haven’t worked because technology pundits haven’t spoken about IPv6 in business terms. There is enormous business value in IPv6; those who embrace it will be the new leaders in their space.