5 Tips for Implementing a New IT Operating Model

When asked to explain the meaning of a Technology Operating Model in layman’s terms, a former colleague of mine remarked pithily: “Well, it’s the way we do stuff around here”. In the years that have passed since, I have not yet been able to come up with an alternate description that so perfectly marries precision with brevity.

The longer form definition describes it as the way the Information Technology department operates, internally and externally. It encompasses how the department executes and interacts with its customers, how it delivers products and services, and the governance that underpins all its activities.

There has been significant discussion about the importance of an IT Operating Model recently. Bain Consulting described it this way: “Companies are spending more on technology, yet major transformations usually fail. Often the problem lies with the IT organization itself: team members with critical skills aren't empowered to use them, Agile delivery isn’t bringing the expected benefits, and the organization is unable to react quickly to changes in the technology landscape. A Technology Operating Model enables high-velocity change, consistent governance and a comprehensive talent strategy that ensures your IT organization is set up for success." 

So, if the Operating Model is such a vital cog to both transformations and everyday operations, why don’t more IT Leaders consider making the changes that are requisite to success. The answer, perhaps, lies in the definition itself. Changing the very mechanism of how a large function operates is comparable to open heart surgery. There is significant risk involved and it may evolve into a major change management exercise. Given the other priorities a CIO is often juggling, it can be a challenge to take on. However, the benefits that can be derived, once implemented successfully, are substantial.

Having had the opportunity to successfully implement a new operating model in the recent past, here are five common-sense ideas to keep in mind as you approach this initiative.

1. Have a compelling reason.

Implementing a new Technology Operating Model is no small undertaking, so the business reasons for doing it need to be sound. In my case, the organization was coming to the end of an arduous digital transformation journey. The transformation had largely been IT-led, and while it had achieved significant results from an implementation of new technology perspective, it had come at a cost.

Six years of digital transformation had been condensed into three and internal, external, and business resources were burned out from the death march. To make matters worse, not all technology had been readily adopted by the business and the IT-Business relationship was turning adversarial. As I surveyed the near future landscape, I realized that things would need to change, and fast. If they didn’t, the organization could run into several problems:

• There would likely be high turnover on the technology side as the hours being demanded by the projects, along with the fire drills and finger pointing emanating from post implementation issues were not sustainable. Accelerated digital transformation was taking a toll.
  
  
• The business-technology dynamic was poor and impacting business participation, adoption, ownership, and general morale. There was a real risk that return on IT investment would not be realized due to these issues.
  
  
• The IT organization itself was set up as a core-flex projectized model with the majority of work being delivered by consultants. This would need to change as we moved into a sustainment phase aimed at adoption, continuous improvement and “building on the change.” The IT Team needed to be business-agile and work closely with the business to deliver new, game-changing functionality on the platforms already implemented.

The Gartner Framework that I used (detailed in the next section), also lists some trigger events and potential operating model changes. Examples include:

• Digital business model changes
• Enterprise changes like M&A or divestment
• IT strategy-driven changes
• Industry changes driven by market dynamics or regulation

In retrospect, my compelling trigger event was relevant to digital business model changes while also being linked to IT strategy. Find the broad category you fit into. Then clearly articulate the benefits or alternately, outline the downsides of not making the change.

2. Use a framework (mostly).

The good news here is that you don’t have to reinvent the wheel. Frameworks to implement a new Technology Operating Model exist for little or no cost in the public domain. However, you may find it useful to leverage a trusted consulting partner here. A quick Google search reveals several models or frameworks from Deloitte, KMPG, McKinsey et. al., all of which may be applied to this purpose. Two things to keep in mind when evaluating these frameworks:

1. Use the magnitude of change you are considering and your organization as your lens, as you evaluate the framework. You will find that some frameworks resonate with you immediately, as they fit your needs better than others.
2. Fit the framework to the problem and not vice versa. It is completely OK to discard components of the framework if they either represent areas that do not need change, can be delivered as a Phase 2, or are not relevant to the problem you are trying to solve.

I used the Gartner Model (below) since I could leverage my existing Gartner relationship with access to Analysts who had crafted the framework. I applied the framework to the issue I was trying to resolve and shaped a vision of what each hexagon would mean in the new operating model I was designing. In some cases, e.g., Tools, there was no foreseeable change. In others, we would significantly transform the current mode of operations.

Once I had my vision in place with the future state mapped out, I was able to interact with the Analyst who had built the framework, to both vet my work and challenge its shortcomings, if any. This was invaluable, and you may not have this level of access, but the base approach can still hold. If you decide to leverage limited consulting dollars to help with this, it is prudent to take a first pass internally before you engage with a partner.

One of the analysts responsible for crafting the framework came back with modest changes which were easily accommodated and did not materially change my future vision. She appreciated that I had not attempted to address areas where issues didn’t exist. Bottom line, use a framework to structure your approach, but only where it makes sense.

Note: The Gartner model itself has been updated in 2022 to accommodate a Digital Business focus. It’s core premise, however, remains consistent with the version I used.

3. Seek a champion (or several).

Your framework will likely address some form of IT / Business Interaction. In the Gartner model above, the “Engage” tower was meaningful in this regard. From a “Performance” Standpoint, I wanted to measure and report Technology KPIs but wanted the Business to provide opinion on which ones were meaningful to them. Therefore, an IT Balanced Scorecard was crafted with significant business input. An early draft version of the BSC is shown below:

