CHAPTER 1

Planning a Project

Let’s be clear. This book is about project planning. Planning is used in many other circumstances—operational management, strategy development, work packages, defect fixing, product development, and even personal to-dos, but projects are special management endeavors. Many techniques from general management are relevant and can be adapted readily enough, but there are differences. These differences can trap the unsuspecting, inexperienced project manager, who will often confuse the scheduling of task and activities with the planning of projects.

So, first things first, let’s address these questions. What’s a project? Why do you need to plan?

Planning to Manage Uncertainty

Projects are often characterized as being unique, or at least ‘relatively unique.’ They may do what has been done before, but not by this team, or not in this way, and this means project managers must actively ­manage uncertainty. This is captured in our definition of a project, which is adapted from Turner (1999, 2003).

Project planning is the way we manage uncertainty. A plan is a view of the future, created from the state of knowledge at that time, and ­supported and extended by the inferences that experience and the underpinning models provide. As knowledge increases that view may change and a new route to the future must be captured by carrying out a re-plan.

A plan that documents exactly what everyone already knows really is a waste of everyone’s time, no matter how beautifully written. It is the worst form of bureaucracy, with nothing new learned and nothing valuable achieved. A good plan makes clear what is uncertain and why, and what to do about it. What is known and what is not should be reflected in the very structure of the plan.

What is certain is why the project was set up. We also know what the stakeholders’ regard as a good outcome. What is less certain is what the right tactics to adopt might be. These are uncertain because currently unknown events, events in the future, will influence them; whether it is by time passing, from the impact of risks, or higher than expected levels of productivity of a process.

Planning Connects Conditions of Success to Delivery

The other fundamental characteristic of projects we see reflected in the Turner definition is that projects are conducted within a set of ­constraints and create a changed future state that delivers beneficial outcomes.

The constraints and beneficial outcomes are an expression by the ­client and other stakeholders of the conditions of success for the ­project—and to plan successfully, you must know what counts as a success. ­Modern ­project management has replaced the earlier time, cost, and quality ­criteria with four conditions that have to be satisfied. Shenhar et al. (1997) set them out:

• Project efficiency
• Impact on the customer
• Direct business and organizational success
• Preparing for the future

The first factor neatly bundles up earlier ideas about traditional project management disciplines. The second and third reflect the realization that unless the project returns something of recognized value, its performance in terms of delivering outputs is worthless. The fourth focuses on what it is that the stakeholders have to bring to the party.

These new, tougher conditions for project success lead to the need for two key actions when planning a project. The first is to establish the ­‘mission’ of the project—why it’s being done, and what ‘good looks like.’ The other is how best to organize people, processes, and products to deliver that mission.

The Goal-Oriented Plan

If you are going on a journey, it’s a good idea to know where you are going and how to recognize when you’ve got there. Might sound obvious, but many projects fail even that simple test. You really do need to know:

• Purpose of the project: the problem or opportunity it is addressing
• Value of the project: why is it worth doing—and to whom?
• Objective: what ‘good looks like’—how to know the project has completed successfully
• Scope: what the project is expected to deliver in terms of physical things
• Critical success factors (CSFs): what has to be in place for ­success
• Risks: what the main threats are to the success of the project

These are six distinct and different aspects of the project, and failure is much more likely if one or more of them is not known, or, which is more common, they are conflated and confused with each other. The usual culprit is a statement that purports to be an objective, but which is, in fact, a hotchpotch of scope statements, activities, benefits and other outcomes. Instead of a scalpel, the project manager has a club, with no way to adequately judge whether the project actions link to the project’s purpose.

CITI’s Project Mission ModelTM (Figure 1.1) was developed to structure the way stakeholders, project managers, and project management offices go about this first part of planning.

The Project Mission ModelTM explicitly distinguishes between the six perspectives. (Impacts and benefits are two ways of setting out the value, and count as one.) The combination of the views related one-to-another forms a holistic description of the project.

Figure 1.1 The project mission model™

As only key stakeholders can answer the first three questions, the early workshops should be run for these people. The project manager role is primarily an interested observer!

The Problem

Why is it being done? This first question is the proper starting point for any project. The answer should capture the purpose of the project.

The Benefits

