| After the foundation has been laid, the project manager, assisted by key task leaders, is ready to write a draft project specification. This specification defines the project outcomes. (It does not deal with how the team will achieve these outcomes.) Note: The project outcomes must be measurable. Developing a software package for materials and manufacturing management, for example, would involve a broad range of required outputs that must be clearly specified so that the performance of the completed package can be demonstrated. Such packages, however, can typically perform thousands of complex processes, with hundreds of particular outcomes, so testing all the processes cannot be done. Therefore, the specification must include the details of a Beta test. A Beta test is a performance demonstration of the project's product at the customer's facility, using the customer's staff. The customer and the project manager collaborate to develop the test's details. They also agree that if the package passes the Beta test, it reasonably can be expected to perform all the functions set forth in the specification. For example, a jet aircraft engine is expected to perform over a broad range of flight speed and altitude conditions. In the experimental development of military jet engines, several representative performance points were identified for demonstration in a test call. If the engine met these performance points, it could be expected to reach the full range required of it. The engine developer and the customer collaborated to determine these points and the measure of successful achievement. Note that ambiguities or vague generalizations are forbidden in a project specification! When this is ignored, a product that is not what the customer wanted can result. Obtaining a good specification is the project manager's responsibility. If the project's sponsor is unwilling to help with details, the project manager must go it alone, redoing the project specification until it meets the customer's approval. (The project change committee and the change procedures provide the mechanism for adjusting the specification later if the customer asks for this. The change process is discussed in Chapter 13.) Producing a good project specification is the very first step in executing a project. The project manager and sponsor(s) begin by creating the draft specification, which is reviewed by all interested parties. Everyone must be comfortable with the specification, and consider it a document that could provide directions a team would readily understand for executing the project. The specification also must identify specific ways of measuring project deliverables so that a knowledgeable third party examining the deliverables could easily determine that the specification had been met. This requires holding a specification review meeting. The group of reviewers must include members of the customer's organization who will be primary users of project deliverables, representatives of the proposed project team who have key roles in producing the deliverables, third parties with similar project experience, writers who will produce user guides and service manuals, and key suppliers who need to understand the project goal(s). The specification must be distributed to attendees beforehand. At the meeting, it may be displayed on flip charts or overhead slides, clearly written in large print. It also can be displayed as the product of computer word processing through a computer-driven projector. (Some specifications will require many pages.) A specification can be written on a software word processing package. As overhead projectors scroll page-by-page, the project manager should read the specification, pausing for discussion and/or questions. A team member must take notes; using a tape recorder also is reasonable. Modifications can be made on the computer keyboard during the presentation, if necessary. After the meeting, the specification will have to be rewritten. Often this rewrite will involve minor adjustments. It can be distributed to meeting attendees for review and comments before it is finalized. If major revisions are necessary, a second meeting also is necessary. Everyone must understand that this specification will guide the planning process without any adjustments, unless and until a project outcome change is processed (see Chapter 13). If changes are required, the specification will be rewritten and reviewed before adjustments are made. This process must not be long and drawn out. However, some projects, like Information Systems projects, have much detail in the specification and require a series of meetings. Getting such a specification correct may take time. | 
