Design Thinking Theory and a change management model

The assignment names two things and joins them with *and*: an analysis of Design Thinking Theory, and an analysis of a change management model. Those are not the same kind of object, and the paper is won or lost on whether you notice. Design thinking is a method for finding out what problem is worth solving — it works outward from users toward a definition of the need, then toward prototypes. A change management model is a method for getting an organisation to adopt something once you know what it is. One generates the idea; the other lands it. A paper that treats them as two competing approaches to the same task has misread the pairing, and a paper that explains how the second carries the output of the first has understood the assignment.

The scenario is doing more work than it appears to and should shape the whole paper. You are not an executive with authority; you are someone with an idea who believes that *beginning a discussion, introducing ideas, and showing examples* are the first steps. That is a description of influence without power, in a large global organisation where change is acknowledged to be slow. Everything you recommend has to be executable from that position. A change model requiring sponsorship you do not have is not yet a plan; the useful version of it explains how the early steps are used to acquire the sponsorship the later steps assume. Keeping the scenario in view is also what makes the paper an analysis rather than a summary. Naming the position explicitly in the introduction also frames the paper as a plan rather than as an overview, which is what the scenario is asking for.

Analysing design thinking means more than listing its phases. Say what each phase is *for*: the empathy work exists because the stated problem is usually not the real one; the definition step exists because a well-framed problem constrains the solutions worth generating; ideation is deliberately separated from evaluation because judging early kills the unusual options; and prototyping and testing exist to make failure cheap. Then say what the method assumes — that users can be observed, that iteration is affordable, that the organisation will tolerate visible early failure. Those assumptions are where an analysis becomes critical, and where a large global organisation may not deliver what the method needs. Naming an assumption the organisation in your scenario would struggle to meet is also the most direct route to a critical paragraph that is specific rather than generic.

For the change management model, choose one and commit rather than surveying three. The two most commonly applied in the literature take different views of what change is. One treats an organisation's current state as a balance between forces pushing for change and forces holding it back, so the work is unfreezing that balance, moving, and refreezing. The other treats change as a sequence beginning with urgency and a guiding coalition, moving through vision and communication to short-term wins, and ending by making the change stick. Say which you chose and why it suits your scenario — a person without authority may find the coalition-building sequence more usable than a model that assumes the power to unfreeze. Saying in one sentence what the model you rejected would have done differently is worth the space, because it shows the choice was made rather than defaulted to.

The strongest structure joins the two rather than reporting them in turn. Design thinking produces a prototype and evidence that it addresses a real need; a change model turns that evidence into urgency, a coalition and a communicated vision. That handover is the paper's argument, and it is also where you can be specific about your own organisation: what the first discussion would be, who would be in the room, what example you would show. Note that the assignments in this course build on one another and are to be completed in sequence, so the choices you make here — the problem, the organisation, the model — will constrain what you can write later. Keeping that constraint in mind now saves rework later, since a problem chosen for convenience here may turn out to be one you cannot carry through the sequence.