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:
- Changes inside of scope
- 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.