Identifying Project Requirements

Generally, identifying project requirements is not difficult; it just needs careful scrutiny of the statement of work and/or other project documents, such as the contract, specifications, and any correspondence leading up to project initiation. That is not to say that it's a small task. The larger the project, the larger, usually, is this task of identifying the requirements. Still, the task is not difficult if there is a disciplined process in place.

The Requirements Identification Process

Defense industry companies generally have well-defined requirements identification processes because their survival is directly dependent on their ability to successfully bid on and win contracts. Other companies, public or private, that depend on bidding for business also know how to identify and interpret customer requirements. However, most companies and organizations typically have a very difficult time identifying their customers' requirements and often don't even realize the need for it. The following process should help you if your organization doesn't have one in place.

Every company may approach requirements identification in a slightly different way, but the basic process is essentially the same regardless of the industry and regardless of whether the customer is internal or external. The four steps in this process are:

  1. Determine whether the project is one that should be pursued.

  2. Look for special conditions placed by the customer.

  3. Capture all the requirements in every document pertaining to the project.

  4. Develop a matrix that cross-references each requirement to where it is found and where it is addressed by the project plan.

Although I have listed only four steps in this process, each of the steps has multiple substeps. These steps are addressed in detail in the next several sections.

Determining Whether to Pursue a Project

Many companies assign people or even a department to be responsible for determining whether a project, internal or external, is one that should be pursued. This would seem to be an obvious thing to do, but the fact is, there are just as many companies that do not have any kind of a formal review process, and, therefore, find themselves in the middle of a project that should never have been started.

Bid or project review generally is accomplished by an ad hoc committee constituted specifically for the purpose. This committee sits in review as the need arises. Exhibit 4-3 presents a checklist for considering whether to bid on an external solicitation. It should be obvious that the checklist is equally applicable, with minor alteration, for determining the viability of pursuing a project that develops within the organization.

Exhibit 4-3: A checklist for making a bid/no-bid decision.

start example


  1. Is the project consistent with our core business?


  1. Will the project meet or further our corporate goals?


  1. What experience gaps do we have in the organization?


  1. What technical gaps do we have in the organization?


  1. What personnel gaps do we have in the organization?


  1. What do we know about the customer/stakeholders?


  1. What does the customer know about us?


  1. Would a team member (another organization or company) improve our chances of winning the contract (successfully completing the project) by enhancing our internal capability or improving our credibility with the customer?


  1. Should our company be the prime contractor or a subcontractor?


  1. Who is our competition?


  1. What are the competition's strengths and weaknesses?


  1. Do we have the resources to meet this project's requirements?


  1. What is the probability of winning the contract or starting the project?


  1. What is the probability of successfully completing the project?


  1. What is the start-up cost of this project (writing the proposal and gearing up to initiate the project)?

end example

The first two questions in the checklist deal with examining the solicitation or project in light of the company's core business and whether the project will improve the company's market share or meet other corporate goals. Many companies chase contracts or projects that appear achievable or that are offered by customers that they think they know, believing that these factors provide enough advantage. They discover too late that they do not have the requisite expertise and experience—it is not a part of their core business. Even if an upcoming project is within the core business, it does not mean that the project would further the company's goals. If, for example, the company is targeting projects with opportunities to enhance its technical capability, then the project should be under the core business umbrella but with elements that enhance its expertise.

Questions three, four, and five in Exhibit 4-3 focus attention on the current internal capability to perform the project. Before embarking on a bid for any contract, or before pursuing any project, it is necessary to understand if there are any existing gaps in the company's capability to perform. If so, then alternatives need to be developed to allow the company to pursue the project (i.e., if the responses to questions one and two are positive).

Questions six and seven are more difficult to quantify than the previous five questions because they deal with perceptions. A company can be confident that its marketing department has made all possible efforts to get to know a customer and vice versa. However, whether the customer really knows or likes the company remains questionable unless they share previous contracting experience. If the company has not done work for that customer before, then the question becomes, "Do we have time to educate the customer about us?" Often the answer to that question is no, unless it is known that the project will not be initiated for a least a year; less if the customer is internal to the organization.

Otherwise, questions eight and nine of the checklist become very important. Note that these two questions, which deal with the possibility of teaming with one or more companies, support questions three, four, and five as well. In other words, if there are technical, experiential, or personnel gaps within the company, the chances of a contract win, or a successful project, improve by teaming with companies or organizations that can fill those gaps. Likewise, teaming with a company that has a long, positive history with a customer is one of the best and quickest ways to become known to the customer.

Questions ten and eleven deal with a competitive analysis. All the likely bidders should be known, along with their relationship to and experience with the customer. If the competitive analysis reveals that your company is likely to be the highest bidder, all the other questions in Exhibit 4-3 become moot. Finally, if all the other questions can be answered in a positive way and the cost of initiating the project is within company guidelines, then the project should be pursued. Otherwise, the project should be avoided regardless of how attractive it appears on the surface.

Once it is decided a project will be pursued, then the serious work of identifying the requirement details begins.

Special Customer Conditions

Almost all projects have specific conditions that have to be met in addition to the usual project/product requirements. These conditions are easily identified because the customer will draw attention to them even when he is lax in their description of the project's general requirements. The most common special conditions, some of which are actually constraints, are:

  • Scheduling conditions

  • Reporting cycles and types of information expected

  • Budget conditions

  • Environmental standards

  • Developmental and quality standards

  • Exclusions from participating in follow-on contracts

It is not uncommon for the project completion date to be dictated, and that is understandable since the project is in place to address a need, and usually that need has to be met by or before a specific date. For instance, in information technology and other highly competitive industries, there almost always is a window of opportunity for the product to be on the market. If the window of opportunity is missed, then the value of the project is zero or at least greatly diminished.

