“IT is too slow.” It’s a refrain heard all too often from business leaders in a variety of industries and especially from organizations undergoing digital transformations. Once upon a time, traditional IT shops could complain about unrealistic customer expectations and, with some legitimacy, the need to slow down to control risks. However, in the era of digital business, time to market is critical, and slow IT may represent the biggest risk of all. Worse still, many IT shops are too late to realize just how slow they are and wake up to find the business looking for IT support from outside the organization. This article discusses some of the reasons why traditional or “trad” IT is struggling to support the business. Along the way, we will also explore topics such as the volatile nature of digital business, relationship management, demand management, agile software development, DevOps, bi-modal and dual pace IT. Read on to learn how to prevent your IT shop from becoming obsolete and outsourced.
How the rest of the organization views IT: They Just Don’t Understand Us
We were hired by the IT department of a well-regarded company that has been around for more than a hundred years to conduct an assessment of their “bread and butter” service management processes including: Incident Management, Change Management (what is now called Change Enablement), and Problem Management. During a group interview with key stakeholders in the Marketing Department, I inquired about the relationship between IT and the business. “They just don’t understand us,” was the almost-embarrassed but unequivocal reply from the Director of Marketing. He continued, “I feel bad for them. I know they have had budget cuts and have lost a lot of staff, but we’ve all been under the same strain. IT is just too slow with everything they do.”
The organization – let’s call them ACME – had thrived for decades on a tried-and-true commodity product that just about everybody in the Western world knows. But within a shockingly short time, consumers stopped caring. ACME plunged almost overnight into financial distress, shed approximately 50% of its employees over a seven-month period, and struggled to find a more saleable product or service. While the business searched for a reason-to-be, IT languished. They bore the brunt of layoffs as IT staff was reduced from a high of about 600 employees to just over 200, a reduction of two-thirds. In addition to supporting business and administrative systems, IT supported the systems that produced ACME’s now-defunct product, so staff layoffs were not surprising, but the magnitude of them caught IT off-guard. Even the CIO was let go and replaced by a mid-level manager who was promoted to director of IT and all but barred from the executive boardroom.
I pressed further: “What’s so slow about IT?”
“Just about everything. It takes forever and a day to get something simple like a new laptop or monitor. It takes almost a week for them to grant employee access to important applications. And changes to the infrastructure take weeks to be reviewed and approved . . . and then they still fail. On top of everything else, they don’t even understand the basic technologies we use in Marketing. When we asked them to roll-out new code, even when they have the skills to write it, by the time they roll it out into production, our requirements have changed.”
The unspoken obvious to just about everybody was that senior leadership was seriously considering outsourcing IT to a managed service provider. The threat of outsourcing was evident to everybody, that is, except IT, which was mostly oblivious.
The Long Rapid Decline
ACME, similar to many heritage companies, spent decades establishing a “household” brand. In fact, their primary product (and the business model supporting it) had not significantly changed in decades and was even more successful in the first decade of this century than the last. As recently as 2005, serious business publications hailed the surprising success of ACME’s uncomplicated product in a world where technological wizardry began to dominate. (Ironically, the simple product was itself a response to a technology revolution more than one hundred years earlier.) The prevailing attitude amongst leadership was “if it’s not broke, don’t fix it.” In short, ACME was successful; and if not growing, it was at least steady. Until suddenly no one cared.
The product decline was reminiscent of what happened to men’s suits a few years after the end of World War II. Tired of wearing the contricting uniform of the soldier and wanting to forget the pain of war, men, en masse, abandoned the business suit in favor of more casual garments. A fabric shortage further nudged the suit industry in a more austere or “square” direction. It was really the confluence of several hard-to-predict factors that contributed, seemingly overnight, to the suit’s decline.
For ACME, almost overnight, business-to-business and business-to-consumer sales dropped by more than 40% with no corresponding macroeconomic downturn. It was as though a large group of disgruntled customers conspired to bring down ACME. Yet there was no boycott and no conscious subterfuge on the part of consumers. There was no one obvious competitor on the horizon, no Amazon of goliath proportions who swooped into the marketplace to wreak havoc. Moreover, despite consistent technological advancements, there was no single “killer app,” digital platform, or whiz-bang piece of software that posed a clear and present digital threat. Instead, the rapid decline crashed into the executive suite like a big black swan that lost its GPS.
Prior to the crash, ACME’s IT department was seemingly well-placed as the custodian of the mystical technology “black box,” the ones that executives assumed they needed but would rather know less about lest they disturb the malevolent spirits lurking there. Less sinister and more mundane, IT performed all the basic functions – provisioned desktops, laptops, and desk phones to employees, deployed standard software, managed servers and infrastructure, and managed the ERP system. There was a Help Desk (it would be a bridge too far to call it a Service Desk that did more than just answer calls and route tickets), a Networking Team, an E-mail Team, Application Developers, an AV crew of one, a couple of guys who called themselves Security, and a few other basic functions. Outside of this structure, IT’s biggest project was working with a third party vendor to implement a bare-bones ERP system and supporting a few simple applications that helped manage ACME’s core product. In many ways, ACME IT was the mechanic shop for a business that did not need much in terms of technology support beyond the basics.
Although ACME did not have complicated technology requirements internally, the fact was that consumer-facing technologies and consumer preferences had been changing gradually during the twenty years preceding ACME’s black swan event. For the most part, no single technology loomed as a threat. The popularization of the Internet in the early 1990s was the most obvious technological threat to ACME. At the time, a few executives recognized this, but instead of seeing it as an opportunity to expand and revolutionize their product, they saw it as a threat and doubled-down on extolling the virtues of their simple 19th century product. And this approach seemed to work for a while. But other seemingly unrelated technology developments were afoot. Consumers increasingly relied on mobile phones and cellular technology to support their “on-the-go” lifestyles. The eventual rise of smartphones and “apps” on these devices democratized the use of technology to the extent that many of the services the business used to provide and charge their customers for, customers could now do for themselves for free. Regional and National demographics in the United States were changing, but nobody at ACME was aware of this trend or tying it back to the business. Competitors, on the other hand, were voraciously collecting and mining data and trying to figure out how to translate this into new consumer offerings. In fact, a European company selling a product similar to ACME (not one of ACME’s competitors), recognized the gathering storm and started to work on a new digital product and digital operating model.
ACME IT started to recognize small changes as well: Increasing security-related events; greater frequency of major incidents; increased offerings from cloud providers; requests for data from disparate parts of the organization. They also experienced a stagnant (though not reduced) budget . . . but nothing that seemed revolutionary.
The Rise of Digital Business
Like the proverbial “boiling frog,” ACME was slow to recognize latent danger because numerous small threats eroded its relevance over a long period of time. The final insult, whatever triggered the rapid demise, hardly matters. For many organizations, the threats posed by digital technology and new competitors will be more obvious and imminent. In fact, according to Forbes, in 2019 alone it is estimated that organizations spent more than $2 trillion on digital transformation initiatives, which includes spending on both digital technologies and digital business models. True enough . . . not all these digital campaigns will succeed, but at least many organizations are aware of the threat and are actively trying to reduce risk or create new opportunities.
The same cannot be said of their IT departments. Already befuddled by trying to understand business needs, they fall further behind when trying to deliver the basics – simple things like new laptops and deploying standard software and quickly responding to and resolving incidents. Then, when the need to learn new technology like Cloud, data management systems, or artificial intelligence is thrown into the mix, IT resists training because given other work, staff simply does not have the time – even when budget is available.
It is no wonder that when organizations look to digitally transform, they often see outsourcing IT as a “no brainer” and include this approach as part of their digital first strategies. Indeed, According to CFO.com, IT outsourcing is at a five-year high.
The Origins of Slow IT
Slow IT does not develop quickly. It is usually the culmination of many years’ worth of missed opportunities by both business and IT leadership and misaligned strategic and tactical decisions. In fact, the lack of alignment or even integration between the business and IT may be the original culprit. Fundamentally, the root causes include poor relationships, reactive demand management, and inappropriate risk management and controls.
These issues can all be complex challenges to solve, and the order in which they should or can be addressed varies from organization to organization. Although “big picture” prioritization may prove elusive, many small, less strategic opportunities can be developed simultaneously. In the following sections, we will discuss a few areas that we have found can help, including building stronger relationships throughout the organization, understanding customer demands, elevating how technology-focused changes are managed, embracing more agile ways of working, leveraging dual-paced or bi-model approaches to IT, and being open to IT as a service broker.
Relationship Management: Starting the Conversation
For IT to effectively support the business (let alone partner with it), it needs to have an understanding of the strategic direction the business is going, what priorities exist, and how IT can best tactically support business initiatives. In the absence of a substantive relationship, IT usually appears slow because even if it is efficient, it is likely working on the wrong things and has to play catch up supporting strategic objectives. In ACME’s case, it was easy for the business to eject the CIO and replace him with a lower level director because no relationship, beyond transactional, existed. For many organizations, a full-blown Relationship Management Practice, complete with dedicated resources, is sorely needed but hard to justify. Yet key elements can be put in place to gradually improve collaboration between IT and the rest of the organization. At a minimum, IT leadership should establish a touchpoint and schedule routine conversations with key business leaders. In many cases, the business will welcome a closer relationship with IT, especially if IT can demonstrate “what’s in it” for the business. However, sometimes the business shrugs this kind of relationship off and expects IT to magically understand business needs and focus solely on technology. In truth, this perverse attitude is difficult to remediate.
With Relationship Management, start small and celebrate quick wins.
Another one of our clients, a senior IT director faced with a similar situation, invited a key business executive to coffee to discuss creating a VIP incident management and service request process for the C-suite to expedite response and resolution for key leaders. In this case, getting the proverbial “foot in the door” involved friendly consideration. It was hardly strategic in nature. Yet it helped to start a conversation, and after several months, IT leadership began to receive invitations to some key leadership meetings. It should come as no surprise that relationships take time to blossom, so starting small and celebrating quick, small wins is a reasonable approach.
Understanding Demand Patterns: Developing a proactive mindset
Demand Management helps to further small wins in Relationship Management by promoting a proactive mindset amongst IT leadership. Simply stated, Demand Management is about understanding what customers want and when they want it. Demand Management is often called the “economics” of IT service management because it compels IT to consider not only customer “pull” but also the ability to supply what the customer needs (as shown in the figure below). After all, if IT does not have the capacity or resources to fulfill internal demand in a timely manner, customer dissatisfaction with slow, reactive IT festers. For example, lacking a service catalog and customer-facing portal, ACME did not have any automation support for receiving and processing requests from internal customers. Standard requests, like new laptop provisioning, mobile device deployments, and employee onboarding and offboarding were handled by e-mails sent to various IT work queues. This rudimentary technique made it difficult for IT to track tickets, impossible to perform reporting and trend analysis, and compelled customers to repeatedly call IT to track the status of requests – all characteristics of slow, reactive IT.
The Supply and Demand of IT Service
Ideally, automation management systems and IT Service Management tools that can track customer service requests; and even server availability monitoring systems go a long way in supporting a better understanding of demand. IT departments that lack these tools will find it difficult to improve planning processes, but that is no excuse for not trying. Simple conversations with frequent customers can give organizations at least a ballpark estimate of what is in high demand; if not when or how much. One technique I have found useful is to identify somewhere between 15 and 30 business customers (you can adjust this number depending on the size of your overall organization) to participate in customer focus/feedback groups. The ideal customer participant consumes and requests IT services on a routine basis (either for themselves or on behalf of others), is somebody you can trust to provide honest feedback, and who will not “throw you under the bus” when IT makes a mistake. Although this technique is not data-driven and does not provide the immediate data that a tool does, it has the positive side-effect of improving customer relationships.
Understanding demand is a good practice for IT to develop to prepare for digital transformation.
To take the conversation a step further, Demand Management is a good practice (or really a collection of practices) to develop within IT organizations to prepare for a digital transformation of the overall business. In a truly digital organization, Demand Management goes well beyond IT understanding internal patterns of business activity and planning for the internal business. It extends to “demand shaping” where the larger business attempts to influence and “shape” what external consumers want and drive preferences in the channels they use to procure it.
Reimagining how to harness change
One of the first areas to assess when revving-up IT is how changes are managed. In this instance, we are not talking about organizational and culture change (though both are critically important); instead, the focus is on technology-focused changes. Often thought of as an IT-centric practice reserved for “gear heads,” in fact, making technology-related changes happen as efficiently as possible is key to digital transformation.
ITIL best practice defines a change as “The addition, modification or removal of anything that could have an effect on IT services.” What this means in the context of digital transformation is releasing new code or software in general, hardware, etc. and deploying it to production, and many IT departments simply do not do this quickly enough to support a business operating in a volatile environment where time to market is critical.
Change enablement is fundamentally about managing risk, ensuring that a technology-related change does not cause disruption to a live production environment. Organizations usually try to apply control by assembling a change authority (sometimes known as a change advisory board or change control board) that meets to review requests for change submitted by technical staff and to determine whether the risks are understood well enough to safely implement the change. When properly executed, this can work well for swapping out servers, implementing infrastructure, or rolling out new software or major version releases. But applying this amount of control takes too much time for frequent and minor releases associated with external customer-facing software and platforms (often called “systems of engagement”).
The Spectrum of Changes
The answer, however, is not to do away with change enablement altogether. To be honest, most IT shops do not place enough control around the changes that require it and too much around the ones that do not. The answer is to apply the appropriate amount of control depending on the type of change being made. When thought of as a spectrum, at one end, organizations that apply no control are highly-flexible, but they also lack the predictability
that is required by infrastructure and back-end systems (often called “systems of record”). At the other end, organizations that apply too much control are highly-predictable but also highly inflexible. Finding the right balance between risk and control and speed and flexibility is no small task.
Where Organizations Sit in Relation to Change
At ACME, hundreds of changes were reviewed by a change advisory board of about 30 people that met once per week for about an hour. On paper, the change documentation and the meeting itself suggested thorough risk review. In fact, it was more of a rubber stamp process. There were so many changes to discuss that each change was reviewed for just a few seconds without any real risk review. We helped them by reducing the number of people that had to be involed in discussing enterprise-wide changes (those on the change advisory board) from 30 to 10 senior IT staff members. We also identified about 100 low risk changes – patches, routine batch jobs, and the like – and obtained approval to create “standard” changes that were pre-authorized and didn’t need review. These changes freed-up time in the CAB meetings for members to perform more meaningful review of riskier changes.
But what about software development, “bugs,” “hot fixes,” and deployments from one environment to another? Should these types of changes undergo the same amount of scrutiny? We will discuss these types of changes in the next section.
The Rise of Agile and DevOps
Agile software development and DevOps have both emerged as complements of traditional change enablement. In agile software development, the team breaks development down into small increments. This approach often includes the release of new features as well as fixing bugs. Releases typically do not undergo the sort of traditional change enablement described in the previous section. Instead, the team manages risk by working closely with customers from start to end, collaborating on a daily basis with others on the team, and releasing features every two to four weeks. In addition to delivering features more frequently, the changes being made are reviewed by the team throughout the process, and they are small in nature so that even if a failure occurs, it is unlikely to be highly impactful.
DevOps takes this approach a step further. In more “old school” IT settings, software developers rarely take into consideration operational issues after deployment. This can lead to increased risk and unpredictability in the live environment. In a DevOps culture, developers and IT operations work collaboratively, typically as part of the same team. All developers check in their code and automatically integrate it on a continual basis to ensure that errors are caught immediately (often using automated testing tools) instead of producing significantly more code and detecting errors much later during compilation. Some traditionalists wonder whether there is less control and more risk in using an agile and Devops approach than with a more “traditional” approach to managing change. The short answer is “no,” if done the right way.
At ACME, a DevOps transformation was too radical to introduce since it involved a significant cultural change that IT was simply not yet ready to embrace. However, there were already a few pockets of agile development teams. Forming them into a community of practice helped them to share lessons learned, and over a short period of time, certain development projects were moved away from traditional change enablement and addressed using an agile approach.
The Path Forward: Bi-Modal and Dual-Pace IT
Some leading digital transformation gurus suggest that the only path forward for traditional IT is for it to become fully integrated with the business. Moreover, certain radical schools of thought bristle at any IT framework, structure, or best practice. For these extremists, even well-respected practices such as ITIL, DevOps, and Agile get in the way of getting work done. In the perfect world, a model where the business and IT are fully integrated may indeed be ideal. However, not all organizations are there yet, and a more reasonable approach is emerging that suggests embracing both bi-modal and dual-pace IT.
Bi-modal IT describes an approach that embraces both experimentation and rapid development as well as traditional IT, which continues to focus on “keeping the lights on” by maintaining infrastructure and delivering IT services to internal customers. Dual pace IT describes an organization that leverages both high velocity and low velocity IT, which we will detail further here.
High Velocity IT
High velocity IT focuses on developing products, software platforms, and systems of engagement for external consumers. In this setting, short time-to-market necessitates rapid development, usually accomplished by some combination of agile software development and DevOps. High velocity reduces speed/velocity risks; but potentially introduces quality risks.
The Effects of High Velocity
Low Velocity IT
Low velocity IT is characterized by tight control and mitigating risks to the core infrastructure. Low velocity IT often serves as custodian for underlying infrastructure and “systems of record” like Enterprise Resource Planning (ERP) and Financial Management Systems, which are critical to internal operations but are not consumer-facing. Low velocity IT reduces quality risks; but at the same time, it introduces risks associated with slowness.
The Effects of Low Velocity IT
There is a growing recognition that systems of record are not going away anytime soon. This means choosing to outsource IT entirely (and hoping that a third party can keep the ERP system up and running) or keeping low velocity IT in-house (albeit with some acceleration and improvements).
Of course bi-modal and dual-pace IT arrangements imply a tale of two ITs: one whose focus is primarily external and using newer, more complex and unpredictable technologies; the other’s whose focus is on using legacy technology that is slow but predictable. Although “shadow IT” are dirty words in many contexts, it may work well in these novel models.
IT as Service Broker
A third opportunity exists for IT as a service broker. And this is the option that ACME decided to pursue. ACME’s low velocity IT department established a service management center of excellence to improve and stabilize service delivery for the internal organization. Core activities revolved around maintaining the infrastructure and systems of record but also in improving relationships with business executives, gaining a better understanding of the tools needed by internal customers, and working with the business to set appropriate expectations around delivery timeframes. They even expanded beyond IT service delivery by convincing other internal service providers (Facilities and Human Resources) to use their existing IT Service Management platform to manage non-IT services.
Although ACME is still a work in progress and the ultimate fate of IT is still not clear, there are some good signs. Despite some initial animosity between traditional IT and the digital team in Marketing, the digital team recently decided to let a cloud contract expire and let IT manage the server on-premise. It took some time, but it is still progress.