How to manage change requests in a project

Almost no project ends with the scope it started with. The client changes their mind, a requirement nobody saw appears, or someone asks for "just one more thing". That is not the problem: the problem is that the change gets accepted without anyone deciding anything. A change request is the tool for turning every ask into a conscious decision, with its cost in view, before it enters the plan.

What a change request is

A change request is an ask that falls outside the agreed scope: a new feature, an extra report, a change to something already approved. It is not a mistake (that is an issue) nor something that might happen (that is a risk): it is something someone asks for and that, if accepted, will change effort, cost or schedule.

Why you need a process, even a simple one

Without a record, small changes are absorbed out of politeness and add up. Each looks harmless; together they eat a significant share of the budget. With a record the opposite happens:

• There is evidence of who asked for what and when.
• The client sees the price of what they ask for before deciding.
• You can say no, or "not now", with an argument and not an opinion.
• At the end of the project you can explain why the planned hours were exceeded: what was not in scope is on the list.

What to record

A good change request is short but complete:

The important thing is to estimate the impact before deciding, not after.

The minimum workflow

1. The ask is received and recorded as a request, with the person who made it.
2. The impact is assessed: effort, cost and schedule. If needed, the team is consulted.
3. A decision is made: approve (it goes into the plan), reject (the reason is communicated) or leave it pending until there is more information.
4. The plan is acted on: if approved, the corresponding tasks or phases are created and dates and budget adjusted. Approving without updating the plan is the most common mistake: the decision exists, but the project does not reflect it.
5. The decision is communicated to whoever asked.

Example

The client asks for an additional sales-by-region report that was not in scope.

• Requester: the client's sales management.
• Estimated effort: 24 h.
• Timeframe: one more week in the build phase.
• Decision: approved because the client agrees to bear the additional cost.
• Action: a 24 h task is created in the relevant phase and the hours budget is updated.

If the client does not accept it, the request is rejected, on record, and the trail that it was asked for is not lost.

Common mistakes

1. Accepting changes verbally. Without a record there is no way to reconstruct what was agreed.
2. Approving without estimating. You decide without knowing the cost.
3. Mixing changes with errors. A fault is an issue and is fixed within scope; a change is something new. The guide on issue, risk or change request helps tell them apart.
4. Not updating the plan after approval.
5. Disproportionate bureaucracy. A small project does not need a committee: it needs a record and a clear decision.

How it works in PjMan

PjMan includes a change request register per project, with a simple workflow:

1. Record the request from the project's Change requests tab: title, source or requester (free text, it does not have to be a user), description, estimated effort in hours, estimated cost and timeframe. (Change requests)
2. Every request starts as pending. It is approved or rejected with a selector in the table itself, and who changed the status and when is saved.
3. Cost and timeframe are free text, so you can write "to be assessed with the supplier" or "two weeks"; PjMan does not add them up or convert them. Effort is a number of hours.
4. Approving creates nothing by itself: it is the record of the decision. You create in the plan whatever tasks or phases follow. (Tasks, Phases and sub-phases)
5. You can also ask the assistant: changes to an already recorded request are proposed on a card with the before and after that you confirm, and they can be undone for ten minutes.

Only the project's owning PM creates and decides requests; project management sees them read-only, and a consultant has no access to them. To prepare a follow-up meeting, the assistant gathers the unresolved requests, with who asked for them, the effort and how many days they have been pending.

Create your account or explore the demo.

Frequently asked questions

What if the change is very small? Record it anyway, in a line or two. The sum of small changes is the most common cause of deviations.

Can I change a decision already made? Yes, but leave a record: PjMan saves who changed the status and when, and the form warns you that you are changing a decision already taken.

Is a change request the same as a new task? No. The request is the ask and its decision; the task is the work done if it is approved.