Recently a canvasser for a charity rang the doorbell and after introducing himself and thanking me for being a past contributor, immediately went into a detailed review of all of good works his organization had done in the community in the past year. I eventually interrupted him and asked about making a contribution this year. Transaction completed, he went on his way, happy that he had received another year of support. Everything worked as it should — or did it?
I contributed in spite of his pitch because I knew and understood what the value of his organization was. Until I interrupted him, he was giving me a data dump, without thinking about, or asking, what information I might be interested in and whether I really wanted a detailed discussion on my doorstep on a cold winter’s day. All he needed to do was to ask whether I was interested in continuing my support and what information I needed to make and support that decision. He came perilously close to not getting my donation by focusing on what he saw as the value of his organization, ignoring what I would see as its value in addressing my needs and concerns.
Establishing the value proposition of how IT enables and supports the business is an ongoing challenge to get executive buy-in for IT as a means of production rather than as a cost centre. The past couple years of recession and the need for belt tightening have amplified this issue. The current emphasis on innovation is one example of the ongoing search to define how and what IT can do to prove its value as an active contributor to the corporate bottom line.
How are you communicating IT value to your business leaders? In that last business case (presentation, report, lunchroom chat), was that list of benefits tailored to the business unit’s concerns and aligned with overall corporate objectives? If the list of benefits in the executive summary was longer than three or four, you’re diluting the very value you’re trying to sell. Obviously a business case has to cover, at some level, issues that impact the organization as a whole; that’s what the appendices in the back are for. The fear that a business case won’t be perceived as complete or having received sufficient thought and planning is leads to trying to cover every base up front. Providing too much information doesn’t help. The resulting clutter makes it hard to see what you’re even asking for, let alone figure out what the key benefits are. If your audience doesn’t see things that they need to understand your business case, they’ll ask in specific terms. Just like Goldilocks and the Three Bears, the business case has to be not too thin and not too thick, just right.
plain ol’ t.m.i.
There are other dangers in taking the too much information approach. The first is that IT looks defensive and focused on the short term tactical. The CIO’s job as a leader is to behave like one, understanding the business and the corporate goals and strategies, not immersed in the detail or asking for more expensive shiny toys. Specific detail questions will arise, but it’s OK to say “I’ll get back to you on that” or “that’s the approach your department’s people worked through with my staff – I can set up a meeting with your people and mine to review that with you if you want.”
Another risk in the flood of information is overwhelming to your decision makers. They will either not read any of the business case, or not be able to figure out what your key points are, or in reading it all, find something that inadvertently hits one of their hot buttons, whether that’s related to the current situation or not. At a minimum, they’re getting the impression is that you’re not respecting their time – like you, they have more on their plate than they can manage.
One other risk is reinforcing the perception that IT is spending too much time on technical details, rather than focusing on the things that will make the business better. Often the additional information is about implementation specifics: server specifications and other things that aren’t necessary for a business case beyond the capabilities needed for the business requirement (e.g. 50 users at 1 transaction/second) and the financial impacts, at the level of detail your financial people want (better yet, as they supply them). By providing extra detail, you’re inviting your business user or CFO to invite their favourite vendor in to offer a counter proposal that will be cheaper, faster, etc., whether or not it meets the business needs your people worked hard to define and build a plan to implement.
no buzz words
One of the things that we lose sight of is that every interaction IT has shapes our reputation and the trust level between IT and the rest of the organization. While we understand it at the micro help desk level, the same is true at the executive and board levels. Each business case or presentation is an opportunity for IT to demonstrate its value to the rest of the organization in business terms. It’s an iterative process, requiring calibration as the corporate goals and focus change to respond to market forces, or to develop new opportunities. We wouldn’t expect the manufacturing executive to give us a detailed list of the loading of every machine on the shop floor or his shift schedule. When a new piece of manufacturing equipment is needed, the business case will focus on what it can produce and costs, not detailed technical specifications full of buzz words and acronyms of how it makes widgets, or its compatibility with the other equipment. We expect that he/she has considered that as part of managing the shop floor function. The same goes for the CIO and IT. Less is more.
