Recently, I’ve been digging into two related issues: how CIOs facilitate business change; and how organizations define what systems, organizations and other elements should be local or global. Both of these areas involve large scale organizational change. During interviews, a few clients commented specifically on the pace of change. Netting out what they said: “You only have a short period of time for people to change, before they get locked into a new way of behaving”.
An example of this was from a colleague who helped lead an ERP dominated business transformation. One particularly interesting comment was that “Once a change was made, people adapted quickly, then dug in and wouldn’t budge”. For example, they consolidated several country-specific order entry processes into a single one for the entire company. The change was made, training was given, a certain amount of begging and threatening by senior management followed and a lot of people changed their habits dramatically over the first couple months. But then they slowed down and dug in, resulting in many functions that were never used.
So, I did some digging and found a number of academic articles on how people learn. One old one seemed very relevant. The topic was how people’s behavior changed as a result of the deployment of a new collaboration platform.
“An average of 54% of all adaptive activity was completed in the first 2.8 months. This given on average that new technologies took almost 14 months to be considered production. As time goes on, momentum for change is lost, the "best" people move on to production work, evangelists lose interest and initial enthusiasm that existed for change is wasted.”
[Source: Marcie J. Tyre and Wanda J. Orlikowski, "Windows of Opportunity", MIT Sloan School of Management, September 1992]
At our recent CIO Forum in D.C., I had a number of conversations with clients who either had gone through or were going through a business transformation. From our talks, one theme jumped out at me — most CIOs will either lead some part of this transformation or get run over by it. From their perspective, there was no middle ground. To paraphrase one CIO, “There’s no way you can just go along for the ride and not get hurt.”
A little data first. In a survey Forrester performed for Tata Consultancy Services, approximately 30% of those surveyed responded that the CIO was the most important senior leader in driving or supporting a business transformation; CIOs were rated highest — even above CEOs! With about a third of the sample coming from IT, the numbers were slightly skewed, but follow-up interviews with both business and IT people confirmed the results. To paraphrase the leader of IT strategy from one meeting, “Once past the vision phase, 80% of the work falls to the CIO.”
So why is the CIO asked to do so much in what is essentially a business initiative?
Let’s use KPMG’s Value Delivery Framework to illustrate. In it are five stages of a business transformation — discovery, strategy, road map, implementation, and monitoring — and a number of activities such as program management that span the stages. Of the five stages, implementation requires the greatest effort. From talking with those who have been through it, the greatest implementation challenges are in data, enterprise process redesign, project management, and organizational change management. And for at least the first three areas, IT is the group that is required to commit the most resources to these areas because IT has the greatest depth of experience.
Look over a list of CIO requirements and you come up with Superman. Great skill in communication, strategy, business knowledge, IT knowledge, consistency with culture, operational knowledge, and ability to MacGyver a storage array with left over parts from an outdoor grill assembly. In short, these descriptions provide little guidance when selecting candidates – they demand everything.
I’ve had the opportunity recently to help companies choose their leaders of IT; specifically the CIO, leaders of the PMO and infrastructure. As someone who has redesigned hundreds of IT shops, I’v often been asked to identify attributes of successful IT leaders. I’ve found you need two pieces of information to determine the type of skills you need for your IT leader:
What are the problems and opportunities the organization will likely face over the next couple years?
How capable is the current staff at handling these?
I was talking with a client the other day about the reporting structure of her applications organization. The group had a single leader, but underneath, it was subdivided into groups that were a combination of technology (website, data analytics, intranet), business unit (four major ones), and IT processes (QA). The leader of this group knew that every organization is different based on the culture, size, maturity of managers and a dozen other factors. However, she was seeing a lot of friction between groups and wanted to know what structural changes other organizations had made and what the tradeoffs were.
We started by talking about the direction of the organization. In particular, she needed to determine if the business units were moving to greater integration of their data and processes or whether the business silos formed were just fine. Though most organizations are moving to greater integration, this is not an obvious answer, as some companies have run-off business areas that are in maintenance mode and may be kept separate. For this call, she asked that we assume the company needed greater integration. There were other drivers around growth and cost containment that we discussed as well.
We’d like to know what job responsibilities give CIOs insomnia, either by responding to this blog or by contacting us directly to be interviewed. The interviews will take less than an hour and go over this question as well as others including:
What decisions do you regularly make?
What sources of information do you use?
What IT decisions are made by IT versus the business?
We are in the early stages of interviews, but the initial responses to the question of what keeps CIOs up at night were very interesting. Some, as expected, focused on tactical and immediate problems. They included:
Security: “I don’t ever want to see [my company’s] name in the paper for a security problem.”
Small mistakes: “A tiny piece of code could have brought the organization to its knees.”
Turnover: “We have two people maintaining one of our ancient core systems, and both could retire soon.”
But there were unexpected responses in that they focused on the long term. Some of these long-term insomnia inducers were:
Investments: “Does the money I’m putting in now make sense for the future?”
Staff leadership: “Do I have the right mix of outsourced and internal staff?”
Reality: “I’m struggling matching reality with where we’re heading.”
An empowered BT model includes the idea that end users will take on some functions that are typically performed within an IT organization. These may include selecting and deploying applications, buying mobile devices, and contracting with services firms.
With factors such as increased availability of cloud applications, more IT-savvy businesspeople, and IT shops buried in maintenance of existing applications, there’s a lot on the side of increasing IT functions outside of IT. However, security and compliance concerns, the need to integrate apps and data, the complexity of these applications, and cost are just some of the constraints that are holding back this approach.
Whether there will be a trend towards functions moving out of the IT organization or the reverse, with IT taking on more control, empowered BT will happen in some organizations. When it does, there are things that CIOs can do to exploit this and minimize potential damage:
Shift senior IT people from “doing” to consulting and overseeing. Architects, for example, spend a significant amount of their time on projects (doing). Some of their time needs to be freed up to provide advice to businesspeople on how to make these functions scalable, secure, and integrated where necessary. Similarly, vendor managers need time to help businesspeople in the selection process for vendors.
Select for and build up negotiations skills. The leader of apps that speaks in technical terms, the security expert who generates every possible scenario as an argument for not doing something, and the architect who hoards information while making pronouncements on what the business should and should not do are working against you in an empowered BT world. With technically sophisticated end users and tools that can quickly build functionality, business requests leading to IT responses now become negotiations.
I’ve been researching why IT roles fail (or at least struggle mightily and often futily). The roles that come up most often are the ones that are not directly building or maintaining systems. These include architecture, planning, vendor management, relationship management, PMO, and security. As I’ve collected this information, there are themes emerging to explain why they fail. These include:
Wrong skills.An architect was told to define the standards fordata tools but lacked the skills to convince others they should care.
Inadequate capacity. Relationship managersat a midsized firmwere sold as strategic partners to business leaders but were also required to run large apps groups that had recently suffered layoffs.They just didn’t have time for the strategic bit.
Lack of support.The leader of vendor management was supposed to provide advice and oversight on which vendors were selected, butthe CIO did little to rein in other managers who previously had bought what they wanted from who they wanted.
Recently, Forrester surveyed a number of CIOs to collect benchmark data on staffing ratios and spending. This is a new initiative within Forrester and one that is not yet complete. We did this for three reasons:
Benchmark questions (called inquiries at Forrester) on staffing have become relatively common. Examples are “Can you tell us the average share of IT Staff as a % of total staff by organization size” and “Would you have specific spending figures for IT infrastructure?”.
This kind of data in conjunction with other data and analysis can identify problem areas.
Staffing benchmark data along with spending and other data are objective measures of IT organizations.
Though our initial sample size is small a preliminary view of the data shows that:
Process based IT organizations have become the rage. These are IT shops that group people around the processes they support, such as software distribution or requirements definition, or by business processes such as claims management. In contrast, traditional shops group people by technologies (e.g. mainframe, desktop), internal customers (e.g. wealth management, retail banking), or geographies (e.g. France, Asia).
There are two types of process based organizations – IT and business. IT process organizations typically follow ITIL for infrastructure and a software lifecycle for applications. Using ITIL, they form groups around process associated with problem management, storage, or configuration management. For applications groups, they may have people dedicated to requirements development, coding or testing. Business process based IT shops are less prevalent but may include IT associated with claims processing in an insurance company or collections in a credit card company.