Why is it worth doing? This is also a why question, and there is always a subtext to it, which is: To whom is it valuable? Benefits are measurable additions of value to the organization.

The Objective

What does success looks like? The response to this question should be a ­single statement describing the project’s completion state, framed in terms of changed organizational (and possibly personal) capabilities. It should directly address the problem or opportunity.

The next three questions are the focus of workshops run later during project initiation with the project team and technical experts. ­Stakeholders are always welcome but rarely attend.

Products

What has to be produced? This is the central question for the project team. What is the project to build or buy to achieve the objective and cause the required impacts? At this level of planning, the focus is on the principal persistent products.

It is worth noting that the objective is not the only source to consider when identifying products or outputs. In total, there are four sources, and together they establish the scope of the project. Inspection of Figure 1.1 shows four arrowheads pointing to the ‘PRODUCTS’ box.

In many projects, CSFs and the management of risk can generate a substantial number of additional products, as can the need to ­trigger required changes in behavior. Many of these outputs are temporary ­products but are still essential to the delivery of a successful project.

Risks

What could cause costs to rise or the value of benefits to fall? At this level of planning, the focus is on risks that should be exposed, shared, and agreed with the stakeholders. Risk analysis features as a continuing thread in all the planning. Even at this early stage, the risks identified should be listed in the project risk log.

Critical Success Factors

What has to be right? The third question is often the hardest to answer. As we will see, it has a profound influence on the conduct of the project and its planning. CSFs are usually derivative and can be identified by analysis of the assertions made in the objective and benefit statements. They are, however, ultimately determined and owned by the project stakeholders.

The Project Mission

The six views have been captured. What the world is to be like at the end of the project is understood, and why it is important to succeed, as well as what it is worth and to whom. In most cases, the basis for the solution is also agreed. All there is left to do is to ensure that the money and effort expended is structured, sequenced, and demonstrably connected back to the desired outcomes. So the next stage is to work out how to provide the outputs, what tasks to perform, by whom, and in what order.

Figure 1.2 shows an amended Project Mission ModelTM that takes into account the factors needed to convert the strategic aspects of the project into a tactical plan. There is a crucial link—a bridge—maintained between the outputs and structuring the project effort.

Figure 1.2 The full project mission model™

The bridge makes it possible for a plan to serve the stakeholder ­community of the project and the project team. If the link is broken project execution becomes detached from the purpose, and expectation management is blinded. What occurs over the bridge is the translation of what is wanted into how to get it.

You will have noticed the Project Mission ModelTM is now framed by two fundamental planning elements. One is assumptions. Plans are very vulnerable to the set of assumptions made. When an assumption proves to be invalid, the project manager has to re-plan using different ­assumptions, and the stakeholders need to be made aware of what has happened.

The other is constraints. We discuss these next as they play a pivotal role in the planning process, and will meet them again many times in this book.

The Role of Constraints and Critical Success Factors

CSFs set out what must be in place for the project to be a success by the stakeholders. The other conditions for success are identified by the ­project’s constraints. Constraints feature in Turner’s definition of a project quoted earlier, and in the PMI’s definition, published in 2017:

A project constraint is a condition that any solution must satisfy and so defines what a successful solution looks like.

Seven frequently encountered constraints (and CSFs) are listed as ­follows. There are, of course, others.

Temporal: some projects must be completed by an end-date determined externally and cannot be changed. Typical examples are the ­legislative programs for financial regulation such as Basel III (2011) and Kings III (2009).

Budget: these projects are limited explicitly by a capped fund. Projects funded by granting bodies are usually cost-constrained in this way.

Resources: a close cousin to budget constraint, but the impact and planning response is markedly different in these projects. Very often, the problem is to do with not having access to a scarce and non-­replaceable resource; for example, world-class research scientists.

Mission-critical: when what a project delivers must meet specific ‘no-fail’ criteria. Examples of this type of project are: NASA staffed launches, nuclear industry projects, and irreversible business ­process changes.

Stakeholder-intensive: when the success of a project is determined by inviolable, non-negotiable acceptance criteria (ACs) set by the stakeholders. Examples of such projects are the Scottish Parliament building and the Integrated Rapid Transit program in Cape Town.

