Kobayashi Maru Change Management: Why the No-Win Scenario Isn't Real
Ann Marvin · IMA Worldwide · Published: September 21, 2026 · Updated: September 21, 2026 · 8 min read
Quick Answer. The Kobayashi Maru is Starfleet's no-win simulation, and most change programs are run exactly the same way: the ship goes live, the crew does its best, and the loss is absorbed as the cost of doing business. James Kirk passed the test by changing its conditions before it ran. In change management, the conditions are sponsorship, target readiness, and reinforcement, and every one of them is a setting the program controls. The failure rate persists because we keep treating it as physics when it is a configuration. Here is what reprogramming the test looks like.
What is the Kobayashi Maru, and why do change leaders keep taking it?
I will confess something up front. I have always been a Kirk person. Not a Picard person, and not a Spock person, though I understand why people are. The scene that made me one is the Starfleet Academy simulation in Star Trek II: The Wrath of Khan (1982). A freighter called the Kobayashi Maru is stranded in the Neutral Zone. Cross the line to rescue it and Klingon warships destroy you. Stay put and the freighter's crew dies. The test is designed so that there is no winning move. It measures how a cadet behaves when losing is certain.
Kirk rewrote the simulation so the ship could be rescued, and Starfleet gave him a commendation for original thinking. When his protege asks how he did it, his answer is seven words long: "I don't believe in the no-win scenario." That line is the reason I do this work.
Because here is what I see in almost every transformation I am asked to look at. The organization has accepted the no-win scenario as the terms of the test. The system will go live. Some percentage of people will never really use it. Leaders will say the right things at the kickoff and then go back to their day jobs. The budget for support will be cut in the last quarter. And when the results come in, everyone will nod and say that change is hard, as if the Klingons were a law of nature rather than a line of code.
The no-win scenario is not the situation. It is the assumption that the situation cannot be changed.
Which no-win scenarios are we running right now?
Three of them are on my desk this month, and I suspect at least one is on yours.
The first is the ERP deadline. SAP has published December 31, 2027 as the end of mainstream maintenance for ECC, with no extension, and program teams across every industry are running ERP and technology changes against that calendar. The test conditions, as most teams accept them, are: hit the date, migrate the data, train people once, and hope. The date is real. The rest of the conditions are choices.
The second is the AI pilot. MIT Media Lab's Project NANDA report, The GenAI Divide: State of AI in Business (2025), studied 300 public deployments alongside interviews and surveys of more than 200 executives and found that 95 percent of the enterprise generative AI pilots examined delivered no measurable profit and loss impact (Forbes, 2025). The successful minority won on workflow integration, not model quality. In other words, the pilots that passed were the ones that treated AI adoption as a change management problem and changed the conditions people were working under. The rest ran the simulation as written.
The third is the merger. Clayton Christensen and his co-authors, writing in Harvard Business Review, 2011, put the failure rate for mergers and acquisitions between 70 and 90 percent. That number has been quoted so often it has become wallpaper, which is exactly the problem. When a failure rate has been stable for that long, the people quoting it have stopped asking whether it is a property of mergers or a property of how post-merger integration is run. The acquiring company closes the deal, announces the new structure, and waits for two cultures to sort themselves out. That is the freighter in the Neutral Zone.
Notice what the three have in common. In each case there is a hard external fact and a set of soft internal conditions that everyone treats as equally fixed. They are not. The hard fact is the Klingons. Everything else is the program.
The Klingons: fixed
The vendor deadline (ECC, December 31, 2027)
The technology (the model, the platform)
The signed deal (the merger is closing)
Real, external, and not yours to move.
The program: settings
Whether sponsors are contracted or just supportive
Whether readiness is addressed to catch our scrolling minds or more spam to be ignored
Whether reinforcement is funded past go-live
Every one of these is a decision the program owns.
Why do we keep dying in the same simulation?
Here is the question the owner of any of those programs should be asking, and it is the one that has bothered me for years. Why do we need to keep blowing ourselves up? If the outcome is this predictable, why can we not change it?
The honest answer is that we measure the wrong thing, so we never see the conditions we could have changed. Most programs measure installation. Did the system go live, was the deadline met, did the training sessions happen. Those questions all have clean yes-or-no answers and every one of them can be yes while the change fails. **Installation is not implementation**. A system being live is not people adopting it, and the gap between the two is where the ship is lost.
The long-quoted change management failure rate, roughly seven in ten transformations, has held for decades, and I think that stability is the most important thing about it. A number that does not move is not describing bad luck. It is describing a repeated configuration. The configuration looks like this: sponsors express support at kickoff and then delegate, targets get information but not ability or any say in how the change lands, and the moment of go-live is treated as the finish line instead of the start of the hard part. IMA Worldwide field research finds that adoption fades within ninety days of go-live when nothing reinforces the new behavior. Ninety days is the length of the simulation. Then the Klingons arrive.
There is a second reason we keep taking the test, and it is more uncomfortable. The no-win framing is protective. If change is simply hard, nobody's decisions caused the loss. The ERP program that cut its support budget, the AI pilot that never touched the workflow, the merger that announced a structure and called it integration: each of those is a decision, and calling the result inevitable is a way of not owning it. Kirk's answer to that is the right one. Do not accept the premise.
A failure rate that has not moved in decades is not describing bad luck. It is describing a configuration nobody has changed.
What does changing the conditions actually look like?
Accelerating Implementation Methodology (AIM), the AIM change management methodology, was developed by Don Harrison across more than forty years of field research, and its entire premise is Kirk's premise: the conditions of a change are settings, and the settings have to be changed before the test runs, not during the rescue. In practice that means four moves, in this order.
Measure your implementation history before you commit the money. IMA Worldwide's own research finds that how an organization handled its last changes is the best predictor of how it will handle the next one. The Implementation History Assessment gives you that number before deployment, when it is still cheap to act on.
Contract sponsors to specific, visible tasks. This is executive sponsorship change management in practice, not in name only. There are six non-delegable leadership tasks in AIM, and the ones that carry the most weight (aligning rewards, cascading to direct reports) are the ones sponsors most often delegate. Active leadership involvement is associated with two to three times the adoption rate of passive support.
Build organizational readiness for change across all five elements, not just the first. Information, willingness, ability, confidence, and control. A rollout that delivers only information and one training session has left three of the five to chance, which is how people end up with a tool they can describe but do not use.
Schedule reinforcement past go-live, and fund it. IMA Worldwide field data shows that reinforcement carries roughly three times the impact of communication in making a new behavior stick. The last quarter of the budget is the part that makes the first three quarters count.
I have watched this reprogram a test in real time. A gas utility rolling out Oracle across more than a dozen sites ran the AIM plays at every site but one, and the baseline read on its implementation history was low enough that most teams would have called the outcome inevitable. Every AIM site went live on time and on budget. The single site that skipped the plays was the one that missed. Same software, same vendor, same deadline. Different conditions.
Kirk did not fly the simulation better than anyone else. He changed it before it started, and that is the whole lesson.
Timing is the whole trick. Kirk reprogrammed the Kobayashi Maru before the test ran, not during the attack. AIM front-loads the same way: implementation history, sponsor contracting, and readiness are measured and set before deployment, because after go-live the old behavior has already reasserted itself and every fix works against it.
What does Kirk get wrong, and what do Picard and Spock get right?
I said I am a Kirk person, and I am. But the film I am quoting is not on Kirk's side as cleanly as the commendation suggests, and I would be cheating you if I stopped at the good scene.
Spock is the one who actually saves the ship in that movie, and he does it by walking into a radiation chamber. His argument is that the needs of the many outweigh the needs of the few. Picard, years later on The Next Generation, tells a young officer that it is possible to make no mistakes and still lose, and that this is not weakness but life. And Kirk himself, at the end of the film, admits to his son that he has never faced death, only cheated it, tricked his way around it, and congratulated himself on his ingenuity. The bill for the reprogrammed test comes due in the same story.
I take two things from that, and neither one changes my answer.
The first is that changing the conditions is not the same as pretending there is no cost. Every real change disrupts people's work, and AIM measures that disruption directly rather than wishing it away. Spock is right that someone pays. The point of reprogramming the test is to decide in advance who pays what, and to make sure it is not the whole crew.
The second is that Picard is describing a different test. He is talking about a fair fight fairly lost, and there are some of those. But a transformation that never contracted its sponsors, never measured its readiness, and cut its reinforcement budget did not lose a fair fight. It ran a rigged simulation and called the result life. That is the distinction I would ask any executive to sit with. Before you accept the loss as the nature of change, be certain you actually changed the conditions you controlled.
How IMA Worldwide helps leaders reprogram the test
Most organizations come to us after go-live, when the Klingons have already arrived. We can help there, and we do. But the engagements that produce the numbers above start earlier, with a measured read on the organization's implementation history and a plain answer to the question of which conditions are set wrong for this particular change. AIM gives you that read, and it gives your own people the plays to act on it, so the capability stays after we leave. You decide the change. AIM gets it adopted. If the change on your desk is an AI rollout, the fastest way to see which of the five readiness elements is missing is fifteen questions long, and the results name your weakest dimension. The questions below cover what leaders most often ask when they first hear this argument.
Find out which condition is set wrong before you go live
Fifteen questions, scored against the five readiness elements, with your weakest dimension named.
**Take the AI Readiness Assessment**
Frequently Asked Questions
What is the Kobayashi Maru lesson for change management?
The Kobayashi Maru is a training simulation designed so that no one can win it. Kirk passed by changing the program before the test began. The lesson for change leaders is that the conditions of a change effort, sponsorship, readiness, and reinforcement, are settings you control, and they have to be set before go-live rather than rescued after it.
Why do so many transformations fail in the same way?
Because most programs measure installation and assume implementation follows. The system goes live, the deadline is met, and adoption is left to sort itself out. IMA Worldwide field research finds that adoption fades within ninety days of go-live when nothing reinforces the new behavior, so the same loss repeats regardless of how well the project itself was run.
What does it mean to change the conditions of a change initiative?
It means measuring the organization's implementation history before you commit the money, contracting sponsors to specific visible tasks, building target readiness across all five elements, and scheduling reinforcement past go-live. Each of those is a decision the program owns. Together they change what is possible in the same way Kirk's reprogramming did.
When is it too late to change the conditions of a change?
It is never too late to improve adoption, but the cost rises sharply after go-live. Before deployment, readiness gaps are cheap to close and sponsorship can still be contracted. After deployment, the old behavior has reasserted itself and reinforcement has to work against it. The earliest honest baseline is the cheapest one.
The Bottom Line: The Test Is Programmable
The no-win scenario in change management is a story we tell after the fact to make a configured loss feel like a natural one. The vendor deadline, the technology, and the signed deal are real and fixed. Sponsorship, readiness, and reinforcement are not, and they are the conditions that decide whether the ship makes it out. Kirk's answer holds: do not accept the premise. Measure the history, contract the sponsors, build all five readiness elements, fund the reinforcement, and do it before go-live rather than during the rescue. If you are about to launch something this year, the next step is to find out which of those conditions is currently set to lose.
A stable failure rate describes a repeated configuration, not bad luck
Hard external facts are fixed; sponsorship, readiness, and reinforcement are settings
Change the conditions before go-live, when doing so is still cheap
Installation going green is not implementation, and ninety days will prove it