Why Complex Change Gets Stuck, and the Six Questions I Ask to Get It Moving Again

An old change-management model that's still one of the most useful tools I use.

There are plenty of ways a business improvement project gets stuck.

Sometimes the software works, but nobody wants to use it. Sometimes everyone agrees something has to change, but nothing moves. Sometimes the business has spent good money on a project and every meeting is another lap around the same problems. And sometimes a project looks like it's going well right up until it's handed to the people who have to use it.

It's easy to put that down to a technical problem, a project management problem, or people just not liking change. In my experience there's usually something more basic going on. One of the ingredients change needs is missing.

There's a model that's been around for decades that I find really useful for working out which one. It's usually called the Lippitt-Knoster Model for Managing Complex Change. It's old and it's simple, and I still think it's one of the most useful ways to think about changing business processes, systems and software.

Not because it's clever. Because it gives you a practical way to think about why change works, why it fails, and what to do when it's not going to plan.

The six ingredients

The version I use has six:

1. Vision
2. Consensus
3. Skills
4. Incentives
5. Resources
6. Action plan

The idea is that all six need to be there, and lined up, for a change to stick. When one is missing, the project shows symptoms you can recognise.

I don't treat it as a formula where one missing piece guarantees one outcome. Real businesses are messier than that. But as a way to organise your thinking it's very effective.

You also don't need a multimillion-dollar project for it to be useful. It applies whether you're replacing the system the whole business runs on or changing how one team records a few bits of information. The amount of formality changes with the size of the job. The questions don't.

1. Vision: does everyone understand why we're doing this?

Vision sounds like something out of a corporate strategy document. When you're changing how a business runs, it's much more practical than that. It's whether people understand what we're trying to achieve and why it matters.

Say we're putting in a new timesheet process in a trades business. Management knows why. They want better labour allocation, more accurate job costing and reporting they can rely on. The owner has a clear picture of what good looks like.

Does the field team know any of that? Do they know why they're being asked to record things differently? Or have they just been told there's a new app and to start using it Monday?

That difference matters.

No vision, and you get confusion

When people don't understand why something is changing, they struggle to make sense of what's being asked of them. Some will question it. Some will slide back into old habits. Others will follow the instructions and miss the point of them.

There's a second problem that's easier to miss. Someone who doesn't understand the purpose of a process is worse at making good calls when they hit a situation the process doesn't cover.

I think businesses underestimate this. You can't predict every situation someone will hit in the field. At some point they'll need to use their judgement, and if they understand why the information matters and how it's used, they'll make a much better call.

Vision isn't just motivation. It's giving people the context to work things out for themselves.

You can't write a process for every situation. Give people the why and they'll handle the ones you didn't think of.

2. Consensus: have we brought the right people along?

Consensus isn't the same as vision. People can understand exactly what the business is trying to do and still not agree with the change. They can agree there's a problem and still not agree on how to fix it.

This is where the human and cultural side of the work really matters. If we're changing how people do their jobs, we need to understand their concerns, explain the reasoning and get enough agreement for the change to move.

That doesn't mean everyone gets a veto. It doesn't mean we need everyone excited about it, and it certainly doesn't mean the business can't make hard decisions. It means we shouldn't mistake management signing off for the business being on board.

No consensus, and you get conflict

When the right people aren't brought in, you end up with a project that's officially approved and practically unsupported. People push back. Departments work around the change. Managers nod along in the meeting and don't back the new process afterwards.

Some versions of the model call this sabotage. That's a dramatic word, but the idea holds: when people haven't accepted a change, they'll undermine it, sometimes on purpose and sometimes just by not doing it.

This is one of the reasons I spend time with people across the business before a new system goes in. I'm gathering requirements, sure. But I'm also explaining why we're making the change, hearing the objections and giving people a chance to shape it. Done properly, those relationships are worth a lot when it's time to roll out.

3. Skills: do people know how to do what we're asking?

This one seems obvious. New system, people need to know how to use it.

But working out what skills are needed is more than handing out a training document. People come into a change with different levels of confidence with technology. Different roles need different things. And someone who knows their current job inside out can suddenly feel like a beginner because the new system makes them one.

No skills, and you get anxiety

Think about someone who's done their job confidently for twenty years. Now we're asking them to use a process they don't fully understand. They might be worried about making mistakes, embarrassed to ask for help, or worried they'll be judged on information they're still learning how to enter.

The rollout has to be designed around the people actually using the system. That means training, clear instructions, real support, and a chance to learn without feeling exposed.

One thing I really like is getting a small group of field users involved while it's being built. They get to know the system before everyone else, they help find improvements, and when it goes live they're there to help their workmates. Those internal champions make a huge difference. (I wrote more about this in what the Toyota Production System taught me about building business systems.)

The goal isn't just to tell everyone how the software works. It's to make sure they've got the confidence to use it.

4. Incentives: does the change make sense to the people it affects?

When people hear incentives they think money. That's too narrow. Here it's about why people would back the change. What's in it for them? Why should they put effort into learning a different way of working?

For management the answer might be better reporting, better margins or more control. For operations it might be easier coordination and fewer admin headaches. For someone in the field, the thing that matters most might be finishing their paperwork faster and getting home.

Those aren't the same, and they don't need to be. But they need to be understood.

No incentives, and you get resistance

If the business gets all the benefit and the worker gets extra work, more scrutiny and more hassle, don't be surprised when they're not keen.

This is where system design and change management overlap. Sometimes the answer is better communication, because people just need to see the bigger purpose. But sometimes the resistance is telling you the system really is more work than it should be. You can't talk your way around a bad process. You have to fix it.