I also wanted to upend the current IT / Business dynamic. Rather than have IT drive technology initiatives, the “Decision Rights” would manifest in a Technology Steering Committee with the Business deeply involved in it. This wasn’t a completely novel idea for the company as such committees had existed before. However, their remits were loosely defined and their scope broad. In the new world, with ground rules clearly defined, IT would act as steward and bring ideas to the table and as always, execute on programs. The Business would act as project champions, second resources to participate, and always have skin in the game. IT and Business would work hand in glove to deliver initiatives – again, not a new concept but one with guard-rails around it in the form of clearly defined rules of engagement, transparency, and enhanced solidarity between functions.

From a “Financials” perspective, the IT Capex budget would be crafted with Business input in this forum, and they would have a say in what came first, when there were competing #1 priorities. The Tech Steering Committee also provided an open forum for resolving any program or operational issues in a positive manner.

From the examples above, it was apparent that success required a high degree of business involvement, at every level. To ensure executive buy-in, this required a great amount of socialization and clear articulation of the benefits this would bring to each individual function. It also required a champion to make this a priority for everyone, which in this case, was the CEO. While operationally focused, he clearly saw the issues prevalent in the current dynamic along with its inherent downside if changes weren’t forthcoming. He then proceeded to make this a priority for the executive suite. While this opened the doors for this initiative, it was by no means a done deal.

The executive suite still needed to be persuaded at a personal level relative to the benefits particular to their individual units. Be prepared for this. A single pitch deck will not work in most cases. I had several, depending on whom I was speaking with, each tailored to the function in question. However, once you have the leader of the function convinced, the going becomes a lot easier. Remember that culture permeates top down, and you will need the senior leaders to “walk the walk" of executing as one team. So, seek a champion, or several.

4. Be bold.

I was very mindful of the fact that I was about to get an opportunity to make meaningful change, which is rare. That spurred me to be bold and challenge the status quo – I would urge you do to the same.

For instance, in the “Places” hexagon, I would advocate that IT move from a culture of presenteeism to one of flexible location policy with hoteling stations for whoever wanted to come into the office. This, because we prized agility, productivity, and employee satisfaction more than being in the office. This might sound passé in the post-pandemic world, but this was before Covid changed mindsets, and in an organization where “WFH” was generally not entertained.

Another example came under “Sourcing and Alliances.” I was going to change the way we interact with our suppliers, consolidating them to a chosen few and challenging them to think beyond simply transactional and emerge as strategic partners. For instance, it would require them to upskill current, commoditized, outsourced resources to keep in lockstep with our ongoing digital transformation activities.

The illustrations above resonated with us and formed part of our recommendations. They were sourced from surveying the leadership teams, our associates, philosophical discussions with our consulting partners, researching future trends online and blue-sky conversations with peer leaders, as well as forums such as Society of Information Management (SIM). Tip: Involve HR leadership from your organization into the mix early as an ally. HR usually has their ear to the ground on trends regarding what associates want, the future of work. They can also help navigate internal dynamics and assist with change management to achieve the results you seek.

Be unafraid to seek advice from multiple sources that you can distill into the final product. Be bold and build for the future.

5. Do it in phases.

We have all heard the term “Boil the ocean” in business. But did you know that it is attributed to the American humorist Will Rogers, who suggested it as an approach to deal with German U-Boats during World War II? Of course, he then also said that he wasn’t concerned with “how” since he was not worried about details. As you well know, the term addresses the issue of solving complex problems by breaking them into manageable units versus addressing the entire vast scope simultaneously.

The concept was applicable to rolling out a new Operating Model. The approach I took was:

It was vital that the program be initialized with quick wins that could be built upon. This included both intra-IT activities as well as IT/Business ones. The IT/Finance dynamic was the closest thing to a finished article that we wanted to emulate with other functions. Finance was an established superuser community with functional leads for projects, full support at the executive level and a great desire to use modern, efficient platforms and processes. It was used as a template for the other functions. The Technology Steering Committee was seeded with key operators to start with and gradually expanded as the business saw value.

Individual IT groups were given latitude to set group level goals regarding ways of working that were experimented with and eventually rolled up into a department-level policy that worked for most. We found that some models worked better than others relative to productivity, communication, collaboration, and agility. Agile solution delivery models, built on the digital platforms just implemented were organized around services and products with approaches, methods, roles, and rewards clearly defined. This too, took a few iterations to fine-tune and get right.

From an overall project perspective, this took three months to design and socialize and six months to pilot, fine-tune and complete the roll out. Rolling out an Operating Model isn’t a quick fix and cannot be rushed. It requires patience, tact, the ability to build alliances and openness to opinions that are contrarian. Plan for this and resource for it, as you will have to carve this initiative into workstreams and assign leaders to execute that are in lockstep with your vision. As CIO, you will need to be the face of the effort and do the heavy lifting to influence at the C-level and presumably the level below. 

In conclusion, implementing a new IT operating model is a big initiative with many moving parts. Start small and establish credibility before moving on. You will find that new, previously unknown learnings emerge from each implemented phase that are very applicable to the next one.