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:
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.
Prioritise
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
Member discussion: