Product based planning

Product based planning can be used for developing requirements with both Agile and waterfall type methodologies.

Product based planning is a good option if you plan to invest limited resources, time and money into developing a product or a service. It will enable you to focus on the end product and at the same time allow changes to ensure that business needs are met.

What is the benefit of product based planning?

There are many benefits to product based planning, two of them are particularly significant with e-commerce projects.

Understanding of the complexity

People often oversimplify what is required when building a web shop (e-Commerce) solution. Using Product Based Planning it is possible to identify all the features and functions that are required even in a basic e-commerce solution. This in turn leads to a better understanding about the work needed to create the different features and functions.

Complexity to simplicity

While we need people to understand how complex the solution is, at the same time we need to be able to break down the complexity to the simplest level of understanding.

Product based planning consists of four core levels

The first three levels define what is needed these requirements come from the business or product owner. The fourth level defines the how and is documented by the team producing the output.

By visualising and progressively developing the first three levels, Project Product Description (Highest Level), Component Product Descriptions (Level 2 and more detail) and User Scenarios & Acceptance Tests (Level 3, very detailed) we are able to distil, crystallise and clarify the user and technical requirements. This process in turn enables us to breakdown a complex system(s) into manageable components. At each level we want to state what is important in the least amount of space necessary while at the same time making clear what is of value and relevant. This process helps to ensure that differences in opinion are understood and resolved as far as possible so that time and money is not wasted on misunderstandings that could have been avoided.

The planning horizon for each level varies with level 1 (project product description) having the longest planning horizon and level 4 (Tasks) being the shortest, possibly one or two weeks.

Illustration of the four levels of requirements development used.

Image showing the four levels of Product Based Planning

Who to include in requirements development

At a minimum the product owner who is from the business side needs to define what the business needs. You will also need to include a technical person so that they can give consideration to the infrastructure and architecture for the product. For larger more complex project you will need to scale the team accordingly.

TIP: Start with the end result in mind

To identify the most suitable solution you need to know what business need is missing, to do this start with the end in mind. Understand what the strategic objectives are, work backwards to identify what benefits need to be realised and what changes need to happen in order to realise the benefits. You can then work out the most suitable solution(s) to deliver the required capability in the form of project outputs and changes in work processes. This is referred to as a benefits-led development process rather than a product/solution led process. I recommend that you use the first workshop in the requirements development process to identify the benefits that need to be realised and then use this as a reference point to work from.

By developing the requirements using a sound structure and process you will have a positive impact in the following areas of project management:

  1. Scope management.
  2. Time management
  3. Energy management
  4. Cost management
  5. Quality management
  6. Communication management
  7. Conflict Management
  8. Constraint management.
  9. Risk management.

Base-lining product descriptions

It is important to understand the concept of base-lining in product based planning. When we baseline a product description we gain agreement on what will be developed.
If we discover that the planned product is no longer the most suitable output to deliver the required business outcomes and benefits. We change the product description and product via the change management process.
This practice gives us the capability of rapidly and efficiently adapting to maximise the opportunity of achieving the business goal.

Energy management

I highlight energy management here because I have seen how much energy and negative emotion is expended on projects that do not have the right requirements structured in a logical way. We all have a limited supply of patience and energy therefor it is important that this energy is focused and used to achieving the projects objectives.

If you have not done this before:

Please feel free to contact me for advice on how to get started. Scroll down for my contact details.

If you feel that you would like further help there are several options including the following:
1: Run a workshop specifically focused on Product Based Planning
2: Work with your team during the pre-study and mentor them
3: Hands on management of projects