A cunning - and charitable - plan...

I’ve never sought to raise money for a charity before. However, in April, I will be heading out to Uganda with my wife and some friends to support the work of the “River of Life”. This is a group based in rural Masaka, helping street children, widows and orphans and others in need. The community now has a farm, a school, a hospital and places of worship, all essential to their way of life, but all dependent on the generosity of strangers.

If you've read this far, you may be thinking, there's an appeal for charity coming up. And you'd be right; there is. But you might also be wondering, as I did as I thought about posting this article, Is this what LinkedIn is for? In truth, I don't think it is. LinkedIn is a networking service, principally for promoting business, not social, connections.

So, in the words of Blackadder's Baldrick, "I have a cunning plan!" In return and thanks for your consideration of a charitable donation, I'd like to offer you something which might be helpful in your working life. What follows at the end of this appeal, is a quite substantial article, written by me, on a subject familiar to many of us; planning. In particular, given how many of us benefit from being reminded of project management techniques we learned years ago, it's a guide to Product Based Planning, giving consideration to the definition of quality before leaping to estimations of time and cost. I hope you find it useful - feel free to share it with colleagues.

If you would like to offer even the smallest of gifts to the River of Life's thriving but disadvantaged community, your generosity can make a world of difference to those less fortunate than ourselves (e.g. locally, ￡50 will feed the entire orphanage for a month). Here’s the “River of Life” JustGiving page. Thanks in advance for whatever you can offer.

And, as promised, here's the guide to Product Based Planning...

HOW DO I PLAN… QUALITY?

A Guide to Product-Based Planning by Paul Roberts

This paper covers:

• the need to use our knowledge of the project’s expected success criteria to determine which deliverables are needed;
• the importance and benefits of understanding what deliverables the project must produce before committing to a timescale and budget;
• a full explanation of the ‘product-based’ planning technique;
• a wealth of practical advice to assist in your use of the technique;
• example product-based plans to serve as a guide.

When you don’t know where you are going, any road will get you there. Too often – and this is especially problematic in projects – we dwell on the journey rather than the destination. We are transfixed by process when we could gain much by focusing on the products which must be delivered. Some of the consequences of our failure to focus on what must be delivered are:

• a false belief that activity equates to progress;
• a tendency to start spending money before we know what outcome must be achieved;
• a failure to accurately predict the time needed to complete the work;
• a failure to accurately predict the resource requirements;
• greater difficulty in identifying and managing the risks;
• an inability to clearly and commonly define, communicate and understand the quality which is expected.

At the very least, a plan is composed from three key components:

• a time schedule;
• a resource or cost plan;
• a quality plan.

In this paper, we’ll turn planning on its head. Instead of cutting up the available time into strips of activity and assigning resources to the work, we’ll first seek to describe the quality of the deliverables the project must produce. We will use some techniques to work at a much more detailed level. Instead of understanding what the outcome of the whole project should be, we’ll try to understand what set of deliverables must be produced during its lifecycle. In taking this approach we will derive a timescale and cost which is more accurately aligned to the required quality. These estimates of time and cost may be unpalatable to the Project Steering Group, and the participants have every right to challenge them. However, at least the ensuing debate can include an extra dimension, allowing everyone to agree not only upon what balance of time and cost is satisfactory, but also what level of quality will be acceptable.

UNDERSTANDING A PRODUCT-BASED APPROACH TO PLANNING

For the purposes of clarity, I’m going to use the expression ‘product’ in place of two other terms which are common: milestone and deliverable. In my opinion, they mean the same thing; both milestones and deliverables should be products which can be described in a conventional manner.

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:

• piece of tested software;
• marketing plan;
• test schedule;
• design document;
• ‘business case’;
• presentation;
• decision;
• trained user.

The last example is an especially good one to help illustrate the difference between an activity and a product. Training is the activity that delivers a ‘trained user’ (the product). When planning a project that requires training to be included, how long should be allowed and what is an appropriate investment? We need to know more about the product itself: the standard expected of the ‘trained user’ must be defined. 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:

• can they perform an emergency stop without stalling the engine?
• can they reverse round a corner without hitting the kerb?
• can they correctly identify and interpret road signs?
• 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. In better describing the expectations of a project’s products:

• fewer activities will be forgotten;
• more activity will be focused on delivering the intended outcome;
• the suitability of estimates for timescale and cost will be improved;
• it will be possible to know when an activity has been ‘finished’;
• expectations of a fit-for-purpose outcome will be clearly and commonly understood, thus reducing confusion and the need for rework.

The technique of ‘product-based planning’ puts quality at the heart of planning, enabling the products of the project to be clearly identified, ordered into a reliable delivery sequence and sufficiently well described. The technique was first explained as part of the PRINCE approach to project management and has become a widely practiced, 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.

