GPM First
Chapter 14 of Project Management for Supplier Organizations (978-1-4724-1109-9) by Adrian Taggart

Project Planning for Supplier Organizations

Chapter 14

Planning is synonymous with project management; a fact evidenced by our familiarity with a myriad of sayings attesting to its benefits.

As previously stated, nothing is cheaper and quicker than getting it right first time during the implementation of a project, but getting it right first time requires time and energy to be devoted to it beforehand; that is to say, devoted to prior planning.

The need for extensive project planning is a direct consequence of the intrinsic uncertainties associated with projects and their environments, and it is the breadth and depth of the planning needed to manage a project that sets it apart from the management required of non-project work.

Compare again, the manufacture of washing machines (a routine operation) and the construction of an Olympic stadium (a project). At the commencement of the manufacture of a washing machine, the necessary manufacturing and test equipment; the specialist and experienced personnel; the tried and tested procedures and methods, are all to hand. At the commencement of the stadium project there exists only a plot of land. In the former scenario the question as to ‘how’ the machine was to be created had already been answered. This stands in stark contrast to the second scenario where a great deal of thinking is required, not only about the nature of the product but also about how it will be created and tested.

For this reason, an organization moving its products up the continuum described in Figure 1.1 (for instance, by embracing the supply of bespoke rather than standard products) will need a step-change in the breadth and depth of its planning, and a new appreciation of how important the Project Management Plan (PMP) is to successful project execution.

The planning techniques described in the lexicon of project management relate directly to Supplier Organizations (SO) as much as Owner Organizations (OO) and so no attempt is made here to explore individual planning techniques in depth. The following offers an overview of the subject, written from the perspective of a SO.

Why Plan?

The simple truth is that careful planning dramatically improves the chances of project success, but how exactly does the planning process help? In reality, planning assists subsequent implementation in a great many ways but they can be summarized under four headings (see Figure 14.1).

 
Figure 14.1 Why plan?

graphics/fig14_1.jpg

Planning Promotes (A Common) Understanding

Why do theatre troupes rehearse? They do it to increase the likelihood that their performances will be ‘alright on the night’.

It is the same for projects. By planning the project team ‘rehearse’ the project by talking through, or otherwise modelling the project, perhaps by creating drawings, schedules, budgets, procedures and the like, and one of the reasons why they do this is to increase their understanding of what is to be achieved, and how best it is to be done.

This dramatically reduces the uncertainty and hence the likelihood of destructive changes being required later in the project.

Further, if this is done in a collegiate sense, with the whole team engaged, then the deep understanding so developed is a common understanding and this is even more valuable, particularly in the context of subsequent team dynamics, collaboration and co-ordination.

For a Supplier Organization (SO) moving along the ‘Organizational Continuum’ of Figure 2.4, collaborative planning sessions will be essential for identifying and understanding what changes to the usual ways of working will be required by the project.

Promotes Buy-In

An important part of the answer to the question ‘How do I motivate my team?’ is ‘involve them in the planning’.

It is unclear why it is the case, but it most certainly is the case, that the earlier we are involved in a project the more interest, commitment and buy-in we have for it.

Look back over your career and think of all the projects you have been involved in and consider which are most dear to you. Chances are they are instances when you were involved early in the lifecycle and were able to shape and influence how the project was approached.

Team members are more likely to ‘own’ the content of the PMP, and accept the implicit challenges inherent within the time and cost estimates, when they have had an opportunity to influence their creation. Imposing a PMP on a team that had no involvement in its creation is a far less favourable situation.

Again, this is hugely relevant for any Supplier Organization (SO) embracing the project environment. Enhanced buy-in reinforces the identity of the project team (as opposed to the functional divisions), encouraging the ‘cross-function integration’ required of project work, and diminishing the ‘silo mentality’ of Functional Organizations.

Facilitates Control

Imagine receiving a project progress report stating that at week 34, two-thirds of the deliverable is complete and that expenditure was a mere £78 million. Is this good news?

The progress report clearly states what had been achieved, the elapsed time and the amount of money spent but, on its own, the information is almost completely worthless.

For it to be of use we need to have some statement of what we had expected to have achieved by this point in time, and for this amount of money. This need for a comparator is met by the plan and it is an indispensable element of control.

To put it more starkly, if a project has no appropriate plan it is out of control, by definition.

