When the Requirements Process Goes Wrong

Many things can go wrong in a project's business modeling and requirements activities. Fortunately, in most cases, these problems can be fixed if they are caught in time. Unfortunately, some situations are not easily recoverable. I have seen such situations occur on multiple projects. What makes these situations especially dangerous are that they are motivated by seemingly reasonable or understandable circumstances, but bewarethey can derail a project.

This section describes situations in which you should exercise extra caution.

They Tell You That the Requirements Analysis Is Already Finished

I have seen many Requests for Proposals (RFPs) explaining that the requirements have already been collected and analyzed. This situation seems to occur frequently. The RFP then proceeds to request a quote for the cost of implementing the requirements that have already been collected. Understanding why the requirements analysis is said to be complete is vital to determining the proper response. Possible motivations are as follows:

• This may be an attempt to save money by eliminating the process of the contractor meeting with the stakeholders and eliciting a complete set of requirements.

• It may be an attempt to save time by directing the contractor to begin implementation immediately, before the requirements are fully collected or understood. Perhaps the system is urgently needed and time is at a premium.

• In an outsourcing situation where the contractor is separated by great distance from the outsourcing organization, it is an attempt to save time and money by avoiding the need to gather the stakeholders and contractors in the same place.

• A previous contractor performed the business modeling and requirements analysis, and your organization is being considered for the follow-on implementation.

Let's discuss each of these in detail:

• If this appears to be an attempt to conserve funds by the outsourcing organization, before bidding or committing to a project with this stipulation, ask to examine the requirement artifacts. Few organizations with little or no software development expertise can perform a thorough job of business modeling and requirements elicitation. If they are willing to share these artifacts with you, examine them for quality. Are they complete? Are the requirements testable? Do they truly represent the needs of the end users? Can the developers obtain a clear picture of what they must accomplish to satisfy the outsourcing organization? Is the system's scope clearly delineated? If this examination yields less-than-positive results, the outsourcing organization may be willing to work with you to strengthen these artifacts before submitting a bid to develop the system. Even if the artifacts appear to be in excellent shape, remember that the contractor staff will require time to examine the artifacts fully and ask questions of the stakeholders to clarify their understanding. If the outsourcing organization cites concerns over giving your organization a competitive advantage by showing you the artifacts, suggest that they make these artifacts available to all potential bidders. At any rate, avoid bidding for the development for such a project until you have had an opportunity to review the requirements artifacts and discover their quality.

• If this is an attempt by the outsourcing organization to save time, be extra careful. I am amazed that this situation continues to occur, given the plethora of literature and experts available showing that this is perhaps the worst way to save time fielding a system. If shortening the time to fielding a system is truly the motivation (perhaps it is an emergency situation), consider these alternatives:

  • Suggest to the outsourcing organization that a prototype be developed and fielded. If this is acceptable to the outsourcing organization, emphasize that this is an evolutionary, intermediate step toward building the real system. Its primary purpose is to get something in the field as quickly as possible, so it will not be a polished solution. It will also help with understanding user needs for the subsequent version of the system to be developed. This can be a risky solution, so it is best reserved for true emergencies.

  • A better solution is to leverage the advantages of iterative development. After some initial discussion of requirements relating to the selection of a proper architecture, a framework can be developed that allows the contractor to focus on the most urgently needed functionality first. These early versions would not have all the features needed by the stakeholders, but they would have enough functionality to enable the users to perform their work.

    I know of no way to eliminate meeting with the stakeholders to discover their true needs. This takes time. The suggestions given here are only ways to move forward when the situation is inflexible.

  • Sometimes, the contractor and the outsourcing organization are separated by great distance. This is generally true when projects are outsourced overseas. The outsourcing organization attempts to mitigate the additional cost and time by reducing the need for the contractor representatives to meet with the stakeholders. Review the first response in this list. Examine the artifacts thoroughly, and set up some sort of process for getting questions answered as needed. In general, I recommend not outsourcing projects that require extensive business modeling and requirements elicitation by distant contractors unless the inherent delays and costs associated with travel are acceptable.

  • If a previous contractor performed the business modeling and most of the requirements elicitation, find out if that contractor is being invited to bid on the follow-on implementation as well. If not, is this because the outsourcing organization was dissatisfied with that contractor's performance? In that case, perhaps it did a poor job with the business modeling and requirement elicitation. Make this determination by following the suggestions in the first response in this list. If the previous contractor is being invited to bid, this is probably a good sign, unless it is "lip service" by letting that contractor bid even though it has no chance of winning the follow-on bid. Unless you have contacts at the outsourcing organization, you may not be able to easily determine if this is indeed the situation. If the previous contractor is in good standing with the outsourcing organization, it is prudent to examine the requirements artifacts you will need to work with. If everything appears to be in order, you may be up against formidable competition for winning this bid. In addition to understanding the existing artifacts, the incumbent contractor has already established a relationship with the outsourcing organization and may have additional insider information that lets it make its bid more competitive.