There are three complementary parts to product-based planning:

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

A practical explanation of this valuable technique is provided below.

The product breakdown structure

This seeks to identify all products to be created by the project. In so doing, it is a means of describing the project’s scope as the set of the things it must produce.

At the top of the diagram is the single product that the project is intended to deliver. This product is progressively decomposed into a series of component parts which together make up the whole. It is these smaller parts that the project must eventually produce. Take, for example, a desktop computer. It is composed of many smaller parts, each of which can be specified. It is comprised of a screen, a keyboard, a mouse and a processing unit, which is itself the sum of smaller components, such as the hard drive, the motherboard, the power supply and the case.

It can help to post reminder notes on a board as products are identified. Here is an example. A project has been created to train a number of people in the topic of project management. Figure 1 is the product breakdown structure which identifies the products:

Fig 1

People’s expectations of what the ‘training programme’ project must deliver may be different. To understand these expectations better, this high-level, poorly defined product has been broken into ever smaller component parts until it has been expressed as the entire set of building blocks needed throughout the whole project.

Initially, the training course has been split into three smaller components: the specified course, the prepared course and the delivered course. It may be possible to estimate the development time and cost of each of these three products but it is unlikely that there would be sufficient understanding of them at such a high level to do so with any confidence. So, the prepared course is decomposed into the gathered requirements and the course definition document. These are difficult to subdivide further, so this ‘root’ stops there. The prepared course can be subdivided into many further products, each of which becomes redundant as those below it describe it better. For instance, there is no longer a need to focus on delegate materials since they are now the sum of exercise briefs, sample solutions and copy of slides.

What began as a single deliverable is now much better defined as a considered list of component parts that together describe the scope of the project.

The starter product (training course) has been decomposed into:

1.1         Gathered requirements

1.2         Course definition document

2.1         Course schedule

2.2.1     Lecturer notes

2.2.2     Presentation slides

2.2.3.1  Exercise briefs

2.2.3.2  Sample solutions

2.2.3.3  Copy of slides

2.3         Course bookings

3.1         Trained users

3.2         Post-course coaching sessions

3.3         Completed course appraisals

If you are the Project Manager, it is likely that you would wish to run this session as a workshop, or perhaps ask an independent colleague to do so in order that you may contribute personally. In any case, the technique greatly benefits from a facilitator. Once the product breakdown structure has been developed satisfactorily, it should be possible to produce a product flow diagram to show the sequence in which products must be developed.

The product flow diagram

The product flow diagram illustrates the dependencies between the products, and thus, the sequence in which they must be produced.

Fig 2

Construct the product flow diagram by removing from the product breakdown structure the redundant, higher-level products and place those remaining in an order defined by their dependence. This can be stressful and time-consuming, but planning is a difficult and demanding process; it is better to identify the challenges and deal with them before it is too late or they become too costly to fix.

At the outset, identify the start and end products, noting that there may be many products with no prior dependency. The sequence should flow from top to bottom and the remaining products should be positioned until most of them are on the board. To reduce misunderstandings, all products should retain the same names as on the product breakdown structure. The facilitator should regularly take stock, challenge and change the order if need. It is important to allow debate, but the facilitator should not become so involved as to lose the chance to listen out for new products, which should be added to both the product breakdown structure and the product flow diagram. When all products are on the board, the arrows between them should be added, but only in pencil. It is normal for discussion to flare up again when the slightest change is made to the product flow diagram.

A robust plan means the same thing to everyone who reads it.

Throughout the process so far, it is highly likely that questions will have been raised about each product and it is unlikely that everyone will have a clear and common understanding. The titles of the products are open to misinterpretation and do not fully describe their content, format and purpose.

The product description

It is often sensible to start the planning process with the product breakdown structure.

The product flow diagram and the product descriptions are frequently developed together because the latter provides a definitive description of each product so that everyone has a clear and common understanding of it.

While the product breakdown structure and the product flow diagram are being developed, the facilitator should challenge and capture the views of the participants on the character of each individual product through the product description, outlined in figure 3.

Fig 3

Title

This should be simple and clear.

Purpose

This section is not a repository for everything known about the product but a specific description of why it is needed, ideally in a single sentence. If the purpose cannot be articulated, it is worth asking if the product is required at all.

Composition

This section should read like a table of contents. If the product is a document, the composition should list the section headings to appear in the end product. The content of each section can be expanded as this helps develop expectations of what the product will contain. Products are not always documents, however. ‘Trained user’ is a product and its composition may be simply described as ‘a course delegate’. Qualifying what standard that delegate must achieve comes later.

Derivation

This section is the equivalent of a list of sources. As well as listing the immediate preceding products needed from which to develop this product, it can also contain directions to any other materials or information necessary in its development. For example, the course definition document can only be developed once the course requirements have been completed. Additional information may be gleaned by interviewing a colleague who has had training elsewhere and is listed here to guide the person developing the course definition document to a further source of information. This section is also often used to list any standards to which the product developer should refer.

