Most people think of requirements definition as a one-time activity within a software project. In fact, there are at least two key points when requirements should be defined. Failure to recognize these points can lead to trouble.
Perhaps the most often missed point is feasibility analysis. Whether it's explicit or not, and regardless of the methodology used, every project has a feasibility analysis phase, which should include important requirements definition. When done poorly, as so often happens, the project is almost certainly destined to fail.
Every software project needs feasibility analysis
Sometimes referred to by terms such as "project initiation," feasibility analysis determines whether or not to do a project. If a project exists, someone has made some decisions about it. Essentially they've identified what they expect the project to produce and whether it seems worthwhile to do so. That in a nutshell is feasibility analysis.
Many organizations conduct formal feasibility analyses, especially for projects they expect to be larger than a certain size in terms of duration and/or cost. Of course, such thresholds can create their own problems, since people are likely to describe their project as just below the cutoff size so they don't have to do a formal feasibility analysis, which they probably perceive as extra work.
Some organizations submit the feasibility analysis results to a steering committee, which is charged with determining which proposed projects will be performed. Steering committees typically consist of senior executives with budgetary authority over the various areas competing for scarce project resources. In other organizations, and often for projects deemed smaller, senior executives tend to go through less formal -- though often no less defined -- processes to determine which projects to perform. For some, identifying the next year's projects is a major part of formal annual budgeting...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
.
For many, project definition and approval is a less structured activity. When the executive has total budget control, they may make project decisions unilaterally with no explicit procedure or schedule, typically as the need for the project comes to the executive's attention. They may put together a somewhat informal description of the proposed project and the rationale for doing it. Or they may make more formal descriptions if the executive group must approve the project or funding of it.
Regardless of whether the analysis is done solely by the authorizing executive, possibly without much conscious awareness, or as part of a formal or informal process involving others, it's a feasibility analysis. The outcome of feasibility analysis is a project definition (what the project is expected to produce) and the project budget and schedule (which seem worthwhile relative to the expected project benefits). Organizations differ on whether they refer to these as "cast in concrete" or "cast in stone." Both hang heavy around the project team's neck, especially when based on inadequate requirements.
Who does feasibility analysis and when?
In some organizations, this project definition feasibility analysis is considered separate from and preceding the project itself. In such cases, a project manager is usually not assigned until the project has been defined and approved. When such analysis is done informally as executive project definition, my experience is that the executive performs the analysis independently in whatever manner he or she chooses and usually doesn't involve anyone else. It's common to engage outside consultants to perform formal standalone feasibility analyses, especially for large, complex and unfamiliar projects.
In other organizations, the project is created as a record-keeping entity, and then the feasibility analysis is performed as its first phase. If the analysis fails to show feasibility, that's the end of the project. When feasibility analysis is considered part of the project, it's more common for the project manager or a business analyst (but often not both) to perform it. Of course, either or both also could do standalone feasibility analyses, and consultants often are engaged to do the work even when it's considered the first phase of the project.
A significant part of feasibility analysis involves work that sounds like the province of business analysts. Yet the role of business analysts in feasibility analysis is enigmatic and inconsistent at best. My informal and limited sampling of business analysts indicates few have ever participated in a feasibility analysis.
When a business analyst is assigned to do a feasibility analysis, it's often before a project manager has been assigned to the project. Consequently the business analyst also has to be project manager for the feasibility analysis phase, which is essentially a sub-project. This can create problems because traditional views of the business analyst role, such as in the Business Analysis Body of Knowledge (BABOK), assume a separate project manager does project management.
In my experience, it's more common for the project manager to do the feasibility analysis, typically without assistance from business analysts. Similarly, problems can result because classical views of project management, such as the Project Management Body of Knowledge (PMBOK), explicitly exclude business analysis skills. (To address these paired problems, a colleague and I are currently in the process of writing a book and seminar to help project managers with business analysis and business analysts with project management.)
Requirements and feasibility
Feasibility analysis answers two main questions:
- Can this approach to the solution work?
- Is the approach worthwhile, that is, do its benefits exceed its costs?
Requirements are the basis for answering both these questions. A solution works because it satisfies the requirements. Satisfying the requirements provides measurable value (or benefits) by solving a problem, taking an opportunity, or meeting a challenge. A solution provides value if and only if it satisfies the requirements.
Therefore, defining requirements must be the starting point for feasibility analysis. But not just any requirements. In other stages of software projects, people get confused because they aren't aware of the need to discover the REAL business/user/customer/stakeholder requirements. Instead, they think that product/system/software/functional requirements are the requirements. With feasibility analysis, there should be no reason for confusion.
Feasibility analysis evaluates the ability of alternative approaches, not products, to economically meet requirements, which must be the REAL business requirements -- business deliverable whats that provide value when delivered by the approach's product how. For more information on the distinction between business and product requirements, see my article "How to avoid requirements creep."
There's a second difference about the requirements used for feasibility analysis. Because feasibility analysis is performed early with a relatively small amount of effort, it is based on high-level REAL business requirements. At first blush, this would seem to be what most requirements definitions do.
That is, many requirements definitions are only high-level, especially those characterized as "business requirements," which often are nothing more than a few sentences describing objectives or expected benefits. Such seemingly high-level requirements are actually a trap for several reasons. Most often they are high-level product requirements rather than high-level business requirements.
Objectives or expected benefits are not the requirements. Instead, they are what will be gained if the requirements are met. Moreover, objectives by themselves tell us nothing about what's causing our current results. Consequently, objectives do not provide a suitable basis for identifying solutions which reasonably will achieve the expected benefits by meeting the objectives.
Avoiding doomed software projects
Many projects are doomed to fail because they are initiated to solve the wrong problem. So the project is likely to fail to provide expected value. Even when the problem is defined appropriately, projects are often destined to fail because the project is defined in terms of implementing an inappropriate presumed product without first adequately discovering the REAL business requirements.
Human nature makes it easy to fall into these traps. When the individuals doing the feasibility analysis lack business analysis skills, as is usually the case with executives and project managers, they are unlikely to get the requirements right, but neither do many trained business analysts who follow conventional flawed requirements models. However, executives are especially prone to problems because they tend to rely almost entirely on their own subjective judgments, which are often based on limited and unreliable data, and seldom subjected to informed objective scrutiny.
Regardless of whether the feasibility analysis is performed consciously or unconsciously, formally or informally, the common failure to adequately define high-level REAL business requirements frequently initiates projects that are already doomed by the time a project manager or business analyst is assigned. Without a reliable definition of what must be delivered to provide value, not only will the project be unable to deliver expected value, but there's no meaningful basis for estimating what it will take to deliver a product that achieves the value. In the absence of compelling and accurate estimates, executives invariably set budgets and schedules impossibly low, making failure the only option.
Organizations can avoid dooming their projects by recognizing that feasibility analysis is occurring, making it explicit, and making sure it starts by adequately discovering high-level REAL business requirements that provide value when delivered.
About the author: Robin F. Goldsmith, JD, has been president of consultancy Go Pro Management Inc. since 1982. He works directly with and trains business and systems professionals in requirements analysis, quality and testing, software acquisition, project management and leadership, metrics, process improvement and ROI. Robin is the author of the Proactive Testing and REAL ROI methodologies and also the recent book, Discovering REAL Business Requirements for Software Project Success.
