:quality(90))
:quality(90))
“Who rejects change is the architect of decay. The only human institution which rejects progress is the cemetery.”
~ Former U.K. prime minister Harold Wilson
Change is unavoidable — but that doesn’t make it easy.
Clients change their minds, industries evolve, and business trends pop up fast and fade away just as quickly.
The longer you work in and around projects, the more you see how easy it is for changes to delay or even derail a project.
To get a handle on project changes, many client services organizations adopt a formal or informal system of change request management. Done well, a change request management system can filter out risky and unnecessary changes while reinforcing and supporting needed changes.
What is a change request?
:quality(90))
A change request is a formal proposal to make some kind of change within an organization, including changes to projects, workflows, and business processes.
As part of the change management process, change requests are key in project management because projects are bound to change. But when those changes happen invisibly or in the shadows, they turn into scope creep.
The project gets more complicated or more costly, but no one accounts for those changes in terms of schedule or budget. As a result, the project runs late or even fails completely.
Change requests clarify the necessity and impact of a proposed change, enabling decision-makers and project managers to navigate (or say no to) a change properly.
Also worth noting: change requests can come from outside a business. When your client requests an ad hoc change to something you’re creating for them, that’s a type of change request.
You can categorize change requests as:
Standard: Everyday small changes with low risk and low impact.
Normal: Significant yet common type of change, often made up of multiple standard changes.
Major: Rare, significant change with budget or schedule implications that likely require specific approval. High risk, high reward.
Emergency: Extremely high priority, drop-everything-and-do-it kind of change. Something is probably on fire. (Metaphorically, we hope.)
Change requests show up most often in traditional project management. Depending on who you ask, change requests in Agile project management may or may not be a thing.
If a change is crucial enough to put a sprint on hold, then it might follow the change request pattern. If it isn’t, then the Agile process itself should accommodate that change in the next cycle.
:quality(90))
The change request process
Businesses with formal change management procedures in place will have a standard change request process. The steps and specifics can vary, but most processes in this category generally follow the steps below.
1. Initiate change request
First up is creating the change request. Anyone involved in a project (including project team members, stakeholders, and even external sources like your clients) can initiate a change request. Often, they’ll use a standardized change request form or template your agency created.
For the best chance of success, any change request should clearly describe the proposed change (what are we doing?), its rationale (why do we need to do it?), and potential benefits (what good will it do?).
You’re not going to get this last one from client-created change requests. But when possible, internal change requests should also include known ramifications — for example, how much it will cost or how much time it will add.
2. Review and evaluate
Next, someone reviews the change request. Who does the reviewing is up to you, but be sure to decide who gets this job.
If you have project managers, they’re usually a good choice for this. They understand the project, perhaps better than anyone else, and tend to be less biased than any individual contributor.
A designer, for example, might be too quick to say “yes” to a change because it will make the project look better from a design perspective. On the other hand, they might also be too quick to say “no” because they’re the one who has to do the work!
A project manager or project lead usually sits in a better position to see the big picture.
Once you’ve selected the person who will complete this step, what should that person do?
In a nutshell, they assess the impact that the change will make. How will it affect the scope of the project? What about the schedule? Budget? What risks does the change create, and are they worth it?
Last — and often most important — how will the project stakeholders respond?
3. Analyze impact
Usually, the reviewer will also conduct (or manage) an analysis of the potential consequences and impacts of the change.
For smaller projects, this step is probably a part of the review (step two). But for larger projects (think like a multi-year interstate construction project), an impact analysis could be its own project, lasting weeks or even months!
Let’s bring it back down to where most of us operate. If your impact analysis is a separate step, it’s likely going to involve consulting with team members, subject matter experts, and stakeholders. You’re trying to get as much information as you can about what the change will do.
Once you have that information, you can compare the impact to the risks and costs you identified previously. And hopefully, the data you’ve collected will lead you to a clear answer for step four.
4. Approve or reject
Based on the evaluation and impact analysis, the reviewer will either approve, reject, or send back the change for more information.
Are the long-term impacts worth making the change? Approve that change and make the necessary schedule and budget adjustments.
Is the change just too risky for the value it might offer? Reject it. Remember, there are plenty of changes out there that you could make to any project or project deliverable, and most of them have some kind of upside. But if you say yes to every change with an upside, you’ll never complete the thing you’re trying to build!
Not sure whether you should approve or reject? Then you might not have all the information you need. Identify what it would take to give the asker a clear yes or no, and send the change request back so they can provide that information.
You can also give conditional approval, requiring the asker to make adjustments to the requested change or provide a mitigation plan.
5. Communicate the decision
We know this sounds a bit obvious, but hang with us for a minute. Once you’ve approved, rejected, or sent back the change for more information, communicating this information to the right people is crucial.
Who are the right people? Start with the requestor, and don’t forget about the stakeholders.
And who are the stakeholders? Well, it depends on the type, severity, and scope of the change.
When you communicate the decision, be as clear and informative as possible. Give clear explanations for the reasoning behind the decision (especially if it’s a no), and make sure your audience understands what the next steps look like.
6. Implement change (if approved)
Next, it’s time to implement approved changes.
You’ll want to work according to a defined plan that includes at least these steps:
Assigning tasks to team members
Adjusting schedules and budgets
Updating project documentation
Communicating changes to stakeholders
:quality(90))
7. Monitor and track
Once you’ve accounted for the effects on the project’s trajectory, it’s time to sit back and watch the change unfold (or get busy making the change yourself).
Best-case scenario, the change goes according to plan and doesn’t cause any further ripples. But if something does start sliding sideways, you’ll need to be there to pick up on it and address it promptly.
8. Close change request
After successful implementation, it’s time to close the change request. As a part of this step, make sure to document the outcome and lessons learned.
Tips for effective change request management
:quality(90))
As you follow the eight steps above, you’ll doubtless run into snags and hurdles along the way. Remember, change is hard. If it were easy, you wouldn’t be here reading this blog post! But these six tips can help you overcome those challenges.
Develop a clear change request process: This one’s kind of implied throughout the eight-step process, but be sure to create a clear, consistent, repeatable, and documented process for change requests. Then make sure that everyone who might use it understands how to create a change request and what will happen once they do.
Use a dedicated change management tool: Managing these processes and steps manually is incredibly difficult. Instead, implement a tool or software that can track and manage change requests efficiently. Teamwork.com, for example, is a great change management software solution.
Train your team: Take the time to train everyone in your agency on your new change request process — both how to use it and what their roles are within it when they aren’t the requester.
Regularly review change requests: Keep up with change requests by scheduling regular meetings to review and discuss them. This both reduces volatility and ensures requests don’t go ignored.
Communicate effectively: Any change, no matter how small, can affect the people involved in the project. Keep them informed about changes, decisions, and impacts on the project.
Document everything: You don’t want to end up fighting off irate stakeholders (or clients!) who are adamant they never signed off on a change. So, document everything and keep detailed records of all change requests, including the rationale for approval or denial. These records can also help guide decision-making for future projects.
Manage your change requests effortlessly with Teamwork.com
Setting up a change request management process and communicating that process to your clients and your team is a huge first step toward getting a handle on project changes.
Let’s be clear, though — a change request system is a smart move, but it still isn’t a simple process. There are plenty of pieces of information and steps to track, processes to run, and documentation to update.
That’s where Teamwork.com comes in.
Teamwork.com is operations and project management software built for client work. It’s incredibly flexible and intuitive, with functionality and templates to cover all kinds of projects and processes, including the change request management process.
See more of what Teamwork.com can do for your business now - get started now for free, view our comprehensive pricing plans, or book a demo today.
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))