The PMP must document anticipated progress in a format, and using units, that subsequently can be replicated by measured quantities of the actual work. This provides the comparison on which control decisions are made.

Aid to Communication of ‘How’

The PMP is a written, and approved, document that explains to anyone with an interest, how the project is to be delivered. This conveys many benefits.

First and foremost, the detailed PMP is proof that planning has taken place. This provides vital reassurance to senior management and, since the actual act of writing something down requires individuals to structure, clarify and validate their thoughts, its creation improves the thinking process.

Secondly, the PMP document provides a reference point, to any relevant stakeholder, for any aspect of project execution they have an interest in. These may include the demand that it will make on internal resources, the demand it will make for cash, the timing of key events, the risk exposure it imposes, and many other important details. It also represents a significant contribution to the wealth of documented expertise within the organization. As will be discussed in Chapter 18, a well-managed archive of such documents can be a serious boon to those addressing subsequent and similar endeavours.

Thirdly, the PMP is the primary mechanism by which the project manager exerts influence over the project team. For team members it is an instruction manual, or rule book, which ensures mutual co-ordination and alignment by communicating in a clear and unambiguous way what is expected of each of them and what they can expect of the Project Manager. Certainly, the team members will have had an input into the process of creating it, but nonetheless, the final approved version is owned by the Project Manager and reflects their expectations. A well thought-out and clearly presented plan goes a very long way in promoting respect and confidence within the team, and the standing and authority of the project manager. It is a golden opportunity that can never be recreated. Conversely, recovery of reputation after a chaotic, unplanned start is very difficult.

Final Observation Regarding Planning

Readers are encouraged to note the shading used in Figure 14.1. In response to the question ‘Why plan?’ four points have been offered but two of these refer to the physical output (the PMP) whereas two of them actually refer to the process of creating the PMP. The creative act is as important (in some respects more important) than the documented output. Many of the benefits are intangible and address the soft side of project management, but this does not mean that they are unimportant; far from it, in fact.

Project Management Plan Contents

Many thousands of students of project management have been taught a certain poem by Rudyard Kipling as a mnemonic to aid the recollection of a PMP’s content. A far less high-brow mnemonic involves a sketch of the backsides of five naked rugby players sitting on a rugby post crossbar, but they both serve to advise us of the six question words: Who, What, Why, Where, When and How (conveniently abbreviated to’W5H’). Collectively they provide an excellent structure for a wide range of activities (journalist articles, police investigations, research) that includes project planning. All PMPs should answer these six question words.

Many would further suggest that ‘how’ is an even simpler summary since it is a question that contains the others (a sense reinforced by the rugby sketch described above).

The Structure of a Project Management Plan

Since all projects are unique there will be differences in the extent and detail of each PMP. Consequently, for very small projects it may be just one document, but for most projects the PMP is best thought of as an umbrella document that contains a number of elements, or individual plans.

However, although there is variation in detail, all PMP can usefully share the same broad structure and although the W5H approach offers a good overall guide and checklist, if we refer to the purpose for which the PMP is created, it is possible to adopt a more convenient structure.

It is suggested that each PMP should consist of three sections:

  • Project Background.

  • Baseline Estimates.

  • Subsidiary Management Plans.

 

Each of these are addressed under their own headings below.

Project Background

Projects are delivered by teams and a main characteristic of an effective team is that they have a clear understanding of the objectives of the team (most projects that fail, fail not because of a failure of delivery, but a failure in understanding and communicating the requirements). It is therefore appropriate to have this section of the PMP that offers a condensed version of the project rationale that will serve to orientate the team, provide context to their decision-making and enable them to offer good advice and ideas.

The essential reason ‘why’ a Supplier Organization (SO) engages in a project is the receipt of the consideration detailed in the contract with the Owner Organization (OO),1[29] but it is sometimes necessary to add to this. As discussed in Chapter 12, a particular contract may have been accepted, not on the basis of the inherent profit, but on some other strategic advantage, such as providing an entrée into a particular market. This needs to be communicated to the team and it can be done here.

It is also appropriate to orientate the Supplier Organization (SO) project team towards the objectives of the Owner Organization (OO). Although nothing written here will supersede the contents of the contract, the SO can help the OO only if the SO are aware of what the OO is trying to achieve. Such an understanding may indicate how and where the SO can be of further assistance, with extensions to contract, for example.

