Project management

1 Introduction

Projects are the primary means by which organisations implement their strategic decisions, and finance people are expected to work within projects and to lead parts of them. This chapter covers:

• The characteristics of projects and why they matter to strategy

• Project objectives: overall objectives, and the time-cost-quality (and scope) trade-off

• The key stages of the project life cycle

• Sources and types of project risk, and how project risks are managed (including scenario planning)

• The business case and the project initiation document

• The planning toolkit: workstreams, work breakdown structures, network (critical path) analysis, Gantt charts and PERT

• Project management software

• Controlling scope

• Project structures and their impact on performance

• Project leadership: the roles of the project manager and other key personnel, and the life cycle of project teams

• Managing project stakeholders

• Completion, reviews, and project methodologies (PRINCE2, waterfall and agile) at awareness level.

2 The characteristics of projects

We tend to recognise a project intuitively, but projects have certain important characteristics:

• Non-routine. Projects are different from day-to-day activities and have specific starting and ending points.

• Novel. They usually address unique challenges – something you have not done before and will probably never be asked to do again, so there is little accumulated experience to draw on.

• Cross-functional teams. Project team members are normally drawn from different departments, with different backgrounds, vocabularies and priorities: they may want different things from the project.

• No benefit until completion. For most projects (though not all), there is no benefit until the project is finished: half a computer system, half a factory or half a quality-control system is useless. Money flows out for a long time before anything flows back.

Together these characteristics mean the risk attaching to projects can be very great. The project and its scope must be carefully controlled, or the organisation's effort and money will simply have been wasted.

3 Why the study of projects is important

A strategic plan is typically for a five-year horizon and for the whole organisation. To implement that as a single task is impossible: it must be broken down into a series of smaller tasks. Each task is a project, and each will have a planned:

• Start date

• Duration

• Finish date

• Relationship to other projects: after some, before others

• Cost

• Person responsible

• Closely defined set of outcomes.

Breaking strategy down like this makes implementation controllable and traceable: each project has its own budget, its own owner and its own defined benefits, so progress – and failure – is visible early.

4 Project objectives: time, cost, quality – and scope

Every project needs an overall objective – a clear statement of what it exists to deliver and why (the deliverables and the benefits expected from them). Beneath that overall objective sit three subsidiary objectives which every project must balance: time (the deadline), cost (the budget) and quality (the standard the deliverables must reach). A fourth variable, scope – exactly what the project will and will not deliver – connects them all.

The diagram makes two points. First, if you change one variable you are bound to affect the others: if you want the project done more quickly you may have to spend more money, limit the scope, or cut corners on quality. Second, even where nothing is deliberately changed, most projects have one variable as a priority. If a new payroll system must run on 1 January because the law changes that day, time will dominate – and cost (overtime, extra consultants), scope (drop the nice-to-have reports) or quality (less testing – not recommended) will be squeezed. If the project concerns public safety, quality dominates instead. The project manager must know which variable is the priority, while never abandoning the others.

Scenario planning can help in managing this balance: look at the events that could unfold and build from them a coherent set of possible futures. For example, if quality problems were identified at the testing stage, completion would probably also be delayed and cost increased – a viable scenario that can be planned for in advance (see risk management below).

5 The key stages of the project life cycle

Descriptions of the project life cycle differ in detail from one organisation (and one methodology) to another, but the key stages, their purpose and their typical activities are:

A project milestone is a fixed date by which certain parts of the project should have been accomplished – a natural point to pause, compare progress against plan, and warn stakeholders if time or cost is drifting.

6 Project risk: sources and types

Project risk can be partially judged by considering three independent variables:

• Scope definition. How well defined is the project? A project defined as 'improve the inventory system' could mean anything – keep less inventory? more? fewer stock-outs? – and everyone will put their own spin on it, guaranteeing disappointment. A project defined as 'reduce stock-outs from 20% to 5% and cut average inventory value by 25%' leaves nobody under any illusions. Poor definition is a risk in itself.

• Size. A project affecting only the receivables ledger is relatively small: if it goes wrong, only the receivables ledger is affected. A project affecting the whole organisation puts far more at stake and touches far more stakeholders.

