How is the CIO role changing?

In today’s world, many CEOs forget they the must be CEOs (Chief Enabling Officers!) and act like CEOs (Chief Execution Officers!).  But that is not part of our topic now. We will save it for a rainy day.

We also see two important developments happening in the realm of CIO:

1. Technology and business boundaries are getting blurred. Either of them cannot be stand alone!
2. Business strategy is not decided independent of technology rather the latter is a critical component in formulating a plan.

In other words, the era of business-led / technology-enabled CIOs has ended; a new one technology-led / business enabled has begun!

What kind of battle is waged by the CIO? A three-pronged battle:

1. Drive / Enable business strategy harnessing the power of technology in a secure way
2. Battle with monolithic systems of records and data and inflexible, technical-debt ridden architecture
3. Maximize value

Where does that leave the CIO? Here is how I see the role changing:

There will be a huge metamorphosis of the role possibly eliminating a dedicated CIO. Parts of the role may manifest in other areas. For example, the resources (including technology, required infrastructure, cloud, network, end user computing, devices) might be controlled by the COO. The enabling aspects of this would be owned by the line function leaders who are responsible to customers or business stakeholders.

The first view point is that the CIO role would disappear. Whilst this may take a while, things will become difficult for the CIO in the coming few years. Certain steep changes will be the order of the day.

#1. CIOs who are experts in technology – legacy or digital can expect to be pigeon-holed. Those who use to to bamboozle the rest of the organization with fancy architecture and buzz words will recede into the background. They need to invest in soft skills. They need to seamlessly align with the organization business strategy and business line function. Every project that originates from the CIO office will be relentlessly subject to CBA (Cost Benefit Analysis). Can the CIO stand up and articulate what, when and how he plans to stay relevant and important to business? Even this won’t do; they should be skilled at spotting new business opportunities and be able to influence their ideas. They have to become more human and partner with others in order to maximize their value to business. This partnership can be internal or external. Nurturing and harnessing a good eco-system will help.

#2. Continuous realignment of the organization, teams, skills and outlook will be required even to stay afloat. What do I mean by this? IT world is ransacked by new trends and terms like agile, DevOps, DevSecOps, Continuous integration/deployment. More trends and methodologies will start coming in. We are already talking about a low or no code IT that can be bought, scaled up or down and customized / enriched. The CIOs should reflect on how and what this means for the team? We used to have specialists in IT like SQLServer expert, Oracle DBAs and Network engineers. Whilst some roles will continue, they need recalibration as the IT world changes. Does it pay for a separate testing category to be developed? Perhaps an automation tester is required. A developer should also be a capable tester. To what extent soft skills and business skills are to be embedded within IT? 

A recalibration of the IT team that is not compartmentalized but can be assembled to deliver digital transformation of the business is the need of the hour. And the IT team members should be prepared to don different roles in different teams! Towards this, the CIOs should be prepared to and implement redefinition and rebaselining of skills, recalibration, training and enablement etc. And the team identification, deployment and delivery should, subsequently, follow these new ways.

#3. A CIO should transform into being a change agent of the organization. They will have to become value creators and for that they should transform into change instigators. Status quo is no longer an option. Even if a CIO continuously maintains the estate well and runs a tight-knit disciplined shop, that won’t be enough. Most of the normal health parameters have been pushed into the very bottom so much so that they don’t require special oversight nor reporting. Today’s tools / products come with self-healing and self-reporting properties. In order to transform a business operations and drive value, they have to remain restless (in a positive way!). I would go to the extent of saying a controlled panic will do a world of good now and then!

To conclude:

• Tomorrow's CIOs will have to drive, innovate and execute with the first two as the dominating functions

• They need to enable a high-performing environment, business-oriented and flexible teams with multiple skills.

• The operational responsibilities will not go away but take up less and less time allowing them to act more as leaders, communicators and innovators.