This section of the PMP also allows for continuity between those managing the project through the preceding phases (Marketing and Selling), and those managing it during subsequent phases. Inevitably there will have been some assumptions made during these earlier phases relating to such aspects as resources to be used, existing designs to be used, profit margin expected, major risks, constraints, dependencies on other projects, and the like. These will not feature in the contract but are important to the team executing the work.

It can also be appropriate to indicate here the priority of a project. If it is part of a portfolio of projects that share resources, it is almost inevitable there will be some form of conflict. Many such disputes between different teams can be avoided if, at the outset, senior management indicate the relative priority of the projects.

Baseline Estimates

During the lifecycle of the project, many estimates will be made of time and cost but the ‘baseline estimates’ are those that are agreed and signed off at the end of the planning process. By this they become ‘locked’ and can only be changed by formal change control protocol.2[30]

A fundamental purpose of baselines is to provide the comparator against which progress and performance can be assessed, and hence control decisions made. However, in the first instance they are essential for arranging and coordinating the activities of the team members by indicating when work will occur and for what cost.

As suggested earlier, the exact makeup of a PMP is largely within the gift of the PM but, regardless of the size, shape or nature of the project, the three core baseline estimates of scope, time and cost, need to be addressed within any satisfactory PMP.

These three aspects cannot be planned in isolation. They depend upon and influence each other in complex ways so need to be evolved in a structured and formal way. There is a coarse sequence whereby the scope is planned before the duration, which is planned before the cost though, inevitably, there will be a degree of iteration involved. For instance, if on calculating the cost of a project, the projected total is well beyond an externally imposed budget then, most likely, the solution will lie in changes to the scope, and hence an iterative loop is created.

Creation of these baselines is demanding upon the team but the reduction of uncertainty and promotion of understanding it achieves is colossal.

Inevitably, these baselines will become targets which may deviate from the parameters within the contract. For instance, the senior management of a Supplier Organization (SO) would be unhappy if a PM simply adopted the contract price as the limit of the cost baseline. Profit (their ultimate objective) is dependent upon the costs being less than the price and so the target, for control purposes, will be a lesser amount. This is addressed further in Chapter 16.

Scope baseline

This describes the content of the project. Depending upon the context, ‘scope’ can refer to the sum of the products to be delivered, or the work to be done by the project team, or both. For the purpose of the PMP we shall consider it referring to the work to be done by the team.

It is the most important of the three baselines since the other two are based upon it and errors in scope estimation will lead directly to errors in the baselines for duration and cost.3[31] Unless and until the totality of scope can be ring-fenced, estimates for duration and cost will be meaningless.

Many projects come in late or over-budget and very often this is blamed upon poor control of the execution phase. However, closer inspection often reveals adequate control but baseline estimates for duration and cost which were grossly optimistic. In turn, these estimates were poor because insufficient time and energy had been invested in fully defining the scope in the first instance, such that the scope upon which they were based was understated. Very many organizations become obsessed with the planning of duration and cost, largely encouraged by the availability of specialist computer-based tools, without first having established a robust scope baseline. As a consequence their efforts are often futile.

The format adopted for the scope baseline is a Work Breakdown Structure (WBS)4[32], sometimes supported by a WBS Dictionary.5[33] A WBS decomposes the work into discrete parcels of work, defined by a verb and a noun, known as Work Packages (Figure 8.1). These ‘manageable chunks’ of work are then passed onto team members or alternatively other Supplier Organizations (SO), who become the Work Package Owner. These Work Packages become the common currency of the project that link all the different perspectives of the project such as expenditure, responsibility (Figure 8.2), scheduling, and the like, and are instrumental in making the project manageable. This is often aided by each Work Package having a unique number, the format of which is based upon the structure of the WBS.

In identifying the Work Packages, the totality of the work scope required to meet the contract’s requirement, is defined. The imperative is that everything that needs to be done on the project fits into one of these packages, and there is nothing in any of those packages which is not necessary; there is a place for everything and everything is in its place.

