Honeymoon Hangover:
The Happy Beginnings of a Creeping Scope

Product Standards

Purposes

All too often misunderstandings, miscommunication, or disagreements about a product's features or capabilities do not surface until considerable effort and resources have been expended in its development. In fact, it’s not uncommon for misunderstandings about what a product should contain or do to be discovered only during the product’s post-development review. When this happens it can have a direct effect upon the project's available schedule and resources and produce ripple effects throughout the other areas of the project's performance.

There are approaches for mitigating the risk of this happening (such as design reviews and approvals, incremental delivery, or rapid prototyping), but these often only reduce the impact of such problems. The best way to avoid their occurrence is for the project manager to develop a rigorous and detailed specification of what he or she plans to deliver for each product. The client and the stakeholders can then review, react to, correct, and ultimately agree on these standards at the very beginning of the project before any effort has been spent in their design and development.

But all contracts contain a specification of the products to be developed, don't they? “Why”, you might ask, “would anything else be required?” For one thing, the fact that deliverables so commonly require revision is in part an indication that contract specifications can often be unclear, incomplete, or subject to misunderstanding by a project's team members and stakeholders. Some reasons for this are:

• Many specifications have elements that are open to interpretation, especially when they include terms like “timely ”, “thorough”, “integrated”, “innovative”, “rigorous”, or “detailed”. Terms like these are the Achilles heel of product specifications. While people may be able to easily agree about the definitions of such words, there can be big differences in what they think such terms mean in the context of a particular product.
• The requirements for product may be scattered in different places in the contract so that a contracted product's specifications in a data item description (DID) may not completely capture all of the stakeholder expectations for that product. And because the different contract sections and attachments may have different authors the possibility always exists that the product requirements reflected in different parts of the contract may not be totally consistent.
• A product's specifications may include references to external standards and documents (such as a handbook or a requirements analysis report). When they do it is sometimes unclear just what parts of the referenced document are being applied to the product or just how the requirements derived from that document are to be applied to the particular product. In addition, agency-wide, government-wide, and industry-wide standards often include specifications that are written at a high enough level of abstraction to allow their broad applicability. As a result, some interpretation is necessary to apply such specifications to a particular product.
• Not all stakeholders may have reviewed the winning contractor's proposal and so may not be aware of, or agree with, the contractor's interpretations regarding the products.
• Even after the project starts it may not be possible to completely specify the requirements for a product if they are based on the results of an early project task. For example the project's first phase may be a requirements analysis whose results will later guide the project’s design and development efforts. Until the early task is completed, some assumption of its results will be needed to guide the development of the a project baseline budget, schedule, and approach. Unless that assumption is explicitly stated and widely supported as reasonable, different expectations about the product may develop among stakeholders based on their varied expectations about the early results. We’ll go into this situation more in the “Project Assumptions” section that follows.

Using the project’s kickoff meeting to fully specify, and get agreement to, what will be produced and delivered for each product ensures that these sources of misunderstanding and miscommunication do not later cause rework, delays, replanning, and an inefficient use of project’s resources. In addition, having such clear and completely detailed acceptance criteria will allow products reviews to be faster and easier, reducing the burden on government reviewers with many other things to do. For a contractor, faster reviews and fewer revisions will allow on-schedule invoices and payment, which in turn reduce the project’s cash flow burden.

Developing Product Standards

The process for developing product standards is the same as that used for developing the project success criteria. In fact, developing the product standard is a direct extension of the project success criteria.

As with the project success criteria, the development begins with the PM (that is, you) building a preliminary set of standards for each product for later presentation at the kickoff meeting. In doing this you should make sure that all of the requirements—which may have been scattered throughout the RFP’s sections, attachments, and references and may have been further specified through assumptions and interpretations in the proposal—are incorporated into in the standards. Where there are some apparent inconsistencies or contradictions in the specifications, choose the most reasonable compromise and your rationale for choosing it. Both of these will be discussed at the kickoff meeting.

The more detailed the product standards are, the lower will be the risk of later rework and delays. In general, they should include specifications in the following areas:

• Technical – the contents, functionality, or results of the product or service. If the deliverable is a report these specification could include the anticipated contents (shown perhaps in a high-level outline), the format or publication standard that will be used. If it is a system component, the specification could list or reference the specifications of the required functionality along with exhibits displaying how each associated government or industry standard will be implemented in the product. If it is a service, the specification would include the staff qualifications, the conditions under which the service will be supplied (e.g., hours of operation, location, government-provided information, equipment, or logistic support), and the required performance standards (e.g., response time for service calls, number of classes given per week).
• Delivery – the method and media used for delivery, the quantities delivered, the location (physical, Web, or e-mail) where it will be delivered.
• Distribution – Who will receive the deliverable and how will delivery be confirmed.

The window opened by this link «Sample Product Standards Table» shows one possible format for presenting the material. Note that many of the detailed specifications are included in attachments that would be provided as handouts before or during the meeting.

Developing the draft standards in preparation for the kickoff meeting can require a substantial effort for a project that has more than a few products. They can therefore be challenging to fully develop if the kickoff meeting is held very soon after the project has begun. Fortunately, most of the effort to define what will be required for each product will have been already done during your proposal preparation as part of developing the basis of estimate underlying your cost estimate. Retaining your notes and records from the cost estimation will therefore be very helpful to this effort, as well as to other aspects of the project’s management (e.g., developing best practices and lessons learned as part of the project’s close-out).

If there are a substantial number of project products the draft standards can be provided as part of a read-ahead package to allow the kickoff meeting attendees to become familiar with the standards and arrive at the meeting prepared to discuss them. During the meeting attendees will review the draft standards with the objective of making any revisions needed to produce a final set with which all agree. The final version of the standards are then incorporated into the Project Management Plan where they will guide the development, submission, review, and acceptance of the products and services provided through the project.