Agile methodologies are spreading across a broad range of industries and functions. Agile is a great approach when done well. Results improve, increasing confidence and engagement throughout the organization. And yet, have you experienced an agile project that begins with great promise but ends as a failure? At Group Atlantic, we’ve found that some organizations occasionally blunder and therefore suffer acute frustration with projects that fall short of stakeholder expectations due to defective requirements practices.
From our work advising and studying client companies, we have discerned many blunders that leaders should avoid if they want to fully capitalize on agile’s potential. Here are key indicators that warn you when you are about to make a requirements blunder:
1. Insufficient Stakeholders Engagement
Stakeholders can be missed early in the project because some of the business areas that are affected may not be known. As the project progresses, it encounters a new business area, but a representative from the business does not become part of the extended project team, or arrives too late to be effective.
An effective Stakeholder Analysis helps ensure that the proper perspectives, sources of expertise and experience, and decision-makers are effectively engaged in the project. A Stakeholder Analysis is not a one-and-done event. It’s an activity that should be reviewed throughout the life-cycle, especially when elicitation discussions enter a new business domain.
Identifying your key decision-makers early helps you know who can resolve issues expeditiously and keep the project moving toward delivery. Including the proper stakeholders who are depending on the requirements during work product reviews enables them to judge when it’s appropriate to proceed with implementation.
2. Ambiguous Requirements
Ambiguity is the single greatest threat to getting requirements right, right now. If a requirement statement can have several different meanings and you’re not sure which is correct, then the requirement is problematically ambiguous. A more treacherous kind of ambiguity results when multiple stakeholders interpret a requirement in different ways. Each stakeholder concludes that his interpretation is correct, and the ambiguity remains undetected until later—when it’s far more expensive to resolve.
If you can’t think of tests to verify whether each requirement was properly implemented, your requirements are not sufficiently well defined. Developers might assume that whatever they’ve been given in the form of requirements is a definitive and complete description, but this is a risky assumption. As my associate Bob Charette says, “Assumptions made are risks accepted.”
3. Poorly Prioritized Requirements
Too often an influential stakeholder will declare “All my requirements are important, or I wouldn’t have given them to you.” Simply stating that all requirements are equally critical deprives the organization of the opportunity to invoke a systematic way to respond to new requirements and to changes in project realities (budget, staff availability, deadlines). If it’s not clear which features you could defer when events force the need to reduce scope, poorly prioritized requirements force the team to make decisions without adequate guidance from the business.
4. Including Functionality That No One Uses
Many organizations experience the frustration of specifying, architecting, designing, coding, and testing features that stakeholders insisted they needed, and then not seeing anyone use them after deployment. Be careful of stakeholders who suggest, without basis, an extravagant user interface that must be present for the software to be “useful.” Also beware of features that add unnecessary functionality that “the users are just going to love.” In short, watch out for proposed functionality that isn’t clearly related to the project’s goals. Remember that the job is to satisfy the customers’ needs. Involving actual users will reveal which features will be “loved” and which will be ignored.
5. Analysis Paralysis
Business Analysts can fall into the trap of feeling that the requirements they are eliciting must be 100% correct before they share them with anyone. They feel that any corrections or changes to the requirements mean that they did not do their job correctly. “Death March”[1] projects often are characterized initially by requirements development that seems to stagger on endlessly. Analysis paralysis results when the viewpoint prevails that no software implementation can start until the requirements are “perfect.”
In business the goal is not to create perfect requirements, but to develop a set of clearly articulated requirements that permit development to proceed as soon as possible and at acceptable risk. If some requirements are uncertain, select an appropriate development lifecycle that will let you implement portions of the requirements as they become well understood. Flag any knowledge chasms in your requirements with “To-Be-Determined” warning markers, to indicate that proceeding with construction of those parts of the system is a high-risk activity that warrants expeditious escalation and careful follow-up.
Model and prototype only the complex or poorly understood parts of the system, not the whole thing. Don’t make prototypes more elaborate than necessary to resolve the uncertainties and clarify user needs. Simple prototypes can prove a design’s viability with a small expense of time and money.
6. Scope Creep
Most projects face the threat of scope creep, in which new requirements are continually added. Stakeholders keep imagining more functions to include, and additional business processes to support. Another factor is inadequate analysis, which is discovered when critical information appears in testing. This becomes a problem when project deadlines can’t change, the project is not properly or adequately staffed, and lower priority requirements are not removed to accommodate the new functionality.
When the product scope was never clearly defined in the first place, the risk of scope creep dramatically increases: schedule delays, cost overruns and diminished quality. If new requirements are proposed, rejected, and resurface later—with ongoing disputes about whether they belong in scope—then scope definition was inadequate.
Requirement changes that sneak in through the back door, rather than through an institutionalized change control process, lead to the schedule overruns characteristic of scope creep. If approval of the requirements is merely pro forma, then continuous waves of changes will derail the project and anger stakeholders whose expectations were not met.
7. Insufficient Change Analysis
Often, leadership and stakeholders approve changes without understanding the implications, or reaching agreement about the most viable action to take. What is initially perceived to be a trivial change might grow into a problem more complex than anyone anticipated. The approved change might take longer than promised, be technically or economically infeasible, or conflict with other requirements. Such decisions reflect insufficient analysis of the impact of a proposed change. Another indication of inadequate impact analysis is when developers continually discover affected system components as they implement the change.
Avoid Requirements Blunders In An Agile Era
Agile is a great approach when done right, but is your team making these common mistakes? Take a look in the mirror and be honest with yourself on the approach your team is taking. While these seven blunders aren’t the only ones potentially found in an organization’s practice, they are among the most common in industry and the most severe in consequence. Understanding and eliminating these blunders will significantly improve your team’s performance.
For more about improving performance, please take a look at our Right Requirements, Right Now practice area.
[1] http://www.amazon.com/Death-March-Edition-Edward-Yourdon/dp/013143635X