• Complexity. If the problem is well understood with well-understood solutions, the ground is safe. If the project is cutting-edge and experimental, nobody can be sure it will work at all.

A large, hazy, experimental project scores badly on all three variables and will probably fail; a small, crisply defined, routine one carries much lower risk. That does not make large or adventurous projects wrong – sometimes they are exactly what strategy requires – but a project should never be hazy: an organisation should not spend money before pinning down what the money is meant to achieve.

Within any project, individual risks come from many sources: technical risks (the technology may not work), people risks (key staff leave, the team lacks skills), commercial risks (suppliers or contractors fail), financial risks (funding or currency problems) and external risks (regulation, weather, economic conditions). High-risk projects should be more carefully monitored for cost, time, quality and scope.

7 Managing project risks

Once identified and assessed (typically for likelihood and impact, and recorded in a risk register), each risk gets a response. The CIMA terms are remembered by TARA:

• Transfer: transfer the risk to another party – outsource part of the project so the risk falls on the sub-contractor, or insure against it.

• Avoid: the risk is assessed as so great that the project (or the risky element of it) should not be undertaken at all.

• Reduce: take measures to mitigate the risk. For example, instead of putting a new IT system into every branch at once, pilot it in one branch, learn from mistakes and gain expertise, then roll it out more safely across the whole organisation.

• Accept: every project has some risk, and where a risk is small enough it is simply accepted and lived with.

These responses are sometimes also known as the 4Ts: transfer, terminate, treat, tolerate. Risk responses are not set once and forgotten: the register should be revisited throughout the project, and scenario planning (above) used to think through how combinations of risks would play out.

8 The business case

A business case should be prepared for any project and will begin with a feasibility analysis using four criteria:

• Financial feasibility (see below)

• Technical feasibility – will it work?

• Operational feasibility – will it help the organisation carry out its functions?

• Social feasibility – will it be acceptable to stakeholders? For example, what is its impact on the environment? Will customers like using the new website?

Financial feasibility should always form a very important part of any business case. In a profit-seeking organisation it is necessary to demonstrate that the project will increase profits. In a not-for-profit organisation it should show how service levels or other outcomes will be improved. Possible techniques include:

• Cost/benefit analysis

• Net present value (the best technique, because project costs come now and benefits much later), plus payback and ROCE as simpler measures

• Sensitivity analysis and risk analysis

• Forecasting techniques

• Expected values

• Decision trees.

Usually costs are easy to budget. However, benefits are often intangible (such as customer service levels) and much more difficult to quantify with any precision. How would you quantify the benefits of a major training project? You might firmly believe it is worthwhile – but could you prove it in advance?

8.1 Types of benefit

Ward and Daniel identified four types of benefit:

• Observable: impossible to measure and often unexpected. A new IT system that lets staff complete their work more easily may lead to better morale and lower staff turnover: the benefit can be seen, but is hard to measure and was never predicted.

• Measurable: can be measured after the event but not predicted in advance. Better stock control might improve sales – the increase can be measured, but could not have been forecast.

• Quantifiable: measurable and predictable – for example, evidence that average stock held should fall by 20% if a new stock-control system is introduced.

• Financial: the benefit can be assessed and predicted in money terms. Once a benefit is quantified, the final step is usually easy: a 20% fall in stock volume translates into a predictable reduction in stock-holding costs.

Benefits become genuinely useful to the business case once they move from measurable to quantifiable, because predictions are needed for DCF calculations. Methods for making that transition include:

• A pilot operation: try the new system in one branch, measure the improvement, and assume it will be available company-wide.

• Simulation, based on mathematical models.

• Observing improvements found by other users – but be careful: a vendor will only ever show you its most delighted customer.

9 The project initiation document

The project initiation document (PID) answers the big questions – Who? Why? When? How? What? How much? Despite its name, it is not just used at the start: think of it as the master handbook of the project, the key reference document for anything anyone needs to know about it. It accomplishes the following:

• Defines the project, its scope and its deliverables. Only by setting out deliverables in advance can success be judged after the event – and a pinned-down scope is the main defence against project drift.

• Justifies the project: cost/benefit analysis and risk analysis. A project with substantial benefits might still be declined if the risks are too high.

• Secures funding for the project, if necessary – remembering that most projects yield no benefits until completed.

• Defines the roles and responsibilities of project participants: sponsor, manager, team.

• Gives people the information they need to be productive and effective right from the start: assignments, schedule, human resources, project control and quality control.

10 Workstreams and the work breakdown structure

Typically a project consists of a number of separately identifiable pieces of work. Related pieces of work are often grouped into workstreams – parallel strands of activity, each with its own leader, that run through the project. An office-relocation project might have a property workstream, an IT workstream, an HR workstream and a communications workstream: each can plan and progress semi-independently, with the project manager co-ordinating across them.

Within each strand, work is broken down hierarchically – project into major steps, steps into tasks – until manageable work packages are produced which can be assigned to the appropriate people. This is the process of deriving the work breakdown structure (WBS, sometimes called a work breakdown schedule). Each work package, or task, will have four components:

• The task name and description

• The costs, both marginal and any fixed element included

• The duration of the task

• Who is responsible – and, in particular, whether the work will be carried out internally or externally.

Now the project manager knows who is doing what and how much each element should cost. Costs are relatively easy to track: give the project (or each activity within it) a cost code, so that material, labour and overhead costs are booked to it automatically and actual costs can be compared with budget. Controlling time, however, requires specialist techniques.

11 Critical path analysis – network diagrams

Critical path analysis (network analysis) is used to plan and control the time a project takes. The diagrams show that some activities can be carried out simultaneously, while others must be carried out serially, in sequence. Diagrams of this type are universally used in large projects: IT development, construction, ship-building and so on.

To illustrate, we will use a project to build a house. The project has been broken down into activities A–G, with the duration of each in weeks:

The logic: foundations must be in before brickwork starts, but the joinery can be made in a factory off-site, so it can proceed in parallel. Windows, doors and roof beams can be fitted only after the brickwork (and the joinery itself) is finished. The roof covering needs the roof beams in place. The house must be weatherproof – roof, doors and windows all in – before wiring and decoration can start.

The activities can therefore be set out as follows:

The numbers in the circles are for reference only: they label events, points in time. The arrows are the activities, with their durations.

You can now trace each pathway through the network (moving forwards only) and calculate its length:

The critical path is the longest way through the project: here A B E F G, so the project cannot be completed in less than 21 weeks. A, B, E, F and G are critical activities: if any one of them takes longer than planned, the whole project takes longer. These are the activities the project manager must watch most carefully.

11.1 Float

Non-critical activities have some flexibility, known as float: the amount of time an activity can be delayed (or overrun) without delaying the project. C can take up to 8 weeks without harming completion, because it is not needed until A + B = 8 weeks are done – so with a duration of 4 weeks it has 4 weeks of float. Similarly D can take up to 7 weeks, because G cannot start until E + F (3 + 4 = 7 weeks after the walls are finished) are complete – so D has 5 weeks of float:

Critical activities always have zero float. Float is useful to the project manager: workers can be moved from activities with float (C, D) to help critical activities that are slipping, and activities with float can be scheduled to smooth the demand for people and equipment.

In simple projects like this, the critical path can be found by listing all the pathways and choosing the longest. Project management software (below) does the same job automatically for networks with hundreds of activities.

12 Gantt charts

Gantt charts provide an alternative layout of the same information. They highlight float and show plainly which activities can be carried on at the same time. Using the example above (weeks along the top, activities down the side):

The dark bars are the critical activities (A, B, E, F, G) – they run end-to-end with no slack. The mid-grey bars are the non-critical activities C and D at their earliest times, and the light shading shows their float: C could slide or stretch up to 4 weeks, and D up to 5 weeks, without delaying completion in week 21. A and C start together; B starts as soon as A finishes; D and E must wait for both B and C; G cannot start until both D and F are done.

Gantt charts are also the standard tool for tracking progress during execution: mark how much of each bar is actually complete, and compare with today's date.

13 PERT

PERT (program evaluation and review technique) is an approach to dealing with uncertain activity times: if activity times can vary, so can the total project duration. PERT takes timing uncertainties into account – though rather subjectively. Each activity needs three estimates:

