What are change requests and do you manage them?
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:
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:
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.
Requirement Management (21) Stakeholder feedback (6) Business Analyst (16) Press release (4) Project Mangement (12) Integration (1) Issue tracking (1) Webinar (3)
Need help?Click here to contact us
"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