When an IT service management (ITSM) transformation is planned, most of the ITSM transformation’s structured effort goes into the parts you can specify in advance: platform selection, data migration, process design, integrations, and the go-live date. These parts have owners, budgets, and milestones that a program board can track. The leaders who sponsor the new operating model and the managers and practitioners who’ll work inside it are usually covered by a communications plan and a training schedule, assuming they’ll adopt the new model once the technical work is done. Adoption rarely appears on the program’s risk register alongside migration or integration risk, and the work needed to win these groups’ buy-in isn’t planned or resourced the way the technical workstreams are.
ITSM Transformation: People and Adoption
If people did adopt it once the technical work was done, more ITSM transformations would succeed. Bain & Company’s 2024 research found that only 12% of business transformations achieve their original ambitions, a figure I looked at in an earlier piece on simulation-based learning in ITSM.
Gartner’s research points to people as the reason: it reported in October 2025 that only 45% of employees said they’d realized the change goals their organization set, and in a separate 2025 survey, only 32% of mid-to-senior business leaders said the last change they led had been adopted by employees on time and without undue strain.
These figures cover all industries, and my experience of ITSM transformations matches them: the ones that stall do so after go-live, when the people who sponsor and run services fall back on the decisions and habits the new model was meant to replace, and nothing in the program tested beforehand whether they would.
Sponsorship That Ends at Approval
Senior leaders approve an ITSM transformation based on a business case describing outcomes such as better availability and a lower cost to serve. Few of them work out what the new operating model will ask of them personally, such as which decisions they’ll have to stop making informally, what resources and budget they’ll really need to commit, or what they’ll do the first time a disciplined change process slows down something the business wants this week. When a leader overrides the process the first time it gets in the way, practitioners take that as a signal of how seriously the new model is meant to be taken.
In Emergn’s 2025 Global Intelligent Delusion survey of 751 organizations, carried out by Censuswide, 41% of respondents said leadership errors had contributed directly to transformation failure.
The same Gartner research that produced the 45% figure included an April 2025 survey of nearly 1,000 mid-to-senior business leaders, in which 36% said their teams were more likely to hold back and wait to see whether a change would last before adopting it.
The service management function rarely has the authority to enforce a new operating model by itself, so in ITSM, practitioners follow what senior leaders do under pressure more closely than anything written in the process documentation.
ITSM Transformation: Practitioners Who Have Seen It Before
A service desk analyst or change coordinator who has been through a platform replacement or two has seen for themselves that the way of working announced at launch and the way work gets done six months later aren’t always the same, and waiting to see whether a new model lasts is a reasonable response to that experience. Whether they stop waiting depends largely on their team leaders and middle managers, who set the tone for how change is received in their teams and whose commitment tells practitioners whether it’s worth engaging with.
Gartner’s research suggests that skepticism is widespread: an April 2025 survey of more than 2,850 employees found that 79% had low trust in their organization’s ability to deliver change, and the volume of change is adding to that.
In the Emergn survey, 50% of respondents reported transformation fatigue, 44% said change came too often, and 55% said AI initiatives were adding to their fatigue. ITSM teams are now adopting AI capabilities in their ITSM tools, often while another transformation is still under way.
During an ITSM transformation, change enablement asks engineers to follow a process when it feels like an obstacle and asks managers to back that process when a senior stakeholder wants an exception.
My earlier piece on the business case for experiential learning covered Uptime Institute data tracing most human error outages to procedures that weren’t followed or were flawed. The same thing happens during an ITSM transformation, when people under pressure revert to the old way of working.
What Communications and Training Leave Out
Communications explain that change is coming and why leadership wants it, and training explains the new processes and tool screens. Both are needed, and many organizations don’t get them right. In the Emergn survey, 42% of respondents reported insufficient training during transformations and 31% said they felt uninformed about transformation goals.
However, doing more of either won’t be enough, because neither lets people try the new model before they have to depend on it. In an ITSM operating model, a decision in one practice affects others: a rushed change leads to incidents weeks later, and an underfunded problem management team means more repeat tickets.
Training can explain these connections, but people only see them by experiencing the model and dealing with the consequences of their own decisions. Until then, a sponsor who has read the business case and a practitioner who has passed the training know how the model is supposed to work without having seen whether it does, or what’s expected of them when it’s under pressure.
Gartner’s 2025 research found that leading change through inspiration and a vision of the future only works where employees already trust their organization’s ability to change, and it advises leaders to build change skills that employees practice often enough for adoption to become instinctive.
Leaders and practitioners also wait on each other, because practitioners take their cue from what leaders do under pressure, and leaders judge the new model by whether practitioners appear to be making it work, so a program that prepares the two groups separately leaves each waiting for the other to commit first.
ITSM Transformation: Preparing the People Layer Before Go Live
One way to prepare both groups is to have them run the new model together before it goes live, which is what SXP’s simulations are built for. The people who’ll sponsor, manage, and operate the model work through it in the same session, in person or virtually, running a realistic business through compressed cycles representing months of operation.
This business can be an off-the-shelf one, such as an airline or an online retailer, or one configured to their own organization and the platform they’re implementing. The participants make decisions about incidents, changes, investment, and service levels, and the results of these decisions feed into later cycles. They can also see what happens when a new technology such as artificial intelligence (AI) is deployed before the processes, data, and skills it depends on are mature.
Run alongside training, a simulation session lets leaders find out what sponsorship asks of them when the model is under strain, in front of the practitioners who’ll be judging how they respond. These practitioners see the new model work, or fail, as a result of decisions made by people they know. Both groups also get the repeated practice the Gartner research recommends, and the cost of a bad decision stays inside the simulated business.
Some constraints are structural, for example, where ITSM has no say in how priorities are set or where the change process can’t approve changes at the speed the business needs. A simulation session will make those constraints visible to the people who can change them, but the fix is still organizational. The earlier business case article covers those limits in more detail, and the article on applied judgment covers how simulation works alongside training.
Planning the People Layer as a Workstream
If fewer than half of employees realize the change goals set for them, and only a third of leaders see the last change they led adopted on time and without undue strain, the people layer is where an ITSM transformation is most likely to fall short.
Most ITSM transformation plans don’t reflect this, giving the platform an owner, a budget, and a schedule, and giving the people layer a communications plan. The experiential learning that builds buy-in and adoption is also missing when organizations look at why their previous ITSM transformations fell short, so the same people layer issues carry into the next program.
The people layer needs the same treatment as the platform: an owner, a budget, and a schedule for the buy-in work, and a place on the risk register alongside migration and integration. It also needs preparation that starts with senior stakeholders before the decision to proceed, and ends with a readiness test before go-live, involving the leaders and practitioners whose decisions will determine whether the new model is used.
ITSM Transformation FAQs
It’s the leaders who sponsor the transformation and the managers and practitioners who operate the new model day to day. Their decisions and habits under pressure determine whether the operating model is used as designed after go-live, regardless of the platform and process designs.
Leaders often approve an ITSM transformation without working out what it will ask of them. What the leadership team agrees to at approval tends to fall away when each leader has to commit time, people and budget from their part of the organization, particularly when those commitments weren’t made clear at the planning stage. How leaders behave when the new process slows down something the business wants then tells practitioners how seriously to take the model. In Emergn’s 2025 survey, 41% of respondents said leadership errors had contributed directly to transformation failure.
Training builds knowledge of the processes and tools, and people need that knowledge, but it doesn’t let them run the model as a connected system or see the consequences of their decisions before go-live. People come away knowing the theory, without the experience of seeing the model work that would convince them it’s worth committing to.
In stages, planned alongside the technical workstreams. It should start with senior stakeholders, influencers and leaders before the decision to proceed is made, so they’re aligned and fully aware of what they’re signing up to, because leaders need to buy in as much as practitioners do. The project team should follow at kick-off, so they understand the people risks and can build mitigations into the roll-out plans. Leaders and practitioners should then prepare together before go-live, so each group sees how the other behaves when the model is under pressure.
Henry Strouts
Henry Strouts is a co-founder and Director of SXP Limited, a software business that develops serious games and business simulations that raise situational awareness and breakthrough understanding of new models and ways of working, including best practice frameworks and enterprise software solutions. Henry has been developing and delivering experiential learning for 30+ years, working with teams and executives to drive performance outcomes, whether in support of technology sales or organizational transformation. He has worked with many of the world’s largest vendors and enterprises, and his extensive industry knowledge supports the creation of highly relevant, business-issue-focused simulations designed to resonate with the transformation challenges organizations face today.
