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.
What does a well-formed Project Product Description do?
What does a well-formed Project Product Description NOT do?
What can we use a well-formed Project Product Description for?
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:
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