When compelled to compile a WBS, and its attendant dictionary, for the first time, practitioners are often surprised at just how extensive the array of Work Packages is, and how mundane many of them are. Readers should be under no illusion as to whether this is anything but a good thing, since the reality of projects (as well as for our working life) is that we spend most of our time and money doing mundane tasks. How much of your time do you spend doing things that only you can do by dint of your expertise and how much addressing tasks such as travelling to meetings, booking a meeting room, filling in a timesheet? It is the same for a project. The technically challenging aspects usually account for a small amount of time and far more is spent on organizing deliveries, holding meetings, disposing of surplus material, compiling QC documentation, demobilizing site facilities, and the like. Creation of a WBS helps recognize these essential but mundane tasks as well as commonly overlooked work like the project management effort and the creation (and removal) of temporary works.

The beneficial effect of this is best evidenced by the step-change in the quality of estimates for time and cost made after the exercise is complete.

Although the design of the structure of the WBS (for example, whether the decomposition is based on sub-product, location, phase, etc.) is usually at the discretion of the PM, there are instances, especially for SO projects, where it is appropriate to impose a predesigned structure. Such ‘WBS Templates’ can be part of a project management method described in Chapter 4 that is imposed on similar projects within a portfolio. A particular benefit of this relates to management of historical data used for estimating purposes, as discussed in Chapter 13.

Time Baseline

Having identified the work to be done, its duration can be estimated and the project schedule, the time baseline, created. The process can become complex but follows these essential steps.

In the first instance, Work Packages are converted into activities. In an ideal world there would be a 1:1 relationship but in practice some rationalization or further decomposition of Work Packages is necessary.

Secondly, the logical sequence inherent within any project that determines the sequence of the activities must be understood and documented (a roof cannot be built until the walls are complete, which in turn cannot be built until the foundations are poured, for example). The result is a Precedence Diagram (also known as an Activity on Node diagram, or simply a ‘network’) showing the activities as boxes (nodes) connected by arrows, indicating the precedence. This exercise is not straightforward and demands a thorough understanding of the project.

Thirdly, a duration must be estimated for each activity.

Fourthly, this information allows analysis to be carried out - critical path analysis - to create a provisional schedule which identifies the shortest period of time the work can be completed within; the sequence of activities that determine this period; and also the amount of float each activity has within that schedule (the amount the activity can be delayed or extended before it impacts upon the rest of the schedule). This analysis can become quite involved and for this reason most practitioners choose to take advantage of one of the myriad of specialist software packages designed for project scheduling.

In reality, this provisional schedule is almost useless in predicting completion dates. This is because there is an unspoken assumption that all resources required will be available as and when required. Of course, this is not the case for real organizations where the availability of resources is severely limited. Accordingly, any meaningful schedule needs to be based on the interplay between the project’s demand and the organization’s provision of resources. This is such a crucial topic for every Supplier Organization (SO) that it is the subject of a dedicated chapter (Chapter 15).

Should the projected end date be beyond the requirements of the contract (or indeed any other internal SO target) then the scope and time plans will need to be iterated.

Cost Baseline

Projects consume resources and it is the quantity of these resources so consumed that is referred to as the cost of the project. For convenience the units used are usually financial (pounds, dollars, euros) since most resources can be expressed as a financial cost.

Some commentators, i.e. the APM in the UK, refer to two different types of resources, reusable and replenishable.

Replenishable resources are sand, wood, concrete, fuel, paper; things that can be used once and afterwards need to be replaced. They are the ‘bought out items’ that incur a one-off fixed cost. Once a WBS is in place an idea of what is to be bought can be drawn up, and once a schedule is available the timing of the purchase, and hence incurring of cost, can be estimated.

Reusable resources are people and machinery, things that can work hard today but then work hard again tomorrow, and they incur costs on the basis of a rate such at £ per hr, $ per day, euros per month. Accordingly, their total cost cannot be estimated before establishing the duration of their engagement (hence the importance of the planning scope before time, before cost).

The connection to the schedule allows the anticipated accumulation of cost6[34] to be calculated against time. A graph of cumulative cost against time is the result. By this, rather than simply expressing the cost as a total figure, it can be expressed as a profile. As discussed earlier, the shape of this profile has important implications for the management of aspects such as risk and cash flow.

Other Baselines

