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:
Let's discuss each of these in detail:
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.
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.