image description

Product-Based Project Planning by Susanne Madsen. An Introduction to Product-Based Planning.

In this blog post Susanne Madsen explains the importance of project planning and introduces five steps to producing an outline plan during the planning and initiation phase. The outline plan is based on the principles of product-based planning.

The value of your role as a project manager and the success of your project are heavily dependent on how well you plan and initiate the project you are responsible for. In the words of time management expert Alan Lakein, “Failing to plan is planning to fail.” If you start to execute a project without planning what is to be done, you may actively contribute to its failure. The same holds true if you do not adjust or change the project’s plans if they are no longer accurate or do not work.

The purpose of planning is not to create a map that is set in stone but to think through the project’s critical elements and steps before you make irreversible commitments and take irrevocable actions.

When you take the time to establish the project’s scope and analyze the requirements, problem domain, and solution up front, you are much more likely to understand the project’s core challenges and recognize what it takes to address them and deliver a quality product to the client.

Up-front planning is required for all types of projects because the organization and customer need you to estimate the project’s size, cost, and completion date before they fully commit to undertaking it. Likewise, as the project manager, you need to understand the exact scope of what your team is expected to deliver and how you plan to deliver it.

Having said that, the extent to which you plan a project in detail during the planning and initiation phase depends on the specific domain and nature of your project as well as the chosen methodology. Some projects are large, complex, and volatile, while others are smaller and much simpler to define, plan, and deliver. For the purpose of this blog post we will assume that your project is somewhere in between: a medium-sized project of medium complexity, with a project methodology that is neither rigid nor extremely flexible. As a result, you may plan the project at a high level during the initiation phase and subsequently refine and adjust the plan as you move through the execution of the project.

Creating an Outline Plan

There are many different ways of creating a plan. One of them is a product-based planning technique. With product-based planning, your focus is first and foremost on the products that need to be delivered as opposed to the activities the project needs to undertake. It means that you plan the project from the client’s and user’s perspective, because you put the focus on tangible deliverables and outcomes.

Note that the plans you produce during the initiation phase will mostly be high level, unless you operate within a domain where your plans for some reason must be fixed and contain a minimum amount of uncertainty. Under most circumstances, though, I would recommend that you only plan in detail for as far ahead as is sensible. Keep your plans realistic yet simple. It is better to be broadly right than precisely wrong.

Do not attempt to plan your project in isolation, but seek assistance from your team members. You need them to help you break down high-level products into subproducts, tasks, and activities with durations and dependencies.

Use the below tips and techniques to help you create a high-level product-based plan. Note that you will only be able to produce the plan once you have a reasonable understanding of what the requirements are and once you have estimated these requirements. Planning is an iterative process, so do not worry if you do not have all of the detailed information up front. Create a high-level plan and refine it as you go along.

1. Create a product breakdown structure
The first step in creating a product-based plan is to create a product breakdown structure in hierarchical format, similar to one you would use to build an organizational chart. It should contain all of the major products (i.e., components and deliverables) you plan to produce and deliver.

  • At the top of the hierarchy, you depict the final product—the finished system, building, or deliverable.
  • In the level below, you document its constituent parts. This could consist of two, ten, or more subproducts depending on your project. 
  • On the third level of the hierarchy, you break down the subproducts even further. 

Continue breaking down your products and deliverables to a level that makes sense for the project. The product breakdown structure does not contain any dependencies or activities but is a pure representation of what the users need and how their needs break down into sub-subdeliverables.

2. Create a product flow diagram
The next step is to turn the product breakdown structure into a product flow diagram, which is a view of the sequence in which the different products are likely to be delivered. Use the products and subproducts from the product breakdown structure, and rearrange them according to their priorities and dependencies. Make the diagram flow from left to right, ending up with the final product on the far right side. Use your knowledge of interdependencies between the subproducts and their relative business priority to create the diagram.

3. Produce a high-level plan
Use the product flow diagram as the guide for creating a road map and a straw-model scenario that you can use to jump-start more in-depth planning conversations and activities. In the early stages of the planning process, you may have to make many assumptions and use approximate durations and timings. Determine the sequence in which you aim to deliver the products, then arrange them into phases with clearly defined milestones. Aim to deliver the core and most critical part of the solution first.

Once you know what the distinct phases are, focus on the first phase and break down its subdeliverables into as much detail as you can, preferably until you have individual tasks and activities that would take days, rather than weeks, for a team member to execute. Continue breaking down the subsequent phases of the project, but use a broader brush for the later phases, where you might not yet have full understanding of the detailed activities that need to be carried out.

4. Assign resources
Start assigning resources to your plan, and tighten up the estimated duration of individual tasks. In order to do that, you must understand which resources are available and also plan for the possibility of their being unavailable. Play around with different resource levels to get a good feel for when the project might complete.

When doing so, identify and pay special attention to the project’s critical path. The critical path is the longest sequence of dependent activities in your schedule that must be completed by the due date in order for the project to be on time. It is the critical path that will determine the actual duration of the project, as all other activities can be scheduled in parallel. More than anything, it is the critical path that you must pay close attention to throughout the execution of the project to make sure that the overall project time line does not slip.

5. Present the plan
Before you provide your sponsor and steering committee with the outline plan, review it one last time with members of the team, and make sure you have added sufficient contingency to the critical path. Remember that it is better to under-promise and over-deliver than the other way around.

Once stakeholders see a schedule, they have a tendency to think it is set in stone. Plan for worst-case scenarios, and provide a range of dates within which you expect to deliver the project, as opposed to just one fixed date. Explain to your stakeholders what your planning assumptions, risks, and issues are, and make it very clear that events are not set in stone. Explain that you will update and refine the plan frequently as you move through the project and that you will keep them informed of any changes.

***
Susanne Madsen is a project and program manager, mentor and coach with over 15 years experience in managing and rolling out large change programs for the financial sector. She is a qualified Corporate and Executive coach and a PRINCE2 and MSP practitioner. Her book, The Project Management Coach, will be published in January by Management Concepts. You can visit Susanne’s website or follow her on Twitter: @SusanneMadsen.

Join 660,449 customers and have your first
Gantt chart live today!