Project recovery or putting projects back on track is a key ability that project managers need to possess and will be valued by their employers. Project recovery involves many steps that include examining the overall project environment, examining specific problem areas to carry out root cause analysis, and implementing the most important corrective actions as determined through Pareto charts and weighted decision tables. Carrying out root cause analysis requires experiential insights to look for clues in common problem areas, closely examining the area further to identify the root cause. Having a better understanding of project requirements helps project managers to identify the root causes of requirements-related problems and hence implement corrective actions.
Project requirements management is a critical-to-success area according to many survey reports that have studied reasons for project success and project failures Instability of requirements not only shakes the boat but can sink it as well. Therefore, the specific aspect of requirement change needs a closer look.
Nature of Requirement Changes
Having identified requirement change as a critical success factor, the questions are if requirement change should be avoided and if it is possible to avoid or easily control requirement changes. And the answer is a NO to both the questions. As any project is a human endeavor, and human thought gains clarity over a period of time, it would not be possible to specify everything with crystal clarity, which will not be changed at all. Projects will be refined as time goes by and a certain level of change is essential to ensure that the project is successful eventually. Therefore, it is neither desirable to avoid requirement changes nor is it possible to avoid them because customers will be very forceful in demanding requirement changes.
That having been said, the next set of questions that arise are – What level of requirement change is healthy and what level of requirement change can rock the boat? Why do requirements change? How to manage requirement changes? Let us explore answers to all these questions in the next few sections.
Managing Requirement Changes
A standard way of managing requirement changes is by applying a change control procedure. Most industry standards such as CMMi, ISO, and PMBoK have the standard change management documented. There are standard steps in these change control procedures – requirement changes are registered through a change request form and are documented in a change request register with assigned numbers. Then, the priority of the change is determined and the impact is analyzed. Based on priority and impact analysis, the Change Control Board (CAB) decides whether to reject the change, hold it or implement it. If it is decided to implement the change, the project is re-planned, work products are changed according to the change request, tested and documents are updated.
To go back to a previous question as to what level of changes are manageable, the answer is – if the changes are few that can be managed through the above change control procedure, the level of changes can be considered to be manageable. On the other hand, if requirement changes are going unnoticed (getting implemented in the form of scope creep) or the changes become so high that carrying out impact analysis becomes an unmanageable overhead, then, we say that the required changes are at an unmanageable level. Among the two types of unmanageable changes, scope creep is a topic by itself and is a subject for another article. We focus on unmanageable requirement changes in this article.
Thus, when requirements start changing so much that the change control procedure breaks down, the project enters crisis mode and is said to be a troubled project. This is when one has to identify the root causes of requirement changes and implement corrective actions.
Read previous posts on recovering troubled projects below:
Recovering Projects that are Troubled by Requirement Storms
In a well-researched book, Leffingwell says that requirements change because of what is called external reasons and internal reasons.
External Reasons for Requirement Change:
The external reasons have to do with changes to the competitive landscape, changes to market conditions, new legal compliance requirements, changes to the infrastructure, and so on. For instance, when a competitor supports a new feature, the current project stakeholders may get compelled to include that new feature in the current release otherwise they may lose some customers to the competition. The requirement changes arising out of external reasons cannot be avoided, as they are either critical to business success or obligatory in terms of legal compliance.
And if the changes arising out of external reasons cannot be managed using a simple change management process, then one must adopt a suitable life cycle model that is capable of handling such a level of dynamics in requirement changes. One has to choose a semi-agile life cycle model such as the 2I (incremental and iterative model), or a fully agile model such as Scrum or Kanban. In summary, if a project is in trouble because of uncontrolled requirement changes due to external reasons, the solution to be adopted is to change the life cycle model of the project.
Internal Reasons for Requirement Change:
There is another set of reasons called internal reasons and these have to do with how and from whom requirements are elicited and agreed upon.
-
Stakeholders:
The requirements originate from stakeholders, typically the business users or business user representatives. Therefore, it is important to elicit requirements from all these stakeholders. If requirements are not elicited from a few stakeholders, these people in any case will have their say later in the project and will say “This is not what we wanted” and will initiate massive requirement changes. A case study of project recovery illustrates requirements-related trouble arising out of excluding stakeholders.
- Solution: A pre-emptive action to avoid such situations would be to elicit requirements from all the stakeholders during the requirements elicitation phase. And if it was not done initially and if the project gets into trouble at a later stage, even then, the corrective action would be to put the project or specific modules on hold, initiate a requirements elicitation exercise with the initially excluded stakeholders, re-plan the project and restart the execution.
-
Elicitation Techniques:
The second root cause among internal factors is inappropriate usage of elicitation techniques. Requirements can be classified into 3 types – implicit, explicit, and undreamed. Different techniques are suited to elicit different types of requirements and there is no one-size-fits-all technique that can be used for all situations. For instance, while interviewing is more suitable for eliciting explicit requirements, brainstorming is more suitable for uncovering undreamed requirements. And observation or ‘apprenticeship’ is more suitable for uncovering implicit requirements that the stakeholders don’t articulate.
Most books on requirements engineering including that of Leffingwell and requirement engineering or business analysis bodies of knowledge illustrate multiple elicitation techniques and their suitability. In a project, if these elicitation techniques are not used appropriately, then the elicitation phase would not have resulted in clear and complete requirements. The requirements that didn’t get discovered or elicited during the initial phases start surfacing later on and will be a source of significant requirement changes throughout the project.
- Solution: A pre-emptive solution to this problem is to analyze the project before planning the requirements elicitation phase and factor-in usage of the right elicitation techniques into the requirements elicitation plan itself. And if not done initially and the project gets into trouble, it would make sense to pause the project, initiate one more small round of requirements elicitation by using the right elicitation techniques, prioritize the new set of requirements, re-plan the project, and restart the execution.
-
Requirements Documentation:
It is very crucial to document requirements adequately and clearly so that the three parties of requirements, the stakeholders, the analysts or the elicitation team, and the development team are on the same page in understanding and interpreting the requirements. If the documentation is inadequate or unclear, or if the documents have not been reviewed by the stakeholders, then there may be an understanding gap between the stakeholders and the development team and when the project is close to delivery, the stakeholders can come and say “This is not what we wanted”.
- Solution: It is very crucial to ensure there is a 3-party concurrence on what constitutes requirements and ensure a level of documentation that can ensure this consensus. If a project is in trouble because of this gap in understanding, then it makes sense to revise the requirements document, get it reviewed by the stakeholders, and re-plan the project if there are requirement changes arising out of document review.
In summary – the following are the root causes of requirement changes and corresponding corrective actions:
| Sl.No | Root cause type | Description of the root cause | Corrective action |
| 1 | External reasons | Market changes, changes to the competitive landscape, legal compliance, etc. constitute external reasons. | These changes must be permitted and usage of an appropriate life cycle model such as 2I, Scrum, or Kanban would be the solution to requirement changes arising out of external reasons |
| 2 | Internal reasons – Stakeholders | Requirements not elicited from a few stakeholders can give rise to significant changes later on. | The solution is to put the project or specific modules on hold, elicit requirements from these stakeholders, and re-plan and re-start the project. |
| 3 | Internal reasons – Elicitation techniques | Not using appropriate elicitation techniques can result in requirement changes surfacing frequently throughout the project | The solution is to put the project or specific modules on hold, elicit requirements using appropriate techniques, re-plan and restart the project |
| 4 | Internal reasons – Documentation | Inadequate or unclear documentation can result in the development team developing something that is not in accordance with what stakeholders expect. | The solution to this problem is to revise the requirements document so that all 3 parties of requirements arrive at a common understanding of the requirements |
Conclusion:
To conclude, it is well known that a certain level of changes to project requirements can be healthy and aid in business success. But when there is a requirement storm the best practice is to pause and take corrective actions where you elicit requirements from all the stakeholders using proper elicitation techniques and revising the requirements to put the project back on track.