Format

This describes the physical characteristics of the product. In figure 3 it is a document and its ‘look’ has been described. If the product was an ‘architectural plan’, the format may be ‘A0 blueprint’.

Audience

This important section lists the users of the product. It is important to know who they will be so that the next section can encompass their varying expectations.

Quality criteria

Because quality criteria define the characteristics of the product that would make it fit for purpose, this list is the most important part of the product description. Just as the project has success criteria, so does each individual product and, in the same way, they are expressed as questions. If each question asked in this section were answered positively, the product could be deemed fit for purpose and could be approved and signed off. The more sophisticated and elaborate the list of quality criteria, the greater the expectation of the quality of the end product.

This list not only confirms that the developed product is complete, but also steers the product developer towards getting it right first time. Knowing the audience and describing their expectations before development starts minimises the potential of developing a series of failed prototypes.

Creating a list of quality criteria is a difficult process and can be helped by:

• arranging quality criteria in order of those who will use the product (the audience);
• asking everyone in the audience to prioritise the quality criteria relevant to them;
• checking all product quality criteria for consistency with project success criteria;
• asking whether the rest of the product description has been followed;
• expressing quality criteria as measurable and unambiguous questions to which the answers yes or no are the only options;
• avoiding adjectives such as effective, clear and suitable because each member of the audience will interpret them differently;
• checking the composition section and determining the quality criteria for each item listed. This will help if identifying quality criteria for the overall product is causing difficulties.

Quality method

There are many ways of testing a product, including:

• examination;
• informal/formal review;
• inspection;
• demonstration.

In all cases, the product description is the yardstick against which the product itself is tested, and approval for the formal completion of the product can be sought only on its outcome. Only then can it be said that the product is fit for purpose and finished.

USING A PRODUCT-BASED APPROACH TO PLANNING

Good practice

It is highly desirable to involve the emerging project team in the planning process. It not only results in a better and more clearly defined outcome, but also promotes the involvement of senior stakeholders from whom approvals will be needed, and from team members who will be required to estimate the time and cost needed to deliver the project’s products.

The facilitator (perhaps that’s you) should recap frequently what has been described during the creation of the product-based plan so that everyone has a clear and common understanding. And it is a good idea to nominate a note-taker because products will be taking shape and some of their characteristics will need to be captured.

How detailed should this product-based plan be? The answer is the same regardless of whether the plan focuses on products or activities. As the plan will be used to delegate and control the delivery of products, those products should be subdivided to a point at which you feel confident enough to monitor the progress of their delivery. You should ask yourself – and your Project Steering Group – how long would you be prepared to wait to discover whether a product had been completed or not? I find a good rule of thumb is 2–3 weeks.

There will probably be debate about which products should be in or out of scope. If a product is to be excluded from the project but its development is still necessary to it, identify it as an ‘external’ product so that you can manage your dependency on it.

Producing the product flow diagram can be challenging, not least because everyone involved will have an opinion on the best sequence. This is also a benefit because it can help in drawing a wide and varied range of expertise into the project. Try to keep hold of the people who helped develop the product breakdown structure to assist in drafting the product flow diagram. This retains their value to the planning process for longer and they will become more involved as the plan takes shape. Consequently, it is desirable that senior individuals take part as their views will be valuable. As everyone will be asked to estimate the time and investment needed to deliver each product, involving them early helps them to understand the project and the emerging approach.

A common misunderstanding is to give the product flow diagram a timescale. This comes later in the planning process. Therefore, the fact that two products appear next to each other (for example, presentation slides and course bookings) does not mean that they will be delivered at the same time. Indeed, the words at the same time should be avoided when discussing a product flow diagram. This allows the project to be discussed without preconceived and unsupported constraints, and matters relating to quality can be articulated first so that time and cost expectations can be more effectively managed.

If the project is large or clear teams have formed already, groups of products can be allocated to smaller teams. These teams may develop their own product flow diagrams, which are consolidated after debate. Alternatively, to improve the product flow diagram, you might have them work independently on the same products and then meet to identify and resolve differences.

It follows that the people tasked with delivering the project’s products should be those who know them best. No one, especially the Project Manager, can ever be an expert in every area of the project, so it makes sense for the product-based plan (particularly the product descriptions) to be developed by, or in co-operation with, the experts.

You may worry that a product description is needed for every product in it. However, it is usually possible to prioritise some products, either because they are critical, or new, or confusing, or all three. Producing proper product descriptions will lessen the risk of delivering something that is unfit and will need reworking. In fact, many organisations have a library of product-based plans and there is every reason to benefit from those drawn up for previous projects. This does not mean that a plan can be transferred from one project to another with a little tailoring, as all projects are unique. However, this is a great opportunity for the planners to learn from planners of the past.