Part of the job is telling the difference between resistance that comes from misunderstanding and resistance that comes from a real problem. In practice it's often both at once.

You can't talk your way around a bad process. You have to fix it.

5. Resources: has the business actually made room for the change?

Of the six, I think this is the one most often underestimated. Not necessarily money. Time, attention, availability, and access to the people who know how the business runs.

When you bring someone in to improve your processes and systems, the business still has to take part. Hiring someone who knows what they're doing doesn't remove that. I might know systems, process design and the technology, but the people inside the business know how the work actually gets done.

At some point someone has to explain how the current process works. Someone has to make decisions, review what's proposed, test it, and tell us what we've missed.

No resources, and you get frustration

When the business doesn't make enough time, progress slows. Decisions sit there. Assumptions get made. Feedback comes in late, and things that could have been caught during the build get found during rollout.

It turns into a cycle. The business is too busy to give the project time, so the project takes longer and needs more rework, which makes the business even busier. It's a false economy.

The fix isn't everyone sitting in meetings all day. It's having the right people available at the right moments, and treating their time as a real project requirement. That's why the first part of any engagement with us is time inside the business: we put the diagnosis up front rather than paying for it later in rework.

If you don't make time for people to contribute early, you'll usually spend a lot more time fixing the result later.

6. Action plan: is there a realistic way from here to there?

The last ingredient is the action plan, and the important word is realistic.

A business can have a clear vision, people on board, the right skills and enough resources, and without a workable plan the effort still splinters. Teams head in different directions. Decisions get revisited. Changes land before people are ready. Momentum drains away.

No plan, and you get false starts

The model calls this false starts. Projects begin, stop, restart and change direction, and people lose confidence because they can't see the way through.

For me, good planning means getting two things right that people often lump together: rhythm and pace.

Rhythm is how often we're talking to and working with people. Pace is how much change we're asking the business to absorb. They're different. A business might need to hear from us often but take on new processes slowly. Another might be able to move fast, as long as people know what's coming and have support.

A good plan accounts for both, and it has to be adjustable. Sometimes we need to move quickly. Sometimes we need to slow down. Sometimes we need to stop building new features and spend time sorting out what we've already delivered. That's not a failure of planning. It's what managing a complex change properly looks like, and it's why I work at a pace the business can digest rather than the pace I can build at.

The other way to use it: work backwards from the problem

This is where the model really earns its keep.

Most people use change frameworks for planning. Look at the components, check they're covered, move on. That's useful. But I also use this one in reverse. When a project starts going sideways, I look at the symptoms and ask which ingredient might be missing or out of line.

It's not an automatic diagnosis. Resistance, for example, can come from poor training, no real benefit, a lack of trust or a process that's harder than it should be. But it gives you a good place to start asking questions.

Symptoms are clues, not answers

Say we're rolling out a new operational system and the field team is pushing back. We could decide they just don't like change. That doesn't help anyone.

Instead, work backwards. Do they understand why the system is coming in? Were they involved in designing it? Do they know how to use it? Does it make their work easier or harder? Did they get enough time to learn it? Did we change too much at once?

Now we've moved from blaming people to looking at the conditions around them, which is a far more useful way to solve the problem.

The ingredients feed off each other

Simple readings of the model miss that the six aren't independent. A weakness in one can make another much worse.

Take a team that doesn't fully understand the vision and hasn't had enough training. They're confused and anxious. Now management responds to their uncertainty by watching them more closely and putting the pressure on. Suddenly there's an incentives problem, a trust problem and probably a resources problem too. What started as a fairly simple communication and training issue has become a much harder people problem.

Or take a project with a good plan where the business hasn't freed up enough people. The plan is sound on paper but can't be delivered with what's been allocated. As it slips, people get frustrated, confidence drops, and the agreement about where it's heading starts to wear thin.

The point isn't to find one box to blame. It's to understand how the weak spots are feeding each other.

That's where experience comes in. The model organises the investigation. It doesn't do it for you.

Not every change needs to be a big project

One of the things I like most about this model is how well it scales.

If I'm making a small change to an existing system, I'm not going to write up a formal assessment against all six. That would be pointless paperwork. But I will run through them in my head. Do people understand what we're trying to do? Are the right people on board? Do they know how to use it? Is there a good reason for them to make the change? Have we set aside the time and support? Do we know how we're going to bring it in?

That might take a minute, and that minute can save a lot of trouble.

On a bigger project that touches several teams or changes how the business fundamentally runs, the same questions need a lot more structure: workshops, training plans, people committed to the project, a staged rollout. The model hasn't changed. We've just matched the effort to the size and risk of the change.

It's a tool for judgement, not a replacement for it

One of the traps in project management is believing that following a formal process guarantees a good result. It doesn't. You can fill in every document, run every workshop and tick every box and still miss something important. And someone with experience can often spot a problem very quickly, because they've learned what to look for.

For me the Lippitt-Knoster model has become part of how I think. I don't pull out the diagram every time I make a decision, but the six ingredients are always there in the background. They shape how I plan a project, the questions I ask, how I read resistance, confusion and frustration, and where I look when things slow down.

The value isn't in being able to recite the six ingredients. It's in noticing when one of them is missing.

Complex change doesn't have to be a mystery. The warning signs usually show up well before a project goes badly wrong. The skill is reading them, asking the right questions, and being willing to change course when the answers tell you something isn't working.

If you've got a project that feels stuck and you can't put your finger on why, the fit check is a good place to start, or get in touch and we'll work through it together.