Change Requests: Stop Managing Scope Changes in Your Head
A client asks your lead consultant during a working session if the system can handle a new billing exception. The consultant says yes, they'll figure it out. Nobody writes it down. Three sprints later, that undocumented agreement is the reason two requirements are failing UAT and nobody can explain why scope grew.
This is scope creep — not the dramatic kind where a client demands a new module, but the quiet kind where small decisions accumulate across dozens of meetings until nobody can account for the gap between what was sold and what was built.
Change requests are the tool that closes that gap. But only if they're actually logged.
What the Change Requests Module Is
ProjektMind now includes a full Change Requests module under the Scope Control section of every project workspace. It's where you log every formal change to scope, configuration, timeline, or process — the ones that were agreed to, the ones under review, and the ones that were rejected.
Every CR gets an auto-generated ID (CR-001, CR-002, and so on) scoped to the project, so your log is traceable from the first change to the last.
Each change request captures:
- Title and CR ID — a permanent, referenceable record of the change
- Type — Scope, Config, Timeline, or Process
- Impact Scope — High, Medium, or Low
- Requested Date and Requested By — who asked for it and when
- Description — what exactly is being changed and why
- Timeline Impact and Resource Impact — how it affects the project schedule and budget
- Status — the full workflow: Submitted, Under Review, Approved, Rejected, Deferred, or Implemented
- Approved By and Approved Date — the formal record of who signed off
- Resolution Notes — what was decided and why
- Sign-Off Required — flag CRs that need formal client acknowledgment
The status workflow gives you a real audit trail. A CR that goes from Submitted to Deferred to eventually Approved six weeks later tells a different story than one that moves straight to Rejected — and both stories matter when a client disputes what was agreed to.
Linking CRs to What They Actually Affect
A change request that isn't connected to the requirements it modifies is just a note. ProjektMind connects the two.
When you create or edit a CR, you can select which RTM rows are affected. That linkage does two things: it gives you a documented trail from the change request to the specific requirements it touches, and it automatically flags those requirements in the RTM.
When a CR is approved, every linked RTM row gets flagged as cr_impact_flagged — a visible signal that this requirement has been modified from its original baseline. The flag clears automatically if the CR moves off approved status and no other approved CR links to that row. No manual cleanup required.
You can also link decisions that resulted from the CR, and connect it to the meeting where the change was raised. The CR becomes the connecting node between what was agreed to, where it was agreed, and what it affects.
The Cumulative Scope Summary
Individual CRs are useful. What's harder to see is the cumulative picture: how much has the scope actually shifted across all the changes logged on this project?
The Sage Cumulative Scope Summary answers that question. At the bottom of the Change Requests page, a single click sends all your CRs — statuses, types, impact scores, linked requirements, linked decisions — to Sage, which returns a structured prose analysis.
Sage looks for patterns: recurring scope growth in a specific area, timeline pressure accumulating across multiple approved changes, deferred or rejected CRs that carry unresolved scope risk. It addresses the PM directly and references specific CR IDs, so the summary is grounded in your actual project data rather than generic observations.
If you're preparing for a steering committee meeting or a client scope conversation, this summary is where you start.
Scope Control Lives in One Place
The Change Requests module sits alongside Risk Register and Sign-Offs under the Scope Control section of every project sidebar. These three modules handle different failure modes — risk is what might happen, change requests are what already changed, sign-offs are what's been formally accepted — but together they cover the scope and accountability layer that implementation projects need.
Every CR you log is one fewer ambiguous conversation later. When a client asks why the delivered system looks different from the original specification, you have a documented answer: here are the changes that were requested, approved, and implemented, with dates, owners, and linked requirements.
Change Requests are available on all ProjektMind plans as part of the project workspace. The Sage Cumulative Scope Summary is available on plans that include Sage AI.