The Role of the Product Development Specification for Short Duration Projects
The project life cycle is being challenged for the shortest possible schedule in all facets of business today. Products that used to take months to go to production are now needed to go from concept to a limited production prototype in days or weeks, rather than months. Many programs that are critical to the project pipeline are of shorter nature and follow a product derivative type of structure. A powerful document that has been used in the past but, is often overlooked for short fast-paced projects will be reintroduced to you in this article from a different perspective.
Often overlooked for short duration projects, the Product Development Specification is a powerful document that can be prepared very quickly and provides a great organizational starting point for the project. This article re-introduces this important document from a different perspective and examines the important sections it should contain. The Product Development Specification, if used properly, can turn a faced paced high stress program into a successful well-documented result for your project. The use of this document will result in the project being documented in a controlled, efficient manner and will serve as a foundation for other programs in your firm.
Bringing products to market faster than the competition is critical to successful business today. Program Management tools, if carefully selected, can play an important role in properly defining the program and keeping the project on scope throughout the course of product development. The project life cycle is being challenged for the shortest possible schedule in all facets of business today. Products that used to take months to go to production are now needed to go from concept to a limited production prototype in days or weeks, rather than months.
Documentation for a project can commonly take as much resource as the execution work packages of the project itself. Many programs that are critical to the project pipeline are of shorter nature and follow a product derivative type of structure. Businesses rely on these shorter projects to keep revenue flowing while projects of longer duration are dealt with from a different program management approach.
A powerful document that has been used in the past but, is often overlooked for short fast-paced projects will be reintroduced to you in this article from a different perspective. Often overlooked for short duration projects, the Product Development Specification is a powerful document that can be prepared very quickly and provides a great organizational starting point for the project. In this article, I will re-introduce this important document from a different perspective and will examine the important sections it should contain. This article can serve as a guide to help the Program Management group in your firm, focus on the correct issues concerning the documents proper use.
The Product Development Specification, if used properly, can turn a fast-paced high stress program into a successful well-documented result for your project. The proper use of this document will result in the project being documented in a controlled, efficient manner and will serve as a foundation for other programs in your firm.
Keeping on Scope throughout the project:
The most important item to the success of a project is keeping the Scope of the program on track. The scope represents the fundamental direction to a satisfactory outcome and helps ensure a delighted customer. When Scope is poorly defined and the project shifts to customer needs that were not part of the original plan, the program management triad parameters of cost and time start to suffer and lack control. When the Scope is focused only on the needs of the provider, the customer usually suffers or may become unhappy with the program. When time and resources are limited in an organization and when projects are small, keeping the scope on track is even more difficult but, essential. Small projects are usually done quickly or often off the side of the desk, and can be left untouched for days or weeks.
Delays by either party can result, because of resource, funding problems or lack of attention. This shuffling of attention to the project, can lead to misunderstandings and forgotten details that can make or break the project. The key to success is a method for fast accurate documentation. For these situations, I would like to recommend the use of an important tool called the “Product Development Specification”.
This short, but comprehensive document serves as a living document and serves as the voice of the customer. It serves to translate the customer’s needs into scope documentation for the project, from the project teams point of view. This document can become the negotiation between the project team and the customer to make sure both sides are going to be on the same page throughout the execution of the project. In fact, this document is usually signed by both parties prior to design freeze and can serve as a interim contract to ensure detailed and complete communication was generated during product development. A document of this type can ensure both parties are working to a common goal and can keep the project from suffering severe scope creep. Many projects are done with numerous aspects undocumented. Although we like to think our memories are very good, most often relying on memory results in unclear expectations, confusion, and a disappointed customer. The lack of good documentation can have legal consequences as well.
The Product Development Specification should include important sections such as:
1) A section addressing the Scope of the project, defining the purpose of the project, delivery expectations and the intended final application for which the product is being designed.
2) A detailed description of the product or service including operational descriptions, important required features and Performance Requirements, including a list of all identifiable critical characteristics.
3) A section pertaining to details about installation and product aesthetics.
4) Agency requirements and or special approvals or contracts that may be involved or necessary on or before delivery.
5) Try to include Manufacturing details, if pertinent, which may focus on manufacturing rates, special manufacturing needs and costs of certain critical processes.
6) Be sure to address Quality and Safety Targets for the product and manufacturing process.
7) Consider shipping and handling of the final product. If the product is service oriented, try to document how the service will be provided, the format for delivery and who will be responsible for delivering it.
8) Finally, a section on Reliability and /or Final Testing Requirements, the customer will agree to, for Acceptance of the product of the project.
The section on Scope is used to define the project so that expectations between the customer and provider of service will be concise and clear. Scope statements generally involve details such as defining the boundaries of the project and a good detailed description of the product of the project.
The golden rule is to define things from a delivered product point of view, detailing exactly what the customer needs and no more. From this documentation a reasonable understanding of the work necessary to finish the project will be easy to generate. It is often helpful to include a paragraph on the reason the project is being done. This view of the project will satisfy the project team that a useful result will be the ultimate goal of the project and will help to reaffirm purpose when the team strays away from a clear objective.
This short section must be done from the customer point of view and should be continually tested and reaffirmed with the customer during the course of the project. Timeframe for the project should also be addressed. Try to determine a negotiated delivery time for the product and document it. A customer rarely knows the development issues a manufacturer faces and discussing those constraints and assumptions with them, will add to understanding about realistic program milestones and product delivery.
A clear expectation must be established between the customer and the project team for what work will be done, when it is expected and by what responsible person. If the project warrants the additional effort, a short work breakdown structure considering the major delivery elements could be added to this section. Definition of each of the work package items can be detailed over the course of the project as progressive elaboration. The success of the project depends on how well the team understands the expectation from the customer.
Product Description and Critical Characteristics:
The second section of the Product Development Specification should focus on a detailed description of the product. The product must be defined from an engineering point of view detailing major elements of construction, specific operational or performance characteristics, and how the operational aspects of the product will be achieved. The simplest form of documentation of customer requirements is to ask the customer for a written specification.
The project team can then go through the specification identifying ways in which the designed product will attempt to meet those customer needs. In generating this information, the team must think in terms of translating the customer needs into functional product design characteristics. This is a hard concept for many team members to grasp. A helpful way to go about this is to list the customer’s requirements and then identify the specific functional product characteristics that enable the product to meet those requirements.
This approach is a fundamental approach to documentation of product characteristics similar to the QFD process. Another way to think of this is to identify controlling characteristics of the product that if controlled to a given specification, then the product would meet the customer’s needs for that particular product requirement.
The project team must think in terms of Critical Characteristics. A strong focus between the customer and the provider on critical items can eliminate embarrassing misconceptions and forgotten details at time of product acceptance. The critical characteristics should also be considered for the type of quality control necessary to meet the specifications. Often, the customer will demand unrealistic controls on certain specifications because of bad experiences in the past. It is important for the project team to document the specification but more importantly capture the voice of the customer in terms of control, thereby avoiding embarrassing unrealistic expectations passed down to the Quality Team at product launch.
|< Prev||Next >|