Innovation/research: the success of these projects is dependent on the delivery of outputs that trigger outcomes that are not explicitly anticipated—including the identification of ‘blind alleys.’ The story of the accidental invention of ‘post-it notes’ and Viagra are both well-known examples. Many modern research projects adopt this approach.

Operational: these projects can only succeed if the operational performance of an ongoing enterprise continues without disruption. This constraint often requires highly responsive planning. Classic examples are enhancements to products and processes used in hospital and financial systems.

The Delivery Plan

The project mission is agreed. It may change under the pressure of technical infeasibility, but the pre-requisites for planning how to deliver are now in place. So what’s next to do? Is there a process? How do you go about structuring people, processes, and products to deliver the mission? Well, there is a process. It has seven steps, and as you will see in the later ­chapters the sequence varies to reflect the hierarchy of the constraints, but the steps are the same. The standard sequence of steps is easy to ­remember. It is ‘C’ followed by an alphabetic stammer:

C-Constraints

P-Products (outputs)

P-Processes (tasks)

R-Resources

R-Risks

S-Schedule

S-Stakeholders

Steps from Constraints to Resources

Once you have determined the constraints, the steps to completing the project plan are:

  First, determine the…

Products—the outputs you need to achieve the outcomes: Then look at the...

Processes—tasks that will get you these products: This will suggest the types of...

Resources—capabilities needed for the tasks: These three aspects each can create...

Risks—that threaten the achievement of the objective: These four integrate into a...

Schedule—activities with resources sequenced: And all together must meet...

Stakeholder—expectations: It is their view that determines whether a plan is acceptable.

There is a temptation to see planning as being a top-down process, done in a single pass. This is most decidedly not the case! As Figure 1.3 shows, each step can cause you to go back, to revisit choices and ­decisions made higher up the chain. The two immovable things—the only two things project managers cannot change—are the constraints and the objective. They have to get permission from the sponsor and other key stakeholders to change either of those otherwise they are in genuine ­danger of damaging that crucial link, the bridge, between the Project Mission ModelTM and the executable plan.

Figure 1.3 The basic planning steps and their associated knowledge areas

Step one establishes the ‘box’ in which the plan has validity—what are the constraints the project, and hence the plan, must work within. Which constraint is the most important may not immediately be apparent. Sponsors and stakeholders are not always clear in their own minds as to what is truly important. However, there is always a hierarchy. Sometimes the only way to establish what the real constraints are is by engaging with the stakeholders during planning, by posing situations and seeing how issues are resolved.

The next step involves elaborating on the outputs or products. You should avoid identifying the processes at this stage. Projects are a vehicle for producing products—or outputs. Discussing tasks before knowing what the outputs are is usually a grievous error. So list the outputs! Once you have a list of the set of products, you will have definitively established the scope of the project—an excellent basis for planning.

Start by agreeing what the principal persistent products (those ­outputs that will remain after the project has closed) should be. This will be, for the most part, what the project must deliver to meet its objectives. This list can be developed as a product breakdown structure (PBS), see Figure 1.4.

Figure 1.4 A product breakdown structure (PBS)

Once you’ve set out the outputs, and this may involve several iterations, it is now appropriate to define the tasks (methods, techniques, and tools) to acquire (create or purchase) each product. As you are doing so, it is also valuable to establish the level of quality—the acceptance ­criteria (ACs)—that the stakeholders expect. The ACs are usually negotiable, unlike ­constraints and CSFs. By establishing the ACs now, the likely processes to be used can be determined as well as the likelihood and type of defects to expect.

The task list, which can be organized into a logical work breakdown structure (WBS), is not yet sequenced. Best practice is to keep the PBS and the WBS as distinct elements, as is strongly encouraged by PRINCE2®. However, many methods and the PMI allow or even ­promote both ­products and tasks to be defined in a single structure, confusingly called a WBS.

Once the WBS is created, estimates of skill and likely resource demand can be made. These, too, should reflect the level of uncertainty and be provided as ranged estimates. The effort is derivative of the ­numbers and size of each product set out in the PBS. The effort demand can be ­modeled in yet another breakdown structure—one that reflects the resource structure of the organization—an OBS. The choice of process inevitably dictates the kind of resource you need—the skill sets necessary to carry out the process.