• The optimistic time, o

• The most likely time, m

• The pessimistic time, p.

It is the expected time that is then placed on network diagrams and Gantt charts.

Another way of dealing with uncertainty is simply to build padding into estimated times: if you think an activity should take 10 days, put 12 on the plan. This can lead to inefficiency and complacency – if an activity is allowed to take 12 days, it probably will. The term that tries to make padding sound respectable is 'buffering'.

14 Project management software

Real projects have hundreds of activities, shifting estimates and many people to co-ordinate, so the techniques above are in practice operated through software. Project management packages typically provide:

• Planning and scheduling – enter the activities, durations and dependencies and the software calculates the critical path and floats, draws the network and Gantt charts, and recalculates everything instantly when an estimate changes ('what if activity B takes 8 weeks?').

• Resource management – allocating people and equipment to tasks, spotting over-commitments, and smoothing workloads using float.

• Cost tracking – budgets per work package, actual costs booked against them, forecast cost at completion.

• Progress monitoring and reporting – percentage-complete tracking, milestone alerts, and dashboards that give sponsors an up-to-date view without waiting for a monthly report.

• Collaboration – shared task boards, documents and discussions, so a distributed team sees the same live plan (see Chapter 7 on digital communication tools).

Traditional packages such as Microsoft Project and Primavera are built around WBS/Gantt/critical-path planning; team-oriented tools such as Jira, Trello and Asana are built around shared task boards and suit iterative ways of working. Many organisations use both.

15 Controlling scope

Of all the things likely to go wrong with a project, allowing the scope to drift ('project drift' or scope creep) is the most likely and the most serious. It happens for two main reasons:

• The scope (the deliverables) was never properly defined in the first place. This might be cowardice on the part of the project sponsor and manager: it avoids making hard decisions at the start, and everyone hopes it will sort itself out later. It won't.