‘Baselines’ are a statement of expected performance that can be used as the basis of co-ordination and control, and it can be appropriate to establish a baseline for other aspects of the project. Consider the following:

  • Payment – SO must submit invoices and expedite payment in a timely manner.

  • Quality – A statement of what is to be expected in terms of performance of the final deliverable and indeed interim deliverables that are available at the end of each Work Package or phase.

  • Risk – Many project teams maintain a ‘Risk Register’. This is a structured list of the risks that the project is exposed to and ancillary data such as response strategies and owners. The label ‘baseline’ is appropriate since it can be used as a comparator to show how risk is being managed, and reduced, during the lifecycle of the project. It is unlike the previous baselines in that it is not an early statement of expectation since the expectation is that at the end of the project all risks will have been eliminated.

  • Assumptions - Similar to a risk register, a list of assumptions can be used to facilitate control by indicating how the number of assumptions reduces during the life of the project. As such it offers some tangible evidence of a reduction in uncertainty.

 

Subsidiary Management Plans

A subsidiary management plan describes how the project team is to manage a specific facet of a project. They are processes and procedures and as well as identifying techniques to be used, they may also establish such things as who is responsible for what. The W5H approach is highly relevant to their content.

Conveniently, they can be titled ‘ Management Plan’ whereby the

facet of the project that it addresses is inserted as the first word. There can be a subsidiary management plan for any facets deemed worthy but the following are typical:

Requirements

Scope

Schedule

Cost

Quality

Risk

Configuration

Communication

Change

Procurement

Health and Safety

Environment

Some of these, such as cost, can be the subject of both a baseline and a subsidiary management plan but the two documents are very different in purpose and content. The cost baseline will be the documented estimate of cost, whereas the latter will instruct the project team about the ways things are to be done; assisting individual team members and ensuring a common and known approach. For instance, the Cost Management Plan may contain definitions of the different types of cost (accruals, committed costs actual costs); tolerances for different classifications of estimate; protocols for financial management (e.g. profit will only be taken once 50 per cent of the contract value has been delivered); templates for formal documents (spreadsheets or other financial reporting tools to be used).

The number and type of such subsidiary plans depends not just upon the project itself but the context in which it is delivered. For example, a Supplier Organization (SO) delivering a portfolio of similar projects may require the same facet of each project to be managed in an identical way. In such instances each project simply adopts the ‘house standard’7[35] as the relevant subsidiary management plan. For example, the SO may have an ‘approved supplier’ list and established ‘call-off’ contracts that impose constraints on how individual project teams (and their project manager) are to behave in relation to procurement. These are adopted by each project as their own Procurement Management Plan.

Another common example relates to quality management, especially if the SO in question is accredited to a formal standard such as the ISO 9000 series. In such instances the organization’s accredited quality manual becomes the Quality Management Plan for each of their projects.

A caveat is appropriate here. Since each project is unique, and for the SO the minimum requirement is ultimately dictated by the contract, there may be instances where the ‘house standard’ is not sufficient or appropriate. Accordingly, when an SO embarks on a new project the project manager (or salesperson) will review the ‘house standards’ against the contract requirement before either adopting them, or else drafting a new plan specific to their project.

Planning and the Project Management Plan Through the Project

Planning is a time-consuming activity and any Supplier Organization (SO) will be reluctant to start it before it has received a clear commitment from the relevant Owner Organization (OO) in the form of a contract. However, in very many instances the SO must engage in a significant planning effort precontract, for reasons of risk mitigation.

As discussed earlier, the Decision Gates of ‘Bid/No Bid’ and ‘Make or Accept/Reject Offer’ are vitally important here and these decisions are informed by an estimate of the likely cost and duration of the work.

If these estimates can be reached with sufficient accuracy using ‘top-down’ estimating techniques then significant amounts of the cost of planning can be deferred (or, in the case of unsuccessful bids, avoided). However, at some point it will become necessary to have very precise estimates (e.g. a ‘Definitive Estimate’ with 90 per cent confidence limits at +10 per cent/-5 per cent) and for bespoke items this level of accuracy, most often, can only be achieved with the detailed ‘bottom-up’ techniques associated with the WBS and precedence diagrams discussed above.

Accordingly, within the SO lifecycle, detailed planning may well first be done to facilitate estimating and reduce the risk of underbidding a contract, rather than as a prelude to project execution.

Even if this is the case, it is most likely that much more detailed planning will occur post-contract (not least to secure the soft benefits of the planning process described earlier). There is merit in the SO imposing a common planning approach such that plans started by the marketing team can be evolved through the entire SO lifecycle, rather than starting from scratch at the commencement of each phase.

Such an approach would be an intrinsic part of any project management method adopted by the SO.

Submit your own content for publication

Submit content