Another way of managing the potential number of product descriptions is to focus on the characteristics of the product that matter most. By shrinking the number of sections, it is possible to reduce the workload needed to create them. This can be achieved by replacing a number of product descriptions by a single table of product outlines (see table 1).

Table 1

Table 1 shows only five of the eight possible ways of characterising a product, but the loss of value arising from the absence of the remaining sections is balanced by creating an expression of quality that is more likely to be digested by the Project Steering Group.

Can you identify and describe your project’s products and their sequence of delivery?

Examples

The product breakdown structure, the product flow diagram and the product descriptions will go through a number of changes, so maintaining robust control of the versions of the plan is important. New products will be identified, existing products will be considered too detailed or too high-level, and some products will become redundant as knowledge improves and the plan is rationalised further. For instance, when developing a product flow diagram, there may be suggestions that the product breakdown structure has identified products that have not been fully broken down. Figure 4 shows the product breakdown structure for fitting out and marketing a new factory.

Fig 4

Factory employees may be described as ‘paid employees, working in the factory’, but placing it in the product flow diagram highlights a risk (see figure 5).

Fig 5

The risk is that employees may be in place before the factory installations are completed and are being paid before they can do productive work. If Factory employees really means ‘staff who have been offered a role with the company’, the plan is missing the original outcome, ‘paid employees working in the factory’, which remains an essential project milestone. Factory employees needs refining on the product breakdown structure, as shown in figure 6.

Fig 6

Figure 7 shows the revised product flow diagram.

Fig 7

The reconsideration of one product has changed the plan significantly.

The product flow diagram contains no timescale or budgetary information. This means you can produce a draft relatively swiftly and present the basic plan to senior managers so that they can consider the project’s content without the usual pressure to debate time and cost. Until the products and their delivery sequence have been agreed, time and cost expectations will be largely unsupported by evidence and the product flow diagram describes the project without the need to commit too much advance resource.

However, if the timescale is brought up during discussion, the product flow diagram can accommodate it by dividing the project into stages against each of which a target date and budget may be placed. This should not mean that the date or investment has been promised, but this new expression begins to show how quality, cost and time expectations may need to be played off against each other. Looking at figure 8, the Project Steering Group will see what must be delivered to meet a deadline that, on reflection, may cause them to realise that compromises are necessary.

Fig 8

Common Errors

The best way to learn about planning is to do more of it. If you’ve not tried a product-based approach before, it may take you a little time to feel confident, but keep at it. Here are some examples of common errors, beginning with those often seen in a product breakdown structure.

Fig 9

If you find the product breakdown structure too hard to comprehend or use, remember that it is simply a means of identifying the list of products to be delivered by the project. You may find it just as easy to list down the products as your team call them out, and then confirm that the list is complete. It’s a less structured approach, but if it achieves the same end, it has served its purpose.

Some errors commonly encountered in the product flow diagram are shown in figure 10.

Fig 10

The product description is equally prone to the introduction of errors. The most common fault is for them to be void of any quality criteria. Since a key reason for developing the product descriptions is to describe quality, the absence of the very section which does so is cause for concern. Here are some other examples of common errors.

Fig 11

CONCLUSION

At the start of a project, with the months stretching before you and a pile of money which has yet to be spent, it is easy to think that decisions about quality can wait. But when the time has run out and the money has been spent, quality will suddenly become uppermost in everyone’s mind; they will finally clap eyes on what it is they are about to inherit from the project. Whether or not they like what they see, it is not possible to ‘add more quality’ without investing more time or cost.

The products your project has delivered will be the only legacy that allows the benefits to be realised. If the products are of a substandard quality, the benefits may be forfeited and the project could have failed.

I hope I’ve been able to convey sufficiently well in this paper the techniques and benefits of a quality-centric approach to planning. If you can succeed in getting this far, you are more likely to have a robust foundation upon which to develop those important additional views – the time and cost plans.

Key tasks:

• invite team members to a planning workshop, requesting them to prepare in advance by identifying any deliverables they think the project must produce;
• develop a product breakdown structure (PBS) which identifies all deliverables expected from and during the project;
• if the use of a PBS is confusing, try developing a list of all of the deliverables you and the team think are needed (some example product-based plans are available for download from my author’s page on the publisher’s website);
• develop a product flow diagram (PFD) and write up product descriptions (PD) as you go, following the guidelines in this paper;
• invite Project Steering Group members to participate in a review session to confirm that there is a clear and common understanding of both the target, and the means to reach it, as described by the emerging PFD and PDs;
• despite pressure to do so, avoid the natural tendency to explore timescales and budgets;
• compare the product-based plan to the list of success measures to judge to what extent the emerging plan will meet peoples’ expectations of success.