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!

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. 

Trends in Banking and their impact to IT service providers

As part of an IT service provider in financial services especially to banks, we are constantly reminded of  and surrounded by what’s happening in the midst of our customers. The changes are hard to miss. We ignore these trends at our own peril!

I see the following 3 key changes happening in banking that have huge impact to IT service providers.

#1. Banks are placing more importance on open banking standards and providing APIs (Application Programming Interfaces) either due to regulatory pressure or from a desire to stay relevant

#2. Banks are using data and AI in almost all services where possible to provide differentiation.

#3. Banks invest a lot in understanding and enhancing their end-customers' engagement with them. They want to make their customers' journey – as much STP (Straight Thru Processing) as possible whilstnot comrpromising on customer experience.

Where do the new customers, especially the millennials, shop for financial products? Where do they perform the analysis and comparison? The answer is in their own mobiles or hand-held devices.  In other words, a strong integrated data management that helps in analysing real-time structured or unstructured data to understand customer better and create a personalized experience is required. IT service providers who understand this and build solutions that can adapt will survive. Such an IT system should allow customers to engage in the channels of their choice at any time. The switching from one channel to another should provide a seamless experience.

Second, long winded vendor selection process (perhaps robbing of certain revenue for “Sourcing advisors”) with a view to reducing cost of the landscape is gone. This is because banks have started focusing more on enhancing experience than cost reduction. This, of course, doesn’t mean the latter is not important. It is just that it has taken a back seat to the former and has huge implications in terms of the type of skills a service provider needs to engage with the banks to develop suitable solutions. And the banks are not prepared to wait for 3 months or more in order to select a partner! Failing fast is the new norm.

The banks are willing to pick up customers at any point in their journey but want to provide a wholesome experience that lasts long and enhances the relationship. A customer may have come to avail a particular banking service, say housing loan, after using online comparison or aggregator tools. But it is in the bank’s interest to hold on to the customers by understanding their preferences and evolving a bouquet of services that are way better than what they are currently having. IT systems can no longer be built to do only one thing. Instead, they should be nimble, lean, have the ability to learn and grow very quickly and provide a means of differentiation to the organization.

Impact to IT service providers

All the above changes affect the Indian IT service providers (ISP) in many ways and in different dimensions.

• Capability: The skills, required for building or changing IT systems, are continuously changing. As a result, people who can adapt quickly are the need of the hour. How fast can a service provider deliver such skills? This has huge impact on reskilling, cross-skilling, recruitment etc. As service providers grow hugely, such changes take long time implement. They have to start exhibiting in pockets and spread them across the rest of the units. They can’t afford to wait for global roll-outs! 
• Skill mix: Major impact in the percentage of thinkers vs builders. As the IT systems of the bank move to providing more and more business value, the fundamental nature of the skills change. ISPs used to break down every piece of IT work and execute 80% or more of them at offshore. This ratio is becoming more skewed. Some of the new type of IT work demands more than 40% work be done close to the customer and falls into the "Thinking" category. As the release cycle reduces, very quick execution is required. This would place huge emphasis on collaboration tools to enhance the quality of work and provide a seamless experience to the banks.
• Location is the third aspect. As the banks expand into new markets and offer new services, there would be demands from ISPs to service them locally. For example, there is a growing market in Baltic region. Many banks are targeting customers in the region who are considered very tech-savvy. Such demands have to be met locally very close to customer. Traditional models of building capability in a monolithic way and transporting the people to the desired locations may not work. The lead time may not be advantageous to the ISPs. Many ISPs make use of centres in off-beat fancy locations. How many of them are known for certain capability other than being a low-cost location? The customers are paying increasing attention to the capability and people being developed in various delivery centres.

All the above will call for various measures, in a co-ordinated way, to be implemented by the ISPs. Guess what, implementing these will not only be simple but add to their growing costs. But the banks may not be willing to give you a long lead time nor absorb a temporary surge in their IT costs! Only those ISPs who are not afraid to experiment and who invest in understanding their customers' journey are more likely to succeed.