What is project change management?
Project change management is the formal process of evaluating, approving, rejecting, implementing, and communicating changes to a project's scope, schedule, budget, or deliverables. It is the gatekeeper mechanism that separates intentional, value-adding evolution from uncontrolled scope creep — the gradual, often invisible accumulation of unapproved additions that derails more projects than almost any other single factor.
Every project is a learning journey. Teams deepen their understanding as work progresses. Topics that seemed critical at kickoff turn out to be peripheral. Dependencies that weren't visible at the start emerge as central constraints. New information arrives. As Henning Christiansen writes in Project Management: The Red Pill: change is not a failure of planning — it is an inherent property of delivery. The question is not whether change will happen, but whether you have a system that channels it productively.
A change request management system is exactly that system. It creates the structure through which changes must pass — ensuring they are evaluated honestly, documented transparently, and implemented with full visibility of their impact before work begins.
Why every change is a risk — even the good ones
The instinct in most project teams is to treat change requests as problems to be argued about: should we do this or not? That framing misses the point. The real question is: what are the ripple effects of this change through the project model?
Christiansen illustrates this vividly. In a car design project, moving a seat seems minor. But it requires repositioning the door. Which affects the exterior design. Which ripples into structural elements. What began as a small adjustment becomes a major rework — discovered only after commitments have been made at full project cost. The same cascade operates in software, construction, product development, and every interdependent system.
"A project manager who thoroughly understands the project can foresee the ripple effects of a change. It saves time and minimises unintended chain reactions."
— Henning Christiansen, Project Management: The Red Pill
Even technically justified, beneficial changes carry risk — because every change introduces new variables into a system that was previously stable. The more changes accumulate without controlled impact assessment, the harder it becomes to trace problems to their source when things go wrong.
The three decisions: approve, defer, or reject
Not all changes deserve the same response. Christiansen's framework draws a clear distinction between three outcomes:
The most common change management failure is the informal defer — acknowledging a request verbally without documenting it, intending to revisit it later but never doing so. Every deferred change must be formally recorded: what was requested, who requested it, why it was deferred, and when it will be reconsidered. This protects both the project and the relationship with the stakeholder who proposed it.
Reading the true intent behind a change request
The most important skill in change management is the ability to identify what is actually driving a request. Christiansen is explicit: the motivation behind a change request varies enormously, and confusing a genuine technical need with a political manoeuvre has serious consequences in both directions.
Chameleon-driven requests
Chameleons are motivated by personal recognition and career positioning. Their change requests typically add features that increase their visibility — framed as client satisfaction or business necessity. "The client really needs this." "If we don't do this, we'll lose the account." The feature itself may be reasonable. The problem is that the motivation is personal positioning, not project benefit. The Chameleon wants to be seen as the person who "saved the client".
Rooster-driven requests
Roosters are motivated by intellectual challenge and technical prestige. Their requests typically involve complex enhancements framed as quality improvements. "This is technically essential." "The current architecture won't scale." The risk: the change serves the Rooster's desire for stimulating work, not the project's delivery requirements. A technically valid argument that serves a personal agenda is still a personal agenda.
Regardless of the source or suspected motivation, every proposed change must be treated with respect and evaluated seriously. Dismissing a request because you've identified the requester as a Chameleon damages trust and creates the toxic atmosphere that escalates into Monkey Poker. The Godfather approach: remain calm, acknowledge the request, evaluate it honestly against project objectives — then decide.
The Monkey Poker playbook: moves to recognise and counter
When formal change control is in place, Chameleons and Roosters don't stop pushing — they shift to informal tactics. Christiansen documents two specific moves that project managers must be able to identify and neutralise.
The hornet's nest move carries a significant backfire risk: if the project manager can demonstrate that the claimed crisis is not real, the move destroys the attacker's credibility. A project manager armed with facts and a stable project model can expose the move — and use the attempted deception as documented evidence of the stakeholder's political motivations.
When everyone agrees to freeze the project scope, Chameleons and Roosters treat it as a signal to shift to informal channels — because the formal gate is closed. Scope freezes often intensify political pressure rather than eliminating it. The project manager must be especially vigilant during declared scope freezes, not less so.
Case study: the Sydney Opera House and uncontrolled change
The Sydney Opera House (1957–1973)
The Sydney Opera House is the most quoted example of a project transformed by uncontrolled change — and worth studying precisely because each individual change had a plausible justification at the time. Together, they produced one of the most dramatic cost and schedule overruns in construction history.
The project illustrates every failure mode that a change management system exists to prevent:
- Construction started before design was finalised — scope was undefined from the beginning, so every design evolution became a full-cost change
- No formal change evaluation process — design revisions were made repeatedly without structured assessment of cascading effects
- Political interference drove scope changes — government leadership changes shifted requirements mid-build, treating the project as a political instrument
- Technology limits discovered in execution — not in planning, forcing solutions to be invented at construction cost
- No effective gatekeeper — the project manager role was insufficient to evaluate and control the volume of simultaneous changes
The change request management process — 7 steps
A formal change request process is not bureaucracy. It is the mechanism that creates accountability, protects the project manager from politically-driven pressure, and gives the project board the information they need to make strategic decisions.
Understanding and communicating ripple effects
The impact of a change rarely stops at the directly affected task. Being able to trace every downstream consequence — and communicate it clearly — is one of the most valuable competencies a project manager can develop.
| Change request | Direct impact | Cascade effects | Decision |
|---|---|---|---|
| Move API integration to new vendor | Replace vendor tasks; new contract | Authentication module rewrite; 3 downstream services affected; testing extends 2 weeks; security review required | Approve — contingency accessed; timeline adjusted |
| Add real-time notification feature | New development tasks; WebSocket infra | Mobile app changes; backend load implications; testing scope increases; launch criteria change | Defer to v2 — not launch-critical; complexity disproportionate |
| Refactor data model "for scalability" | Significant backend rework across all modules | Every endpoint affected; QA restarts; 4-week impact; no measurable v1 benefit | Reject — Rooster-driven; defer to post-launch architectural review |
| Change primary colour palette | Design system updates; asset regeneration | UI component library rebuild; screenshot tests fail; marketing misalign; 1-week impact | Approve — client-driven, legitimate; all teams notified |
Handling rejected change requests
Rejection is not the end of the change management process — it is often the beginning of a more delicate phase. When stakeholders fail to push through a change request, they frequently experience frustration or a sense of being unheard. Left unaddressed, this creates the toxic atmosphere that generates ongoing Monkey Poker escalations.
The project manager's obligation after rejection is threefold: communicate the reasoning clearly (not just "it was rejected" but why); acknowledge the underlying concern as legitimate even if the specific change is not; and offer an alternative path where the underlying need is valid.
If a stakeholder whose request was rejected continues to push the same agenda through informal channels, that pattern must be addressed directly and recorded in the communication plan. A single rejected request is normal. Repeated re-escalation of the same rejected request is a political dynamic requiring active management — not continued tolerance.
Scope creep: the silent accumulation of uncontrolled change
Scope creep is the most common consequence of inadequate change management — and the most insidious, because it rarely arrives as a single dramatic event. It accumulates: a small feature added here, a minor enhancement agreed verbally there, a "quick addition" that bypassed formal review. Each individual change seems small. The cumulative effect is a project that has drifted far from its original scope, with no documented record of the journey.
Christiansen identifies three conditions that accelerate scope creep most dangerously: deadline pressure (formal processes get bypassed under stress), high morale ("we're the best at this, why not add a little extra?"), and declared scope freezes (which Chameleons and Roosters read as a signal to shift to informal channels).
📋 Change management health check — run monthly
- Is every change in the past 30 days formally logged, regardless of size?
- Have any verbal agreements been made that bypass the formal change log?
- Is the current project scope still aligned with what was agreed at kickoff?
- Are all deferred changes formally documented for the next version?
- Have any rejected requests been re-raised through informal channels?
- Is the communication plan up to date with all recent change decisions?
Change management in Proglar
Proglar's change request management is built directly into the project model workflow. Every change request is logged against the specific task or model component it affects, and the impact assessment draws on the project model's dependency structure — surfacing every related task before a decision is made.
When a change is approved, the project plan updates in place: affected tasks, timeline, budget, and risks are all updated together. The full change history — who requested, when, what the impact assessment showed, who decided and why — is maintained as a permanent auditable record accessible to the project board at all times.
Guard the gate — but keep it open to the right things
The goal is not to prevent change. It is to ensure that every change that passes through the gate genuinely serves the project's core purpose — not a Chameleon's visibility, not a Rooster's curiosity.
- Every request, regardless of source, is evaluated on the same criteria: does it serve the project's objectives?
- Impact is assessed before decisions are made — not estimated retrospectively
- Decisions are documented with reasoning, not just outcomes
- Rejected requests are communicated respectfully, with an alternative path where possible
- Approved changes are implemented fully — plan updated, team informed — before work begins
- The communication plan is updated after every significant change decision
Manage every change request with full project impact visibility
Proglar connects change requests to your project model so every decision comes with a complete picture of what changes — in scope, timeline, budget, and risk. Try free for 30 days.