Return to Components


Plans constitute the backbone of any project. More often than not a successful project relies on the success of the planning activity and on the monitoring and implementation of countermeasures to make sure events, which might impact the plan, are being controlled.

The general purpose of a plan is to create a structured and controlled schedule that allows for an efficient use of management time and other resources which provide the best possible implementation of all the development activities aimed at delivery the outputs of the plan with defined constraints expressed in terms of cost, Time, Scope, Quality and Risk tolerances. A plan provides answers the questions: Who, What, When, How, Where and How Much. An effective plan will define clearly for all parties involved, what is required, what approach has been chosen to achieve the desired outcomes, the timescales for the activities to take place and the targets expressed in terms of Cost, Time, Scope, Quality, Risk and Sustainability objectives.

Although the most recognisable aspect of a plan is perhaps the chronological scheduling, a complete plan provides much more comprehensive information related to all the aspects to be covered during a specific piece of work. In PM4SD, much as the reference method PRINCE2®, the different plans contain detailed information aimed at covering the different monitoring requirements of the different Organisation levels. As such a PM4SD project might encounter a Programme Plan covering the larger Programme blueprint, a Project plan covering the entire project, a Stage plan covering a specific management stage within a project, and possibly a Team plan covering the specific activities involved in the delivery of a particular Work Package within a stage.

From a management point of view we can expect plans to have a common framework/structure, regardless of the level of planning as it is the level of detail within the content of a plan that changes according to the individual necessities of those impacted by that plan. For instance a Project Plan would provide high level details for the project, describing the total forecasted cost and timescales, the major products to be delivered (or milestones to be achieved) and an indication of the project level objectives to comply with. It is mainly used by the Project Board to monitor the overall progress of the project.

Conversely, a Stage plan will define more detailed day-to-day activities to be covered during the duration of a specific management stage. It is the main instrument with which the PM will monitor the progress of a stage against its objectives. Although the technical details and contents of a plan will be different in one project from another (or one plan from another) there are some aspects of the planning process that are common and help the PM in creating a manageable and efficient plan. These are details such as any planning pre-requisites that must be in place and remain so for the plan to work, planning assumptions which can only be confirmed once the plan is implemented, scheduling and effort calculation which will help the PM ascertain the viability of the plan and the risk profile where the PM can ensure the planned work is not susceptible to a level of risk higher than is acceptable for the project.

There must also be clarity concerning the difference between the plans dealing with the products to be created during the project and the plans outlining specific aspects of project management activities such as the Quality Plan, the Communication Plan and the Risk and Issue Management Plan.

The PM4SD approach uses the product based approach to planning. This means plans are created around the scope of what needs to be delivered rather than the activities to deliver the products, and as such gives a better definition of the product scope, a reduced risk of scope-creep, and a more widely accepted understanding of what the plan is going to produce. At the same time such an approach provides a more precise method for the estimation of effort and for measuring the effective achievement of the desired result.

For instance rather than planning an editing activity to produce an advertising brochure and trying to steer it towards something that might be acceptable, the product-based approach will start by first planning in extreme detail all aspect of the brochure to be produced, from its contents, to its format and presentation and any quality criteria the User might request. In this way planning an activity aimed at producing some exact specification will become more practical and the achievement of the set criteria will be better measured against the product itself rather than the performance of the task. The difference (although in more complex project this might not be so clear) is that planning an editing activity might have many different outcomes while planning the product needed will have a precise activity aimed at delivering exactly what is required.


To support the Focus on Products principle PM4SD suggests the application of the product based planning technique. This is a four-step procedure with which the products to be developed or modified as part of a plan are identified and all the activities and effort calculations are worked out before a detailed schedule can be created.

At all times during these steps the risk situation must be monitored for new or revised threats and opportunities, which could impact any of the identified products.

Create the Product Description for the Final Product

This activity is the starting point for any plan and is a prerequisite for the creation of the project plan during the Project Initiation process. On completion of a detailed description of the component parts of the final product to be delivered and the acceptance criteria we can go to the second step of the technique. The product description for the final product will be created by the PM with the information being provided by the Senior User during the Starting activities of the project and will be refined in its details during the creation of the project plan.

Create the Product Breakdown Structure (PBS)

Once the component parts of a product have been identified within its product description they can then be split into sub products and represented in a hierarchical structure where the top products are composed of the sum of the products directly below them. This decomposition can continue as long as for each newly identified product the product description is created providing details of the product specifications and quality criteria.

The level of decomposition permissible is dictated by the development needs of our project, For instance, if the project is to create a footpath along a Heritage site there might be a need to break the product down to the materials to be used and the facilities needed along the route but it would be both inefficient and pointless to break down the tarmac used to its molecular composition. Create the Product descriptions for each newly identified Product.

Create the Product Descriptions

Following the identification of products, derived from the Product Breakdown Structure the relative product descriptions should be produced to allow iteration of these two steps until the desired level of breakdown is reached.

Create the Product Workflow Diagram (PWD)

Once all the products relative to a specific plan have been identified and their Product Descriptions created the PM will proceed to create the flow chart relative to their development. The relationships between products and development interfaces must be considered in order to produce the most efficient Product flow relative to the order of creation of the products.

This four-step technique is the main focus of the Planning activity flow and is applied by the PM any time a plan needs to be created or modified. The recommended activities are:

  • Create the Plan Template
  • Identify products
  • Identify Activities
  • Prepare Estimates
  • Create the Plan Schedule
  • Revise the Risk Exposure
  • Complete the Plan

This approach to planning presents various benefits:

  • It promotes User participation in the definition of each product requirement;
  • It promotes Supplier participation in assessing the effort estimates and resourcing requirements and overall plan viability;
  • It reduces the risk of incorrectly scoping a plan
  • It promotes active monitoring of the risk situation and provides for actions to be taken to produce a plan that is threatened as little as possible;
  • It facilitates the identification and creation of the work packages and allows for more measurable criteria to be used during the plan implementation for assessing progress.