Over the course of our decades of working on digital projects, we have found one of the best was to ensure a successful project is by planning properly.
But we have also realized that it doesn't matter how well you plan, there’s no way to completely avoid changes as your project unfolds. But this doesn't have to be a problem.
This is where change requests come in. They are absolutely essential to keeping any project on track and budget after it has started.
What is a change request?
A change request or sometimes called a change order, is a formal written request to change some part of a project from what you have already agreed on in your plan.
These change requests can be asking for something beyond the scope of the project (not included in the original plan), or to change something already committed to.
The importance of change requests
If you have gone through proper project planning you should start with a clear list of requirements and responsibilities – change requests are the addenda to the project document.
Using change requests allows you to expand your project document as you go along making sure you have an accurate record to be accountable to.
When you have a thorough project manager who has ensured that there are formal change requests for every change (even the ones that don’t add scope), you will have a full record of the project as it’s unfolded which is important if:
- Someone doesn’t like the end result and wants to know how you got there
- There is a need to granularly account for budget
A formal change request process will also serve to stop people suggesting any idea that comes into their head. Like the concept behindunpleasant design, if there’s a full process for getting changes in the system, stakeholders are more likely to give a little more consideration to what changes they will submit.
Third, a change request formalizes the request to the development team. This means the submission has to be clearly articulated, rather than just a providing a vague idea and expecting them to understand (X happens a lot, Y causes a lot of problems.)
For example, imagine a request by email for the design and development team to change all the call-to-action buttons on a website to be 'more clickable’ – that is a poor change request.
However, if the project had a formal process that captures what’s in scope now, what needs to be changed, and what it needs to be changed to, it makes it easier for the development team to execute and produce exactly what is expected.
In this example, if the change request said:
‘CTA buttons need to be more clickable by making the font contrast more with the colour (but keeping the colour within the brand palette) and making them 20% larger’ – then that’s an easy change to make.
Finally, clear and well-documented change requests mean that developers and project managers can say yes more often.
Most projects budget for a few extra changes and if you consolidate all the change requests and make them as detailed as possible, it’s often a small job to put them into place without risking the whole project. If they come in via email or over the phone with loose specifications, it’s much harder to know if you have the scope to make the changes or not.
This means suppliers get to say yes more often, and clients get a better product that better suits their needs. It’s a win-win.
What makes a good change request
There are a few key pieces of information that should be included on any change request. These will come from either the client’s project lead, or the team implementing the change.
To see a sample of our change request, click here.
1. Impact
Different requests will have different impacts on the project. Changes to critical systems and milestones should be treated differently from minor changes that don’t require any change to the project scope. These thresholds will be different for every project.
2. Cost and timeframe
How much is the change going to cost? Most changes will take some resource to put into place (and thus increase the cost), as well as push the timeline out. Both of these should be documented in the change request that gets approved by the client.
3. Approval
Who else has read this and confirmed that the change can go ahead? Most projects will have a steering committee, made up of a client’s project lead, a project sponsor, and project manager. Before a project starts, there should be some preliminary agreement over who can approve what.
For example, changes that don’t require more money might be fine to be approved by the PM. Anything that requires more budget will likely go to the sponsor or the full committee, depending on the nature of the job.
It’s important that whose approval is needed is on the change request.
4. Confirmation and clearance
Confirmation from the client side that they’re happy to accept the impact and revised cost and timeframe, and confirmation and clearance from the development team that they can handle the change for the budget and time they’ve set.
5. What’s changing (specifically)
The change request should reference what was in scope, what it is being changed to and why. This should be as specific as possible.
This is also where unpleasant design comes in – if you’re asked to justify why you want the change, it might deter the ‘well I just don’t like it’ changes.
Wrap up
Change requests can seem like horrible red tape you have to cut through to get anything done. But in reality, they are an essential part of delivering a project on time and on budget.
In our opinion, the humble change request is the linchpin of a well-run project.
