What is a small scope change?

Posted by Elizabeth Harrin

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.

Have you split your change request process in two and implemented a shorter process for the small changes? Let us know in the comments.

Tags: , , ,

7 Comments to “What is a small scope change?”

  • Elizabeth quoted here definition of a small scope change from our upcoming book scheduled for release in September 2013.. She also provided a good analysis. One may ask: who cares whether the scope change is small or large? In fact it makes a huge difference. Using small scope change has significant advantages as outlined in the book.

    Planning of large scope change uses the following planning processes, which are described in the book in great details:

    Scope Change Control
    Risk Management
    Quality Management
    Communication Management
    Configuration Management

    Planning of small scope change simplifies the process, using only the Scope Change Control, making the planning process faster and less expensive.

    Dan Epstein

  • Dan’s right. If you can make this distinction and manage appropriately there is a huge savings of effort and time. It’s not dissimilar to the process of qualitative risk analysis and risk management in general, where the *real* objective is to put the effort, time and resources on the risks that matter most to the project’s objectives.

    Thanks for the post, Elizabeth, a keen observation as usual.



  • Thanks for commenting, guys. Gosh, I didn’t realise the book wasn’t out until September, that’s ages!

  • Yes. We use to have different process to manage small & major scope changes..& it does make lot of sense to do so. the difficult part is in convincing the client about where the scope for small scope creep ends…

  • Ram, that’s true! It helps to have a definition in place before the project starts, as I’m sure you know.

  • #Ice Bucket Challenge: the hottest topic despite the name It has been a long time since there was a trending topic as hot as the Ice Bucket Challenge on Weibo. A bit of an oxymoron there. But so true. Never before have the Chinese caught a western social media bug like this.
    [url=http://www.gardnerweb.com/cdn/cms.asp?pandora-charms-on-sale/]pandora charms on sale[/url]

  • China has cut three out of four widely watched Spring Festival galas sponsored by ministries and state media, as the ruling party has stepped up efforts to cut pomp and fight corruption.

Post comment