Steps from Risks to Stakeholders

So, we have now considered ‘CPPR’—the constraints, products, processes, and resources. The next ‘R’ is the set of risks. As you step through the planning sequence you will identify risks: risks from the products (level of performance), risks from the processes chosen (types of defects arising), and risks from the resources (capability and productivity) you are going to use.

Now, and only now, are you in a position to devise the schedule—the sequence with which your project is going to order the tasks and activities, and when to engage the various resources. Without a doubt, the appropriate scheduling of effort time within calendar time is what distinguishes good project managers from less capable ones—it is a fundamental skill. It is also, however, secondary to and derivative of the planning process.

Typically, schedules are based on the WBS, and it is good practice to create work packages—sets of tasks with their resources—for each primary deliverable. With this approach, it is vital that dates in those sub-schedules are coordinated with the master schedule, and that the master schedule is correlated with the business milestones within the overall project plan.

So there you have it. All the technical aspects of planning set out in a step-by-step process. However, we are not yet finished! There is one more ‘S’ to factor into the plan—and it can be a game-changer.

This last ‘S’ is the stakeholders. The crucial test the plan must survive is whether the various solutions, trade-offs and tactical considerations made, meet the stakeholders’ needs and expectations. If it does, you have a viable plan; if it does not, it will have to be changed.

This final point has an enormous impact on the approach to planning. The plan is not yours. It is not primarily for the project manager, it is for the stakeholders, and in particular for the needs of those stakeholders that form the governance group for the project. This has all sorts of consequences, from determining the plan’s contents, the appropriate format, to the level of detail it should go to, and the communication needs it has to address.

So, that’s nearly it for planning many straightforward projects. There is just one more topic to discuss. How does the hierarchy of constraints affect the planning process?

Hierarchy of Constraints

Though project managers are often presented with a set of constraints that they are informed they must meet, it turns out that, within a given project, some constraints are more important than others. This difference in ranking is one of the most important factors when deciding how to plan. Table 1.1 illustrates four common hierarchies of constraints found in projects.

When the type of constraint at the top of the hierarchy is different, the plans—and the planning tools to be used—differ. Plans drawn up under one hierarchy are not readily interchangeable with one drawn up under a different one.

In the following chapters we explore stories and insights for each of the seven frequently encountered constraints (and CSFs):

• Temporal
• Budget
• Resources
• Mission-critical
• Stakeholder-intensive
• Innovation/research
• Operational

There are, of course, others! And that matters because the reality is that project characteristics on complex projects do change during the project. A project may initially be driven by a hard deadline, but then issues arise that can only be resolved by acquiring scarce resources and the characteristics of the project change fundamentally, and a re-plan is forced.

During the 1980s, we were involved in research into what makes project managers successful. You can read more about this in The Lost Art of Planning Projects (Worsley and Worsley 2019). What seems to be the distinguishing characteristics of high performing project managers is that they are excellent project diagnosticians, and they have an extensive toolkit to pull upon when deciding what combination of approaches will be right for any particular project. They understand the impact on the hierarchy of constraints on their projects and adapt appropriately to the different challenges they present.

We hope the insights from these different project types inspire reflections on how you should approach your project planning. At the end of each chapter, we reflect on what’s been discussed and pose questions for you to consider in light of your own experiences, your projects, and what makes them different. Do take time to give these some thought or better still discuss with project colleagues back in your organization.

Reflections

This chapter introduces two fundamental models: one to establish the strategic aspects of a project plan—the project mission—the second, the tactical concerns. It also set outs a structure for a plan that reflects the different levels of volatility.

Consider for your projects and from your own experiences:

1. How do you go about developing a plan? Is there a process you can share with others? Do you use a template to guide you? What advantages does that give? Are there any disadvantages?
2. How do you record time-dependent information used in planning, such as issues, risks, and decisions?
3. When sponsors ask for the status of the project, what are they asking for, and what do you give them?
4. How frequently do you review your plan? Your logs? Your schedule? Do you and project team members use the schedule to direct what they do on a day-to-day basis?
5. During development, do you discuss your plans, with the project office? The sponsor? The stakeholders? Colleague project managers? Your team? What aspects do you share, and why?