Insufficient Use Cases

I was hired by a contractor to manage a project that had recently been won. The outsourcing organization said that the requirements elicitation was finished, with a complete set of system use cases developed. After the project kick-off meeting, we rolled up our sleeves and began working. It was immediately clear that the use cases were in terrible shape. They lacked detail. In some cases, the use cases were nothing more than a template with the name of the use case replaced and none of the sections filled in. I raised this issue with the project manager of the outsourcing organization, indicating that the use cases were of insufficient quality to begin development. The response was very reasonable. We were directed to do what was necessary to "clean up" the use cases and make them proper and to validate the existing requirements with the stakeholders. This is when the trouble began. Our first discovery was that few stakeholders had been consulted in the development of these use cases. It was simply one user's view of how the system should work. Second, there was disagreement over some of the business processes among the stakeholders. After expending much effort and time correcting these deficiencies, we began to realize that the system's scope went far beyond our ability to deliver under the terms of our original contract. We eventually worked through most of these issues, but not without considerable angst and gnashing of teeth on both sides.

The bottom line is that if the outsourcing organization claims that the business modeling and requirements elicitation and associated analysis are complete, insist on seeing this information to prepare a proper bid. Explain that your interest in seeing these artifacts is to better understand the problem so that you may prepare the best bid possible. If the outsourcing organization refuses, don't bid. In other disciplines, this situation is unthinkable. Imagine a civil engineer being asked to bid on construction of a building without knowing any of the requirements. A bid produced under those circumstances would not be considered valid.

Lack of Agreement on the Business Process in the Outsourcing Organization

This problem is very difficult to overcome. If there is disagreement on the business process, there is no way a system can be built to satisfy all the stakeholders. This is a sign of a dysfunctional organization. Any system use cases that are developed under these circumstances are likely to be unacceptable to some of the stakeholders. Forging ahead with developing a system in such a situation may lead to considerable angst during the customer acceptance test, when the disagreements will rise to the surface again. Note that some disagreement is normal, perhaps even healthy. But it should be overcome after some discussion. If meetings to discuss business process frequently degrade into chaos, it is time to call a halt to the meetings to determine the underlying cause. Meet with the management of the outsourcing organization and the key stakeholders in question. If no constructive outcome can be determined, it may be wise to pull the plug on such a project until the organization gets a handle on its business process.

A variation on this problem happens when you discover upon meeting with the stakeholders that no one has ever discussed or documented the business process in the stakeholders' organization. Remember that it is possible to succeed in this environment, but ironing out the kinks will take longer than the normal business modeling effort. I consider this effort beyond the scope of most contractors. Your organization may not have the expertise in the company's business to lead it through this effort. Proceed in such situations very carefully.

Avoiding Unbounded Growth in Requirements, or Requirements "Churn"

In the traditional Waterfall lifecycle process, requirements are "frozen" at some point, where design begins, followed by implementation. Iterative processes such as the RUP assume that it is impractical to "freeze" requirements at any point in time. Instead, requirements are discovered through a process of learning, and as these new requirements are discovered, they are prioritized with the other remaining requirements. However, the discovery of new or changed requirements should taper off and trend downward as Elaboration nears completion. I prefer to be able to confidently state by the end of the Elaboration phase that all requirements affecting the architecture have been discovered by that point (with the architecturally significant ones implemented), plus 80% of the end user functionality. In other words, all the complex, risky-to-implement requirements have been discovered by that point.

