Purpose

The word prototype comes from the Greek for “first impression,” which is an apt description of the purpose of a prototype. It is a model created for the first impression of how a final deliverable may look, feel, or function. A prototype affords a first look at a system or deliverable, so that it can be evaluated to determine if full-scale production or implementation is warranted. It can either be a first step in the implementation of a project, or in some organizations, it may be generated as a means to determine if the project approach will be deemed viable and appropriate.

Application

Although prototypes are most commonly associated with hardware and software implementations, they are actually used in virtually every industry. From galley proofs in publishing to concept cars in the auto industry, prototypes provide the project and customer organizations with an opportunity to examine some of the key features of the final deliverable without the expense and energy associated with larger-scale production.

Content

Although prototypes are varied in type and nature, they share the commonality of being a model or mockup of the final deliverable. However, because they are models, rather than the real thing, some of their qualities will differ from the final deliverable. In order to present a prototype to an outside party, the project organization should ensure that the description of the prototype includes certain elements:

1.  Nature of the prototype. What components, features, or elements of the real deliverable is the prototype supposed to emulate?

2.  Nonfunctional aspects of the prototype. What components, features, or elements  of  the  real  deliverable  will,  by  intent,  be  omitted  from  the prototype?

3.  Substitutions. What elements of the real deliverable are not incorporated in the prototype, but instead have been replaced with a substitution for the sake of prototype development?

4.  Intent of the prototype. What responses, inputs, and/or clarifications, are expected based on a review of the prototype?

5.  Iterations of the prototype. Will only one prototype be developed or is the prototype one in a series of “draft” models that will be delivered prior to final production?

6.  Acceptable levels of change based on the prototype. What should the reviewers be looking at/for? What are they allowed to change? Are there any aspects of the prototype that may not be changed?

Approaches

The depth of information expected from a prototype review may range from a yes/no approval to an in-depth analysis of how the prototype looks, feels, or performs. Thus, the expectations for the prototype review should be clearly established. The more thoroughly the intent of the prototype and the acceptable level of change are detailed, the more likely the reviewers are to provide the information sought by the developing organization.

Considerations

Prototypes are not the real thing. They do not function as the final deliverable, and there will always be some differences between a prototype and a final deliverable (even if they are simply differences in how they were produced). As such, reviewers need to be keenly aware of those differences, or they may cite those differences as “flaws” with the prototype. Prototypes also tend to be somewhat expensive, and reviewers also need to be aware of the limits to the number of iterative prototypes that will be developed before the deliverable goes into full, final production.