You have your scope change process, right? It’s working well, and everyone follows it. There are standard forms for people to submit their change requests and a proper process for evaluating the impact of each change. Then recommendations are put to a project board who make the decision about whether or not to make the change, based on a full understanding of the additional time, cost, quality or resource implications of doing so.
Even if your change process doesn’t work exactly like a textbook, you probably have something that enables you to get changes approved on your project. The trouble is, some people don’t or won’t follow the process for small changs – and that can apply to your project sponsor too, who is just as likely to ask you to do something without a full analysis.
Is there a better way? Maybe a process for handling small changes that does not have the bureaucracy of the full change management approach? Before we answer that, it’s worth looking at what counts as a small scope change.
Small scope changes can be difficult to define as it really does depend on the type of project you are working on and the overall size of the work. For example, if you are working on a six-week project, then a change that takes two days is significant. But a change that takes two days on a project that lasts two years really isn’t that big of a deal.
There’s another way to look at this as well, which is set out by Dan Epstein and Rich Maltzman in their forthcoming book, Project Management Workflow. I’ve been lucky enough to see a copy of the book before its official release date and there is a section about scope change planning and what constitutes as small change which can help us answer the question of whether a new process is needed to handle smaller requests.
Epstein and Maltzman say that a small change:
- Takes less than 8 hours of effort to complete
- Adds no additional risks to the project
- Impacts nothing else in the project
- Impacts nothing else outside the project
- Creates no new issues
- Does not add any new stakeholders or business users.
That seems to me a pretty comprehensive list of everything that could potentially fall into the small change category. Let’s go through those in detail.
- A short duration: this ensures that the change can be completed within the existing tolerances for time. You could change the 8 hour limit if your project runs to a much longer timescale than most projects and you feel that 8 hours is too short. Otherwise, it’s essentially a change that can be completed in one business day.
- Adds no risk: you really don’t want to be making changes that impact the risk profile of your project. Stick with simple things in your small change process and if you do feel that there are going to be risks with doing the work, use the full change request process to complete a proper analysis of the impact.
- Impacts nothing else in the project or outside it: this is important because if the change has an impact on other areas of the project or business then it can’t legitimately be a small thing. You’ll have to take into account new communications channels, change your stakeholder management plan and probably replan some other activity and amend other documents too. So push changes that impact other areas through the full change request process to ensure they are analysed fully.
- Creates no new issues: I think this goes without saying. Don’t consider anything as a small change if it creates more work in the form of an issue management plan! This should all be assessed and planned out as part of the full change request process.
- Adds no new stakeholders or business users: again, new users means new communications planning activity, new groups involved in testing, new people who need to be briefed on the project to date. All of this is more effort than you could predict, so it is better to fully assess the change instead of using a small change process.
So, should you have a small change process for handling simple change requests that meet the above criteria? I think you should. It saves time and paperwork – and that has to be a good thing. Your streamlined small change request could be something that saves your sanity as a project manager because it will cut out a lot of admin and make the project overall move much more quickly. It also gives you a structure for dealing with the ‘can you just?’ type requests that come from senior stakeholders. Instead of having to say yes and cross your fingers that it works out, you can push these requirements through the small change process – it’s faster and more controlled.
Your small change process depends on your full change request process, so it is hard to prescribe what it should look like. As a minimum it needs to have an entry point where someone requests a change, a brief assessment phase to check it meets the small change criteria, and then be handed off to someone or a team to do the work.