• Quite a few organizations are taken aback by the lack of clear definition of “Digital.” A few CIOs and their direct reports, I met, are constantly worried by the lack of uniform definition of "Digital." Why worry? Instead, the CIO (whether it is a digitally-born or digitally-aspiring organization) can take this to his/her advantage. This is because any digital transformation is less about a digital technology or strategy but more about a successful business in the digital world.

Why does the business love Agile development?

Agile continues to be the preferred way of delivering business outcomes. Still organizations use waterfall techniques especially to the system of records. But it is agile that is becoming de rigeur for system of innovation and differentiation. Agile’s willingness to fail is the primary reason that endears it to the business.

I have been involved with more and more teams, especially in Europe. There are some very clear observations that are quite evident.

1. The mentality and emotion quotient surrounding a waterfall project team is still based on avoidance of risk. Of course, they do fill up the RAID log as it is commonly known. Documentation trumps up all other requirements.

   

   Agile Model in action

2. A pre-mature optimization happens in the delivery of such waterfall projects. Many factors contribute to it. One is the time lag behind the business requirements and delivery when everything changes around you in a faster manner. Second, the freezing of architecture and design without understanding some of the future-changes start pushing the projects into a tight corner.
3. Integration happens at the last and that’s where new but significant risks start to emerge as the project deals with other adjacencies.
4. Agile embraces risks and that’s what makes it adopt a different approach. The team starts in a humble manner and learn as they progress. Early and constant feedback changes the games.
5. With each sprint / release, integration happens. The product may be incomplete but it is brutally subjected to feedback and criticism. In general, the right behaviour, in agile teams, doesn’t make them nice and avoid negative feedback. The old adage “Silence is golden” doesn’t work.
6. As the teams, in waterfall, are split into smaller units for tighter control and delivery, the risks due to dependencies (known or unknown) rise faster. Michael Nygard says in Architecture without an end state “The problem with dependencies is that you can’t depend on them.”
7. Waterfall assumes the leader is quite capable and prone to enforcing a herd mentality. This works well to avoid a difficult terrain but not when the business is waiting to expand. In agile, the management trusts the teams to find their own way. This is not to was off one’s hands completely. After spending time to help the teams understand the big picture, trust the team to negotiate further. Equipping and empowering culture are important.
8. Recognizing that change is quite frequent, it is better to work on what we know latest instead of applying an artificial freeze. Agile teams remain flexible.
9. Team happiness becomes critical in agile teams. Continue to measure it.
10.  Agile teams indulge in such planning where more minds are put to work. Instead of waiting for someone to solve their problems, they are encouraged to find their own. The team, typically, rises to the challenges and comes with measures.

Not all parts of IT need to become fully agile for the sake of it.  But, the entire IT, as a coherent entity, needs to be agile o rnimble enough to the changing business. Where it makes sense and where IT remains a blocker to realizing business outcomes are those areas that should embrace this culture. 

Finally, a word of caution. Do not brand agile with no-process or free-for-all approach. It is where you lay the stress that becomes different. Projects in agile mode are also supported by quality and rigorous document and associated metrics. Informality should not be confused with indiscipline.

Which agile model is right for you? What are the solution considerations?

Choosing the right type of agile model is of paramount importance. Enterprises are experimenting with Scrum Kanban, XP, Spotify etc. Looking at the user interaction and rate of change as two parameters, we can make use a specific approach. The following diagram gives one such idea.

In the table below, the considerations of application type, type of work, type of team, volatility etc. determine the applicability of different methodology.

Parameter	Description
Application Type	Strategic Maintain Run to Retire PoC
Volatility Type	High, Medium, Low
Work Type	Large/Medium enhancement Maintenance/Small enhancement Migration Large platform based Innovation
Variability Type	Small, Medium, Large
Team Type	Independent Frequent collaboration High collaboration
System Type	Stand-alone/Small Medium complex/Medium dependencies Highly complex/Multi-dependencies