Many customers, in particular those in the federal sector, dictate the number and types of reports, reviews, inspections, and meetings that they expect. In addition, they also will specify the kind and depth of information to be presented and the frequency of these events. In the private sector, such requirements exist, but usually they are less stringent and often are left to the provider to determine.

The budget for a project also can be a limiting factor, particularly if the customer has not performed a good estimate of the cost to perform the project. Frequently, many projects begin with inadequate funding.

Standards of all types are usually a part of any formal solicitation. Even internal customers provide guidance about how the product will be assessed. In addition, many industries have standards that are imposed on them by regulating agencies, developmental practices, and financial institutions. All the pertinent standards are listed in a formal solicitation, and they should be identified and listed for an internal project as well.

Occasionally there are specific instructions to the provider that if the project is undertaken, then the company will be barred from performing any follow-on projects that evolve from the given project. An example of such an occurrence would be a project that is done to determine the requirements and specifications for another project. A company that develops these requirements and specifications would have a decided advantage over any other company if the customer issued a solicitation for the follow-on work. Hence, the customer will usually bar the original provider from bidding so that the competition is fair. This, however, is not something that happens very often in the private sector and especially not in the information technology industry.

The special conditions or requirements are, as I stated previously, generally not difficult to spot because they tend to jump out at you, and they are usually highlighted by the customer. In fact, it is common, if there is formal project documentation, for the customer to include a paragraph with the heading for special conditions. But ferreting out all the other requirements can be a challenge unless you follow some simple guidelines.

Capturing All the Project Requirements

If identifying requirements is difficult, it is because one must read every line of every document that is provided about the project. The good news is that 99 percent of the requirements are contained in the SOW. The problem is that some projects, because of their complexity or the sheer size of the effort, have other documents such as specifications, the contract, engineering drawings, and other explanatory material associated with the solicitation. There are two key things to remember if you are involved in such a project. First, the SOW is the governing document. Any other document is subservient. So if there is, say, a specification attached to the SOW, and the specification describes the product's size or function differently than the SOW, contractually the SOW is the guiding document. Of course, the wise project manager will clarify the discrepancy; however, don't make the mistake of thinking that the specification, because it is a more detailed description of the product, is the correct version. Second, although the SOW is the primary or guiding document when resolving discrepancies, it is not the only document containing requirements. The requirements search must be carried throughout all existing project documentation.

Formal Solicitations

In a formal solicitation, the requirements search is actually simplified because all requirements are introduced with a "shall" clause. That is, the SOW or other documents state that "The provider shall build . . ." or "The product shall be capable of . . ." So identifying requirements begins by finding and listing all such statements. Incidentally, if the customer intends to provide equipment, data, special tools, or anything else to support the project, she identifies these items by introducing them with a "will" clause in such formal solicitations. For example, "The buyer will provide to the contractor data to support . . ." or "The buyer will provide computers for . . ." So it is equally important to identify what the customer brings to the project because that affects how the project is planned and how the schedule and costs are estimated.

Internal or Informal Projects

It is far more difficult to determine project requirements for those projects that are internal to the organization than it is for formal solicitations because, typically, there is little or no documentation to describe the product. Early in this chapter, I pointed out that every project should have a SOW describing precisely what is to be accomplished in the effort. But the general feeling among many organizations is that if a project is internal, there is no need for a formal SOW. Perhaps there is no need for a SOW as formal as is found in a solicitation, but at the minimum there needs to be a scope statement describing the product, the customer's requirements, special items such as schedule and budget, and the criteria for project completion.

Once all the requirements are identified and listed, then the most important step in the process occurs—creating a cross-referencing matrix.

Cross-Referencing Requirements Matrix

The cross-referencing requirements matrix is a useful tool for mapping the requirements against where they are found—that is, in the SOW, specifications, drawings, and so on—and against where they are addressed in the work breakdown structure. Exhibit 4-4 is a sample requirements matrix that demonstrates how this tool is developed. Please note that it is only a partial matrix of a fictitious project. A complete matrix can be several pages long.

Exhibit 4-4: A sample requirements matrix.

start example






Provide a distributed IT infrastructure for the ATLAS project

Para 1, Scope Definition


2.3.2 Dist. IT Infrastructure

Develop a grid communication system to support the ATLAS

Para 6.b, Section C

Plate 3 Design & model grid architecture

Integrate all the ATLAS software services

Para 3 c, Section E Integrate grid software services

Develop a data management system

Para 14 & 15, Section G

Plate 6, 7

2.3.3 Grid data management

Integrate database tools to management of ultralarge databases

Para 4 g.2 Section B Integrate database tools

Develop, integrate, and test tools and middle-ware infrastructure to support and manage Petabyte-scale information volumes

Para 13 & 25 Build middle-ware infrastructure

end example

This matrix serves several useful purposes for the project manager. First, it serves as a worksheet for identifying the requirements. Just having the form in front of you helps you focus on the task of identifying all the requirements, and, in this capacity, it is a constant reminder that requirements exist in all relevant project documents. Second, many of the same requirements will be addressed in different documents. Hence, the cross-referencing action allows the project team not only to determine which documents discuss the same requirement but whether the description in each is the same. If not, then the customer needs to be notified and asked for clarification. Nevertheless, remember that until or unless the inconsistency is clarified, the statement of work is the guiding document. Third, the cross-referencing document provides a way of ensuring that each requirement is addressed in the WBS. If it is not in the WBS, then it is not in the project.

Identifying requirements should not be drudgery. It is not difficult, but it does require attention to detail, and it requires that every document initiating the project be thoroughly reviewed. Unless all the requirements are identified before the planning begins, then the project can suffer delays, additional costs, and even failure.

Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: