Nutshell: Planning for project success

Project planning is where the project scope is brought to life with a more detailed plan.

Not all projects need to start with great fanfare or the cutting of a ribbon, but they all need a kick-off meeting – a moment from when the work officially begins. It’s a time to celebrate all the hard work done so far and to dispatch the project team and stakeholders feeling focused, excited and confident that all is on track for project success.

But hold the horses; there’s plenty of work to do before then. A kick-off meeting is the culmination of the second project management phase: build-up and planning. This is where the scoping document is brought to life with more detailed plans, schedules and costs: estimates are firmed up; schedules and budgets agreed; risks identified and plans put in place to manage or mitigate them. It’s when the project team is assembled, key tasks are identified and roles and responsibilities are clarified.

In this Nutshell, we’ll look at some key elements that need to be in place before a project can start in earnest:

1. Tasks: What are the main tasks and sub-tasks that make up this project?
   

2. Team: What expertise is needed to deliver the tasks? Who’s responsible for what and how will the team work together? 

3. Time: A schedule for the major delivery milestones and deadlines and, crucially, which tasks are dependent on other tasks being completed first. 

4. Cost: Crucially, how much is all this going to cost? What’s our budget?

We’ll also be looking in detail at some of the tools that can make the job more manageable.

On the importance of planning

Managing projects to time and budget is hugely important. We all want projects to succeed; our reputation depends on it. To achieve that we need a plan, using a range of techniques and tools to work out what needs to be done and in what order, how much everything will cost and how we’ll manage project risks.

Plans, of course, often need to change along the way; as boxer Mike Tyson summarised so prosaically: “Everyone has a plan until they get punched in the mouth”. That’s not to say that we should give up on planning entirely, but we must remain adaptable as circumstances shift. Having the right tools to manage this flexibility will help.

To a large degree, the plan draws on the work breakdown structure (WBS) that was prepared in the scoping phase. A WBS will have identified the key tasks we need to carry out to deliver a project; this is the time to review the WBS and make sure all necessary tasks and sub-tasks have been included.

Then it’s time to assemble our project team, ready for those tasks to be allocated.

Project teams

A crucial element of any project plan is making sure we have the right people with the right skills charged with its delivery. They might be colleagues from within your team, people from other areas of the organisation, outside contractors and freelancers, domain experts or a mix of all of them.

Project teams can be organised in a variety of ways. In many cases, we’ll need to factor in work on routine operations outside specific projects, which can be a tricky balancing act.

With that in mind, the two most common team structures are:

Purpose-built project teams

Purpose-built project teams are created when a group of people are brought together to work solely on a specific project operating under the direct control of a project manager. When the project is complete, the team will be disbanded.

Purpose-built teams tend to be most common when projects are large or complex and likely to last a long time. They benefit from having a single point or focus and purpose, which helps to build commitment and motivation. Reporting lines are clear, communication is easier and decisions can be made and implemented quickly. Having autonomy over dedicated resources can also avoid clashes over priorities.

There are also some downsides. Unless the team is big, the project might be compromised if a key skill set is missing for any reason (for example, if someone leaves). Bespoke project teams might fall prey to silo mentality, failing to share spare resources elsewhere or discuss problems and issues more widely.

There’s also the matter of what happens at the end of a finite project. Arrangements for post-project support will need to be made – and communicated – at the project’s outset. And people hired specifically for a project will need to be recruited with the project’s specific schedule in mind.

Functional matrix

A functional matrix is where project teams comprise a range of people from different functional groups within an organisation. For example, a team charged with delivering a new IT system will include not only representatives from an IT department, but also key users from a range of functions.

The project manager has responsibility for a project, and they co-ordinate people from different functional groups to work on that project, while project team members are still under the direct authority of their line managers. The organisation’s normal operations continue alongside the project and individuals may work simultaneously work on more than one project.

