Image by Aline Dassel from Pixabay.
One of the most important causes for project delays and budget overrun is requirements change. Actually, it is not the changing requirements that make projects fail. It is the negligence of properly dealing with them.
There are many reasons for changing requirements within a project life cycle. In one of my blog posts I wrote about causes for changing requirements that can be avoided. Does change prevention solve all problems? – I do not belive so! Lack of flexibility has made projects and even companies fail. In another blog post I presented good reasons why change should even be initiated by the project manager.
So what can you do, to prevent changes making your project fail? The answer is: requirements change management. Here is my approach.
Phase 1 – Creating Conditions For Requirements Change Management
Effective requirements change management depends on preconditions. Some of them can be created during the planning phase (project management perspective). Others within the requirements analysis phase (system engineering perspective).
Precondition 1: Flexible Planning
I think it is easy to understand that the impact of requirements change can be quite different, depending e.g. on
- project type – a construction project will have a more limited flexibility than a website project (it will have more impact to change the layout of a building that is under construction than changing the look of a website)
- project stage – when the project is almost finished and the results are nearly completed, changes will be more expensive and will have more impact on the completion date than in early stages of a project
While the project type can hardly be affected by planning, the project stage can. Does the complete design have to be frozen early? Or can partial decisions be made later in the project? Flexibility for requirements change management can be gained by optimizing tasks and shifting decision points to later project stages – when possible.
Precondition 2: Changeable Requirements
Changing requirements creates risks. Risks are not a problem, when they can be managed. So what are the risks here? Major ones are certainly interdependencies with other requirements or requirements creep. In particular this needs to be analyzed for each specific change.
Well-specified requirements can support this analysis, if they include:
- traceability – if the interdependencies of a requirement (which can be higher, same or lower level requirements as well as documents, plans and other information linked to the requirements) are recorded, the impact of a change can comprehensively assessed
- rationale – the reason that exists behind the original requirement specification explains why the requirement exists as it is. It can support the assessment, whether the change is beneficial or not. The reason could even be invalid at the time of change.
- owner – there must be someone who is entitled to make a decision about a requirement’s change – the owner. The owner is the one who is responsible for the requirement and connects all links that influence and are influenced by the change.
If you have deeper interest in this subject, I recommend this article of John Simpson that covers the important aspects of requirements traceability related to requirements change management.
Precondition 3: Defined Requirements Change Management Policy and Process
I am convinced that the key characteristics for effective requirements change management are
- to make sure that necessary and beneficial changes are implemented and
- unnecessary or detrimental ones are sorted out.
These are my key considerations when I develop a requirements change management policy. An effective process considers:
- change request – Who can submit a change request? What information has to be included in a change request? – Develop a change request form
- change control board – Who will be involved in the decision making process? How will the communication be performed? – Set up a change control board
- decision making – What are the criteria that are taken into account when making the decision? – Develop a decision matrix template
- approval – Will the project scope (budget and schedule) change? Who has to approve the change? – Involve these stakeholders early and convince them of the benefits of a necessary change
- change plan – What has to be done to implement the change? When does it have to be done? How can it be tracked? A change plan should tell you how to get from the current situation to the desired situation
I am sure that with this foundation, a project manager is well prepared for the changes to come.
Phase 2 – Dealing With Change Requests
If you have defined your requirements change management process, you already know what to do. Beyond that, here is some advice you may want to consider when dealing with change requests.
Tip 1 – Think before you act
When a change request comes in, it tends to create disorder. Your first priority should be keeping the project on track – on budget and schedule. Before you leave the proven path, make sure that the new path is clear of obstacles. And make sure you have the approval of the relevant stakeholders. Until then: Follow your existing project plan – and its objectives.
Tip 2 – Understand The Problem
When you have ensured good traceability of your requirements, it might be easy to analyze the impact of the requested change. But will the change be sustainable? Understanding the reason behind the change request will help to answer this question. And the answer is useful. Nobody wants to change a new requirement again after a few weeks because the first change did not solve the problem.
Tip 3 – Consider Alternatives
If you understand the problem behind the change request, you may think about alternative solutions. Maybe the solution proposed in the change request is not the most effective to solve the problem. Probably you will find a solution that meets the needs of the request and makes your life easier.
Tip 4 – Create Involvement
When there is change – there is opposition. A proven strategy in requirements change management is involving the affected people. Those who fund your project – and those who have to work with the change. If their concerns are taken into account, there will be a sustainable solution and happy people. Who would resist that opportunity?
Tip 5 – Get the approval
At some point it is time to stop thinking and start acting. There is a final step that should be taken before implementing the change: the approval.
By now you will have found out whether the change is necessary and beneficial. Will it also affect the budget and the schedule? In case the project end date shifts to a later date or you need to spend more money, you will need the approval of some of your stakeholders. Now it is the time to get it.
Tip 6 – Make a plan
You already knew where you were. And now you also know your new destination. But how can you get there? A change is a project in itself. Take it seriously. Find out what has to be done. Define who will do it and when it has to be completed; and how the progress can be measured. And record all that in a requirements change plan (which could be as simple as an action list).
Those were my tips. Maybe you are interested in some more tips from Vadim Katcherovski in his article about requirements change management.
Phase 3 – Implementing Change
The final stage in my requirements change management approach is aiming on the successful implementation of the change. Or – if necessary – the handling of unforeseen events. What are key activities in requirements change management that should accompany the implementation process?
Configuration Management
Before you start implementing any change it may be wise to record the configuration. In particular if it is a working one. From that point, I recommend logging any change. In case things happen to go wrong at some point, a change log will be a fountain of knowledge to get back on track. And this is not only for software projects.
Communication
If you haven’t already done it – now it is the time: inform everyone who is affected by the change. What information needs to be given? Here are just a few questions I am used to hear when changes appear: What was the problem? What is the solution? How does the solution solve the problem? How am I affected? What do I have to do? When does it have to be done? …
Communication should not be one way only. Keep your ears open while change is being implemented. You might find out about unexpected events before they cause damage.
Monitoring
One of my tips was to establish an effective plan to implement the change. Monitoring shall assure that this plan is followed. But there is also a second purpose. Most probably during implementation it turns out that some things do not develop as planned. By monitoring you obtain the information that is necessary to react to unforeseen development. It enables you to adapt the plan accordingly.
Verification
How can you measure the effectiveness of your requirements change management activities?
One criteria is that the problem is solved. How can you verify this? Perform a formal check-out review within the change control board. Of course the originator of the change should participate. Once you verified that the problem is solved, formally close the change process.
Another criteria is that the project is still on track after the change. I am confident that my requirements change management approach supports keeping that criteria. But of course it depends on a good project control.
What is your experience in requirements change management? Share your thoughts in the comments below this post.