You have read the chapter on Lewin, Kotter and ADKAR. You can list every stage from memory. And yet your draft still comes back with the comment that stopped so many students in their tracks: "too descriptive." It feels unfair, because you did the reading. But the problem is rarely effort. It is that a model explained is not the same as an organisation understood, and that gap is exactly what this guide helps you close.

Start With the Organisation, Not the Model

Picture a mid-sized NHS trust rolling out a new electronic patient records system. Six months in, nurses are still scribbling notes on paper and typing them up later. A descriptive essay would explain Kotter's eight steps and stop there. An analytical one asks what actually happened on the wards, and that is a far more interesting question.

Was the reason for the system ever explained properly? Did ward managers back it, or quietly roll their eyes? Was training squeezed into a lunch break between shifts? Did the system add ten minutes to every patient handover? Each answer points towards a different explanation, and each explanation leads to a different recommendation.

That is the shift markers look for at advanced undergraduate and postgraduate level. Criteria vary by module and university, but critical engagement almost always earns more than a neat run of textbook definitions. Hold onto this: the organisation is the subject, and the model is the lens you look through.

Where Description Sneaks In

The most common trap is mistaking description for analysis. Writing that Kotter begins with creating urgency tells the reader about the theory. Writing that senior leaders announced the restructure but staff kept asking why it was needed starts applying it. Asking why that message failed, and whether something else fits the evidence better, is where the marks tend to sit.

Resistance is another one. A nurse who avoids the new system might be resisting change, but she might equally be responding to poor training, unclear instructions, a heavier workload, or a genuine fault in the software. Label all of it "resistance" and your recommendation ends up as a vague suggestion to communicate more.

Before you write, try six questions: What changed? Why did it change? Who experienced it differently? Where did implementation get difficult? What does your chosen model explain? And, most usefully, what does it leave unexplained? That last one is often where strong critical evaluation begins.

Getting Support Without Losing Your Own Analysis

Many students wonder whether outside help could speed things up. The better question is what kind of help actually teaches you something. Anyone looking at a Change Management Assignment Service Online UK should check whether the guidance shows how to move from a case study to an argument, or just returns a tidier textbook summary. It is worth knowing what separates the two before you decide.

Here is a quick test. Ask to see how one paragraph travels from concept to evidence to interpretation. If you can trace the reasoning and explain it back in your own words, it is teaching you. If you cannot, it is decoration, and your marker will probably notice.

Three Models, One Problem

Lewin, Kotter and ADKAR each light up a different corner of the same situation. Take employees who have not adopted a new customer-management system. ADKAR asks whether people understand why it exists and have the knowledge and ability to use it. Kotter turns attention to leadership communication and how the wider organisation supported the rollout. Lewin asks which routines and assumptions the system is disrupting, and why the old way is hard to abandon.

None of them gives the full answer, and that is your opportunity. Ask what each model makes visible, what it quietly assumes about change, where the evidence fits, and where it pushes back. The strongest comparison is never "Model A beats Model B". It explains why each one reveals a different part of the problem.

Context, People and Evidence

Context comes before theory. A small procedural tweak, a departmental merger and a major technology rollout will not behave the same way, even under the same model. Think about who gains, who loses, and who actually has to change their behaviour for it to work.

Leadership matters too: a board may back a change publicly while middle managers struggle to explain it on Monday morning, and that gap often says more than the words "leadership was supportive." Culture adds another layer. A retailer may describe itself as innovative while its bonus structure rewards playing safe. A model can map the stages of change, but culture helps explain why people react differently at each one.

Then connect your evidence. Company documents show what the organisation says happened; peer-reviewed research gives you concepts to interpret behaviour. Try this chain: claim, evidence, interpretation, theory, limitation, judgement. It stops references becoming decoration at the end of a paragraph.

How to Write It Well

Write a one-line diagnosis before opening the theory section. For example: employees are struggling to adopt the new system despite formal training. That single sentence throws up questions worth chasing, such as whether training is really the problem, whether managers reinforce the new behaviour, and whether workloads changed.

Then build each paragraph in four moves: concept, evidence, interpretation, evaluation. Introduce the idea briefly, show what happened, explain how the theory makes sense of it, then flag a limitation or alternative explanation. It beats spending a full page on a model before the organisation appears.

Test each major paragraph with three questions. Have I explained something about the organisation? Have I used theory to interpret rather than describe? Have I judged how useful that interpretation is? Three yeses mean the paragraph is working.

Mistakes That Quietly Cost Marks

A few habits quietly drag marks down. Explaining every stage of every model adds length without insight; if only two concepts fit your case, analyse those properly. Padding with company history does the same unless it explains the change. Treating resistance as an obvious diagnosis, or assuming that formal rollout equals real change, hides what employees are actually doing, such as keeping old workarounds alive.

Models simplify reality, so treat them as ways of interpreting rather than facts. And do not save criticism for a closing paragraph: 700 words of description followed by 100 of questioning still reads as descriptive. Finally, a recommendation like "improve communication" needs a diagnosis behind it: what went wrong, what effect it had, and how your response addresses it.

Bringing It Together

Analysing change is not about showing how many models you know. It is about using theory to make sense of something that happened inside a real organisation. Start with the change, find the difficulties, gather the evidence, and only then choose the lens.

Keep moving between theory and evidence, and keep asking what the model explains and where it falls short. A model should answer a question about the organisation, not become the answer itself. Do that, and Lewin, Kotter and ADKAR stop being things to memorise and become tools you actually use.