Planning quality

A plan is a forecast. Many people think that a project forecast is expressed in terms of a completion date and a total budget, but neither can be predicted adequately until what the project has to deliver is known. Thus a forecast is better described as a probability assessment based on skill and experience of the time and resources required for the successful delivery of a specified end product.

The specified end product will not be produced by chance. It must be defined, planned, built, tested and accepted before it can be used for its intended purpose. This means that a successful outcome will mean different things to different people. The sponsor may consider as successful a project that delivers a low-cost, high-income-generating solution, whereas customers may expect it to provide something that works and is robust and reliable. For the developers, a successful project must deliver an outcome that is supportable since it may have to be maintained and managed over a long period.

When a project has been completed questions will be asked about its success. Posing them at the beginning of the project forces participants to identify success criteria, which might be:

e Does the new computer system process twice as many trades per day as the previous one? e Does the new office provide each of the 350 staff with at least

36 square feet of desk space? e Were all new staff recruited by the end of June? e Have the new facilities been secured within their quoted budget? e Have the new office operating procedures been made available to the Tokyo office as a priority?

These questions describe the quality of the project's intended outcome, but it is also essential to measure the quality of the project's output as it progresses. Only by having clearly defined and agreed measures is it possible to know whether a step in the project has been completed successfully.

Consequently, before creating a project time schedule or a resource plan, it is helpful to know what the project must deliver at periods in its lifetime and at its end. These are the project's milestones or "products".

If an activity fails to deliver or contribute significantly to the delivery of a product, it is reasonable to ask why time and effort were spent on it. This means it should be possible to show that all project activity contributes clearly to the delivery of specified products. Examples of products could include a:

e piece of tested software; e marketing plan; e test schedule; e design document; e "business case"; e presentation; e conference; e trained user.

Products result from activities; for example, training is the activity that delivers a "trained user" (the product). When planning a project that involves training, how long should be allowed and what is an appropriate investment? It is possible to answer such questions only when more is known about the product itself. The standard expected of the trained user must be defined. In the same way that success criteria have been described for the project, so is it possible to describe success at product level. In the example above, if the users have been trained to drive a car, these are some of the ways an examiner might judge their fitness to do so:

e Can they perform an emergency stop without stalling the engine?

e Can they reverse round a corner without hitting the kerb?

e Can they correctly identify and interpret road signs?

e Do they use their rear-view mirrors before every manoeuvre?

If time and cost were the only things worth planning, the roads would be full of drivers who had completed their training when their budgets and instructors' patience had run out. If the expectations of a project's products are clearly described:

e fewer activities will be forgotten;

e more activity will be focused on delivering the intended outcome; e the suitability of estimates for timescale and cost will be improved;

e it will be possible to know when an activity has been "finished"; e expectations of a fit-for-purpose outcome will be commonly understood, thus reducing confusion and reworking.

The technique of product-based planning puts quality at the heart of planning, enabling the:

e products of the project to be clearly identified; e products to be ordered into a reliable delivery sequence; e quality of products to be described.

Product-based planning was first described as part of the prince approach to project management (see page 14) and has become a widely practised, robust and reliable technique. It does not remove the need to plan a timescale and a budget, but it ensures that when developing the schedule and resource plan, they are based on a far better understanding of the intended outcome and approach. Product-based planning produces the:

e product breakdown structure; e product flow diagram; e product description.

A simplified version of this valuable technique is described below. Details of enhancements can be found in the book Managing Successful Projects with PRINCE2 (PRINCE Guidance).*

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment