Common Project Risks and Agile Mitigations, Part 2, Requirements

As noted in Part 1, this series is intended to “identify the various reasons cited for project problems and suggest how elements of an Agile approach might minimize the risk of them occurring.” That first part set some background to where the categories of project difficulty have come from and identified a list of some 17 such categories. A number of the latter categories mentioned far less often in the sources of failure data and observations. So I’m going to cover the categories from most to least frequently cited in the belief that’s how people would like to see the parts in this series emerge.

This part will address the most frequently mentioned category of issues that can lead to project failure: requirements.

Requirements Related Issues

It probably comes as no surprise that requirements related issues are at the top of the list. After all, there would be no project unless someone felt a need to have some work done; however, problems eliciting and defining requirements “completely” are likely no surprise. The traditional phased-sequential process expects someone to explain everything they want, analysts to translate that into formats (often text-based) understandable to all others who need to know, and rigorous control over changes. This is aggravated by the fact that many “someones” (i.e., stakeholders) may be involved. (Stakeholder issues related to project problems are covered later in this series and, no doubt, contribute to requirements being at the top.)

The particular issues related to requirements mentioned in the various survey sources seem to fall into two groups:

First, late discovery of information that was assumed to be true or was not known when work began.

• Discovery that there is no more need for certain requirements (or the system as a whole) to be developed.
• Late recognition of the seriousness of requirements repercussions.
• Mid/late-development changes in requirements and scope.

Second, misperception in what could be expected and how satisfaction of expectations would be determined.

• Inadequate acceptance criteria, which results in "poor-quality" delivered software.
• Incomplete, ambiguous, inconsistent, and/or unmeasurable requirements (and other project objectives).
• Unrealistic Expectations.

One could look at this list and also say the items are communication problems. That is, inability to be capable of communicating what is needed early enough to avoid the problems described. That would be true enough. But it is also clear that change constitutes a good bit of the concern over the role of requirements in project problems. Finally, it seems that “knowledge” is another possible theme. All of these are focused here on requirements and contribute to project instability of one sort or another.

A couple of things are suggested by the above two groups of issues. In the first, much effort is usually expended based on assuming, one way or the other, that the information available after “due diligence” has occurred is, in fact, accurate. In the second, even without significant change, if criteria for assessing satisfaction of requirements are inadequate or applied only after much effort has been expended, disagreements are likely as to whether the result satisfies what was intended.

A large, up-front investment in very detailed descriptions of functionality and stringent change control procedures are often not justified by later project occurrences and lead to both of the difficulties noted above. We are asking much of stakeholders to insist they can, and should, be fully explicit up front and incur large costs when changes become necessary. However, knowing this, stakeholders must acknowledge that to avoid such problems both regular, direct communication and effective prioritization of requirements will be necessary on their part.

An interesting remark comes from Watts Humphrey [May] who has said, “You can’t design a process that assumes [requirements] are stable” so “learning what the requirements really are while building the product” should be expected.

Applicable Agile Values and Principles

When it comes to this category of issues, every Agile Value and most of the Principles apply.

From a change perspective, an Agile approach seeks a development process designed to adapt to, rather than resist, change. It does this by focusing on working software rather than documentation as its measure of achievement. This does not mean all documentation is rejected, just that it be kept as simple and direct as possible in leading to working software.

Up front specifications are kept simple (e.g., stories) with stakeholder involvement used to replace extensive documentation passed from one person/group to another. Given short iterations and frequent demonstrations of working software, simplicity and brevity in specifications is possible. Simplicity in requirements is also achieved through emphasis on the importance of test cases as executable requirements specifications. Hence, less is written in static text/diagrams and more in executable scripts.

Given that individuals on a project (e.g., developers, testers, product owners, etc.) work on effective, direct interaction between one another (on a daily basis), collaboration can replace extensive written specifications. Then, with software demonstrated and delivered within a few weeks of the start of the work (and every few weeks after that), there is significantly less chance that stakeholder expectations and development work will diverge greatly before a correction can be made.

This last point is an important one in reducing the cost of change and addressing the concern that full, up-front specification is needed to prevent disappointments at the end of the work. An Agile approach seeks validation of all aspects of the work on a frequent basis: every few hours, every day, every few weeks.

All of this, combined, does not guarantee changes will not be required that can be costly. Nothing can do that unless change is prohibited from occurring completely. In some cases, that may be possible, but usually only if the time from beginning of work until the end is short anyway. What an Agile approach can ensure is that change impacts, possible requirements misinterpretations, and issues of dissatisfaction with functionality can be identified early and resolved as inexpensively as possible, all without significant cost having been incurred until such things are discovered.