Change Request Management: A Three-Column Framework That Works

A client asks for an extra feature partway through a project. It sounds reasonable, so someone notes it down as “something we’re looking at.” Weeks later a resource constraint turns up, the feature gets dropped, and the client is confused, because as far as they knew it was already agreed. Change request management exists to prevent exactly that confusion. Sort every request into one of three categories, confirmed and in progress, pending approval, or rejected and deferred, and the category itself does most of the communicating for you.

Why Do Change Requests Turn Into Scope Creep?

In IT project management, change requests are a genuine double-edged sword. Accommodating a good new requirement can improve the outcome. Left uncategorised, the same request turns into scope creep and a client who feels misled.

The risk is conflation, and it’s rarely malicious. A request gets discussed favourably in an internal channel, someone mentions it to the client as “yes, we’re doing that,” and it was never actually costed, scheduled, or approved. The client now believes it’s confirmed scope. When the gap surfaces later, usually at a worse moment than now, the result isn’t just an awkward conversation. It’s distrust, a stalled timeline, and sometimes a dispute over who owes what.

Most of these requests don’t arrive as a tidy ticket either. They show up buried in a client email thread alongside four other topics, which is its own extraction problem before you even get to categorising anything, see structured requirements from a messy client email thread for how I handle that end of it. The categorisation problem starts the moment a request is pulled out of that thread and written down somewhere.

The fix isn’t complicated. Keep a precise record of every request’s status, and say that status out loud to the client, every time.

The Three-Column Framework for Change Requests

A practical way to run this inside whatever project management tool you already use is a three-column board: confirmed and in progress, pending approval, and rejected or deferred.

Category	What belongs in it	How you talk to the client about it
Confirmed and In Progress	Fully approved, scheduled, actionable work that needs no further sign-off	Regular progress updates and expected completion dates
Pending Approval	Requests still under discussion, not yet costed or agreed	What’s being considered and what factors are still in play
Rejected or Deferred	Declined or postponed requests	A clear reason, and an alternative if one exists

The columns aren’t just labels, they’re the message. If a request is sitting in Pending Approval, the client should be told it’s under discussion, with a reason, not left to assume the silence means yes.

A Change Request Lifecycle: Pending to Confirmed to Rejected

Here’s how the categories actually move on a live project. A client asks for an additional feature. It isn’t costed or scheduled yet, so it goes into Pending Approval, and that’s what the client is told: this is being considered, here’s what we’re weighing up.

Discussion continues, and the feature turns out to fit the project’s goals and the budget, so it moves to Confirmed and In Progress. The client is told that too, along with a rough timeline.

Then, partway through development, a resource constraint turns up that wasn’t visible at the point of confirming. Despite the earlier approval, the feature moves again, this time to Rejected or Deferred, because the budget genuinely can’t stretch to it.

That last move is the one people flinch from communicating, since it looks like reneging on a commitment. It isn’t, if the client has been told about the constraint as soon as it surfaced and given the reason plainly. What breaks trust isn’t the rejection. It’s a rejection that arrives as a surprise, after weeks of silence following what the client understood was a green light.

How Does This Help With Resource Planning and Forecasting?

There’s a second, quieter benefit to running the framework this way: it turns your Pending Approval column into a forecasting tool, not just a parking lot for undecided requests.

Every request sitting there has a rough cost. Track it as a “Total Contract Value Opportunity”, the potential upsell revenue if the client approves it, and you get a running total of work that could land, not just work that already has. That number feeds two decisions: whether you have the resource capacity to take it on if it’s approved, and whether your revenue forecast should count it as a possibility.

That same data is worth putting in front of leadership, not just holding for your own planning. I’ve found a single executive dashboard that surfaces confirmed scope, pending value, and rejected value side by side does more to align expectations upward than a verbal update ever does. A number attached to “pending” reads very differently from a number with no category at all.

How Do You Roll This Out on a Live Project?

1. Set up the three columns in whatever project management tool you already use. Don’t wait for a new system to justify starting.
2. Train PMs and stakeholders on what belongs in each column. The discipline is in the categorising, not the tool.
3. Track Total Contract Value Opportunity against Pending Approval so it feeds resource and revenue planning, not just status updates.
4. Communicate every category shift to the client as it happens, especially the downgrades, since those are the ones people are tempted to delay saying out loud.

None of this needs new software or a heavier change control process. It needs one discipline: never let “we’re looking into it” and “we’ve agreed to it” sit in the same column. Pair that with the kind of plain, specific client communication I’ve argued for in stakeholder management, one message, one owner, no ambiguity, and change requests stop being the thing that quietly erodes a client relationship.