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.

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.

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.