Is your CIO funding projects or business capabilities?

Context

Earlier, the CIOs tended to organize their teams and functions around specific projects. Wherever possible, consolidation was touted as the panacea! The seemingly good candidate is RTB (Run The Business) function that typically “Keep the lights on.” Support, both application and infrastructure, falls into this category.

As the rest of the units start aligning themselves to operate nimbly in an agile and digital world, what happened to the IT organization? Many CIOs have simply reorganized them using fancy terms but essentially retaining the same flavour. Ask them about the IT budget. They will talk about RUN and CHANGE. Drill them into more detail, for example the cost of introducing a new product and see their reaction!

In this blog, I share the experiences of working with CIOs and IT organizations around two important aspects.

• How to look at the IT budget and get answers quickly?
• How to align and develop an operating model?

Let’s understand the changing paradigms to the meaning of IT as organizations go digital and embrace new technologies:

Diagram #1: Emerging interpretation of IT in the digital context

In short, business strategy automatically becomes IT strategy. It is no longer possible for CIOs to emerge victorious when the entire business is going southwards! The CIOs are in the thick of things.

Funding Model

Diagram #2: IT Funding by Portfolio

Typically, the CIOs look at the funding by any of the three categories:

1. Type of focus - RTB (Run the Business), CTB (Change the Business) and Grow (Linked to Business Growth)
2. Budget (Cost of personnel, license, hardware, storage etc.)



Diagram #3: IT Funding by Budget

3. Financial accounting sense (Capex / Opex)

Diagram #4: IT Funding by Accounting

These types of funding keep the technological interdependencies and the business led IT aspects deeply hidden. The real cost drivers become virtually impossible to find quickly. In a way, this explains all the IT costs but presents an incomplete view. This may lead to investment silos and/or duplicates. The flexibility needed to understand digital investment is not the hallmark of these methods. Moreover, justifying the legacy refresh takes inordinate time.

Diagram #5: Allocation of IT Budget

Instead, allocate the IT budget by product line. For this, work with business to understand the strategic / relative importance of the product lines annually. Empower the PLMs (Product Line Managers) with the discretion to allocate funds to maintenance, technology refresh, innovation etc. They should have the wherewithal to reallocate the funding as priorities change.

In the diagram #6 below, an illustration is given. The key focus area is to build new business capabilities and ensure the business strategy is not impeded by IT. 

• New business capabilities (BC) are financed by respective business area budgets. Examples can be subscription based services like SaaS or getting third party services.
• New business capabilities are funded by IT to the extent of technology implementation or major changes/enhancements.
• Then comes the "Maintain to Operate" layer that focuses on licenses, upgrades, hardware/software maintenance, staffing etc.



Diagram #6: Shifting Budget Patterns



• Finally the digital foundation layer that addresses cloud / building new platforms etc. This directly mitigates operational risk.

As can be seen, the key differences to this type of approach are:

• Part of erstwhile IT budget for funding new products or building new capabilities is shifted to the respective business unit or area.
• Business area is the owner of the budget for introducing new capabilities.
• The funding that is required for digital foundation is separate from maintenance.
• The linkage of technology to the business capability is clear.

What comes out clearly is that enterprise wide view of technology spending covering business-led IT. This view complements the traditional views to gain quick insight into cost of transforming the landscape, cost of sustenance of new capabilities as well as introduction of newer ones. As the technology funding is clearly aligned to business, the ability of IT to influence and respond increases.

Operating Model

Let's start with what we aspects we should expect from the IT operating model.

• Faster time to market
• Greater business integration
• Flexible ways of working
• Improved customer experience

For this, we need to shift the mindset from projects to products. What are the differences?

Diagram #7: Redesigned Target Operating Model

How do we factor them in the operating model?

• Diagrams 7 and 8 give an overview of how to visualize these changes in the model and consequently the organization of the teams.
• Choose products or business capabilities over projects.
• Each capability is a vertical tower that comprises all IT operations pertaining to it. RTB and CTB work will come under this.
• The product line manager is empowered to organize his teams, allocate budget and change funding.
• These operations are done on the product lines in an agile / DevOps / CI manner.
• Everything cannot operate in a vertical stack. IT has to spot scaling / efficiency opportunities wherever possible. What is not common to each capability but to the entire organization is (1) the building blocks of application and (2) Cloud based scalable infrastructure. These may include shared applications, shared ERP, shared platforms, shared BI and shared data centre etc.

Diagram #8: Team Organization

Conclusion

It makes immense sense to appreciate the paradigm changes in the way IT is viewed and linked to the business. This should logically flow into the way the IT teams are structured and funded. 

What are the advantages of reorganizing the IT along these lines?

• Business knows easily the respective IT to discuss/contact.
• As the IT services each business capability, the skill sets / knowledge of understanding of the business grows within that unit. This means informed resources that have the ability to respond to changes.
• IT supports the business more efficiently in terms of understanding the cost components and come up with answers to question like – what will be the time taken / savings in IT if a product line is killed? what will be the incremental cost of introducing a new product in a particular market? Etc.
• The IT landscape becomes less complex and easier to understand/operate.
• The portfolio metrics, at each capability level, make direct sense to the business head as well as the CIO.

