I am focusing a lot of my attention these days around the completion of my dissertation, which primarily focuses on requirements analysis capabilities. What I have noticed is that there seem to be two contexts for requirements: a small context of system design and development and a larger context of what IT is expected to contribute to the business objectives.
A little background first. Despite the rising importance of information technologies for process improvement, competitive advantage and innovation, the challenge of IT alignment with the business remains the first or second top concern for CIOs in nine of the past 10 years from surveys of IT professionals done by the Society for Information Management. Moreover, most all of CIOs’ top 10 concerns are clearly business-IT alignment-related (e.g., cost reduction, business agility, IT strategic planning, business productivity, business process re-engineering).
Despite all this concern for alignment by IT leadership, it generally doesn’t result in alignment at all. CEOs tend to view CIOs unfavorably, as itinerant professionals with little real understanding of the business or its industry, and it’s unlikely that they can offer real strategic insights to the organization.
Sadly, most CFOs agree, as only a quarter of those polled in a Network World survey opined that their IT department is able to deliver against the enterprise/business unit strategy, and only 18 percent said they thought “our IT service levels meet or exceed business expectations“.
It isn’t as though we don’t hear them. We understand that business values revenue-generating IT solutions and IT cost reduction solutions. But we also know that although business wants us to provide strategic solutions, we as IT professionals are generally not evaluated on the business value we create; we’re measured against IT operational metrics.
When I look around at CIOs who are involuntarily separated, it is invariably due to a security breach, implementation failure or critical service failure. That’s because nothing gets a CIO fired more quickly than a security breach. An implementation failure, usually an ERP solution, is the second quickest way, and a prolonged service failure is just as deadly.
I’ve often heard these referred to as table stakes, for which you’ve got to be able to provide the service for the organization to value your input into strategy. But that’s like saying, “We don’t want to listen to the marketing guy because sales were down last month,” or “The CFO is incompetent because he mistakenly posted something to the wrong account” or “The COO doesn’t get a seat at the table because there was a fire in the janitor’s closet.”
To Achieve Alignment
It is necessary to (1) genuinely know the business, its language, and its requirements and (2) build IT systems sufficiently agile to adapt quickly and cost-effectively to the ever-changing business.
At the same time, our performance metrics revolve around time to answer phones, deliver projects on time and on budget, first call resolution, and so on. You’ll notice that they are all operational metrics.
Our obsession with operational metrics (requirements in a small context) is never going to lead us to alignment (requirements in a large context). You get what you inspect, not what you expect, and I believe this is the same challenge in IT’s alignment with the organization. I’m not sure how to address this, and I’d like to hear other views on this issue and see if you see it as I do.