• Changes are permitted as the project develops, but are not properly costed or evaluated. Stakeholders want more and more ('wouldn't it be nice if…'), and in many projects – IT projects are a good example – late changes to the design are enormously expensive.

Any change to a project's specification and scope should be subjected to a rigorous feasibility check – economic, technical, operational and social – and a cost/benefit analysis should certainly be carried out before any change is authorised: the incremental benefits of each change should exceed its incremental costs.

16 Project structures and their impact on performance

How the project is positioned within the organisation's structure affects the project manager's authority, access to resources, and ultimately performance. Three broad structures are used:

Matrix working is the most common arrangement for the cross-functional teams most projects need – which is why managing dual reporting lines is a core project-management skill.

17 Project leadership

17.1 The project manager

The project manager is the person in charge of running the project – tracking resources, controlling, leading, inspiring, negotiating, reviewing, resolving disputes. It is an immensely challenging job and requires personal qualities such as:

• Leadership abilities, including the ability to motivate

• Technical ability, both in running projects and ideally in the subject matter

• Negotiation ability – with project sponsors (those who are paying), team members and suppliers, for example when time or budget needs to be renegotiated

• Reporting skills: honest reporting of progress and difficulties, including bad news

• The ability to stay calm in a crisis

• Excellent communication

• The ability to delegate to team members – and then to let them get on with it, reviewing at agreed intervals rather than hovering.

17.2 Roles of key members of the project team

17.3 The project team and its life cycle

A team can be defined as “a group of people with a full set of complementary skills required to complete a task, job, or project.” Project teams usually work best if they are fairly small, united in what they want from the project, and have the right mix of complementary skills and personalities. This can be difficult to achieve, because members are drawn from different backgrounds and departments and are likely to have different priorities for the project's outcome.

Because project teams are assembled from strangers and then disbanded, they pass through the classic team life cycle – forming, storming, norming, performing and finally adjourning (Tuckman's stages, covered in Chapter 6) – on a compressed timescale. The project manager should expect the early storming, invest in getting the diverse members to work together quickly, and manage the adjourning stage deliberately: celebrating completion, capturing lessons, and easing members' return to their departments.

Leading and motivating the project team draws on everything in Chapters 2 and 4: clear goals and roles (the PID and WBS provide them), meaningful work packages with visible progress, milestones celebrated, individual development recognised – plus active management of the matrix tension between project and departmental demands.

18 Managing project stakeholders

Projects succeed or fail with their stakeholders: sponsors, users, staff whose jobs change, departments losing resources to the project, suppliers, regulators, sometimes the public. Chapter 1's stakeholder analysis applies directly to projects, as a four-step process:

1. Identify the stakeholders – everyone affected by the project or able to affect it.

2. Assess each stakeholder's power (can they help or harm the project?) and interest (how much do they care?).

3. Choose an engagement strategy for each, based on that assessment.

4. Plan the communications – who is told what, how often, through which channel – and revisit the analysis as the project proceeds, because stakeholders' power and interest change.

19 Completion

19.1 The completion report

Completion involves formally accepting the project and bringing it to a close. A completion report shows the outcome of the project and is used to:

• Check that everything promised by the project has been delivered, i.e. that the project objectives have been achieved

• Check on any changes which had to be made to reach acceptance, and that there are no outstanding project issues

• Deliver the final budget report

• Arrange for the post-project and post-implementation reviews.

Two types of review should then be carried out:

19.2 Post-project review

This is about the project: it examines how the project was run, looking for areas that did not go smoothly and for those that did. If the project was late or over budget, could that have been prevented? It can also look at the performance of the project team members. Without such a review there is little hope of improving the management of future projects – and lessons can be learned from what went well, too.

19.3 Post-implementation review

This is about what the project achieved. The business case and the PID set out hopes and ambitions for the project; now it is time to see whether it has delivered something of sufficient value, at the right cost, by the right time, which people are prepared to use enthusiastically. In other words: has the project realised its benefits? If not, the organisation must critically examine what went wrong so that similar waste is not repeated.

20 Project methodologies

A project methodology is a standard, documented way of running projects. A methodology provides:

• Documentation – standard documents such as the project initiation document

• Techniques – a standard set of planning and control techniques (critical path analysis, PERT)

• Sequence – the order in which the stages will be performed

• Overview – a picture of how the documentation and techniques fit together.

20.1 PRINCE2

PRINCE2 (PRojects IN Controlled Environments) is a widely used structured methodology – the de facto UK standard for systems projects. It organises a project into stages, each controlled through seven processes: starting up a project (business case, approval), directing a project (ongoing oversight by the board/sponsor), initiating a project (detailed plans and controls), controlling a stage (activities monitored, regular progress reports), managing stage boundaries (a stage must be completed satisfactorily, and the next stage's plans approved, before it begins), managing product delivery (acceptance and sign-off of what was promised) and closing a project (final reports and reviews).

Control is exercised through a structure of reports and meetings: a project initiation meeting approves scope and objectives; end-stage reports gate each stage boundary; regular progress reports (often monthly) go to sponsors and the board; and the project team meets more frequently (often weekly) for detailed management. You need awareness of PRINCE2's shape, not its full detail – the syllabus's aim is to equip finance people to work within projects, not to train project managers.

20.2 Waterfall, agile and hybrid approaches

The life cycle presented in this chapter – plan fully, then execute, then deliver at the end – is often called the waterfall approach: each stage cascades into the next, and the tools of this chapter (WBS, network analysis, Gantt) fit it naturally. It suits projects where requirements are stable and known in advance – construction being the obvious example.

Agile approaches, common in software development, instead deliver the project in short iterations ('sprints', often two to four weeks), each producing a small working increment which users try, generating feedback that shapes the next iteration. Scope is deliberately allowed to evolve; time and cost are controlled per iteration. Agile suits projects where requirements cannot be fully known up front – but it is not an excuse for the undefined scope this chapter warns about: each iteration is tightly defined, and the discipline is in the feedback loop.

Many organisations use hybrid approaches – for example, waterfall planning and governance for the overall programme, with agile delivery inside the IT workstreams. For this exam you need awareness of the distinction, not the mechanics of running a sprint.

21 Test your knowledge

Two quick checks before you move on: run the flashcards to fix this chapter’s definitions and frameworks in mind, then attempt the ten objective questions to see whether you can apply them.