Recap
In the last part of this topic, we discussed business strategy and how budgets are tied directly to total revenues. Finally, we started to see why Operational Strategy is crucial to the overall success of the business. In this final part, we will define exactly what Operational Strategy is, why it exists in the first place, look at the four types of activities that are important to the CIO as part of this. Finally, we will wrap everything up with four words that describe how a CIO approaches their responsibilities from a macro level.Revenues vs. Budgets
This is where the Operational budget comes into play. It is responsible for funding the KTLO ("Keep the Lights On") role that IT plays in the business. And because IT is still generally viewed as a cost center instead of a revenue source due to the lack of a well-defined and implemented chargeback policy, this budget is limited. After all, why would the business dedicate large amounts of money to a portion of the business that does not contribute to the bottom line of the Income Statement?
Operational Strategy
Since this budget comes with limitations, it is crucial that the successful CIO make every dollar count. The Operational Strategy, therefore, has the four types of activities listed below associated with it. Note that each of these types has a hard dollar cost savings associated with it.Consolidate technology. As time elapses, more and more technology is proposed, justified and purchased when, in reality, it is frequently possible to either accomplish the same goals using existing footprint or retire older technology after the new purchase is completed and implemented.
As a result, companies end up paying far more for licenses (as capacity needs are met), maintenance (which is a percentage of total licenses), services (to integrate with newer solutions that are purchased), and education (for new functionality rolled out in subsequent versions and to train new staff due to attrition). A substantial percentage of these costs can be eliminated through an assessment of the solutions in use and the goals to which they are associated. Overlap is identified and older or less capable solutions are eventually phased out.
As the size of the company increases, the resulting savings increases exponentially. For example, a large financial institution underwent this "software rationalization" exercise and, after an assessment of the IT portfolio concluded, we realized they had over 140 solutions strictly for monitoring the infrastructure. For the sake of comparison, let's consider a more realistic number: 3 types of infrastructure (servers, networks and applications) multiplied by 5 operating environments (2 Windows, 2 Unix, and 1 mainframe LPAR) multiplied by 3 sets of solutions to ensure 100% coverage due to gaps results in a total of 45 solutions needed. Even if you add another 1 or 2 operating environments you end up with a maximum of 63 solutions, which is less than half of the 140+ that this company owned and actively maintained.
Consolidate vendors. Similarly, additional technology purchases are not done with the same vendor that a company bought its first solution from. Instead, new additions to the "preferred vendor list" occur on a semi-regular basis as niche solutions are identified and acquired.
While limiting the list of vendors seems counter-intuitive consider the following: if a CIO is spending $100mm on IT solutions per calendar year, they can divide that by 5 vendors or 50 vendors but it will not impact the underlying need to address the business requirements behind the purchases. However, if they conduct business primarily with a smaller number of larger vendors, they will be spending more with each vendor giving the CIO leverage in negotiating larger discounts on an Enterprise-wide Licensing Agreement (ELA). This either gives them money back that can be spent in other areas or frees up some of the CapEx budget to spend on additional technology that may not have been considered a top priority due to budgeting constraints.
The first two items were CapEx related. Now let's look at OpEx related items.
Streamline existing processes. We've all heard the horror stories like the following: "it takes us 10 times longer to remediate production outages because we have several poorly integrated solutions for our Help Desk. This requires a lot of manual effort to circumvent the limitations of our process to execute efficiently." Ensuring that existing processes are operating as efficiently as possible allows IT to realize several benefits: underlying staffing requirements are reduced; the need for specialized staff to deal with archaic systems that don't play well with the rest of your infrastructure is reduced; and the "time to value" for new staff as a natural result of attrition is also reduced, which reduces total operational staff requirements.
Process streamlining can be effected through the use of solutions that integrate with each other (resulting in features / functionality that would not have otherwise been available), automation where possible (especially Run Book Automation), and Service Request Management (the "Help Yourself Desk").
Deliver new services. When I first got involved with application development, it was common for major releases to take 18 months. This was shortened to 12 months, 6 months and now - due to Agile development methodologies - we see major releases sometimes coming out as frequently as once every month. As timelines are shortened we've all noticed an increase in DPMO (Defects Per Million Opportunities, a Six Sigma term that describes the quality of process output). This causes contention because companies want to release things faster but with a high degree of quality and that's not always successfully done.
Examining current processes for delivering new services and implementing new processes to do so more effectively allows a company to remain nimble without impacting the ability to conduct normal business due to quality issues. And while this is not as easily quantifiable as the previous three points in a general sense, the resulting increase in productivity does have a measurable impact on revenue either by increasing the capacity of existing streams or adding new streams more quickly.
Putting it All Together
Now that we've discussed Business and Operational Strategy, let's see how they impact the approach that the successful CIO takes when developing their 18-24 month plan. This approach can be distilled to four words: decide, prioritize, assess and execute. Let's define what each of these action verbs means in the context of strategy development.
Prioritize. "What's the impact on the business if I do X?" The answer to this question (asked of each initiative) forms the basis of a cost benefit analysis that ultimately results in a red light or green light. Remember: for every initiative that is implemented there is an associated hit to the operational budget after the initial rollout occurs, which is the motivation behind this activity.
Assess. By definition, the sole purpose of Keep the Lights On is to...well...keep the lights on. Effective operational groups in IT have well defined processes for the triage and remediation of production events that occur. New initiatives that are implemented represent a change to the operational environments under their care and, as such, there is a risk to the operational capacity of the business if those changes are not fully understood so that IT can continue keeping the lights on with minimal disruption.
Execute. After all of the planning is finished the actual work commences. And with it comes the need to monitor, automate, manage and secure the next set of initiatives being implemented. This is the activity that most people are very familiar with.