Based on the above, we can construct a table that shows the usage and applicability of various models.

Parameter	Scrum + XP	Scrum	Kanban	Waterfall
Application Type	PoC	Strategic	Maintain Run to Retire	Maintain Run to Retire
Work Type	Innovation Platform	Large/Medium enhancements	Small changes	Maintenance Migration
Team Type	High collaboration Frequent feedback	High collaboration Frequent feedback	Independent	Independent
Volatility Type	High	Medium	Low	Medium/Low
Variability Type	Large	Medium	Small	Medium/Small
System Type	Large/Complex	Medium complex	Small / Stand-alone	Medium complex/Medium dependencies

What are the factors to be considered in designing the solution and commercials?

When working with a customer's IT organization that is in some form of agile, the solutions team need to consider the following factors and ensure their impact on delivery as well as commercials is understood.

Area	Considerations	Impacting
Transition	·           Current level of agile maturity across business units (Each unit can operate in a different level) ·           Current offshoring maturity ·           Usage of distributed agile ·           Consider various scenarios like: o   Waterfall to Agile o   Agile to Agile.	·           Knowledge absorption: Include pair programming and architectural runway (Existing code, hardware components and software functionality that technically enable near term business features) ·           Replication: Sprint based execution ·           Boot camp duration and costs (focus on Agile foundation, Agile Associate, Scaled Agile. behaviour aspect - People mind set, culture ·           open-up and express their view) ·           Include time and effort for doing agile assessment of the in-scope portfolio ·           Onshore ratio ·           Timeline
Steady State	·           Agile maturity of different business units ·           Level of life cycle management and DevOps tools usage ·           Type of full stack engineers required ·           Availability of roles like PO, Agile coach, Scrum master with the customer ·           Time proposed for transformation ·           Quantum of work ·           Current effective tools usage ·           Usage of DevOps ·           Current mapping of resource levels	·           Operating Model ·           Evolution of ToM across time line ·           Squad size ·           Release cycle ·           Onshore ratio across months/years as the customer moves up on the maturity curve ·           Type of resources and their distribution ·           Productivity % resulting from people, process and tools
Commercials	·           Physical Infrastructure ·           Connectivity requirement considering more online interactions / meetings ·           Typical squad size per ODC (there could be many special requirements per squad)	·           # Travels could be more as compared to a traditional model ·           Special infrastructure (meeting rooms, furniture, boards, interactive rooms etc.)  costs ·           Special equipment like monitor (big size, two monitors per person) ·           Additional tools/license ILF (initial License Fee) and RLF (Recurring License Fee) ·           Cost of baselining the resources of the customer and plotting them against standard models like SFIA or Dreyfus model ·           Recruiting costs (cost of running hackathon) ·           Cost of hosting customer periodically ·           Cost of building Academy ·           Cost of configuration/customization of existing tools, frameworks and accelerators ·           Training / Upskilling costs covering the initial training required to make the resources more engagement ready as well as upskilling as they move the Dreyfus cycle. The traditional training materials will not do.

Is digital transformation the panacea?

Every enterprise is in some stage of “Digital transformation” today. The new ones are born digital anyway. But, is transforming the enterprise digitally enough to maintain their competitive advantage? Does this automatically bring the organizations closer to the business? The answer is NO.

Today’s digital world is shaping the way customers, markets and even employees think, write, share ideas, experience the world leading to changed buying behaviour. The options, before the stakeholders, are vast. Customers change their needs fast even building up some en route. How efficiently can the enterprises understand these changes? The key to success is whether they can make use of this digital transformation into delivering “Personalized experiences or realities” on time. An example is the Japanese e-commerce site Zozotown. Its mobile app is paired with Zozosuits to take customer’s body measurements. They can then order individualized clothes online.

