I have rarely been as proud as when I held a beautiful, accurate, concise, clear requirements document that I had just gotten approved by all the stakeholders. What a feeling of accomplishment! Unfortunately, the excitement often turned into frustration as soon as someone identified a change that was needed.
Change is inevitable on all but the simplest and shortest of projects. In some cases, such as missed requirements, we need to identify the root causes and put preventative measures in place to avoid future reoccurrences. But in other cases, the business need changes for strategic, tactical, or market reasons.
Plan for the Inevitable
So, what can we do about the inevitable change?
As simple as it sounds…plan for it before you need it. Change you haven't planned for is usually unmanaged change, and unmanaged change is a bellwether of project failure.
The first thing a Business / Systems Analyst should do is track down the Project Manager. The PM should be concerned about anything that impacts a project’s schedule, cost, and quality…and unmanaged change is a risk they are acutely aware of. The PM and BA need to be in lock-step on how requirements changes are managed.
Together, they need to create a plan to address requirements changes. The significant questions that need to be considered are:
- Identify - Who is going to discover requirements changes? How will items be identified as changes? Who needs to be notified when a change is identified?
- Quantify - How are requirements changes going to be tracked? How will the impact of the change be determined?
- Communicate - How will you determine who needs to be aware of the change? How will you determine who needs to approve the change? How will you communicate the effect of all requirements changes on the project?
After it is created, the plan should be communicated to the affected parties. In some cases, the plan is formalized into a Requirements Management Plan or rolled into the project's overall Change Management Plan. In other environments it can be simpler and less formal, as long as everyone understands it and agrees to it.
Without a clearly articulated plan, requirements changes can easily be mishandled, leaving decision makers and important stakeholders out of the loop. And if changes aren't tracked, it is very hard to communicate the cumulative effect on the project.
The Easy Stuff
If you're looking for simple steps you can take to improve requirements change tracking and communication, two of the easiest things you can do are:
- Add a change log to each requirements document, then clearly and concisely track the changes made
- When changing a signed-off document, send an email to the affected stakeholders that summarizes the changes (with references to changed sections). Don't expect all the stakeholders to pour through the whole document to see whether they need to be concerned about each change. Also consider adding highlighting to the changes within the document; MS Word's change-tracking feature makes this easy to do, though it can be hard to interpret.
Delivering with Change
Change can be very frustrating, but some change is inevitable and necessary. If you can start with some simple steps and work to establish appropriate ways to identify, quantify, and communicate requirements changes, you can help your projects stay relevant to the changing business need.