Handling Change Requests
1 min read

Handling Change Requests

Handling Change Requests

As a project manager, I'm striving to improve the workflow for every stakeholder, in order to optimise their efficiency and involvement. Therefore, I devised a process for handling requests.

The process

The handling process is quite simple:

Request for change - Approval

Generate Request

The Business Manager collects business requirements and electronically completes the Request For Change (RFC) form.

Classify Request and Decision Body

The RFC form is discussed and finalised with the IT Project Manager. The RFC form is completed with:

  • A rough estimate of required effort and
  • A classification of the request as either scope change or project change

It is subsequently presented for information to the Decision Body to raise awareness and allow relevant stakeholders to participate. Decision Body can reject the RFC if e.g. incomplete or obviously unfeasible.

Analyse Change (only for scope change requests)

If the RFC changes the scope of the project, a detailed analysis of its implications on the project is performed by both IT and business. Its result is integrated into the RFC document.


IT Project Manager and Business Manager prioritise the RFC against the other change requests available for the project.

Evaluate and Authorize

Decision Body reviews and approves or rejects the RFC

Evaluate and Determine Actions

A complete analysis of the RFC is performed by IT resulting in appropriate artefacts for development. It is subsequently implemented by the IT team.

At any point, changes may be elevated to new projects. Each step in a request’s lifecycle is logged.

Pros and Cons

Here are several pros:

  • Everything is logged, so there is a trace in case clients "forget" about their requests
  • Helps avoiding creep
  • Can theoretically be agile

And some cons:

  • Is slower than just agile. You need investigation and approval
  • Artefacts are created/updated