Project product description

The project product description is typically a concise, 1–3 page document that defines the main output of the project — the final product that must be delivered to achieve project success. Its structure is aligned with both the quality and plans themes in PRINCE2. It is created during the starting up a project process and refined during the initiation stage.

Purpose

The project manager develops the project product description by consulting the senior user(s) and relevant subject matter experts to ensure the product is both desired and feasible. The project product description is used to:

• Gain agreement on the project’s scope — what the user expects the project to deliver.
• Define the customer’s quality expectations, ensuring the final product is fit for purpose.
• Specify the acceptance criteria, acceptance method, and responsibilities for verifying that the product meets expectations.

Timeline

The project product description (PPD) is used throughout the project lifecycle to define, refine, and verify the project’s final product.

• The PPD is first created during the starting up a project process and is included in the project brief.
• It is then refined during the initiating a project process, particularly when developing the project plan, and continues to guide delivery during the project.
• At each stage boundary (via the managing a stage boundary), the PPD should be reviewed and updated if there have been changes to scope or quality expectations.
• During the closing a project process, the PPD is used to verify whether the project has delivered the agreed final product and that the acceptance criteria have been met.

Source data

The project product description is developed early in the project and is based on input from key stakeholders and business needs.

• Facilitated discussions or workshops with the senior user, to understand business needs, user expectations, and quality requirements.
• Discussions with the project executivee to ensure alignment with business objectives and strategic priorities.
• A request for proposal (RFP) or similar document, if available, may outline customer requirements in customer/supplier environments.
• Input from subject matter experts, including future team managers, to validate technical feasibility and clarify constraints.

Quality criteria

To ensure clarity and usability, the project product description should meet the following quality criteria:

• A clear and specific purpose for the final product is stated.
• The project scope is complete and, where relevant, includes what is out of scope.
• Acceptance criteria are well-defined, realistic, and unambiguous — avoiding vague language.
• Acceptance criteria reflect stakeholder requirements and expectations.
• The method of assessment for the main project product is clearly described, ensuring:
  • All criteria are measurable
  • Each criterion is individually realistic
  • All criteria can be tested and verified within the project’s timeframe

Tips

Here are some practical tips to help you create a clear and useful project product description that sets realistic expectations and guides delivery.

• You don’t need to write a long or complex project product description — keep it clear and to the point.
• Show users an example of the type of description you’re aiming for (e.g., a one-page overview of a PC or a house) to set expectations.
• Begin with a clear and agreed-upon purpose for the product — get stakeholder buy-in early.
• When defining features, always ask: “How can we prove we’ve met your expectations?”
  • Example: “fast search results” → “search results displayed in under 2 seconds”
  • Example: “big SSD drive” → “SSD drive with 500 GB capacity”
• Understand the difference between requirements and product specifications — requirements describe what the user needs, while specifications define how those needs will be met.
• If a change request is accepted, review the project product description to check whether it needs to be updated to reflect the change.

—o—

Written by Frank Turley.

If you have questions or doubts after using this wiki, you can ask for help on the Facebook or LinkedIn study groups.