The matrix approach to team structure offers organisational flexibility and supports post-project support. As such, it’s best suited for organisations dealing with several simultaneous, smaller projects. It allows people to join a range of projects and acquire new skills alongside their day job. People with particular skills can be pulled into the project as needed, and there’s a greater likelihood that spare resources will be re-allocated outside the team.

However, having people work under both their line manager and a project manager can be a recipe for ambiguity, conflicting priorities and divided loyalties. Team members may not feel the same sense of team spirit and purpose as in purpose-built teams. Communication can be more difficult and priorities might not always be clear.

Both types of team structure can be highly effective depending on the type of project and the organisation. They can also be used in hybrid. This is where organisations generally operate a matrix structure, but also set up purpose-built teams for certain projects when necessary. This can offer the best of both worlds.

And whatever team structure we opt for, we need to bear in mind the characteristics that make an effective team, building in a range of skills and expertise, and creating the conditions that support maximum team performance.  

Roles, remits and responsibilities

Once we have our team in place, project roles and responsibilities need to be clearly assigned.

This is where a RACI (or responsibility assignment) Matrix can help. The matrix doesn't just cover team members themselves, but can also cover other stakeholders. It outlines the levels of ownership and input that each person has. It can be particularly useful for cross-functional projects, virtual project teams or when delegating major pieces of work.

RACI stands for:

Responsible: the person who carries out the work on a particular aspect of the project or task.

Accountable (or Approver): the person who approves the work delivered by the Responsible person; they’re held accountable for its successful completion. 

Consulted: the people whose input is necessary to ensure the task or project is successful, though they’re not directly accountable for the results.

Informed: people who, while not consulted directly about the task or project, still need to know about it.

The project sponsor or manager usually creates the matrix, although a draft is usually shared with the wider team. This involves:

• identifying a list of key tasks or activities, in the order they need to be completed.
• identifying team members and other stakeholders who are involved.
• for each task, allocating a RACI rating (R, A, C or I) to each person.

It’s recommended that only one person is responsible and one person accountable for each task, although the same person can, of course, be responsible for more than one activity in the project as a whole.

The RACI technique provides clarity about who is responsible for delivering the key stages of a project, and helps set stakeholder expectations. It helps prevent confusion over project roles and saves duplication of effort – a common issue with this type of work.

It can also give an insight into things that might slow us down: if we have too many Cs, for example, having to consult too often might get in the way. We also need to remember to revisit the matrix regularly as a project progresses or if team membership changes.

A simple RACI Matrix

Setting schedules

Schedules can be slippery things. Projects need realistic schedules that take into account the constraints of our iron triangle variables of quality, cost and time.

There are, though, plenty of things that can get in the way, not least the fact that we humans are terrible at estimating how long it’ll take to get things done, a tendency termed planning fallacy by psychologist, Daniel Kahneman. Whether the project involves restocking the stationery cupboard or restocking the nuclear arsenal, things always take a lot longer than they first appear.

A much better strategy in terms of estimating time (and money) is to use Kahneman’s reference class forecasting. This means examining previous projects of a similar nature and using them as a guide to how long things will take (and cost) rather than planning from scratch.

Once we have a handle on our scheduling shortcomings, we’re ready to look at the interrelationships between tasks, how dependent they are on each other.

Dependencies

Identifying the dependencies between project tasks is a critical part of project planning. A good starting point is to create a dependencies table, showing dependencies in a straightforward, logical summary.

The table lists the tasks, how long each task will take, and notes which tasks need to be finished before others can begin. The aim is to create a clear sequential list of the tasks that need to be done. For example, it can help to identify what has to be done before another task can start (a predecessors table).

The key thing to remember when developing a dependencies table is to watch out for too many dependencies. It’s best to restrict what needs to be done before other tasks can start to the absolute essentials. Otherwise, there’s a danger we’ll be left in dependency limbo.

Taskboarding

Taskboarding is a visual methodology used to identify the sequential order of things in a project: what needs to be done and in what order. It’s a clear, easy way of sorting out the blocks of work that need to be done and which block must be completed before others can start.  

Taskboarding follows a simple two-step process:

1. Brainstorm what the activities are and jot them down on sticky notes, then
2. Rearrange them in order by asking “What needs to be completed before we can start something else?”
   

In this way, all of the necessary tasks required can be captured in sequence.

Developing a network diagram

A network diagram is another visual way of showing how tasks are interrelated, showing which need to be sequential and which can happen at the same time. Networks begin with a start box and finish with an end box. We can draw up the network by using the information in the dependencies table.

Here’s how to draw a network diagram:

• Draw a 'start' box at the left of the page.

• Show all of the activities that depend on nothing else coming out of the start box. 

• Continue to add activities by drawing boxes to the right of the preceding tasks.

• Once all activities are shown, draw them together to an 'end' box.

Be sure to look out for any activities that aren’t connected to any others, or that aren’t connected to the 'end' box. Remember to refer back to the dependencies table as well to ensure that the tasks have been logically worked out so we can see what’s before and after. Finally, take care to ensure that all connections are displayed on the network.

We can illustrate how a predecessors table and network diagram can work together by looking at the stages we need to go through to make a lasagne:

Making a lasagne: predecessors table

Critical Path Method

The Critical Path Method (CPM) is a key planning and control methodology used in project management. Developed in the 1950s by Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand, it traces its roots back to a competing methodology: Program Evaluation Review Technique (PERT), developed by the US Navy.

This in turn can trace its roots back to the Manhattan Project, the allied project to develop the atomic bomb in the 1940s. Given that the military operates in a highly structured fashion, it should come as no surprise that this is where the roots of CPM lie.

CPM is a useful method for estimating the total time needed to complete tasks and identifying which tasks have to be completed on time if the whole project is to stay on schedule. The analysis uses a WBS as its starting point and expands on the tasks to include their duration and a start and finish time. Task durations can be drawn from the dependencies table.

Applying CPM follows a clear six-step process:

1. Specify each activity using a WBS.

2. Sequence the activities to understand the dependencies that link each activity.

3. Draw a network diagram to create a visual representation that links activities.

4. Estimate activity durations by assigning a specific time frame (good and bad, as the times are fixed but not flexible).

5. Identify the critical path, which is the longest path through the network (there can be more than one). Any extension to any activity will impact this critical path.

6. Update to show progress: the critical path is as much for monitoring as planning.

   
   

The critical path also calculates the earliest and latest possible start times for activities. Armed with this we can identify where we have float (often called slack), which is the ability to see where we can vary the start time of an activity without affecting the completion of the project.

Using this example, we can see that the critical path is the time it takes to cook and drain the pasta. If this takes longer than planned, we’ll be delayed layering the lasagne. If we can save time here, we can layer the lasagne sooner.

CPM is a very strong way of understanding the logic and sequence of project tasks and estimating how long they will take.

Gantt charts

Named after US engineer Henry Gantt who first designed his chart in the early 20th century, a Gantt chart is one of the most commonly used project planning tools. It gives a clear, visual overview of how a project is progressing and offers a timeline view of a project that can help us to plan, tracking individual project tasks, dependencies, resources, and work still to be done.

A Gantt chart comprises two axes: task (vertical) and time (horizontal). Bars represent tasks, and can show dependent tasks and predecessors. It also identifies the resources needed to complete each task.

The starting point for creating a Gantt chart is listing all the tasks that need to be completed to finish the project. Alongside each task, the chart tracks the earliest date each activity can be started, how long each task is estimated to take and whether any of them are dependent on the completion of other activities. It’s a brilliant visual summary of the scheduling that needs to underpin any project plan (although we should bear in mind the cautionary words of project expert Jasper Polak:  “No Gantt chart has ever survived contact with reality.”)

Looking after the pennies

So, tasks, team roles and responsibilities, and time have been assigned and defined, but what about budgeting?