On a lighter note: If a CIO's lingo becomes as close to the business and everyone understands the CIO's response in the first instance itself without seeking further clarifications, latch on to that CIO for God's sake!

How much business value is added by your IT division?

You are the consumer of IT services in your organization. How do you ensure you get the maximum business value from them? Of course, it is second nature to think of IT adding lot of value. But, how do you see it? It is likely that you get a set of huge reports from the CIO showing metrics and other related things, most of them almost always green. Have you taken time to sit down with them and ask them to explain why there are important metrics and how they relate to you?

There are the three broad dimensions in terms of adding business value:

• Speed of delivery
• Quality of delivery
• Customer experience (# options, # value added services, Ease of operating a channel, Omni-channel, service offerings etc.)

If your IT is to become a value-added partner to business, it should:

• Assure the business that security is not compromised, the applicable regulatory changes are adhered to and ensure there is a plan B always in terms of disaster recovery. This is the bottom-most layer and a sine qua non today.
• Promote innovation and be a true partner to business.

 It is the latter that we are discussing in this article. Here are some pointers to get around this:

Pointer #1: If you don’t question and understand your IT’s output,

your customer will do so in no time consequently leading to more costs. Do not accept metrics or any report from IT without a sitting. Good metrics, however good they are, do not tell much about business. High uptime of an ATM is good. Imagine the loss of ATM for a minute on an important occasion like boxing day. If your IT team is able to resolve all the issues within the agreed time (SLA – Service Level Agreement), very good. By themselves, all these metrics may not mean much. Do not be afraid to dig deeper and learn further. At the end, you as well as the IT must be convinced there is merit behind the metrics. Usually, the clue is to have a few meaningful metrics that can be directly or indirectly correlated to your or business KPIs.

Pointer #2: Whenever you have a meeting with IT, are you getting inundated with technical mumbo-jumbo too often? Perhaps, there is a problem. It is not uncommon today for everyone to exhibit how “digitally aligned” they are. This is ok to start with. If someone, from IT, including a thorough-bred architect cannot explain in plain English whatever proposals they are acting on and their corresponding business benefits, chances are that they require more meetings to unravel the mystery.

Pointer #3: Before you can question the IT, have you spent time with them articulating your business goals and priorities? Have you taken them into confidence? Do they know your KPPs? Do they know the direction you are planning to take? Do they understand where you are trying to invest? Share with them transparently. Make them understand what you are doing. If you change your priorities, let them know.

Pointer #4: Leave the management of the IT to the CIOs and do not get into too much nitty-gritties. Giving them the required freedom is essential. At the same time, do not allow yourself to be outmanoeuvred by the CIO that the IT reports are bound to be voluminous as the IT is outsourced to many vendors. The last thing, you want to be afraid of is the fact that there are n vendors supporting your IT portfolio. Whether your IT is insourced or outsourced doesn’t eliminate the need for your IT to present a single view to you. Demand from them.

Pointer #5: We should use IT and technology to see how they can add value to the business process. IT can be a great enabler to open new channels. They can help you to cut costs. If you happen to call them only when you have a break-down or an irate customer, perhaps you are not making use of IT to the full extent. Remember, in today’s world, more strategies are designed keeping IT in mind. The more they participate and the more freedom they have, the better they can come up with alternatives. But agree with them upfront on the “definition of success” for each important business initiative.

Skills for shaping the digital enterprise

In the world of digital transformation happening, how do we see the roles emerge? Does the old definition still hold good? Here is a brief view.

Most organization will become “digital” in some way or other. When they change from a monolithic to a digitally agile unit, usually a saviour is recruited and he or she is called CDO (Chief Digital Officer). But things do not end there. Rather it is a start. The entire organization should become digitally nimble. For that, we also need to see how the roles encompass some of these aspects. Mind you, today’s world will not be strict 1-1 mapping. We will find that CHRO and CMRO should work together in incubating labs and the would be their joint KPPs.

CHRO (Chief Human Resources Officer) - Starts with identification of digital gap and engages in acquisition of such talent to fill the gap. Target is for the CHRO to own the “digital experience” and initiate a culture of “incubation labs” that foster and nurture talent closely allied to business as the enterprise becomes digital throughout.

CMRO (Chief Marketing Officer) - Starts with setting up marketing related digital aspects. Target is to own the “digital experience” along with CHRO. All start up labs / eco-systems for building products and experiences should be the mainstay.

What about CTO (Chief Technology Officer)? The vision of CTO means a nice team of geeks who set the enterprise architecture standards for the organization. Of course, the starting point is development of digital architecture. Target will be to own digital product labs.

The all-pervading CIO (Chief Information Officer) will be responsible, initially, for defining and managing digital infrastructure as part of the enabling function of IT. The entire portfolio including the actual digital infrastructure of the organization as well as the target channels of interaction should be governed in the end.

The CDO (Chief Digital Officer) is the digital evangelist at the beginning. He or she should lead the digitalization initatives as well as the incubator labs.

Chief Data Officer is responsible for modelling digital standards and driving data access. All the development of data-driven products and usage of digital to fuel more data and innovation will become de rigueur.

In summary:

1. Culture will change form strict compartmentalization to porous boundaries. Roles and KPPs will impact each other and will require working together not only across functions but also with various service providers and other technology partners.
2. A common set of traits will form the bedrock of digitally nimble organizations. They will include digital thinking and lean principles. The mindset will move from a generalist to digital generalist taking into account the “domain” knowledge specific to the industry.
3. Finally, every one in the new era cannot be a risk avoider. No reward for such a strategy. They will be encouraged to take calculated risk, try out new things rapidly harnessing data from different channels, discard things that do not work out but in the process go towards what is likely to work.

Dear customers, Rationalize your SLAs…

You go and ask an ISP (IT Service Provider) of any customer especially in the field of FS (Financial Services).

You: Hi, tell me about your delivery quality.

ISP: Welcome. We are at the top of the delivery excellence curve in the eco-system of my customer. All SLAs are green for the last … years. We are very proud.

You: Good. How many SLAs (Service Level Agreements) do you measure and report?

ISP: We pride ourselves in reporting more than 100 SLAs covering all aspects.

You: Wow! 100+ All your SLAs are green. Can you vouch for no degradation in the performance of your customer’s service to their end-consumers?

ISP: We can’t say that. Whatever we do, we are GREEN.

The above is not an uncommon conversation that can be experienced today. SLAs are good and needed. But what started off as a measurement mechanism is not what you see. It has become muddled, saddled with increasing number of measures and is being religiously reported. The only problem is that who consumes and what useful information is derived from it? What has happened in the last few years?

• The eco-system has more than one vendors.
• Very rarely does a complete business process start and stop with one vendor. Different vendors act on different parts of the value chain to complete a service.
• More vendors result in more hops of process flow. Each hop adds complexity to measurement, governance overhead and lead time.
• SLAs have become more operational and reflect the process capability of the ISP and have nothing to do with the business outcome of the customer. A system has an availability of 99.99%. It is possible to have one minute outage and meet the SLA. If that one minute happens to be during a critical window, business suffers. On the other hand, an outage at some other time may not impact business.
• The amount of time spent in recording data, reporting and managing can fund a fully-fledged vendor department!

What should the customer do?

1. Have a focused 1-2 week exercise. Look at your vendors and different services.
2. Understand your business capability and map the IT processes/vendors against each. Identify the critical points in the value chain.
3. Start developing SLAs to match with the “success criteria” of IT as a whole. For this, assume you are the only party in control of all IT resources/services.
4. Do not waste time in operational SLAs vouching for the process capability of the vendors. If you have selected a vendor compliant with certain process standards, it is the responsibility of the ISP to comply with it. So long as the MSA (Contract – Master Services Agreement) covers it, that should be fine. However, retain the option to ask for artefacts that couch for compliance.
5. Call for a workshop with the ISPs and set about how each one can take the SLA you have devised. It comes in many different flavours:

• Flavour #1: Every ISP can take the SLA and apply it with respect to its domain/services. For example, consider a resource ramp up time of n weeks. It applies to every ISP and can work with their portfolio.
• Flavour #2: The SLAs have to be taken by each ISP; however, the target value should change as the quantum and type of work done by each ISP vary. Consider the fact that 20% of the IT staff are considered “KEY” and there is a whole host of definition behind what is “KEY” including longevity in the account, skills, capability, offboarding procedure etc. Customer’s IT has a target of 25%. But the same % may not be relevant for an infra service provider vs high end application service provider. The values should reflect their role and volume of work.
• Flavour #3: This is the most complex. The completion of a business capability requires services from different ISPs. Here, the respective ISPs should take the entire SLA as it is and have a responsibility to work together and ensure all of them complete the task within the overall time. This will call for a high maturity discussion, understanding and a passion to work with multiple vendors in order to deliver a business outcome. Once agreed, the ISPs will ensure they work seamlessly, find ways to inform one another well in advance, have planning sessions, find ways to reduce the hop etc. If any ISP is not willing to take, you really need to re-examine the fundamental reason behind. Or it is perhaps time to re-examine the relationship with the ISP.
• Flavour #4: This is similar to the variant #3 but with a difference. The single business capability can be broken into distinct steps with each step owned by an ISP. Here,  the ISP take that part of the SLA (After breaking it down) that applies to them with a specific target value.

After agreeing on this, focus on:

• Propagation of the same across all users/stakeholders
• Laying down of the measurement and reporting system to be used and
• Developing an automated system for tracking and reporting eliminating the need for a voluminous governance around this.
• As a guideline, any set of SLAs more than 20 measures may not augur well.

Finally, a word of caution: If, as a customer, you find too often lifting the phone or dropping an email to ask for an SLA report or spend days validating the data in the SLA report or get happiness in organizing SLA meetings, you have slipped into a danger zone.