Project Product Description

A high level overview of the project product or service

The product description should be a relatively quick read and give a clear overview of the business need for the project. The reader should have a good understanding of the expected high level outcomes and benefits the organisation wants to realise, along with the capability that will be delivered as a result of the project output.
The project product description is defined during the initial Capability Discovery process.

The more detailed requirements in the form of wireframes, Component Product descriptions and User Scenarios & Acceptance Tests are developed in the initial Blueprint Design process and subsequent design processes throughout the project. Please refer to the rolling wave planning concept to get more information on how and why some detailed requirements are only defined once the project starts.
NB: The Capability Discovery process and Blueprint Design process can be run in parallel, sequentially or a mixture of the two.

For those who use Scrum, the project product description is similar to the product vision.

The Product Description in combination with the Product Breakdown Structure is a powerful communication tool

The product breakdown structure can be used to visualise the product and its components.
Image displaying the Product Breakdown Structure

What does a well-formed Project Product Description do?

  • Describe the strategic objectives the project will contribute to.
  • Define who are the intended users of the project product or service.
  • Define the benefits that will be realized as a result of the outcomes being achieved from this project.
  • Define the outcomes that need to be achieved from the capability delivered by this project product or service.
  • Document assumptions about the benefits and outcomes.
  • Defines the project product scope.NB: This can be changed during the project and a new baseline set with the changes
  • Defines what output the project must deliver in order to gain acceptance.
  • Define the clients quality expectations
  • Define the acceptance criteria, method and responsibilities for the product.
  • Define and understand what the term “Done” means for the project output.
  • Define the first level of component products in summary.
  • States what is important in the least amount of space necessary so that we make clear what is necessary for there to be a good understanding of the project product.

  • What does a well-formed Project Product Description NOT do?

  • Define the project scope. (The project scope is defined in the Outline Project Plan, the product scope is part of the project scope
  • Give a detailed breakdown of the requirements. (This is done in the User Scenarios & Acceptance Tests)

  • What can we use a well-formed Project Product Description for?

  • Maintain alignment between the project output and the required business benefits
  • The first step in eliminating unpleasant surprises and broken promises through clearly defining what is wanted at a high level.
  • Enable the product owner with the project manager to develop a high level understanding as to what they are asking for without wasting time on defining the detail that will inevitably change under the course of the project.
  • As an input for the technical experts to start defining high priority non-functional requirements for infrastructure and architecture.
  • Gain agreement and focus on the project product’s scope limits
  • Scope verification and management
  • Developing the initial business case for the project
  • Communication to stakeholders across time, organisation and culture boundaries
  • Initial Identification of talents, skills and knowledge required to deliver the project product.
  • As a reference when developing component product descriptions and US&ATs
  • Progressively develop the component product descriptions within set planning horizons.(Rolling wave planning)
  • Cost management, through effective scope management
  • Quality management
  • Keeping a focus on the end product during the project.

  • Once you have baselined your project product description you are then in a position to define the component products/services and the level 3 User Scenarios and Acceptance Tests.

    A few guidelines on building your Project Product Description

    The project product description is an output from the Capability Discovery process as mentioned before. Here are a few guidelines on what needs to happen so that you have a reasonable and useful document that communicates the projects purpose for the life of the project. Bear in mind that the work carried out during the initial Capability Discovery process will result in a large amount of information that will also be used in defining more detailed requirements documentation.

    During the Capability discovery process the following four questions should be part of every workshop and discussion.
    1: What are the market related outcomes that need to be achieved and business benefits that must be realised?
    2: What changes are necessary to make a better or more effective experience so that we can achieve the desired outcomes?
    3: What dis-benefits or problems may arise as a result from the change in the way we work?
    4: Are the tools and service we have adequate to enable the new ways of working or do we need new tools, products or services to do the job?

    What are the market related outcomes that need to be achieved and business benefits that must be realised?

    Start with identifying the market related outcomes that when achieved will result in realising the needed benefits. The outcomes will often be quantitative, but can also be qualitative. Understanding what outcomes can be expected is important as it informs the decision on what capability is needed and what output to product from the project. When we understand what outcomes are expected we are able to validate or invalidate our hypothesis on what is the most suitable output to deliver the right capability.
    Some of this information should be available from the processes that led to the decision to initiate the project.
    This exercise is very important input to creating the project product description and it is often not done. When your organisation does not have a clear set of market related outcomes and business benefits along their performance metrics defined, you tend to get a solution from the project that an individual wants you to have rather than what the organisation needs.
    By identifying benefits and their performance metrics at the beginning of the project, the project team can focus on benefits-led change. Where we define the project product description and other requirements based on a clear understanding of what the organisation needs the project team to realise. This will help to avoid the tendency of stating what we want and then work out a justification as to why we want it.

    What changes are necessary to make a better or more effective experience so that we can achieve the desired outcomes?

    If our example business is an online retail business we may be looking at improvements from the end customers’ perspective or from the perspective of company staff working with the eCommerce solution. During the Capability Discovery process it is important during each workshop to apply the above question in the context of the particular area of business being discussed. For those not familiar with eCommerce this will include areas such as:

  • Managing product information
  • Managing customer information
  • How the merchants work with selling products online
  • How the marketing team uses the online solution and other social media solutions to market the business.
  • How customer services work and how customers register enquiries
  • The project product description should reflect a high level summary of the answers to these questions while the User Scenarios and Acceptance Tests will give more detailed information on desired outcomes when they are defined in the design process.

    What dis-benefits or problems may arise as a result from the change in the way we work?

    Success can sometimes lead to problems. As you work through the capability discovery process it is important to uncover potential dis-benefits that may evolve as a result of the improvements that are being made. By identifying potential dis-benefits you are able to implement more robust risk management to mitigate or reduce potential dis-benefits. Specific dis-benefits should be included in the risk management register, it is useful to include a high level summary on the project product description so that everyone is aware that there are potential risks and what they may be.

    NB: This page is being updated.
    Please feel free to contact me for advice my contact details are at the bottom of the page