The reality of contracts (finite time and resources, funding, and so on) catches up to you at some point. The wise contractor monitors requirements growth closely and gives the outsourcing organization advance warning when the number of requirements to be implemented is reaching a point where they cannot all be completed within the existing contractual framework. In other words, the contractor has to start saying no to the outsourcing organization, or it risks failing to complete the project on time and within budget.

It is possible to offer an alternative to the outsourcing organization. This assumes that the contractor has been wisely tracking the priority of each requirement as it has been elicited. Instead of giving a flat-out no answer to a request for a new requirement, offer the notion of eliminating or deferring an existing low-priority requirement to accommodate the request for the new requirement. In this way, the set of yet-to-be-implemented requirements remains stable, and you avoid having to say no to your customer.

It is also wise to counsel contractor analysts not to make commitments to stakeholders during requirements meetings. Instead, advise them to carefully note each request, along with the contact information of the person requesting it, and the level of importance (priority) to the requestor. The contractor can review the requests during its internal planning sessions, determining whether each request is within scope. Usually, especially in the early stages of requirements elicitation, most requests are within scope. When you encounter requests that may be out of scope, you can review them with the project manager and lead user representative of the outsourcing organization. The key in this process is to avoid making a commitment directly to the end user organization that later has to be retracted due to issues of scope or funding. Failure to avoid this can mean that the stakeholder meetings become less productive as the stakeholders lose confidence in the process and the contractor.

Saying No to End users

One weakness some contractors seem to have is a reluctance to tell a customer no. Many otherwise good projects can spiral out of control due to this weakness, where the contractor commits beyond what can be reasonably accomplished within the time and budget given. When this happens, projects get behind schedule and go over budget, and stakeholders lose confidence. To avoid this problem, instruct the contractor not to make commitments directly to the end users. Instead, management from both organizations should review requests for requirements together and make decisions jointly. For requirements determined to be out of scope or beyond the ability to be met within the time and budget, you need to manage this within your organization, particularly the lead user representatives. Emphasize to the users that although all requests are important, some have to be postponed or deferred to protect the ability to get the existing requirements implemented and make them available on time. Avoid putting the contractor in a position where it has to manage the end users' expectations by itself. Some organizations perform this function as part of a Change Control Board (CCB).

Multiple Contractors and "Forgotten" Stakeholders

So far, this chapter has used the term "stakeholder" almost interchangeably with "end user." It is important to note that although all end users are stakeholders, not all stakeholders are end users. Early in this chapter, it was noted that some projects involve interfacing to other systems, either legacy systems or newly developed systems. If your system to be developed falls into this category, consider the nature of the interface between the systems. Will an application programming interface (API) need to be built? If so, who will build it? Do the existing contractual mechanisms permit allocation of resources to solve the issues? If the application to be interfaced is a legacy application, are the original developers of that system still available? If not, does your group have the expertise to develop the API needed? Do you have access to source code and documentation for the legacy system? These questions need to be addressed early in the project, or they risk becoming expensive showstoppers later.

Another "forgotten" stakeholder is the IT department of the outsourcing organization. Does your customer's IT department have any initiatives under way that affect how your project should be implemented? A common example is the increasing use of Service-Oriented Architectures (SOAs).

One function of an SOA is to provide "services" in the form of software that can be referenced or "called" from multiple applications. The value is that tasks common to many systems can be designed, implemented, and tested once and then reused across all newly implemented systems. An example of an SOA service might be a login service that implements the organization's business rules for login security. Other examples might involve logging transactions, searching, and auditing.

Finally, the organization may have standards for user interface design. This is common with companies that outsource many of their systems. Without these standards, every system's user interface might have an entirely different look and feel.

During the project's Inception phase, part of the requirements elicitation activity should be to seek out and identify these types of requirements. Obtain the documentation for the application interface if appropriate. Incorporate the organization's user interface standards into your requirements repository for the project.