Knock knock.
Who’s there?
IT’s business requirements.
IT who?
IT has business requirements too!
If your first reaction to the above joke was “IT is separate from the business,” or “IT gets its requirements from the business but doesn’t have its own,” then this article is definitely for you. If you agreed that IT has business requirements, read on for additional ways to improve receptiveness and value to conveying and meeting IT’s business requirements.
Addressing the Counterproductive Gap in Mindset We Created Through Language
The business and technology markets like controversy and uses “us versus them” to make points about how things are and should be. We’ve had a similar “call to arms” for several years now about how we need better business and IT alignment.
However, despite all the ways IT serves the business, which it should, I still consistently see and hear the perception that IT has no voice and no say in determining “business strategy” or “business requirements.” Suppose IT is part of the business, as you say it is. How can IT not also have requirements that should be given the same consideration, evaluation (collectively “airtime” in the C-suite), and funding as business requirements from the lines of business or traditional business stakeholders?
Case in point. A CIO is led to believe that while IT is part of the business, his requests or even requirements are discriminated against and have lower stature and importance than requests or needs from his business/functional counterpart. In one case, he may recommend they keep applications and hardware under support. Or keep software maintained to fairly current levels. Why would he specify these “business” requirements? Because he is managing risk if something breaks and knows that the more current his applications are and under active support contracts his hardware is, the more likely he’s going to get timely and quality support and problem resolution from his staff and vendors.
Why else would a CIO have business requirements? By having good IT hygiene and keeping applications, databases, systems, and infrastructure up to date, his IT organization is better prepared to respond to the business’ request to try something out or implement a project. Unfortunately, suppose our CIO’s requirements are most often downgraded to a request and repeatedly denied. In that case, it’s that much more likely that when the business wants to execute a project or roll out an improvement to their business for their customers or employees, IT has a much higher risk of having to say no. It escalates quickly, as characterized by these quotes below.
– “Sure, we just had some layoffs, but as long as you can get funding for some contractors, we can get started right away.”
– “I’m not saying no, but we have to take care of these 1-3 minor projects first, then we can get to your project.”
– “You’re going to have to wait for 3-6 months for us to take care of our other needs first, assuming we get started right away. Did you include a few hundred grand for IT in your project budget? Oh, and we’ll need your business team for an extending period of testing too.”
– “Can’t do that. We’d need to develop more precious capital funding and OpEx approval to pay for all of this. And we’ll need 9-12 months. Only then can you, the business, get to work on improving the business.”
The Challenge to Be Overcome by the Business — and the CIO
The challenge is part cultural and part messaging. When the CIO states his requirements to do IT projects, such as application and/or infrastructure upgrades to stay current, there may be two common challenges:
- If “the business” counterparts didn’t ask for it, they often don’t think it provides any value.
- If the CIO can’t equate or otherwise convey the value of doing said upgrade or maintenance project, his business counterparts will likely resist participating in required testing activities.
So how does the CIO overcome this common challenge?
First, get on the same page
IT has needs just like the business. Suppose the business doesn’t consistently evolve its business process to adapt to the marketplace, create new products and services, or continuously respond to customer demand for how they want to be engaged. In that case, it’s virtually certain the business will begin to lose mindshare, wallet share, and market share because the business’ requirements won’t be met. Likewise, if the CIO can’t have his needs met, the risk is absolutely 100% certain that:
1. Software support and ability to work with it erodes year over year, sometimes even faster.
2. Your team and partners’ ability to support aging software diminishes over time.
3. Software support will end. Remember, your organization probably literally has hundreds or thousands of applications, middleware, database platforms, and operating systems that all have a support lifespan of their own.
4. Hardware will go out of support. It will go from hard to get service or replacement parts to be much more expensive to get them, and eventually, the CIO won’t be able to get them at all.
5. IT’s ability to respond and enable and support the next project the business brings to them escalates quickly from “sure, let’s get started” to “we can do it, but need to take care of this too” to “hold up, wait, we have to take care of these needs first before we start on your project.”
Second, create a way to talk about the impact of technical debt on business agility and risk
Use recent examples, both for positive and negative reinforcement. Show where, because IT was up to date and current, IT responded quickly with the business to achieve fast payback and maximum ROI on an initiative or project. Likewise, have an example ready where IT couldn’t respond without severe delays, cost, or risk – or at all to the business’s current need. If your organization is assessing technical debt regularly, say at least annually, with a technology review including technical debt assessment and roadmap to address those debts, you’ll have a good idea about your level of readiness to support business needs. You might come up with a scorecard that factors in elements such as:
– Risk: the likelihood of an unfavorable event caused by IT’s inability to respond to a business need
– Schedule: impact estimated for a delay, measured in weeks or months
– Cost: Estimated cost of delay to satisfy prerequisites before a business need can begin being met (could be as small as a few software licenses, some labor, to short projects, or full-on serious capital investments or transformative programs)
– Agility: estimated or known hard costs if legal, regulatory, security, contractual, or service-related fees are triggered due to an inability to implement the business’ needs in a required timeframe
We could add other factors in the mix, such as the difference between being to satisfy an IT need for a given processor technology with existing staff, all the way out to pay premium rates for SME’s to deal with outdated and unsupported systems, processes, and technologies. But I think the above elements will give you the rough order of magnitude of the risk, impact, and cost of downplaying IT’s requirements as somehow separate from what you usually consider “business requirements” that come from the line of business or functional leadership stakeholders.
Conclusion
In closing, I pose the following question to you. Do you consider IT part of the business? Consider this: if you’ve ever been successful because of what IT enabled the business to do, or likewise, disappointed by IT’s inability to respond to the business’ needs, then IT is absolutely part of the business. Consequently, IT’s drivers and requirements need to be recognized, given the same airtime and funding consideration as the requirements from the rest of the business. They are all “business requirements.” Do your organization a favor and don’t separate the two anymore. Don’t let the sometimes-intangible value of IT’s business requirements deter you. If needed, assign business-friendly value indicators like risk, schedule, cost, and agility to IT’s needs to quantify the value in satisfying IT’s business requirements, both now AND later.