APMG Agile Change Agent common mistakes
APMG Agile Change Agent · Understand the traps and how to avoid them.
Treating the change roadmap as a one-off Gantt-style project plan, listing tasks and dates rather than outcome-based stages with decision points and feedback loops.
Candidates carry over project-management habits and assume a roadmap must be a fixed schedule; the syllabus instead frames the roadmap as an iterative, outcome-focused view that is revisited as understanding grows.
What to do instead
Describe the roadmap as a sequence of change stages or iterations, each tied to a business outcome, with explicit review points where the approach can be adjusted. Practise drafting a roadmap from a short scenario and checking that every element links to an outcome, not just an activity.
Producing a roadmap that stops at 'deliver the change' without covering adoption, embedding, and benefit realisation after go-live.
Candidates equate the end of the roadmap with the end of the build, reflecting a delivery mindset rather than a change mindset where the change only succeeds once it is adopted.
What to do instead
Extend every practice roadmap past implementation: add stages for piloting, adoption support, reinforcement, and measuring whether the business need is actually met. Ask 'what happens after go-live?' for each roadmap you write.
Starting a roadmap without first articulating the business need, so the change is described as a solution ('install new CRM') rather than a problem or opportunity to be addressed.
Scenarios often lead with a proposed solution, and candidates anchor on it instead of asking what outcome the organisation is trying to achieve.
What to do instead
Before drafting anything, write a one-sentence need statement covering the current situation, the desired outcome, and why it matters now. Check that every roadmap stage can be traced back to that statement.
Confusing outputs (what the change delivers) with benefits (the measurable value realised) and presenting deliverables as the justification for the change.
Delivery language is familiar and concrete, while benefits require reasoning about outcomes and measures, so candidates default to the easier option under time pressure.
What to do instead
For each output, state the benefit it enables and how it would be measured. Use the test 'would a finance or operations stakeholder accept this as value?' to distinguish outputs from benefits.
Assuming the business need is fixed and known at the start, and not revisiting it as the change progresses and stakeholder understanding develops.
Candidates treat the need as a static project charter input rather than something that is refined through iterative learning and feedback.
What to do instead
Build explicit checkpoints into answers where the need is revalidated with stakeholders, and state what would trigger a revision. Show that the need is a living statement, not a one-time sign-off.
Listing stakeholders as a flat register of names and job titles without analysing influence, interest, attitude to the change, or what each needs from the change agent.
Candidates recall 'identify stakeholders' as a step and stop there, missing that relationship building requires differentiated strategies per stakeholder.
What to do instead
For each stakeholder group, state their interest, influence, current stance, and the specific engagement approach. Practise mapping a scenario's stakeholders and justifying each approach in one sentence.
Treating relationship building as a one-way communication task (sending updates) rather than a two-way, continuous activity involving listening, trust, and adapting to feedback.
Communication plans are a familiar artefact, so candidates substitute 'tell people' for 'build relationships', which misses the collaborative core of the role.
What to do instead
In answers, pair every communication action with a listening mechanism (workshops, feedback loops, one-to-ones) and describe how the change agent will act on what is heard. Frame engagement as ongoing dialogue, not a broadcast schedule.
Ignoring resistance or treating it as a problem to be overruled rather than legitimate feedback to be understood and worked with.
Candidates adopt a compliance mindset where resistance is an obstacle to delivery, rather than recognising it as information about the change and its impact.
What to do instead
Describe resistance in terms of its cause (loss of control, uncertainty, workload, skills) and pair it with a response that engages those affected. Show that the change agent surfaces and addresses concerns rather than suppressing them.
Designing a change approach that ignores the organisation's culture, capacity, and readiness, applying a generic template regardless of context.
Candidates memorise a preferred approach and apply it uniformly, missing that the environment shapes what will work and the pace that is realistic.
What to do instead
For each scenario, identify environmental factors (culture, appetite for risk, workload, skills, prior change history) and explain how they modify the approach. Practise justifying why one approach fits a given environment and another does not.
Overlooking the wider environment beyond the immediate team, such as competing initiatives, external regulation, or organisational politics, when planning the change.
Candidates focus narrowly on the change itself and the directly affected team, treating the surrounding context as background rather than a constraint on the roadmap and engagement strategy.
What to do instead
Before answering, scan the scenario for competing demands, external drivers, and political dynamics, and explicitly state how they affect sequencing, resourcing, and stakeholder strategy. Build a short context checklist and apply it to every practice question.