Product Description 1.0.0

Scope

This document describes the output (either service or product) that fulfils the benefits sought in the Business Case. This is aimed to supply all necessary indications for producing the output within the limits (budget, time and scope/quality) fixed in the Project Brief / Business Case.

Quality

The product should be conceived as a system http://en.wikipedia.org/wiki/System. Each element, whatever the sort of relationship with the main entity has to be described in the terms that make possible a unique interpretation of the stated aims, including “Quality”.

This statement highlights some fundamental rules:

  1. The document will contain (as incipit) the clear and concise reference to the strategy to be adopted for obtaining the product within the set tolerances.
  2. The  “Acceptance Criteria” are an integral part of this document. All necessary reference to the set quality standards (as defined in the QMS) are included as links to the aforesaid document.
  3. Each action (planned or just executed) has to be framed (justified) within the boundaries set by the scope (i.e. the product’s features and whatever is needed for completing them within the parameters set by quality)
  4. For each element, the first property to be evaluated is its compatibility with the system. Therefore, any plan for treating the element will consider the necessary dependencies (e.g. available resources).
  5. If, for any reason, it impossible to have all properties definite with sufficient clarity (see above), these gaps will be highlighted. As soon as the agreement has been reached on these elements (and related properties), a check will be carried out in order to verify the alignment between the “new entries” and the existing elements. In case of any discrepancy, an issue will be risen and – if needed – a procedure for “Change Management” will start.
  6. For each property, the metrics to be used for evaluating it – from the QMS viewpoint – will be pointed in that document.
  7. Any source of information deemed relevant for a better comprehension of the element in its nature (e.g. derivation) will be included as a link and updated whenever it is necessary.
  8. Notwithstanding this is a “technical” document (no explicit references to costs or gains) each feature, and its implicit elements, is to be named with a unique identifier for allowing the necessary computations (e.g. used resources).

RACI (who does what)

Operation desc./Roles Spr PM SME BA Stkhd
Description of the Product (usually starting or including the Architectural Document) C A C R C
Assessing the feasibility of the proposed strategy C A C R C
Verifying that all necessary information is consisted with the rules set by the Project Brief (Business Case), QMS and all relevant standards (e.g. industry-related) C A C R C
Approving R C I C
Updating whenever the board authorizes it A R I I C

Document structure

Distribution list

This kind of information can be considered highly important. Therefore, it is suggested to inform all the interested stakeholders as described in the “Communication Management Strategy”.

Registrar section

These are the key fields

Product Description
Chosen Approach What is the suggested strategy for delivering the product?

  • · Bespoke or commercial product
  • · Based on COTS or designed from scratch
  • · Outsourced or in-house
System’s composition A brief description of the logic used for conceiving the product and how the main system will interact with the established environment (e.g. users and other systems).
Major functions The list of the required (and prioritized) features,
Appearance Any reference (draw) to the expected users’ interfaces
Performance levels Beside each of the “major function” should be present the properties and the metrics for gauging them. This will supplies information for all the Quality documents (e.g. QMS, Quality Register and plan)
Capacity and scalability The stated ability of the system to cope with the working conditions (e.g. band-with) of the environment where it will operate.
Customer’s Quality Expectations Any further detail useful for improving the Quality system with the aim of increasing the awareness of the product and then its acceptance by the customer. E.g.:

  1. availability,
  2. Reliability (mean/maximum time to repair, mean time between failures)
  3. Security and safety (e.g. data integrity)
Delivery date and schedule Set the expected delivery date and the highlight any relevant date that could influence the production  
Required users’ skills A brief description of any specific requirement for using the system (e.g. health and safety rules).
Required producers’ skills It could be a list of sought professional profile.
Major Risks (Gives a summary of the key risks associated with the production
Approved by Project Manager

Technical domains

1)     All relevant documents

Financial / Commercial domains

1)      Project Brief

Notes