RequirementOne Logo

What are change requests and do you manage them?

Martin Gorm Pedersen
WRITTEN BY Martin Gorm Pedersen - 24 January 2013

Ok – so even when you have a beautiful plan and specification for your project – it is a fact of life that something is going to change! So rather than try to avoid change let’s look at how to manage it.

Changes generally happen for good reason and if dealt with in the right way will ultimately deliver a better solution for your stakeholders… If change requests are not managed properly they can spell disaster…

So now that we have looked at how to manage requirements then let’s have a look at the changes that will inevitably be introduced to your requirements.

When we are talking about changes then we are considering the scenario where an initial set of requirements have already been agreed on and the development has typically been started after accessing scope, deadlines and budget. These changes we typically refer to as change requests.

There are in principle two different kind of change requests during this period of time:

  1. Changes inside of scope
  2. Changes outside of scope

So how can you tell the difference if you are building a product internally or for a customer? Well actually it doesn’t matter.

A change that is inside of scope, is a change that typically will be a small correction or refinement to an existing requirement that will have little or no impact on the deadline or budget. The other type of change request that are outside of scope will take considerable time to implement when you consider the project management, development and testing that typically needs to be done.

The threshold for what is inside and outside of scope is typically defined by project management e.g. changes that take less than 30 minutes of development time is inside scope and we accept a maximum of 20 of these. A more informal approach would be to gather all change requests and deal with them on a recurring project management status meeting.

When change requests are received then it would typically be good to let the submitter answer the following questions:

  • What is the change requested?
  • Why do you want this change?
  • How important is this change to you?
  • What part of the product is it related to?

Document. The received change requests should be organized in a “change request specification” or "business requirement" specification similar to requirements as described above. In addition an estimate should be assigned for each requirement and an “impact assessment” note should be added by the developer outlining any impact that the change might have on the existing system.

Classify. Each change request would then also have a lifecycle indicating where in the process it is e.g. New, Analysis, Ready for decision, Rejected, Approved.

Now that we have looked at how to deal with changes then let’s have a look at how you can manage your project day to day using RequirementOne.

Bookmark and Share

Want to run more successful projects?

Start organizing, managing and sharing your requirements now with your free 14 day trial

Get my free account

No credit card required. We guarantee 100% privacy. Your information will not be shared.

Blog topics


Join our mailing list for requirements tips, blogs and other great content.



Martin Gorm Pedersen (Founder)


Get my free account

No credit card required. We guarantee 100% privacy. Your information will not be shared.

Make your next project better

"RequirementOne has allowed us to regain control of our requirements, no longer having to struggle with updating our unwieldy word document. I now couldn't imagine living without filters when organizing sprints." - Luke Kirkpatrick, Software Engineer & Product Lead

RequirementOne Inc. © 2014

1250 Oakmead Pkwy., ste 210
Sunnyvale, CA 94085-4037
United States
Main +1 877 737 8473

Terms & Conditions