A budget is a plan for allocating resources. It’s a statement of how much money will be allocated to different items or activities to be undertaken. It also serves as a tool to monitor planned activity.

Creating and using a budget involves several stages. A budgeting cycle might look like this:

Stage 1: Establish the aim

What’s going to be achieved by creating the budget?

Stage 2: Decide on the type of budget 

This is determined by the type of project; will it require long-term funding, or will it be completed within a fixed period?

Stage 3: Plan and allocate 

The scope of the project needs to be set out with all tasks divided into cost groups. The cost of each task is identified, data is gathered and decisions are made on how to distribute funds over different areas of the project.

Stage 4: Control and monitor

The project manager will track the budget throughout the project to determine if the project is performing to plan.

Stage 5: Evaluate process

This occurs at the end of a project to determine if the budgeting process was a success and, if so, why. Lessons learnt can then be applied to future projects.

Estimating costs

Having defined the budgeting process, we still need to do some cost estimating. Two different methods of estimating project costs and establishing budgets are generally used:

Top-down budgeting: This is where a budget for overall project cost is set, and then broken down into budgets for specific activities.

Bottom-up budgeting: This is where the project team calculates the resources they’ll need to complete the project and cost each element individually. These costs are aggregated and administrative costs added to establish an overall budget for the project.

Bottom-up budgeting tends to be more accurate, as the budget plan includes individual tasks and resource requirements. However, requirements can still be overstated.

Sometimes budgets are estimated by using the collective experience of different estimators. If the project is similar to a previous one then this method can be very accurate. However, if there’s no such similar project, or the external conditions have changed, bottom-up budgeting will be more helpful.

Either way, the budget is normally broken down into the component parts of the project (for example, people costs, raw materials, any travel or other administrative costs) or there is a specified budget for each project phase. Budget categories and codes will usually be allocated to help with tracking and monitoring.

Cost management

This involves setting funding limits and also stating how the expenditure will take place. It’s crucial that funds are available when they’re needed, but it’s also important that no money is wasted or we suffer from unauthorised increases to the budget.

Some changes in expenditure are unavoidable or unforeseen. But, by tracking the budget carefully, these can be spotted early on and alterations can be made to the plan. Effective cost management means that there are no surprises at the end of the project.

Project budgeting involves risks but these can be reduced by including a sum for contingency expenditure. This might mean factoring in 5-10% of the estimated cost, probably in a range from optimistic to pessimistic.

Tracking and monitoring

Budgets are plans, and plans can easily go awry so it’s important to regularly monitor activities by collecting and reporting on expenditure data regularly. Measuring actual expenditure against budget will show any variances between expected and actual expenditure.

These can be positive or negative. Tracking variances will give us an early warning by highlighting the areas where expenditure is going off-piste. Adverse variances show not only that there’s a problem but also how big a problem is. The cause can then be identified and remedial action taken.

Get ready for kick-off

With a plan in place, it’s time to roll up our metaphorical sleeves and put it into action. And there’s no better place to start than a kick-off meeting. This will bring together the project team and any key stakeholders.

It’s an opportunity to get the right people in the right room at the right time to make sure everyone’s aligned and to discuss everything that will guide the project to success. 

A kick-off meeting is also an opportunity to celebrate all the hard work done so far and to dispatch the project team and stakeholders feeling focused, excited and confident that everything is on track for project success.

There’s a lot to contend with in the planning phase: we’re literally bringing the scope to life and putting flesh on its bones. But it’s crucial for project success.

Given the importance of planning, it’s no surprise that the Army has an acronym for it and one that we can do well to remember – the seven Ps: prior planning and preparation prevents pretty poor performance. 

No pressure there, then.

​​Test your understanding

• Identify two advantages of a purpose-built project team.

• Explain what the ‘A’ in RACI matrix stands for.

• Outline the two types of cost budgeting.
  

What does it mean for you?

• Think about a simple project you might be planning. Create a network diagram and critical path to help you understand the dependencies and how long the project is likely to take.