Whilst this is on the customer side, what about employees? Employees should become more like “Human + workers” ready to embrace and apply digital technologies to enhance the way they work and deliver products or services.  Both the entire organization and the employees must keep pace with digital maturity. If either one is incompatible, it may pull down the enterprise ability to differentiate.

The markets are no longer fixed or in a single location. They may not even exist today. Welcome to the world of “digital”, “on-demand”, “At the moment” multi-market scenario. Some may last for a while. Others may not. Enterprises must act keeping this in mind. The underlying processes and structure can be monolithic but the entire firm must be nimble and ready to shape-shift in a moment’s notice. For this, the organizations can and should use appropriate AI tools that help predict preferences and changes in the customers’ thinking.

The essence lies in how the enterprises can effectively use the digital technologies to harness the virtual markets simultaneously building “Trust” with customers, employees and business partners.

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.

Changes happening in Insurance industry impacting IT service providers

Usually people associate technology changes more with banking sector.  about insurance? Global insurance market is valued at $5 Trillion. How the people use insurance and even think of it have undergone a tremendous change. The expectations are different and so is the service catalogue from the providers. How is the technology shaping up the industry?

Here are 3 important changes driving this sector.

All encompassing digital transformation – New models / Personalization

Like any other industry, this has shaken the leaders as well as laggards. No one could afford to be complacent. The overall impact is very positive for both the organizations as well as the customers. Customers’ expectations are changing: They expect very specific bouquet of services, expect services anytime anywhere and through any channel. EY estimates that 80% of customers want better communication with the insurance organizations. And this communication has to work seamlessly across channels!

Big Data And Analytics will play a huge role. Are today’s insurance organizations equipped for collecting all data online and real time? Have they made changes to their organizations as well as the processes in order to make use of the data? Can they offer a single user based insurance and personalized premium based on the data available online? What are the ways to collect data in order to get a competitive advantage?

If 80% of the premium is lost due to distribution costs, imagine the power of digital models. Perhaps they will make the intermediaries redundant in the entire value chain. APIs will redefine insurer-insured-InsurTech relationships. Insight-driven offerings will be the buzzword! An insurance company, in Europe, partnered with Panasonic. The latter’s sensors provide alerts to both the insurer and its customers using which issues are resolved quickly. Drones are here to stay and will become increasingly used for many purposes. Some of them are assessment of property damages, accurate estimation of property, analysis etc. In order to assess Hurricane Harvey’s damages and settle the claims faster, leading auto insurers used drones. In Australia, many big loss claims were settled within 90 days using drones.

Insurtech modernization

The system of records, especially the legacy systems, need to be transformed and operating costs minimized. RPA (Robotics Process Automation) and SaaS are being extensively used. Many companies buy products and customize them so much so that it loses the product flavour. This can only increase the costs of maintaining such systems. Companies are looking at  standardization as a means to cut costs.

Some of these are likely to encompass the following:

• AI and automation to cut down costs
• Focused application for digitalized customer experience and focused approach to problem-solving.
• Implementing a global Blockchain for a more secure and safe information sharing channel.

Partnerships

The collaboration between insurance and InsurTech firms will happen faster. The result will be new revenue models, higher profitability and reduced costs. If we look at the InsurTech firms’ growth, it happens in almost all the areas such as auto, cyber security, home etc. These call for increased technology capabilities which may be difficult to develop by the traditional insurers or would take a longer lead time. The latter is not acceptable in the competitive world. This could even be a win-win for both. Reaching out to large customers could become easier using InsurTech companies.

References

https://www.businessinsider.in/the-insurtech-report-how-financial-technology-firms-are-helping-and-disrupting-the-nearly-5-trillion-insuranceindustry/articleshow/60258913.cms

https://www.itnews.com.au/news/qbe-deploys-drones-to-assess-insurance-claims-452739

https://www.nationwide.com/smartride.jsp

https://www.cbinsights.com/research-insurance-tech-trends

https://riskandinsurance.com/5-tech-trends-for-insurers-to-watch-in-2019/

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.