Managing Smaller

and
Medium-Sized Projects

by Dr Jim Young PMP

Managing Smaller and Medium-Sized Projects
by Dr Jim Young PMP

© Copyright text and images SkillPower Limited, 2018.

All rights reserved.

ISBN 978-0-473-38676-4

Printed in Lower Hutt, New Zealand, by SkillPower Limited.

www.skillpower.co.nz

No part of this publication may be reproduced, stored or transmitted

in any form without permission from the copyright owner.

Acknowledgements

I acknowledge with sincere appreciation the contributions from numerous clients,

student, colleagues, friends and project management practitioners. Their sometimes
unwitting input has been invaluable.

I’m particularly indebted to Dr Russell Radford, a valued friend, fellow author and
former military colleague, for his expert scrutiny of my draft book, and to my wife,
Esmeralda, and my younger daughter Emma, for tolerating all this writing silliness.

Jim Young
Author
 Managing Smaller and Medium-Sized Projects
by Dr Jim Young PMP

Contents

Chapter One: Introductory Stuff 5

Chapter Two: Principles, Processes, Terminology, Roles,

Responsibilities, Leadership, and Challenges 22

Chapter Three: Recognising the Need and Justifying the Investment 40

Chapter Four: Preparing the Charter 58

Chapter Five: Engaging with Stakeholders 66

Chapter Six: Outsourcing the Project 80

Chapter Seven: Planning the Work 92

Chapter Eight: Creating a Work Breakdown Structure 97

Chapter Nine: Analysing the Work 108

Chapter Ten: Scheduling the Work 121

Chapter Eleven: Managing the Risk 143

Chapter Twelve: Working the Plan 154

Chapter Thirteen: Quitting the Project 181

Chapter Fourteen: Closing the Project 186

Chapter Fifteen: Managing the Change 192

Chapter Sixteen: Securing the Benefits 203

Appendix One: Common Terms 216

Appendix Two: Templates 223

Appendix Three: Risk Checklist 229

Appendix Four: Example Trade-off Analysis 231

Index 237
 Chapter One

Introductory Stuff

The Great Pyramid of Giza, the Colosseum in Rome, and the Great Wall of China are
testimonies of huge and successful projects. China’s Great Wall took centuries to build.
President Donald Trump’s modern day wall along the US-Mexican border to repel
illegal immigrants will be a financial, engineering and logistical challenge of similar
proportions. While mega infrastructure projects that cost over $1 billion such as border
walls, floating cities, oil pipelines, tunnels, motorways, railways, bridges, and airports
catch our imagination, most projects are very much smaller in scale and cost. This book
is about how to successfully manage these more modest endeavours.

Is this book for you? Yes, we’re all project managers (PMs), although we don’t
necessarily hold the job title or manage projects full-time. In our workplaces we
often do both project work to realise progress and on-going operational or business-
as-usual work that maintains the status quo. The difference between these two types of
work depends mainly on whether we repeat the activity often enough for it to become
routine. For example:

• Setting up a business is a project; running it on a daily basis is an operation.

• Developing software to process membership applications is a project;

on-going processing of these applications is an operation.

• Closing the books at the end of the fiscal year is a project; routinely running
the accounting function is an operation.

• Installing a robot to paint car bodies at an assembly plant is a project; using

the robot to paint car after car is an operation.

• Developing a PM training course is a project; presenting the course

repeatedly is an operation.

• Setting up a help desk is a project; responding each day to customers’

inquiries is an operation.

• Designing an iPod is a project; routinely manufacturing them is an

operation.

• Composing an opera is a project; performing it regularly is an operation.

5
A project is a one-of-a-kind undertaking that moves things from where they are
now to a new place, and usually to a better place. Projects might develop new
products or enhance and maintain existing products to effect some beneficial change
for whoever instigated the project. We use PM, allied with change management and
benefit realisation management to achieve this better place and often do so given
challenging people, risk, quality, time, financial and other constraints. At our places of
work the performance and competitive advantage of our business often depends on
our ability to do this well.

While PM is chiefly associated with planning and managing change in an

organisation, a project may also be something unrelated to business such as taking a
holiday, organising a dinner party, holding a garage sale, creating or removing graffiti,
emigrating to Aussie or returning to NZ, fixing a leaky home, extinguishing a bush
fire, moving house, having a funeral, organising a jail break or cake stall, regaining
and defending America’s Cup, robbing a bank or dairy, prosecuting a crim, organising
a celebration, holding a coroner’s inquest, winning a rugby world cup, arranging a
boxing tournament, running a referendum or a general election, undertaking a mine
rescue, organising a rock concert or a crowd-funding campaign, finding a replacement
planet, or undertaking a hikoi, hangi or hui. And here’s me undertaking a DIY project
to hardscape our yard, and with Robbie admiring our recently completed dog-proof
fence project.

Yes, we all do projects. We organise events, we look for jobs, we refurbish our
kitchens and bathrooms, we find new places to live and so on. Some would say that
every facet of human life is a project and is best managed as such. For example,

6
getting married or divorced is a project and staying married is mostly a series of TLC
maintenance projects. While PM is now recognised as a life skill, even life itself could
be viewed as a unique do-it-yourself project, which if properly completed may result
in a beneficial afterlife or even reincarnation some religions proclaim. Anyway, like
people, projects deliver products that have a birth, a life and a death, during which
time their use generates beneficial change - the rationale for any project.

Yet, while PM is a life skill, most schools don’t teach it. Perhaps this is one reason why
many young people often struggle with the school-life transition. The basic principles
of PM aren’t particularly difficult - far less difficult than calculus, algebra, geometry,
grammar or spelling surely. While it’s true that there’s no PM class, per se, if we look
at the bigger picture, most of the truly valuable things we learn at school occur in the
playground. Play is the key to the physical, mental, intellectual and social wellbeing of
our children. For children, play is serious learning and the work of childhood. But it
seems that the current parental zeitgeist is one of worry and fear for our children, often
far out of proportion to the actual dangers involved. Yet bullrush is how I first learned
about the essential PM ingredients of risk, reward, and group dynamics - all during the
lunch break. Perhaps PM needs to be officially part of our national curriculum. If we
want our children to build and live in a world that delivers more, with finite resources,
while taking a mature approach to the risks involved, there is nothing more valuable
that we can teach them.

“The Secret Life of Four Year Olds” spy-cam documentary recently shown on TVNZ is
about the leadership, planning, conflict, mischief, lies, rivalry, pestering, negotiation,
dictatorship, decision-making, recruiting, gang warfare, delegation, rejection and
violence of preschool life. It’s terrifying, but perhaps good preparation for a robust life
as PMs, although a few participants seem more interested in playing computer games
than making friends. For some of these four year olds PM may become their accidental
destination. Although today PM is just as likely to be a deliberately chosen career path
as PM has now evolved from a discipline into a profession; to a principal calling or even
an avowed religious faith.

Whether a project involves bomb-proofing an Afghan village or building a garden shed,

it’s our job as PMs to make sure everything comes together in a timely, cost-effective
manner, and we usually take the heat if it doesn’t. But PM has limitations. It may help
us build a career, a house, or a software application, yet it will not help us comprehend
the meaning of life or gravitational waves, understand the opposite sex, know what
the dog’s thinking, explain why we blush or laugh, or help us make sense of semi-
synthetic life, quantum computers, bitcoins, flux capacitors, Higgs Boson, computer
viruses, and the LG W7 “wallpaper” bendable TV. And PM won’t help us find those
damn keys we misplaced last night in our drunken stupor. Yes, there are limits to what
PM can accomplish, particularly if we attempt to apply complicated methodologies
to small projects, when most of our time and energy will be expended grappling with
bureaucratic overheads that quickly kill off our enthusiasm and creativity.

Even given an appropriate methodology, PMs must be willing to deal with frequent
interruptions since project problems, requests and other imperatives never wait for
us to become unbusy. Often we need to drop whatever we are doing and refocus our
attention. PMs who hide behind “Do Not Disturb” signs run the risk of having trivial

7
and easily addressed issues escalate into unrecoverable disasters where the only
constant is stress. Despite our best efforts at managing our time, between urgent
text messages, emails, phone calls, meetings, and people dropping in, we PMs don’t
usually have a lot of uninterrupted space.

The first reality of PM is that a day is very rarely 9 to 5. There is seldom time for
uninterrupted solitude. Often we need to schedule work that demands our full
concentration before the normal workday begins, or do it after everyone has left for
the day, and as soon as we open our eyes in the morning it all starts again as we
reach for our iPhones to field a relentless stream of urgent messages. Such permanent
connection is taking its toll and the French at least recognised that some intervention
was needed to severe this electronic dog leash and cease harassing us at home. PMs
in France now have the right to disconnect during weekends, holidays, before 9am and
after 6pm on work days. Although excessive hours correlate strongly with PM stress
and mistakes, it seems unlikely that Kiwi companies will adopt la courte semaine any
time soon.

Another PM reality is that due to limited organisational resources our project

selection usually comes at the expense of other initiatives to thus ensure that there
are regular turf battles and colleagues resentful that our project got the green light
and theirs didn’t. While suffering this resentment, we also have to stay on top of a
hundred details, all the while attempting to motivate a group of overworked people,
who have other things to do, to deliver on tough deadlines. It’s a juggling act that
has spawned many horror stories and seen the demise of many projects and their
hapless PMs. Truly, PM can be a stressful profession, with its well-documented failures
and steady doses of deadlines, collaborative overload, uncertainty, conflict, unrealistic
expectations, and accountability with little authority. Also, our project teams may be
comprised of reluctant people borrowed from different functional areas who are thrust
together in the hope that we PMs will quickly mould them into a productive synergistic
team.

But it’s not all bad news. One particular saving grace is that we PMs are always
learning, meeting all sorts of interesting people, never having a dull moment, and
our achievements are usually well recognised. Because we solve a problem, create
something new, or something better, our perceived value to our organisations is often
highly rated, and usually moreso than the efforts of our hard-working line management
colleagues. Also, there is usually a greater sense of satisfaction in completing a project
than there is in doing the same activity for the umpteenth time. We PMs are typically
well compensated, foster innovation, create value, develop our team members, reduce
risk, fix problems, and see the beneficial results of our work.

PM is a mixture of administration, planning, experience, analysis, people-skills,

leadership and luck. Luck is rarely acknowledged as an ingredient of PM success, as our
fragile egos would prefer to attribute positive outcomes to our own brilliance. Other
than luck, PMs have three key skills in common with entrepreneurs - the ability to lead
a team, a willingness to take risks, and a readiness to assume responsibility. Also, PM
is now a pathway to CEO positions. We PMs, like CEOs, have a lot of responsibilities,
face all sorts of pressures, have to work with a wide variety of stakeholders and need

8
to deliver promised results within a defined set of financial projections to ensure our
customers are ridiculously pleased.

We PMs are CEOs of our own domains and face many of the same issues as do CEOs,
but usually on a smaller scale and with less remuneration and authority. It’s likely that
many of our next generation of CEOs are at present PMs and if we are interviewing
people for a PM position, we might do well to imagine we are interviewing them for a
CEO position. Good PMs and CEOs are both forward thinking, have a biased towards
action, are optimistic, tough minded, perseverant, and willing to trust others. However,
PMs may even have a tougher leadership role than CEOs since the fellow employees
we depend on, our borrowed resources, don’t usually report only to us. Project team
members often have line managers to contend with who see their own business-as-
usual work as priority. Such is life in the dynamic matrix organisation – sometimes a
recipe for frustration, conflict and confusion.

There are a variety of ways in which to tackle projects. This book focuses on the
traditional, plan-driven approach to PM whereby the desired solution is pretty much
defined at the beginning before project execution starts - front-end planning. We
know the destination before we plan the route. Undertaking a project in this systematic
manner is a process. It’s about leading, planning and controlling equipment, material
and people to achieve a goal. Unlike business managers who oversee a department
or function, we PMs often need to control and co-ordinate the efforts of loaned people
with different skills from different functional areas, even from different organisations,
and sometimes from different countries, to spend other’s money to produce new
products to hopefully satisfy clients and users and a variety of other demanding
stakeholders, which could be likened to attempting to paint a masterpiece with many
hands manipulating our paint brush.

We might liken a PM to a symphony conductor who directs the orchestra to bring

out the magic in the music by keeping everyone moving in harmony, hence the
title of my first book on PM published by the New Zealand Institute of Management
(NZIM) - “Orchestrating Your Project”. Incidentally, I notice that “NZIM” has now been
rebranded “IMNZ “, which doesn’t suggest a very radical change of direction, but
doubtlessly an expensive project and hopefully beneficial.

Within most organisations there are essentially two cultures, two sets of expectations,
two languages even – the routine activity or business-as-usual culture concerned
with on-going daily operations, and separately, the project culture concerned with
producing new products, managing change and realising product benefits. These two
cultures need to work together, although one culture may dominate, and on occasions
there can be mutual incomprehension. While both projects and operations involve
employees, need to be planned, produce products, and are constrained by resource
limitations, they possess some important differences.

Operations are performed by relatively stable teams using ongoing and

repetitive processes and are focused on maintaining the status quo, whereas
projects are performed by temporary teams, are non-repetitive and produce unique
products.

9
Another significant difference is that our projects possess much less certainty than do
operations. Operations, as a result of continual scrutiny and refinement, possess little
uncertainty or risk and are thus much more predictable, whereas projects delve into
the unknown and as such things may not go entirely as planned. For a project there is
only some measure of certainty at completion, although even then results may not be
exactly as originally predicted.

Another important difference is that projects cause change and most people are
apprehensive about change. People who prefer project work like change and new
challenges, rather than steady routines. However, if this change is not completed
successfully, project benefits, which are the rationale for undertaking projects, will not
be realised or fully realised. The management of change and the achievement of
business case benefits are now recognised as essential ingredients for project success
and are fully addressed later in this book.

Differences Between Operations and Projects

Operations Projects
(business-as-usual work) (non-routine endeavours)

• Predictable and certain • Unpredictable and uncertain

• Repetitive and routine
• Have standard procedures
• Have no end dates
• Stable and permanent
• Teams stay together
• Easy to accurately measure
• Preserve the status quo
• Process-focused
• Evolutionary
• Continuous improvement
• Mostly harmonious
• Work in the business
• Maintains the business
• Unique and innovative
• Have individual plans
• Have end dates
• Dynamic and temporary
• Teams disband on their finish
• Hard to accurately measure
• Drive change
• Progress-focused
• Revolutionary
• One chance to succeed
• Sometimes acrimonious
• Work on the business
• Changes the business

Formerly, we PMs were exclusively preoccupied with completing our projects on time
and within budget, which are important measures of PM success, but not necessarily
project success, which is about realising benefits. A project might be completed late
and over budget, yet still yield benefits that ultimately exceed the costs involved and
thus add value; an often quoted example being the Sydney Opera House that was
completed ten years late and more than fourteen times over budget, but is now a
celebrated landmark.

While projects can be acrimonious affairs, conflicts or differences of opinion can be

healthy things and, if properly managed, can trigger useful debates. Conflict can make
people think differently, and expand their knowledge and insights. In fact, if two people
on our project planning team always agree, perhaps we have one too many people.

10
While different opinions are potentially a very good thing, if those two people never
agree, perhaps we have two too many people. It’s how we handle the conflict that
makes the difference.

Projects are discrete, unique and temporary pieces of work designed to achieve
beneficial change. Some projects are monumental, and others are smaller in size.
This book is about the more prevalent latter variety. However, a project is a project
whether it’s small or large; all have a start and an end date and yield a unique product,
which is generally the solution to a problem, but might also be about capitalising on
an opportunity or complying with legislation. We could say that writing this book is a
small project in terms of work effort, duration, size and cost, whereas constructing a
hydroelectricity plant and the battle for Mosul are very large projects both physically
and financially. Yes, military operations are also projects and the military orders format
“SMEAC” (Situation, Mission, Execution, Administration and Command) is an excellent
basis for any project plan. Anyway, size designations help put projects in perspective
and influence the extent to which structured PM methodologies and their associated
tools and techniques might be usefully employed.

Cost, complexity and novelty are usually the main project sizing factor, but exactly what
cost depends on our business environment. To the oil industry a medium-sized project
might have a $100 million budget, and to a minor charity, medium might mean a budget
of $5,000, if not less. While medium is a relative term, in writing this book I’m keeping
in mind those standalone endeavours of moderate complexity and risk that deliver a
single product with only a few stakeholders, with budgets up to say one million dollars,
with durations of less than twelve months, and a work-effort maximum of say 4,000
person-hours, and often undertaken on a part-time basis by a small team. In contrast,
large projects are often multi-year, multi-deliverable, multi-stakeholder, multi-team
member, full-time ulcer-producing complex pursuits, often with huge budgets. Given
all of these “multi’s” it’s little wonder that large projects can be very risky endeavours,
fraught with politics, and difficult to manage. And if they’re big IT projects, they’re
mostly destined to fail due mainly to an explosion of requirements during their lives – a
consequence of the Agile PM methodology often used for their development.

In relation to project size, the terms project scope and scale are sometimes confused.
Projects may be of small scale, but aren’t necessarily of small scope. For example, if
we build a house, some of the main components are the foundations, the framework
and the cladding. These different components add to the scope of the project. On
the other hand, the size of the house determines the scale of the project. So, if we add
a garage to the house, we’re increasing the project scope, but if we double the size of
the garage, we’re adding to the scale of the project.

Small and medium projects aren’t necessarily risk free, of little consequence, or even
simple. The difference in difficulty between small, medium and large projects varies,
and sometimes we are of the mindset that small is simple and large is difficult, but
this isn’t necessarily so. Sometimes small projects are difficult and large projects are
straightforward. For example, it’s a simple thing to run or even walk a marathon – it’s
merely one step after another. We start and don’t stop until we’ve reached the end.

11
What could be more simple? The fact that it’s an enormously difficult project doesn’t
negate its simplicity. Similarly, in our project planning endeavours, to be difficult is
often simple, but to be simple is often difficult.

“Methodology” is a big word for how things are done – the procedure. It was no
surprise that a recent KPMG survey showed that despite a significant uptake in the use
of the PRINCE2 PM methodology by our public sector, there have been more and more
project failures; recent and significant among which was Novopay our NZ Ministry of
Education’s payroll venture undertaken by relative newcomer, Aussie contractor Talent2.
As a consequence, KPMG emphasised that the following are important ingredients for
project success:

• A proven PM methodology.
• A sound business case to support the investment.
• Early and on-going communication with stakeholders.
• Continuous management of risk.
• Accurate and up-to-date progress reporting.
• Effective change management and benefit realisation.

Our government’s uptake of PRINCE2 was encouraged by a notorious government

project, eventually abandoned in 1999 due to compounding risks. The project was
called “INCIS” (Integrated National Crime Information System). At least this expensive
IBM/NZ Police failure provided us with a useful risk acronym:

I Inexperienced team 0.8

N Novel endeavour 0.8

C
5
Complex functionality 0.8 0.8 = 0.33 (33%)

I Imprecise specifications 0.8

S Scope change frenzy 0.8

Each of these five INCIS risk factors might separately reduce the likelihood of project
success to say 80%, but their combined effect could reduce the chances of overall
success to as little as 33%. We practitioners know that risks are much more likely to
compound than compensate, where one risk creates or worsens other risks. Interestingly,
the INCIS inquiry concluded that projects as complex, large and risky as this should not
be approved as a single endeavour but should be broken down into smaller projects.

12
NZ Telecom, now rebranded Spark, has, according to unofficial reports, lost something
close to $1 billion in IT failures over the previous decade. Recent NZ public sector
failures include a Health Waikato project that was abandoned at the cost of $9 million,
the failure of a large part of a $26 million project by Capital Coast Health, and the
Landline project that was late and $52 million over budget. “Dangerous Enthusiasms”
by local authors Gauld and Goldfinch describes why our large IT projects often go
wrong. Their book mentions eight habits to ensure project failure:

1. Prefer multiple requirements and a huge project scope.

2. Change product requirements often during the project.
3. Have an enormous and complex contract document.
4. Rely on the advice of salespeople and use lots of consultants.
5. Ensure the project takes a long time so the technology becomes outdated.
6. Believe everything we’re told about progress.
7. When failure threatens, never terminate project, but rely on promised fixes.
8. And most importantly - continue to throw lots of money at the endeavour.

Although the book focuses on the NZ experience, it’s a reflection of experiences all
over the world. To be fair about IT project failures, our worldwide rate of innovation
seems to be most pronounced in the IT industry where the frequency and extent of
change is exponential. Moore’s Law, now aged over 50 years, continues unabated. We
can download a version of software one day and have it obsolete the next day, where IT
product obsolescence readily beats IT product maturity. All we can be assured of as we
might proudly depart the shop with our new bit of IT is that it’s already superseded. We
are lured on by the delusion that new is better, that more is better, that faster is better,
and that only a lumpen tortoise could be content with yesterday’s model.

Some observers tell us that this breakneck pace of innovation is confined to IT and
other areas of endeavour are showing signs of slowing down. For example, we now
drive modern cars that are faster and safer than previous models, but this upgrading of
the horseless carriage over the last two centuries is hardly a break-through paradigm
shift. Perhaps the slowdown in non-IT pursuits is partly due to an increasing aversion
to risk as a result of increasingly stringent workplace health and safety legislation and
associated penalties, although in the PM business it’s probably better to view innovation
and risk management as partners and not adversaries. Perhaps our local health and
safety legislation is becoming an albatross around the neck of businesses, sometimes
costing them millions of dollars a year and leaving entrepreneurs in fear of speculative
claims.

Regrettably, our most widely used methods for managing projects are specifically
designed for huge projects. The main culprits are PRINCE2 (Projects IN Confined
Environments) and the PMBOK Guide (PM Book of Knowledge) that are both much too
unwieldy and frightening for smaller projects and for use by us ordinary mortals, and
despite their authors’ claims, these methodologies strenuously defy tailoring to match

13
smaller project needs. The PMBOK Guide is an encyclopedic source of knowledge with
currently 49 processes, and PRINCE2 is a huge descriptive and inflexible methodology
that is particularly user-hostile, even in its “PRINCE2 for Dummies” version. The 2012
ISO 21500 is strictly based on the PMBOK Guide, has the same ten Knowledge Areas
and has 39 processes with their direct equivalents in the PMBOK Guide. The ISO
21500 is a much more concise and readable standard than is the PMBOK Guide, but is
a higher-level description that has no mention of PM tools and techniques.

The PRINCE2 methodology is so top-heavy that it generates its own gravitational field,
which together with the corporate immune system can kill innovation and neutralise
anything that differs from the status quo. Britain has invented some great stuff, such as
rugby and television, but PRINCE2 is most definitely not up there. Yet this cumbersome
methodology is a now widely promoted PM qualification. Certainly it’s proof that
we’ve been on an expensive and tedious course to learn about PRINCE2 terminology
in order to pass a theory test. Unlike PMP, the principal PMI credential, we don’t have
to run projects in order to get PRINCE2 accreditation. Furthermore, PRINCE2 training
is mostly about higher-level project control and governance. It does not address PM
fundamentals such as how to lead and motivate our project team, communicate with
a diversity of stakeholders, or any other people skills essential for PM success. Also,
it doesn’t tell us how to apply basic scheduling, estimating and budgeting tools and
techniques, and how to keep our project on track. Little wonder that some people see
PM as a needlessly bureaucratic overhead.

Yet, organisations must “innovate or die” and while PRINCE2 and its even more
terrifying relative MSP (Managing Successful Programmes) seem to be favoured as
default solutions by NZ central government, these methodologies have been likened
to bureaucratic black holes that suck up all our energy. It’s no coincidence that when
this mammoth PRINCE2 method is rigorously applied, even the faithful feel imprisoned
in its many inflexible processes, sub-processes and sub-sub-processes, and some users
doubtlessly lose the will to live. This laborious method of managing projects represents
an enormous overhead, and is simply impracticable for smaller projects.

PRINCE2 may be useful if we’re looking to manage a large-scale project where there
are many people involved and many complex stages, although it failed for Novopay,
and the current Auckland City Council IT project is now well overspent and considerably
late. Perhaps IRD should be apprehensive about applying PRINCE2 to their $1.5
billion computer upgrade, recognising that the project risks and effort involved
increase exponentially with novelty, size and complexity. But if we’re looking for a
straightforward framework to satisfy small and medium-sized PM needs, then PRINCE2
is mostly unsuitable.

Yet, not all PRINCE2 concepts are entirely unsuitable for smaller projects. In particular, I
like its business case and benefits focus, whereby projects remain aligned with business
objectives. But, we don’t need PRINCE2 and its bestial bureaucracy and re-invented
terminology to have sound justification for a project or to reap post-project benefits,
although in this book I have adopted the PRINCE2 expression “product” meaning
the output, deliverable or whatever remains at project completion, be it tangible or
intangible.

14
Thus, for the vast majority of our projects, PRINCE2 and PMBOK are overkills. They are
costly, unwieldy, overly bureaucratic, time-consuming and generate too much useless
paperwork. They add little value, and despite their owners’ claims, these process-heavy
monoliths defy useful scaling. They are labyrinthine and confusing, which I suspect is
in part because the academics who develop and keep “refining” them believe that
simplicity would undermine their worth, or perhaps because consensus by committee
is incapable of embracing simplicity, since consensus usually means trying to placate
everyone.

In addition to the significant investment at stake, PMs most certainly put their
reputations on the line when they take on a large project. Mismanaged large projects
routinely cost the jobs of many PMs, and have even sunk whole organisations. A recent
Standish Group report (an independent international research organisation) indicates
that smaller projects have a very much higher success rate (76%) than do larger projects
(10%).

Survey Results Larger Projects Smaller Projects

Successful 10% 76%

Failed 52% 4%

Challenged 38% 20%

The Standish Group describe “successful” projects as those that are delivered on time,
on budget, and with required features and functionality, whereas “failed” projects are
those cancelled prior to finish or their products were never used. “Challenged” means
late, over spent or with less than the required features and functions. The Standish
Group tell us that smaller projects are much more successful due to a combination of
the following attributes:

• Less Risk. Today’s business environment is constantly changing. It’s unpredictable,

volatile, becoming more complex every day, and is fraught with risk. Among other
things, risk is a function of a project’s duration and complexity. Smaller projects
are usually of shorter duration and possess less complexity, and thus have greater
predictability and certainty. Generally, project plans are rarely accurate for more
than about six months, often due to uncontrollable external factors, none of which
are kind enough to stand still for the period of our project. When a project’s
duration is more than six months, there will usually be several external changes
(political, economic, environmental, social, technological, and legislative) any of
which could upset our project. Also, there is less risk of an organisational disaster
should a smaller project fail, and such failures usually attract little public attention.

• Better Communication. Smaller project teams have fewer communication channels

than do larger project teams, and we PMs are embedded in our smaller teams and
not remote from them. With larger project teams, interactions don’t just grow

15
 linearly; they explode exponentially to the square of the number of people involved.
Anyone who has worked on a large project team knows too well how frustrating the
communication and co-ordination process can be, particularly with cross-functional
teams that are often characteristic of larger projects. Also, it’s easier to establish
a quality relationship in a smaller project team with mutually agreeable ground
rules for effective teamwork. Furthermore, larger projects are likely to have more
stakeholders with different interests in the project. Due to better communication,
smaller teams make quicker decisions that are also implemented more quickly, and
aren’t usually challenged by the need to collaborate across cultures, organisation
boundaries or time zones.

• Better Co-operation. Coupled with better communications, smaller project teams

are more likely to develop strong and trusting cohesive bonds that enable team
members to work co-operatively, and are less likely to suffer from social loafing
(free-riding on efforts of others), loss of individuality, polarisation and groupthink,
which is the tendency for individual members to suppress dissent in the interest of
group harmony. Jeff Bezos, the founder and CEO of Amazon famously coined the
Two Pizza Rule: “If a team can’t be fed with two pizzas, the team is too big.” He
maintained that people in smaller teams were far more productive and larger teams
were often inefficient, lumbering, badly organised and unsupportive.

• Easier to Start. Imagine a freight train, say 15 wagons long, each wagon loaded
with logs. Next to the train is a car. Both are at a standstill and gearing up to go.
Picture as the car quickly speeds off while the train slowly begins to inch along
the tracks as it strains to get going. It’s no contest. The heavier something is, the
greater is the inertia and harder it is to get moving. Smaller projects have much less
inertia and can quickly get underway, are more manoeuvrable, and if necessary can
be stopped more quickly.

• Easier to Stop. With a large death-march project, no one, including the sponsor,
may have the courage to stop it when it becomes evident that costs will exceed
benefits. With smaller projects it’s usually much easier to recognise and admit that
it’s time to stop, and because they are small the impact of stopping them and the
sunk costs involved are much less. Sunk cost is a cost that has already been incurred
and cannot be recovered, which alone should never be the reason for continuing
a project. As PMs, we’re hard-wired not to quit, but should the rationale for the
project evaporate, it’s time to abort the job and minimise our losses. Such failure
might be hard to admit, but it’s easier to do so for smaller and relatively inexpensive
projects of shorter duration.

• Speedy. Smaller projects can make an impressive impact because they generally
produce a speedy return on investment (ROI). Smaller projects quickly create an
environment of success that breeds more successes and promotes the continuous
delivery of functionality in small doses such that the product users don’t need to
learn a lot of new stuff at any one time. It’s true that the return will usually be less
than what a larger project provides, but it’s a return coming now rather than much
later and, regardless of how we’re measuring that return, it’s always good to have
some early value coming back into our organisation. Thus, a smaller project makes

16
 for faster successes that breed their own energy. Furthermore, CEOs, like politicians,
prefer that project benefits be realised quickly and preferably during their term of
office.

• Single Goal Focus. Smaller projects have us focus on a single goal and not multiple
goals that often trouble larger projects. Larger projects usually don’t have a single
common goal to unite effort. In fact, sometimes they have conflicting goals that can
cause the project to overrun its budget and schedule, or even prevent its successful
completion. Also, the closer the goal, the easier it is to reach. In rugby union the
try lines are 100 metres apart. All the players and spectators can see the entire
field, can readily assess progress, and understand most of the rules. Small projects
have similar attributes. The smaller the project the easier it is for the sponsor and
other stakeholders to monitor and control progress.

• Transparency. Fraudulence should never be tolerated. In smaller projects it’s

harder to hide the facts. Also, it’s easier to keep our promises with smaller projects.
Keeping promises establishes our integrity and trust. If our stakeholders trust us to
do what we say we will do, then they are more likely to follow our advice and lend
us support.

• Less Team Turnover. Turnover can wreak havoc with a project team. Loss of
critical talent can delay a project for weeks or even months. However, with smaller
projects it’s easier to keep the team intact because of the project’s shorter duration.
The shorter the project, the less likely the team is to prematurely disintegrate.

Given these advantages, it’s typical for new PMs to be assigned smaller projects to
build their skills and confidence since smaller projects usually have limited value at
risk, have only a modest budget, a shorter timeframe and a smaller team, and are thus
easier to manage.

Regardless of a project’s size, PMs who bring about change may face resentment,
resistance, and even loathing from those affected. Often we are messing with people’s
worlds, challenging their norms, and forcing them to alter something with which they
are very familiar and comfortable. Sometimes we are outsiders who don’t “come from”
or “know the business.” In addition, smaller projects may have these further challenges:

• Lack of Planning. One serious problem is that when projects are smaller, it’s
tempting to skip the planning step and just “get it done”, only to later find that
resources aren’t available when needed, and some essential tasks have been
omitted, done out of order, or done later than desired. Likewise, costly mistakes
can occur when key stakeholders and risks are ignored by executing work too soon,
often causing acceptance disputes and expensive rework. A project sponsor who
asks why we’re wasting time with all that planning nonsense may soon be asking
why our project is well past its intended deadline and why are we now redoing
some work for the third time. It’s sometimes said, “The more we plan the luckier we
get.” How much time we spend planning depends in part on what level of certainty
we want, although in reality, time spent planning eventually shows a diminishing
return. However, no project is too small to ignore planning and as the famous

17
 American, Benjamin Franklin, once said, “Fail to plan, plan to fail.” All projects -
personal, community and business, regardless of their size, need some groundwork
to ensure best use of resources, albeit that once we are underway, things never go
exactly the way we anticipate. Stuff happens, which is why our initial project plan
is best seen as a basis for change. We adapt our plan as we go. Sir John Harvey
Jones, a genial and genuine giant of British industry, once said the only good thing
about not planning is that “failure comes as a complete surprise, rather than being
preceded by a period of worry and depression.” Without a proper plan we would
need to manage our project based on our intuition and “squeaky-wheel” issue
resolution. Much much better to jump into planning early before time slips by,
recognising too that the project end date is usually fixed.

• Insufficient Rigour. Smaller projects are at least as susceptible as are larger projects
to cost overruns since we are inclined to apply less rigour to smaller project. In
such circumstances we soon discover that the business case is based on fantasy –
the product of passion, not facts. Also we might take less time and trouble over
our estimates and we aren’t as rigorous about defining requirements. As a result,
what’s delivered doesn’t meet expectations and expensive change requests come
thick and fast.

• Absentee Team Members. One of the biggest costs for most projects is labour.
Time delays and rework mean we have to keep the team together longer. If we
are lucky, team members can return. But there is a cost implication as it takes time
for team members to reacquaint themselves with our project on their return. We
lose the synergistic behaviour of an effective team. Also, people may not be able
to return when we want them, thus causing further delays, or they may not come
back at all, leading to even bigger delays, and replacement recruiting, training and
assimilation headaches.

• Inexperienced Team. We people are the root cause of most project problems.
We change our minds. We work to our own agendas. We disagree with each other.
For smaller projects, the problem can be the inexperience of the PM since smaller
projects are often used as a training ground for developing the next generation
of PMs. We wouldn’t want a newbie building a skyscraper. That inexperience
means we are more likely to make mistakes. While such projects should get more
support, it’s a smaller project and organisations have lots of them and need to focus
their support on their big investments. We also take holidays and get sick. In a
smaller project we have less capacity to absorb such events and might need to hire
expensive temporary staff or outsource work. The alternative may be unacceptable
delay and extra cost.

• Risks Ignored. There can be a perception that smaller projects are low-risk
endeavours, which isn’t necessarily true and they aren’t necessarily easier to manage
than are larger projects. So it’s wrong to assume that just because the project is
small, it will be simple and straightforward. A small project is still a project, and it
can have just as many problems as a large project, particularly if it’s a pioneering
endeavour.

18
• Less Time. Smaller projects have a challenging characteristic – they are usually of
short duration. This means that there is little time in the schedule for mistakes or
changes. Everything has to happen like clockwork or the project soon falls behind
schedule. On large projects we usually have time to discover and fix problems and
get back on schedule and within budget; on small projects we often don’t have this
luxury.

• Part-timers. While larger projects are likely to have dedicated PMs, smaller projects
often have part-time PMs who also have other projects and business-as-usual work
to contend with and are thus interruption-prone. Their project team members
come from departments that favour the status quo – in fact, they are the status
quo. Projects disrupt the status quo. The combined workloads, task switching and
interruptions involved can become a source of wasted time, confusion, exhaustion,
stress and frustration. In many organisations, where doing more with less is the
mantra, small projects are often under-resourced and it’s just not appropriate to
dump, delay or re-assign our routine operational work. Realistically, there is a
maximum number of projects that any PM can properly manage concurrently.

• Bad Apple. Sometimes not all of our team members want to be part of our project.
Many have other jobs, responsibilities and pressures. Often, they are assigned to
us by a line manager who is required to provide a resource, but not necessarily their
best resource. Don’t assume that all team members are excited and motivated by
the chance to work on our project. One toxic personality can be deadly for the
productivity of a small project team. Also, some friction may arise given that a
project team member may be above us PMs on the organisation chart, but they are
required to report to us during the project.

While I can labour on about PM bad stuff such as politics, cranky sponsors, distracted
team members, conniving stakeholders, and poorly written business cases, to be fair
our project may not possess those deficiencies. Also, we might think because PM
is a mature discipline that it would be practised successfully everywhere, and there
wouldn’t be many if any failed projects. Unfortunately, this is not the case. What we
find is a landscape littered with delayed, challenged and unsuccessful projects.

When we think of success, there is a difference between PM success and project success.
The former is about meeting deadlines, sticking to a schedule, staying under budget
and producing products that are built and perform to specifications. This requires
PM expertise. On the other hand, project success is about achieving outcomes and
measurable benefits created by project products during their operational life. Benefits
typically arise after the project proper is closed and sometimes considerably later. The
ideal is both project success and PM success.

The US-based PM Institute describes a project as “a temporary endeavour undertaken

to create a unique product, service or result” and the UK government PRINCE2
methodology describes a project as “a temporary organisation created for the purpose
of delivering one or more business products according to an agreed business case.”
The shortcoming of these definitions is that they aren’t specifically focused on the
purpose of the project, which is to deliver the benefits that validate the investment. I
prefer to describe a project as “a benefits-driven investment.”

19
 Project and Project Management Success

Also, while the focus should be benefits, projects are usually named after their products,
which can endorse the impression that the product is the sole purpose of the project.
And since outcomes and benefits are usually only realised sometime after a project
is finished, it’s easy for PMs to become product-fixated, given too that PM success is
traditionally seen as producing the specified product on time and within budget.

A project should not be started unless there is a sound business case in place. The
business case describes the reasons for the project and the justification for it, and
is based on estimated project costs, the risks involved, and the expected business
benefits. It’s a “living document” as it needs to be reviewed and updated periodically
during the project life, particularly when major variations are proposed.

A project’s final product that remains when the project is completed has its own lifecycle
during which time the benefits that justified the investment in the project are hopefully
realised. Also, there may be unanticipated additional benefits and even disbenefits.
Thus, project products, the vehicles upon which project benefits are realised, may be
initiated for a variety of reasons such as:

• To realise an organisation’s mission or purpose and business goals.

• To meet business, social, economic and market demands.

• To respond to a customer’s request.

• To increase sales revenue, market size or share value.

• To improve productivity or reduce cycle time.

• To control, reduce or avoid costs.

20
• To reduce or eliminate waste.

• To improve an organisation’s image, processes or productivity.

• To enhance employee satisfaction, motivation, performance or retention.

• To introduce new products and services and exploit commercial opportunities.

• To outperform or gain an advantage over competitors.

• To comply with new codes of practice or meet legal imperatives.

• To retain customers or gain new customers, members and supporters.

In effect all projects solve problems or exploit opportunities. Projects aim to close
the gap between the existing state and the desired state. They upset the status quo,
although the burden of proof is usually with those wanting to change the status quo.
Those who want to keep the status quo don’t usually need arguments.

This book is a guide to managing small and medium-sized projects, with special attention
given to project justification, stakeholder engagement, project planning, implementing
work, keeping on track, managing change associated with the introduction of new
project products, and post-project benefit realisation, recognising that all projects are
undertaken to bring about beneficial change.

Projects don’t just end with the delivery of a product, and after closure we can’t
expect the benefits to just magically appear without effort. As PMs, we are uniquely
positioned to help our clients gain promised business case benefits. Contemporary
thinking is that we PMs should be more involved in project conception activities and
also we must not let our projects just deliver and die; rather we must help ensure the
benefits envisaged at the start are realised at the end. Appropriately, we now include
measures and responsibilities for change management and benefit realisation in our
project plans.

Thus, projects produce various products that result in outcomes that can be expressed
as measurable benefits. Some benefits lead to other benefits or indirect benefits. For
example, an effective advertising campaign means that more tourists visit NZ, which
leads to more income for local shops, which leads to more jobs. Our projects may
also have disbenefits or negative side-effects. For example, more tourists place extra
pressure on the country’s infrastructure. Road accidents and traffic congestion are also
associated concerns.

21
 Chapter Two

Principles, Processes, Terminology, Roles,

Responsibilities, Leadership, and Challenges

Many PMs believe that there is a right or best way to manage projects. They recognise
a number of hard-learned principles or fundamental truths to be observed. While
conscientiously adhering to such principles will not guarantee success, they are ignored
at our peril. Listed here in no particular order, the following ten most frequently identified
guiding practices, derived through the analysis of both successful and unsuccessful
projects, provide a foundation for the successful management of our projects:

1. Establish and regularly reappraise the justification for our project.

2. Have a sponsor who gives us clear direction and effective support.

3. Agree and unambiguously define project roles and responsibilities.

4. Identify and communicate with users and other stakeholders early and often.

5. Apply a disciplined approach from project conception to benefit realisation.

6. Pre-empt problems, including HSWA hazards, and address issues promptly.

7. Check progress regularly and take timely corrective action to keep on track.

8. Manage change to ensure effective product adoption.

9. Recognise that project success occurs when business case benefits are realised.

10. Capture lessons as the project proceeds and learn from each project.

Having mentioned these principles, it wouldn’t be right to hold them in obstinate

blindness since they’re inclined to evolve. For example, it’s only in recent years that
stakeholder engagement, change management and benefit realisation have been
formally recognised as important PM practices.

An overriding consideration is that there’s no innovation or progress without projects,

which often start when we ask why things are done in a particular way. It’s about
questioning perceived or received wisdom. It’s about challenging common sense. It’s
about asking why we can’t do it better, faster, cheaper. And sometimes, it’s about
designing alternative futures and letting the market decide what’s best.

22
While initiating projects can be a challenge, we also need to query or stop projects
that are clearly in trouble or where their likelihood of success has been severely
compromised. We’re not so good at that. Why can’t we kill projects that are clearly
doomed? Is it managerial incompetence or entrenched bureaucracy? Ironically, we
usually persevere from a fervent and widespread belief in the inevitability of ultimate
success. This sentiment typically originates with our project sponsor; it then spreads
throughout our project team and can lead to some very irrational behaviour.

While the importance of project champions is well documented, the value of having
someone who can recommend pulling the plug on a project before it becomes a money
sink isn’t at all common. Perhaps every project should appoint a fearless skeptic or
critical evaluator who periodically reviews the wisdom of continuing.

The methodologies that PMs employ for the management of projects range from plan-
driven to change-driven approaches, where:

• Plan-driven projects have predictive lifecycles sometimes referred to as sequential,

waterfall or traditional lifecycles that require scope, schedule, cost and benefits to
be largely defined before work begins on producing the project product. Clients
then know what to expect. It’s this conventional “ready, aim, fire” approach when
we begin with the end in mind that this author advocates.

• Change-driven projects such as Agile are used predominantly for software

development projects, and have a flexible work scope that evolves with changing
requirements and priorities. Agile means incremental development of the final
product, thus, the argument goes, the risk of developing the wrong solution is
reduced. Scrum is a subset of Agile.

Having dismissed PRINCE2 and PMBOK in Chapter One, nor do I favour the Agile
methodology and its buzzwords, which might be useful for software development
when a lot of uncertainty is involved, but my main concern with Agile is that all the risk
is with the customer. Agile software development people just work until they finish or
until the time or money runs out. In my opinion that’s not PM, it’s just making it up as
we go along – designing the parachute while we hurtle to earth.

I suggest that Agile has limited adaptability outside of the software development
business. It requires we spend a lot of time measuring work and talking about work
instead of actually doing work. With daily stand-ups, sprint planning, sprint reviews,
sprint retros, daily check-ins and backlog grooming, it’s easy to fill out the week talking
about code rather than writing it. And why do Agile people always feel they have to
justify Agile by misrepresenting more traditional approaches? Their logic seems to be
that as some projects go badly, therefore all projects using established approaches
must go badly, so conventional PM must be broken.

Agile gives its users an excuse for avoiding rigour and discipline with their projects. It’s
like playing rugby without a try line, and maybe that’s fine for startups run by kids with
ear jewellery, piercings, hole-filled jeans and blue hair. Oops – my age is showing.

23
Agility is about responding rapidly to changing circumstances and Agile approaches
are meant to allow for such flexibility, while minimising costly disruptions to projects.
In practice, this niche tool achieves the former better than the latter. Large defect
backlogs are nothing new in projects, but what is new is that Agile is inclined to ignore
defects, which creates unmanageable backlogs and, eventually, ineffective projects.
But one thing that’s seductive about Agile is the cool name, since we all like to think
we’re adaptive, deft and sprightly movers.

Waterfall, which is characterised by upfront planning, is not an all-or-nothing proposition.

While the client knows from the start what to expect in terms of time, cost, product and
benefits, the waterfall project plan is not fixed, but is a baseline for change. Waterfall
plans are revisited and revised as more current information becomes available. This
refining process is called progressive elaboration or rolling wave planning and originated
with waterfall. Of course new requirements that add value can be included at any time
regardless of the PM methodology employed.

And then there’s APM (Association of PM – recent recipients of a Royal Charter) whose
PM framework is a hugely better proposition than PMBOK, PRINCE2 or Agile and tells
us what we need to do to plan and implement a project, and allows us to forecast the
finish time and cost at any point during the project’s life span. While the APM PM
methodology is entirely logical, it’s short on specifics and has few templates, although
the APM website now has an amazing on-line library of many very interesting PM
articles. But, one thing that is proving controversial is the AMP’s recently published
radical vision “A world in which all projects succeed.” Skeptics are asking if this bold
vision is realistic or even useful. Do we want to limit project selection to only those
projects that we are certain can succeed, which would reduce innovation, creativity and
appropriate risk-taking. However, the zero-risk project simply doesn’t exist. There is
always some likelihood of project failure.

A project plan is best viewed as a baseline for change, recognising it’s foolish to adhere
to a plan that’s not working for us or when new information comes available, and in
some situations rather than attempt to get back on track, a new track is needed. In
politics, opposition parties might call this a “flip-flop.” Of course, one person’s flip-
flop is another’s sensible recognition of a changed reality. Version control of project
documentation is therefore important, although we might give the printer a break
and ditch unnecessary hard copies, especially when documents are in draft or review
format. MS SharePoint is superb for document management and is characterised by
easy filing and quick retrieval.

In most cases PM ends with the delivery of a product or products, also referred to as
deliverables or outputs. However, to an increasing extent PM now continues through
an extended life to include the delivery of benefits (ie, measurable outcomes) during
the life of the project product. We need to be clear from the outset whether our
project ends with products or benefits, which will govern how we manage the project.
If the product is for an external organisation, change management and benefits
realisation is likely to be their concern, whereas if the product is to become part of our
own organisation’s routine operations, then our PM responsibilities would more likely
encompass change management and post-project benefit realisation activities. In this

24
book we recognise change management and benefits realisation as integral to the full
and proper management of projects.

“That sounds like a great idea.” These are encouraging words, but a great idea isn’t
an automatic ticket to a successful project. The “great idea” must first be made
measurable and actionable so that project work can be undertaken and stakeholders
know what will be delivered. The following diagram shows the basic process for the
management of great ideas, although in practice this process is more dynamic than the
diagram suggests. Previous steps may need to be revisited as reality unfolds.

Project Management Process

25
This systematic process illustrates the science of PM, whereas the equally important
art of PM consists of “soft skills” that include leadership, communicating, developing
trust, engaging with stakeholders, delegating, coaching, motivating, team building,
negotiating, resolving conflict, persisting, and demonstrating political and cultural
awareness. PMI claims that project PMs spend up to 90 percent of their time
communicating, but most of that time is probably spent persuading stakeholders,
sponsors and team members to see the project the way we do.

We should build a PM process that reflects the philosophy and best practices of our
own organisation. Such a process might be based on that shown in this book, which
is sometimes described as a predictive, plan-driven or waterfall approach when the
scope, time and cost to deliver the required project product are identified early in the
project lifecycle, but also adapted to changing circumstances as the project proceeds.
This process includes “front-end” activities to evaluate and justify the investment
proposition, and “back-end” activities to implement change and secure benefits.

In addition to this mostly sequential process, there are also important continuous
PM functions to be performed such as leadership, stakeholder engagement, change
management, and management of risks, issues, variations, benefits and documentation,
which together with a glossary of terms and templates constitutes our PM methodology
or model. Once we have a solid PM methodology defined we’ll need to onboard our
stakeholders and team members to this common standard, otherwise confusion will
reign. Having no single agreed approach leads to misunderstanding and conflict, and
ultimately to a failed project. The structured approach shown in the diagram on the
previous page helps us deliver projects more successfully. The key steps are:

Recognise Need. Innovation comes from anywhere and might arise at any time from
a problem, an untapped opportunity or a compliance requirement. Needs may also
be identified during our organisation’s routine business planning cycle and might be
top-down in origin, or may arise through unsolicited bottom-up initiatives, external
customer requests, business problems or changes in legislation. Ideas for projects
may also come from our competitors - the “me too” compulsion. Wherever such ideas
originate, their identification should be encouraged since maintaining the status quo is
seldom sufficient if our organisation is to remain cost-effective, competitive, and meet
our customers’ ever-challenging expectations. However, all project ideas need to be
concept-checked at this early stage to filter out obvious duds.

26
Justify Investment. Invariably, the demand for project resources outstrips their
availability. So all project ideas that survive our initial concept check need to be more
precisely described to enable their further evaluation. This high-level evaluation of the
possible project focuses on the project’s purpose, goal, benefits, work scope, order-
of-magnitude estimates of cost and time, product quality standards, identification of
stakeholders, risks, assumptions, and issues. It’s an overview statement completed in
sufficient detail to enable a project business case to be prepared. The key requirement
is that the estimated benefits sufficiently exceed the likely costs incurred throughout
both the project and product lifecycles (ie, whole-of-life costs or total cost of ownership),
taking account of risk, opportunity cost, and resource availability - not just the initial
investment or capital cost, but also the on-going product maintenance and operating
costs. This total cost of ownership (TCO) of a product is invariably greater than the
initial capital outlay. When choosing among alternative products we should consider
their long-term cost, since the product with the lowest total cost of ownership is usually
the best value in the long run. A cheap shoddy product is usually false economy as
might be doing a project task job ourselves rather than employing a contractor.

Prepare Charter and Proposal. A project charter is usually prepared for every project,
particularly if the project is to be completed in-house or mostly in-house for our
organisation, and if we outsource the project we then need to also prepare a proposal
as a basis for obtaining quotes:

• Project Charter. The charter formally appoints the PM, endorses the importance
of the project, and provides clear guidelines for the development of the project
plan. Its sign-off authorises us PMs to proceed with detailed planning. A charter
contains internal information about anticipated costs, benefits, responsibilities and
decision-making guidance, and is outcome-focused, whereas a proposal is output
or product-focused.

• Project Proposal. If the project is outsourced, contractors undertake the work,

while we monitor their progress until the project is satisfactorily completed. The
proposal is usually geared towards seeking pricing information for a defined scope
of work or product and contains sufficient information for a contractor to submit a
quote for the work. The project product is what contractors leave with us once they
have completed their work. We focus on managing the change and realising the
benefits created once our new product is in use.

Should it be intended to outsource the entire project, the full tender procedure is
usually an overkill for smaller projects, although NZ government purchases over
$100,000 usually require an open tender process unless there is only one supplier, it’s
an emergency purchase, or the purchase is to be split to avoid being too dependent on
a single contractor, although not to simply avoid the tendering process. The two most
practicable procurement options for smaller and medium-sized projects are:

• Requests for Quote (RFQ). The RFQ is typically for smaller jobs. We might use
this approach when we are seeking pricing information for a defined scope of work.
The product specifications, terms and expectations are clearly described. The
product specifications comply with applicable laws and industry standards.

27
 • Requests for Proposals (RFP). The RFP typically requires the contractor
to determine the work needed and is used when we can’t or don’t want to
precisely define the job. As clients we may be faced with situations where
we know what we want to achieve, but we don’t have the expertise or time to
figure out what exactly needs to be done.

Plan the Work. If the project is to be completed in-house, we first need to “plan to
plan”. Given our project purpose and goal we think through what we should have in
our project plan, who should be involved in its development, and when and where we
will do this planning activity, the typical sequence for which is:

1. Identify the Work. The project planning team usually hold a kick-off meeting
at which the sponsor, PM and planning team members would typically discuss
the charter, then guided by the PM, the team would clarify the project purpose
and goal, and then develop a task list or Work Breakdown Structure (WBS),
which is a “family tree” of successively smaller chunks of work that need to be
completed to achieve the project goal.

2. Analyse the Work. Once the work has been decomposed into tasks or work
packages, these packages are each analysed to more accurately determine
their resource needs, performance standards, costs, work effort and durations
to produce a “bottom-up” cost estimate, which is usually more detailed and
more accurate than the initial business case estimate that may now need to
be updated and the project’s viability again confirmed.

3. Sequence the Work. Here we decide the “logic” of the project, which
recognises the relationship between project tasks. These relationships might
be illustrated by preparing a network diagram. This is an analytical tool that
enables us to identify the project critical path, estimate the project duration
and completion date, and undertake a variety of “what-if” assessments.

4. Schedule the Work. The schedule, or work timetable, is prepared and usually
published as a table or Gantt chart, showing what work is to be undertaken,
when and by whom. A variety of software packages are available to assist us
with this scheduling activity, the most popular is currently MS Project of which
Version 2016 is now available. It’s designed to help us develop our PM plan,
assign resources, track progress, and manage the budget.

5. Assign Resources. The detailed availability of resources to meet the work

schedule is assessed, and resource shortages and overloading of project
team members resolved often by revising the schedule. The result is a
resource schedule that shows who and what is needed when, and is the basis
for procurement action.

28
6. Prepare the Plan. The project plan is now completed with sufficient information to
ensure the successful implementation and completion of the project. Our project
plan usually describes the following items as a minimum:

• Purpose - the reason for the project.

• Goal - what is to be produced to achieve the purpose.
• Work scope - what work is to be undertaken.
• Resources - human, material and equipment needs.
• Stakeholders - how to engage with those involved.
• Schedule - when project tasks are to be undertaken.
• Quality - what standards or specifications will apply.
• Risks - how potential problems will be managed.
• Issues - how actual problems will be managed.
• Variations - how scope changes will be managed.
• Change - how the impact of the new product will be managed.
• Benefits - how project benefits will be realised.

7. Pre-empt Problems. The draft plan is subject to careful scrutiny, often involving
key stakeholders, to identify possible mistakes or deficiencies that may necessitate
some revision to the plan. At this step we aim to “future-proof” the baseline plan,
although variations might still occur and risk management continues throughout
the project life.

8. Publish Plan. The baseline plan is finalised and presented to the sponsor/client
for approval. Should the plan be approved and its implementation authorised,
the project moves to the execution phase of its life. At this point only one thing
about our project plan is certain - it will be out-of-date as soon as the ink is dry.
Project planning is an iterative process that continues throughout the life of our
project. We best view our plan as a living thing that isn’t finished until the project
is completed. Accurate and timely PM plan version control is therefore important.

Implement Project. Formal approval of the plan and its budget allows us to undertake
procurement action to obtain the resources needed for the project. Tasks are delegated
to our employees or outsourced to contractors. Responsibilities, communications,
and control arrangements are finalised, contracts let and work commences. Project
implementation (or execution) is about carrying out the activities described in our plan.
We need to keep records. Every time we change our baseline plan, we record what
the change is and why it was necessary. Every time a new requirement is added to the
project we record where the requirement came from and how the timeline and budget
were adjusted to accommodate the change. We can’t remember everything, so we
write it all down and we’ll then be able to look this stuff up at the end-of-project review
and learn from it.

29
Keep on Track. Work is tracked to ensure things progress as planned. Progress is
usually determined through reports, meetings, site visits, sampling and testing as
appropriate. Proper monitoring enables us to quickly detect and resolve variance,
which is the difference between planned and actual project performance. We also
manage the schedule of work, variations, stakeholders, communications, risks, issues
and quality, revise benefit forecasts, update our plan as required, celebrate milestones
and eventually complete the project on time and within budget. We need to ensure
that the final product has been completed as per specifications and meets the client’s
acceptance criteria.

Close Project. At this step there may be product feature-by-feature checks, defects
are identified and rectified, and we obtain formal acceptance of practical completion
and sign-off from the sponsor/client. The final product is handed over to the owner/
users, and assimilated into the business-as-usual routine. Project closure will already
have been planned, but details may need updating. Finish procedure, which is part
of the project plan, should also address post-project user training, product operation
and maintenance, on-going change management and benefits realisation. Before
the project team disperses, project performance is evaluated and a project report
produced, and project completion celebrated. Lessons learned are documented, and
estimating databases, processes and procedures updated as required. Project files are
archived.

Launch Product(s) and Secure Benefit(s). After project completion and product
launch, the client/sponsor will work with users/customers and a change manager, who
for a smaller project may be ourselves, the PM, to ensure that business case benefits
are achieved. Let’s assume we invest $100,000 in more efficient equipment. The cash
savings from the new equipment is expected to be $25,000 per year for 10 years. The
payback period is 4 years ($100,000 divided by $25,000 per year). Well that’s the
theory, but sometimes organisations have not been properly prepared for the change
new products bring and there is no tracking of benefits or savings, which means that
the project business case is not properly validated; just perpetuated. And of course
sometimes benefits aren’t fully realised for years after product introduction, by which
time CEOs, PMs and sponsors have usually moved on.

Terminology

To the uninitiated “users” take drugs and “stakeholders” are the mob of villagers in
Dracula films. PMs are bilingual. We speak both our native language and projectspeak.
It’s frustrating I know, but every profession has its peculiar terminology. To work together
effectively on a project, everyone on the team needs a common language. For example,
without a common language, phase gates might be confused with milestones, phase
boundaries, stage boundaries, investment gates, review points, phase exits, off-ramps,
exit points or kill points. Or do these terms all mean the same? A glossary of the most
commonly used PM terms and their meanings is at Appendix One.

But a warning – we need to be careful when communicating particularly with our

clients and external stakeholders, some of whom could find our use of specialised PM
terminology patronising or even alienating. It’s often seen as linguistic tribalism.

30
Such language can be annoying and even intimidating if we’re not in the tribe and its
use might also cement unfortunate stereotypes. PMs are sometimes cited as serial
offenders. While our PM colleagues may be impressed with our command of the
jargon, gobbledygook and acronyms of our profession, our clients usually aren’t. We
need to translate projectspeak into plain language when telling other people what’s
going on.

Roles and Responsibilities

Professional relationships between us PMs and our sponsors are organic, they are born,
they grow, they mature, and ultimately they conclude. Importantly, we PMs and our
sponsors must clearly agree our respective roles and responsibilities at the start of the
project and any changes to these as our project proceeds. The first thing that we and
our sponsor might do is interview each other to assess each other’s skills, experience
and philosophy. Our agreed roles and responsibilities are often included in the project
charter and plan. Other than deciding our respective roles and responsibilities, two
essential matters for us to clarify with our sponsor at this first meeting are:

1. Problem. What is the problem that the project is to address? We want to establish
why the project exists.
2. Success. What would a successful outcome be? We want to know exactly what
constitutes success.

Project Sponsor’s Role. Project sponsors are primarily involved in funding the project
but are more than just figureheads. We PMs need someone to talk to who has the
business authority to make decisions and commit the money and other resources we
need for our project. This person is the project sponsor who champions the cause,
secures funding, and represents the eventual owner of the project product. The sponsor
is accountable for the achievement of the business case and will normally be a senior
manager with a relevant area of responsibility that will benefit from the project. They
are involved from the start of the project, before we PMs have been appointed, but are
outside the day-to-day hands-on running of our project, albeit that some misguided
sponsors become de-facto PMs. Our sponsor’s involvement appropriately intrudes
into the operational life of the product while benefits are being realised.

Project Sponsor’s Responsibilities. The sponsor is overall accountable for the success
of the project. They have the authority to sponsor the project and are available to help
the project succeed. They will assure themselves that the project remains healthy and
will decide on proposed changes. While there is no standard job description for our
sponsor, typically they:

• Authorise and champion the project.

• Own the business case and approve changes to it.
• Maintain communication with key stakeholders.
• Appoint the PM.

31
• Provide higher-level guidance and support.
• Chair the project steering committee if one is established.
• Prepare the project charter for release.
• Specify key milestone, parameter thresholds, and product due dates.
• Approve the project plan, significant variations and the final report.
• Approve the project budget.
• Maintain a management reserve and authorise its use.
• Ensure resources are available.
• Resolve escalated issues.
• Attend key project meetings.
• Monitor project performance.
• Arrange independent project audits.
• Account for funds assigned to the project.
• Know when to pull the plug on the project.
• Ensure change is properly managed.
• Oversee the delivery of project benefits.

A sponsor is a business leader and decision-maker, with the credibility to work across
functional boundaries as required and is ready to commit time and support to the
role. They need to be a keen advocate for the project and the change and benefits
it brings, and sufficiently knowledgeable about PM to judge if the project is being
properly managed. Once a working relationship has been developed with the sponsor,
we can jointly decide on the composition of the project team.

Sometimes sponsors are assigned the role and sometimes they choose to be sponsors.
Either way they can have a big impact on project success. They need to be engaged,
although some are too passive, some micromanage, and some are too busy elsewhere.
Those sponsors with a meddling disposition may leave us feeling that we’re not trusted.
Also, this behaviour may mean they miss the big picture while they are focused on
immaterial details. Despite the importance of their role, many sponsors, especially
those new to the role, don’t fully understand their responsibilities and may come into a
project with misguided ideas of how it will run. There are plenty of training programmes
for PMs, but very few for project sponsors, not all of whom have been PMs.

Project Manager’s Role. We PMs supervise and control the daily work needed to
achieve the project goal and ensure that our project is delivered on time, within budget
and to the required quality standards. We also lead our team and other stakeholders.
Essentially, our role is to create an environment in which our project team can be
successful.

32
Project Manager’s Responsibilities. While some people think a PM’s sole job is to
remind everyone about deadlines, crack the whip, and arrange status meeting, that’s
simply not the case. As a PM we’re personally responsible for the entire day-to-day
management of our project and while there’s no standard job description, we are
accountable to the sponsor for project success, and we might therefore:

• Help the sponsor prepare the project business case.

• Help prepare the project charter.
• Be accountable to the sponsor, client and other stakeholders for project success.
• Decide the PM methodology to be used.
• Define the project product and work scope – both inclusions and exclusions.
• Recruit project team members.
• Manage and lead the project team.
• Manage external contracts and contractors.
• Develop and refine project cost estimates.
• Negotiate resource needs with functional managers.
• Prepare and update the project plan.
• Define responsibilities and performance targets for team members.
• Arrange project procurement contracts.
• Communicate regularly with stakeholders.
• Periodically assess client satisfaction.
• Identify and manage risk.
• Authorise the use of contingency reserves.
• Monitor and control project risk and issue logs.
• Monitor and manage project progress.
• Mediate conflicts.
• Resolve or escalate project issues.
• Manage project scope and variations.
• Manage cashflow and budget.
• Maintain project files.
• Produce the project product.
• Periodically report project status to key stakeholders.
• Manage project closure.

33
• Inform line managers about team members’ performance.
• Arrange for the client’s approval of project products.
• Identify and implement product user training.
• Manage change to ensure the new product is properly adopted.
• Participate in benefits realisation reviews (product evaluation).
• Prepare post-project evaluation reports that include lessons learned.

Project Team Members. The project team consists of the full-time and part-time
people assigned to work on our project. We may or may not have absolute control
over the selection of our project team members, but we should be involved in their
selection and take into consideration factors such as their skills and expertise, emotional
intelligence, personalities and team fit. The project team are accountable to us as PM
and are responsible for:

• Completing assigned tasks to budget, timeline and quality expectations.

• Working co-operatively with other team members.
• Identifying and monitoring risk associated with their work.
• Requesting variations and implementing those that are approved.
• Managing the resolution of issues, or escalating these to the PM.
• Reporting progress to PM.
• Attending PM meetings.

Project Leadership

For some reason business theorists love to draw distinctions between management
and leadership. They might tell us that “managers do things right; leaders do the right
thing” and “management is administration; leadership is innovation.” I suggest that as
soon as our project involves stakeholders other than ourselves, we PMs are in both the
leadership and management business. We need to be both good leaders and good
managers, with a focus on both people and results.

It’s not the technical side of a project that most often causes project failure, but the
people side. It’s here where PMs may come unglued. Teams are the vehicles through
which a project’s goal is accomplished, so special emphasis should be placed on
understanding the dynamics of our team and how to be an effective leader. Project
leadership is the ability to establish vision and direction, to influence and align others
towards a common purpose, to remove obstacles to people’s performance, and to
empower and inspire people to achieve in an environment of change and uncertainty.

34
PRINCE2 and PMBOK are surprisingly silent on leadership and focus more on managing
a multitude of processes. Thus, another writing project I have in mind is “PRINCESS” – a
Kiwi companion to the process-heavy PRINCE2 methodology. It will explore the softer
yet vital topics of leadership, emotional intelligence, communication, team-building,
negotiation, motivation, delegation, performance management, personal productivity,
time management, managing meetings, presentation skills, networking, interviewing,
coaching, mentoring, dealing with stress, conflict management and so on, all of which
PRINCE2 and PMBOK publications largely neglect. Phew – given this list I’m beginning
to understand why PRINCE2 and PMBOK avoid the subject.

PMs tend to be selected because of their technical skills, but to be effective PMs
also need to master people skills. Of course, project technical knowledge is a base
requirement; however, no matter how technically correct, we PMs will not achieve
significant results if the people side of the equation isn’t also our focus. There is of
course a mass of literature on leadership and team-building and the subject has been
discussed since time immemorial, but the following practices usually help:

1. Communicate Clearly. We PMs must communicate effectively and often with a

broad spectrum of people at different levels within our organisation and externally.
In order to lead a project, we must be able to clearly communicate our project vision,
goal and expectations to others. The ability to deliver and receive constructive
feedback and listen to others is also an important part of leading our project
team. Listening is often the forgotten communication skill. We can’t learn if we
don’t listen. Furthermore, as our world becomes more interconnected through
technology, with teams dispersed across the globe instead of floors, the ability to
effectively communicate is becoming much more important.

2. Lead by Example. Leadership means following up on our responsibilities as

identified in our plan. For project team members to feel confident about us, they
must see us as someone who follows through, is available and helpful, and who has
a positive attitude. Being in charge doesn’t mean we have to take on a dictator’s
personality. Rather we should treat people the way we’d like to be treated - with
respect and a sense of humanity.

3. Show Enthusiasm. Plain and simple, we don’t like leaders who are negative - they
bring us down. We want leaders with enthusiasm, with a bounce in their step, and a
President Trump-like can-do attitude, but less of the provocative and confrontational
manner perhaps. We want to believe that we are part of an invigorating journey -
we want to feel alive. We tend to follow people with a positive attitude; not those
who give us multiple reasons why something can’t be done.

4. Encourage Trust. Trust is vital. An important factor in establishing trust is to

follow through on commitments. We must respond in a timely fashion to requests,
and offer assistance when needed. While a PM who focuses on management is
merely a conduit for information, a leader creates positive relationships with every
stakeholder on the project.

5. Provide Motivation. A strong leader knows when to offer motivation and how to
deliver. Regardless of the project team size, everyone can use a bit of

35
 encouragement along the way, recognising that motivated team members are
invariably more productive.

6. Be Reliable. As a PM we must be reliable. Without the team buy-in on the project

and how it’s being managed, there’s no way to succeed. We offer guidance,
suggestions and resources, and don’t make promises we can’t keep. Managing a
team that believes in our abilities is invaluable, but it takes work to maintain.

Some PM Challenges

Why do projects go bad? Often due to either a lack of adequate planning or breakdowns
in communication either among the project team members or with other stakeholders.
While the following well-known mistakes can be fatal, they can also be avoided:

1. Wrong PM. Not assigning the right person to manage the project. Projects can
quickly grow out of control without a savvy PM at the helm. Too often PMs get
picked based on their availability rather than on their ability. An inadequately
trained or inexperienced PM can quickly doom a project.

2. Unenthusiastic Team Members. Failing to get everyone on the project team

behind the project is a recipe for disaster. We PMs should start by calling the
team together and talking about the project and its significance in a way that gets
everybody fired up.

3. Senior Management Indifference. Not getting senior management buy-in and

support can be fatal. Somebody at the higher levels of the organisation needs to
own the project from start to finish and be personally vested in its success.

4. Poor Communication. Being a good communicator is probably the most important

credential for a successful PM. Without regularly and clearly communicating, the
project will fall apart. Want to kill the project? Don’t listen or talk to anyone.

5. Unclear Roles and Responsibilities. The PM must make sure that team members’
roles and responsibilities are clearly defined without forgotten or overlapping
responsibilities.

6. Lack of Risk Management. With our team, we must periodically brainstorm what
could happen to slow or derail the project, to make it go over budget, or to prevent
us from delivering the expected benefits. Then together we figure out ways to
mitigate those risks.

7. Scope Creep. To avoid unwarranted deviations from the original scope, we must
track change requests carefully, provide estimates on how they will affect the project
and benefits, and get explicit approval for any change.

8. Inadequate Planning. We should seek advice from people who have worked on
similar projects and take a bottom-up budgeting approach to arrive at reasonable
estimates. Also, we should realise that a Gantt chart alone is not a PM plan. It’s just

36
 a snap shot of the project schedule, the WBS and task dependencies. It doesn’t
provide for the management of people, money, progress, risk, issues, variations,
change and benefits.

9. Incompetent Sponsorship. Sometimes sponsors are appointed on the basis of

who’s available rather than who’s competent. Also, take care that the sponsor
doesn’t take over the project to become the de-facto PM. Some sponsors, whether
from flagging interest, overwork or unsuitability for the job, turn out to be so
dysfunctional or underperforming that they drag the project down. Best solution is
to get a great sponsor from the start. It’s much easier to influence the choice than
attempt to fix it later.

10. Unsatisfactory Business Case. One common problem is the over exaggeration
of the potential benefits in order to justify the investment. Business cases work
best when we are making an investment in tangible products that help us generate
predicable returns in the future. Unfortunately, business cases can fall apart when
we are investing in something less tangible such as software or public relations.
Sometimes organisations announce major funding decisions before a business
case has been fully developed. Also, sometimes no matter how well thought out
our business case is, the initiative may be adjusted by management to become
unreasonably aggressive as a consequence of less funding, less time, or more
features.

11. Borrowed Team Members. Some functional departments loaning people

to our project team are really putting an observer on our team to “represent”
their department’s interests. These borrowed resources can be a PM challenge.
Also, their managers may pull them off our project whenever they need them for
something in their home departments.

New technologies and new ways of working are demanding new skills for us PMs
that include change and benefits management, planning, tracking, communicating,
collaborating, workload management, stakeholder engagement, and familiarity with
PM software. To this list we might now add strategy. Yes, today’s PMs need to think like
CEOs and regularly ensure their projects align with their organisation’s purpose, values
and business goals.

Getting Commitment

Stakeholders and team members who commit to our project are likely to be productive
and co-operate to achieve the project goal. Some strategies to achieve this commitment
are:

• Persuasion. Have the CEO sign-off on the project charter and then give the
document a wide distribution. People aren’t going to consider anything until they
are convinced there is a problem or opportunity that truly needs to be addressed.
Be explicit about the business case benefits. Get visible and powerful advocates
to champion the project.

37
• Involvement. A key component of stakeholder buy-in is early participation.
Involve team members and other stakeholders in planning, problem solving and
decision-making throughout the project life. Real buy-in involves some element
of co-creation. It invites discussion, debate, even conflict and allows everyone to
feel vested in the outcome. If we ask stakeholders for their opinions, make sure
they know that these are valued. Provide feedback and keep everyone up-to-date
throughout the entire project. Research shows that leaders who ask for advice are
seen as more credible, not less. So if we need more input, don’t hesitate to ask.

• Positivity. Be positive ourselves about the project challenge and identify ways
to make the work interesting and enjoyable. If we’re timid, stakeholders will think
we lack confidence in the project. Be prompt to address instances where we see
resistance, since small problems have a habit of ballooning into bigger ones, and
we don’t want unhappy people upsetting the minds of the committed.

• Success. Ensure early project implementation tasks are successfully completed,

in part by assigning sufficient time, budget and other resources needed to achieve
such success, and then broadcast and celebrate the accomplishments. Nothing
succeeds like success. Conversely, early failures can be fatal.

• Recognition. Recognise and reward evidence of buy-in, but also anticipate and
prepare for resistance and evaluate objections. If we encounter resistance, use
strong, open-ended questions to promote understanding on both sides. Start by
asking how we might work together to overcome their concerns. What would make
them more comfortable with the solution?

• Feedback. Stay connected with team members. Practise wherever practicable

one-on-one, two-way, daily performance feedback and avoid bad surprises. Solicit
feedback.

• Management Support. If workloads are excessive have their line managers relieve
them of operational work or check if such work might be reassigned, postponed or
outsourced. Involve our sponsor if resource owners are unresponsive.

During my military and civilian careers I have met several leaders and experienced
various leadership styles and seen the reactions of people working with those leaders.
While I’m no leadership guru, here are some thoughts:

• Stay Positive. As a PM, but also as a member of a project team, it’s important that
our passion to deliver is noticed. If we show that we don’t believe in the project,
why should others believe in it? Don’t “white ant” the project.

• Practise Empathy. Our dedication, our empathy, our responsiveness for and
towards others, and our promptly addressing individuals’ fears and needs, are
crucial for constructive team dynamics. Empathy is the true connection with people
and the appropriate way of addressing their needs. Empathy seems to grow with
experience – we can better understand when we’ve been there ourselves.

38
• Be Visible. A PM has to be visible, personally involved and proactive in personal
communication with the team and other stakeholders. A PM who sits behind their
desk in an office and doesn’t personally communicate with people is not able to
properly sense, understand, and perceive the work environment.

• Walk the Talk. Practise what we preach. This is essential for trusting relationships.
Don’t announce something that we won’t stick to. Don’t make empty promises.

39
 Chapter Three

Recognising the Need and Justifying

the Investment

Just because someone has an idea for a project, doesn’t mean it should go ahead.
An organisation’s process for deciding which projects get dropped or deferred (often
a euphemism for “dropped”) and which ones get approved is sometimes intuitive,
informal, ineffective and inconsistent; the equivalent of rolling dice or the random
throwing of darts. Each project has different costs, benefits and risks, and rarely are
these known in advance with much certainty.

Rational project selection is an important process, but it’s not easy and many
organisations struggle with issues such as running too many projects at once, misaligned
business goals and projects, poor co-ordination between projects, lack of management
commitment, deficient cross-functional collaboration, resistance to change, reluctance
to terminate poorly performing projects, no attempt to check if project benefits have
been realised, and finding the right balance between smaller short-term projects that
improve current operations and larger long-term projects that increase potential for
their organisation’s future survival and competitive advantage.

Also, politics can sometimes play a major role when project sponsors trade favours with
decision-makers. Having witnessed local government in action (or inaction), political
decision-making about project approval is not always about rational deliberation.
Rather, it is often characterised by a struggle for power. This kind of decision-making
necessitates bargaining, accommodation, controversy, conflict, bluff, threats, and even
deceit. The bottom line is that such project decisions are often the result of bargaining
among diverse political interests and not the objective evaluation of viable options
in terms of appropriately weighted attributes. More often local government project
selection and priorities are decided by emotionally charged city councillors who scream,
politic, and subvert in order to push their agenda forward.

The types of working relationships and personal dynamics that develop between the
members of a project team, stakeholders and senior management, can determine how
smoothly a project progresses and ultimately how successful it is. In a group with good
working relationships, problems can usually be dealt with easily and conflicts handled
maturely without causing the project to flounder. But where working relationships are
fraught with politics and tension, and individuals have their own agendas or are vying
to be “top dog” then personal conflicts can get in the way of project success.

40
Projects might arise from a problem, opportunity or compliance requirement. They
might be commissioned to meet a business need, attain a business objective or meet a
market demand. They might be top-down in origin, resulting from business planning,
or they may arise through unsolicited bottom-up initiatives, external customer requests,
mandated needs, or business problems. Most importantly, their identification should
be encouraged since maintaining the status quo is not sufficient if organisations are to
remain cost-effective, competitive and meet customers’ ever-changing and growing
expectations.

Concept Check

Project ideas are always welcome but need to be checked to filter out obvious duds. Only
those suggestions that meet threshold selection criteria should be further considered.
One key criterion is “strategic fit” – the possible project promises to contribute to the
achievement of our organisation’s business objectives. A typical concept checklist is
shown here. Such a checklist is designed to identify appropriate project suggestions
early on, but a worthwhile suggestion doesn’t necessarily need a positive response
against all criteria.

Project Concept Checklist

Project Acceptance Criteria Response Remarks

1. Is the project idea or request in harmony with our Circle appropriate

organisation’s: response:

Business purpose? Yes / No / Unsure

Core values? Yes / No / Unsure
Business objectives? Yes / No / Unsure
Current and pending projects? Yes / No / Unsure
Existing policies and protocols? Yes / No / Unsure

2. Is it a sustainable development? Yes / No / Unsure

3. Is the risk of proceeding likely to be worth the investment? Yes / No / Unsure

4. Is the project idea likely to be technically feasible? Yes / No / Unsure

5. Are sufficient resources (skills, equipment and materials) likely Yes / No / Unsure
to be available?

6. Are the benefits of implementation likely to exceed project Yes / No / Unsure

costs? That is, will the project add sufficient value?

7. Is there likely to be sufficient support and demand to proceed? Yes / No / Unsure

8. Is implementation likely to enhance our public image? Yes / No / Unsure

Comments:

41
Project requests that survive this initial concept check then need to be further described
and in sufficient detail to enable the development of a project business case, which
provides the justification for investing in the proposition. Given this more detailed
description of the proposed project, its feasibility and priority can then be established.

Incidentally, we PMs don’t want to manage the lowest priority projects, which are
sometimes raided to resource higher priority projects whose costs and resource
requirements have been under estimated, and sometimes deliberately so to help
ensure their selection. Nevertheless, as new PMs, we may have no option but to accept
such failure-prone projects, which are often the result of unrealistic or overly optimistic
expectations, and not necessarily the consequence of poor PM. We need to push back
against such career-stifling assignments and at least seek realistic resourcing.

“There are more ideas in any organisation, including business, that can possibly be put
to use”, Peter Drucker wrote. Given limited resources we need to evaluate possible
projects against appropriate and weighted selection criteria or selection attributes,
which might include:

• Business alignment.
• Costs versus benefits.
• Risk versus rewards.
• Time to financial breakeven.
• Opportunity cost.
• Consequences of delay in approving the project.
• Consequences of not selecting the project.
• Technical feasibility.
• Availability of resources.
• Market demand for the project product.
• Legislative compliance.
• Environmental impact.
• Patent, trademark, copyright and intellectual property considerations.

Aligning our projects to maximise their contribution to business objectives is essential,

but if we don’t have such objectives, getting some should be our first project. Every
project should contribute to the realisation of our organisation’s purpose and be
consistent with our organisation’s core values.

Of these selection criteria, sometimes the “consequences of not selecting the project”
can be quite seductive when worrying consequences of the “do nothing” option are
predicted. For example, imagine the consequences of not extending the runway at
Wellington airport, which would include the loss of an estimated $2.3 billion in economic
benefits. When it comes to enabling direct long-haul flights to Asia and America from
Wellington, extending the airport runway seems essential. As a user I look forward to
saving time, cheaper travel, greater frequency of flights and more options. Other

42
benefits include local growth in tourism, more international students, and migrant
attraction. Of course, the anti-extension NIMBY group, “Guardians of the Bays”,
reminiscent of the “Save the Basin” lunatics, are working hard to stymie this project,
siting the dramatic environmental catastrophes they anticipate will come with any such
extension.

Frankly, Wellingtonians need to stop being so short-sighted about infrastructure

projects. Previous local examples of this do nothing option include not having four
lanes in the Terrace tunnel, not having a second Mount Victoria tunnel, and no Basin
Reserve flyover. Consider too the Transmission Gully debacle. It took 50 years to get
that project underway and in that time the construction costs have blown out from a
few million to billions. In 2013 Prime Minister John Key described Wellington as a
dying city, but perhaps this distasteful truth is just a consequence of Auckland’s growth
where planned private and public projects have recently cracked the $10 billion mark.

Strategic Alignment

43
Business planning, from which many project initiatives are identified, is now a continuous
process rather than a discrete half-yearly or annual coven attended by a select few.
Part of this planning process is usually a SWOT Analysis, which is a handy mnemonic to
help planners think about strategy and identify possible projects.

SWOT Analysis

A SWOT analysis aims to identify the strengths, weaknesses, opportunities and threats
of a prospective project. It involves specifying the project goal and identifying the
internal and external factors that are favourable and unfavourable to achieving that
goal. The strengths and weaknesses arise from within our organisation, and the
opportunities and threats from external sources.

Strengths are attributes of our organisation that help us achieve our project goal. We
play to our strengths and our questions might be:

• Do we have the necessary skills in-house?

• Has a budget been assigned to the project?
• What are the benefits of completing the project?
• Will the project require new technology or equipment?
• How experienced is the PM and team?

Weaknesses are characteristics of the organisation that work against the achievement
of our project goal. We address such weaknesses. Our questions might be:

• Is there a reliable estimate of costs available?

• Do we have the budget to provide contingency funding?
• What are the risks and drawbacks of the project?
• Will the project or parts of it need to be outsourced?
• Is the project completion date realistic?

Opportunities are external conditions that help us achieve our project goal. We might
exploit these opportunities. Our questions might be:

• Do the competitors have any weaknesses?

• What are the latest product trends and market developments?
• Are there any new, or imminent technology developments?
• Are there seasonal, weather or fashion influences?
• Is there an unfulfilled need?

44
Threats are external conditions that could jeopardise our project. We hedge against
threats. Our questions might be:

• Is there a well-established product already in the marketplace?

• Are experienced staff difficult to find or replace?
• Has new technology been fully tested?
• Could economic conditions affect the project?
• Could current or pending legislation affect the project?

We may be able to use strengths to overcome weaknesses or to take advantage of

opportunities. Once the SWOT factors are identified, we should be better able to
identify possible projects and decide if they are worth pursuing.

Costs and Benefits

One very important project selection criterion is costs versus benefits, where:

Value = Benefits less Costs

Return on Investment = (Benefits – Costs) / Costs

Value creation or Return on Investment (ROI) is an organisation’s raison d’être. The above
formulae are ridiculously simple and if applied more frequently and more exactingly
would go a long way to preventing many project disasters. If we can’t show value
why would we do the project? Benefits may be of value to the organisation making
the investment, to its staff, to its customers, or even to other parties, but without the
generation of benefits for at least one group of stakeholders, there is no justification for
investing in the proposed change.

Project Requirements

Project requirements drive the project work scope. Get our requirements wrong and
everything we do thereafter is pretty much pointless. Requirements gathering happens
way before our project plan is put together. Requirements are the basis for the project
product specification and recognise stakeholders’ needs and describe what the users
require the finished product to do, whereas a specification is typically a more detailed
and explicit technical explanation that shows how the requirements will be achieved.

Defining requirements means identifying the capabilities, features or attributes of the

project product. Stakeholders’ needs, wants and wishes are sought and analysed to
derive these requirements that are then prioritised to determine which will be included
and excluded. Defining requirements is a continuous process of fleshing out and
refining the baseline description of the project product. We should never assume that
we know our customer’s requirements, since what we think could be quite different

45
to what our customer wants. To get good requirements, we need to ask the right
questions and here are four techniques that may be useful in this regard:

• Stakeholder Interviews. Talk with each key stakeholder and end-user individually
to understand each person’s specific views and needs.

• Focus Groups. Conduct group workshops, remembering it’s a good idea to keep
asking “why?” for each requirement to help eliminate unwanted or unnecessary
requirements. By asking “why” no fewer than say four or five times we usually
discover the real requirements.

• Case Studies. A scenario-based technique allows users to walk through the process
step by step and helps people understand how the product will work.

• Prototyping. A mock-up or working model of the product gives users a proper

3D-feel of what the final product will do and look like. As a result of this prototype
evaluation there may be second and third improved prototypes. Everything from
computers to the latest model car, for example, started out first as an idea, then a
prototype model, before becoming a finished product.

Sometimes we may find the list of requirements is contradictory or more expansive than
our project can address. Requirements must then be analysed and evaluated against
the business case to determine which are in and out of scope. Requirements may be
expressed as features or functions, although we usually use “function” to describe a
product capability and “feature” to refer to physical appearance.

Facetious Functionality

Typically, some 50% of product features and functions are not used or very seldom used.
We need to be wary of “Hey, wouldn’t it be cool if we added…” or we might end up
with an unnecessarily overloaded, unmanageable, expensive gadget. Yet customers
very often select the product with the most features and don’t appreciate the virtues
of simplicity – at least until they get the product home and attempt to use it. If it’s an
intimidating software product with many features that needs extensive training it was
probably the consequence of developers using the Agile PM methodology, which

46
encourages the continuous evolution of requirements rather than devoting sufficient
time at the start to define key requirements. Perhaps the impracticable Wenger 16999
Swiss Army knife that contains 85 devices was a consequence of Agile or is at least a
terrifying example of requirements’ creep.

One way of analysing and prioritising product requirements according to their business
value and usefulness is to complete a paired-comparisons’ table or requirements‘
prioritising worksheet. For example, say the office needs a new photocopier, so we
canvas the users for their requirements and then working together we prioritise them
as shown in this completed example:

Prioritised Requirements

There may of course be more than 10 requirements in which case the table would need
to be expanded. The “Score” is the number of times that the requirement is identified
throughout the matrix. As a check, the total score will be 45 if there are 10 items,
where:

Total Score = {(Number of Items) x (Number of Items – 1)} / 2

If requirements have the same score we may distinquish between their importance
by checking the result when these two requirements are compared. For example,
requirements 1 and 9 both scored 3, however, when these two requirements are
compared, requirement 1 is of greater priority. Once features and functions are
prioritised they may be costed. Budget limitations or cuts might see requirements
progressively removed – least important first. All requirements should be necessary,
unambiguous, clear and measurable, and add value.

47
Requirements may change as our project develops, and as needs and circumstances
dictate. These changes can arise from new ideas, new information, new technology,
new perspectives, changes in regulations or budget changes, or may be requested by
product end-users. Thus, before we get sign-off on the base requirements list we need
to agree the approval procedure for change requests. Unless a proposed change adds
value, it would normally be rejected. “Requirements creep” is another expression for
feature creep or scope creep.

In summary, requirements specify the capabilities, features or attributes of our project’s

product. Stakeholders’ needs, wants and wishes are sought and analysed to derive
these requirements that are then prioritised to determine which will be included in the
final product.

Business Case

If our project needs funding, typically a business case is prepared and designed
to persuade management to invest the required money, time and resources in the
proposed project, rather than in a competing one. The business case evaluates the
benefits, costs and risks of alternative options, provides a rationale for the preferred
solution, and is based on whole-of-life costs and anticipated benefits to be gained
over the same period. The business case underpins our project by describing success
in terms of measurable benefits and is arguably the single most important document
in our project.

The sponsor is responsible for the business case. In practice the business case may be
prepared by a business analyst (BA), but we PMs need to understand it, given it’s the
rationale for all we do. As PMs we appreciate that our management of the project can
help or hinder the achievement of business case benefits. Thus, it’s very helpful if we as
the prospective PM are involved in the preparation of our project’s business case. We
will then better understand the reason for our project and help ensure that it’s a realistic
pursuit, since those sponsors who are very keen for their projects to proceed have been
known to forecast overly optimistic benefits, play down risk, and underestimate costs
to create an attractive proposition that transpires to be an impossible challenge for us
PMs. Without our input, it’s possible the project charter will mandate something that
we cannot accomplish within the time and budget constraints imposed.

The business case for our project comes from one simple line of logic - projects produce
products, change management prepares people to use these products, organisations
invest in projects to get benefits, and the benefits will not be achieved unless people
are using the products and using them properly. Although a group of people may have
contributed to the development of the business case, it’s helpful for consistency sake
that one person puts it all together. However, sharing drafts with others is a good way
to test the arguments and get buy-in.

There’s no magic formula when it comes to the size and structure of a business case,
although a common format should help us better compare, select and prioritise
competing propositions. A business case does not have to be a written document,
but the chances are that if it’s written, we will have edited and proofread it to ensure

48
its effectiveness and have an agreed basis for its periodic review and updating as
circumstances change. We should have at least one other person, whose opinion we
respect, edit and proofread the document before it’s published.

Sometimes it’s useful to precede the preparation of a business case with a Force Field
Analysis whereby project stakeholders brainstorm the driving and restraining forces of
the proposed project, but without attempting to quantify the respective arguments,
and then work on strengthening the driving forces and/or removing the restraining
forces. During 2016 NZ had our flag debate. Some common arguments for and against
this option made by binding national referendum are summarised here in Field Force
Analysis format.

Force Field Analysis - Flag Project

Forces For Change Forces Against Change

The national flag is too similar to the
flag of Australia and the two are often
confused, whereas the fern is much
more us.
Our current flag does not represent
New Zealand’s status as an
independent, sovereign nation.
It alludes to New Zealand being a
colony of the United Kingdom.
Our current flag acknowledges those
of British heritage, but ignores our
Māori population and other New
Zealand ethnic groups.
Removing the Union Jack from our
flag disrespects the sacrifice of those
soldiers who “fought and died under
the flag.”
The Union Jack represents New
Zealand’s past and present ties to the
United Kingdom and its proud colonial
history as a part of the British Empire.
There is no national consensus for
change. The Prime Minister simply
latched onto the new flag idea as an
expensive legacy/vanity project.

How can we ensure that an individual’s passion for a project doesn’t distort the business
case? Should we aim to eliminate emotion completely so that the case is made
dispassionately? Or should we value emotion as something that stems from a deeply
felt sense of what needs to be done to protect and nurture our business? Bringing
together several voices, rather than listening to one passionate individual, is essential
in order to strike the right balance in such decision-making.

A business case template is on the next page. A written business case might also have
a title page, approvals, distribution, a contents page, and an amendment record since
it’s a “living document” subject to periodic updating as circumstances change.

49
 Business Case Template
1. Summary

Depending on the length of the business case we may want to include a summary
that mentions the main benefits and costs, and our recommendation. Although the
summary appears first, it’s written last, when we know what we are summarising.

2. Statement of Problem or Opportunity

Describe the business need, problem or opportunity that the project will address.

3. Analysis of Options

What are the best alternatives to solve the problem? Here we identify and describe
feasible options to solve the problem or capitalise on the opportunity. Basic options
may be to outsource the project work or do it ourselves. Buying the product off-the-
shelf or leasing may also be options. For example, our options to feed the family are
to prepare a meal at home, to get takeaways, or visit a restaurant. The final business
case may contain say three or four options that usually include a “do nothing” or
benchmark option. And for each option, we need to discuss:

• Benefits. We explain why it would be a good idea to do the project. Benefits

may be both qualitative (intangible) and quantitative (tangible / measurable). If
benefits are not measured, or are not measurable, then insufficient evidence may
exist to justify the investment in the initiative. Informed and accurate decisions
around business cases cannot be made unless disbenefits are also identified
and measured. Different projects can’t claim the same benefits. For a particular
project, benefits to be realised during the next 12 months might be:

• Reduce sales administrative costs by 30%.

• Increase sales by 5% to 10%.
• Lose no existing clients.
• Eliminate all errors in the ordering process.

• Disbenefits. We should also identify any significant disbenefits. For example,

perhaps the new photocopier will run more quickly but require more maintenance.
A very common disbenefit is a reduction in productivity during the time taken
for users to learn to properly use a new project product. Of course, disbenefits
should not outweigh benefits.
• Costs. We include estimated whole-of-life product costs that include on-going
operational, maintenance and support costs.
• Timescale. Estimate of the project duration and time until we see a return on
the investment – the financial breakeven point - sometimes years.
• Assumptions and Risks. An assumption is a circumstance or event outside
the control of the project that can affect its success, and a risk is a potential
problem or opportunity that may impact project success.

50
 Our estimates should be realistic and wherever possible supported by solid data.
Also, we need to be balanced in our assessment, meaning for example if indirect,
long-term and qualitative estimates are used to determine benefits, the same criteria
should also be used for costs to help ensure a fair comparison. However, usually
greatest weight is given to short-term, tangible or measurable and direct benefits
and costs. We should avoid relative terms such as “better”, “lighter”, “cheaper”
etc. We might also mention here the consequences of doing nothing. If the return
on investment can be quantified as dollars in the form of savings or profits, that will
be a great help in building our business case.

4. Recommended Option

Here we state our preferred option and explain why it’s recommended.

5. Outline Plan

We provide a brief explanation here about how the implementation of the

preferred option should proceed.

In a cost benefit analysis, the key component of our business case, it’s dangerous to rely
too much on intangible and unquantifiable benefits to justify the investment. In general,
a project is approved primarily on its hard-dollar benefits. Unquantifiable or soft-
dollar benefits may enhance the likelihood of project acceptance, and may encourage
commitment from various stakeholders, but these alone are generally insufficient
to justify a project. Short-term outputs that lead to immediate, measurable and
substantial benefits are generally the easiest to argue and most persuasive. Although,
for example, while investments in employee health and well-being can be costly in
the shorter term, over the longer term such investments may pay off with reduced
workplace absenteeism, better retention, greater engagement and productivity, all of
which should contribute to the organisation’s bottom line. Also, activities that can
initially seem to have a positive effect on finances can be detrimental later on. For
example, encouraging employees to work overtime, rather than hiring more people
or outsourcing work, may be cost-effective in the short term, but the longer hours
involved may lead to employee demotivation, burn-out, reduced productivity and more
absenteeism. As a result, a project that was originally profitable can end up lemon-like.

One local lemon looks like being the proposed Wellington City Council’s $100 million
plus cycleways project, the business case for which argues that whole-of-life health
and safety benefits will total a very surprising $600 million. I wonder how that figure
was determined and I’m picking that Wellington City Council in-fighting, “bikelash”
and local government elections will stymie this one. Conversely, the business case for
an extended Wellington airport runway seems much more persuasive, but as with the
proposed Basin Reserve Flyover project, a handful of protestors could readily derail the
whole proposition.

51
Financial Evaluation

The reason for any project is to add value, which occurs when benefits exceed costs.
Some projects take longer than others to reach this breakeven or payback point. For
more expensive longer-term investments, future cash flows may be discounted to
present values to help ensure a more accurate financial assessment. The discount
rate or hurdle rate, as per the table below, is our organisation’s cost of capital, or for
government, Treasury suggest a current default discount rate of 6%, where for example
$1,060 return next year is the same as $1,000 today, and is determined by the formula
PV = FV / (1+r)n where PV is Present Value, FV is Future Value, r is the interest rate
expressed as a decimal (ie, 0.06, not 6%), and n is the number of years.

YEAR 6% 7% 8%
1 .9434 .9346 .9259
2 .8900 .8734 .8573
3 .8396 .8163 .7938
4 .7921 .7629 .7350
5 .7473 .7130 .6806
6 .7050 .6663 .6302
7 .6651 .6227 .5835
8 .6274 .5820 .5403
9 .5919 .5439 .5002
10 .5584 .5083 .4632

If NVP is positive after we subtract the cost of the investment, the project is worth
proceeding with (from a financial perspective anyway), although other factors might cull
the proposition from contention. There are other financial tools that may also be used
by an organisation’s financial manager to assess the financial viability of a project. In
most cases, discounted cash flow techniques such as net present value (NPV) or internal
rate of return (IRR) are appropriate to assess the value of benefits. Here are the various
tools used to assess the financial viability of more expensive project propositions:

• Payback. Time taken to recoup the project investment. For example, if double-
glazing costs $10,000 and saves $500 a year, the payback period would be 20 years
(although personally I hope that climate change will negate the need for any extra
warmth).

• Cost Benefit Analysis (CBA). It’s a comparison of estimated positive and negative
dollar impacts. If net benefits are positive, the project is likely to be worthwhile.
Dollarising some factors can be challenging, although, for example, I notice that
economists have managed to put a value on human life. For NZTA transport funding
decisions the current value is $3.56 million per fatality. But in great contrast, the
current official price for a human life in the Philippines is a mere 50,000 pesos,
which is about NZ$1,500.

52
• Net Present Value (NPV). This requires we add up all the present values of all
future cash inflows, and then subtract the sum of the present value of all future cash
outflows. If the result is positive the investment is financially favourable.

• Internal Rate of Return (IRR). This is the interest rate at which the NPV of all the
project cash flows (both positive and negative) equals zero.

• Accounting Rate of Return (ARR). This is dollars profit divided by the cost of the
investment expressed as a percentage. It ignores the time value of money.

• Discounted Cash Flow (DCF). This is an estimate of the money received from a
project investment, adjusted for the time value of money.

• Economic Value Added (EVA). This is net profit less the equity cost of the
organisation’s capital, which is not an easy calculation. The goal is to determine
true economic profit after taking into account the opportunity cost of the capital
invested in project.

• Opportunity Cost. Cost of a missed opportunity of similar risk. For example, the
opportunity cost when selecting between two projects is the value of the project
that is not selected.

Project and Product Lifecycles

53
Evaluating Project Options

A decision matrix can be employed whenever we need to choose among options.

Possible options are evaluated against common weighted attributes. We might use
this tool when we need to determine which of several projects to proceed with, which
proposal to select, which solution to implement, or for any other decision-making
occasion. For example, a company wishing to satisfy an increasing demand for its
products might evaluate the following options:

• Employees continue to work overtime to meet the sales demand.

• Expand the workforce to create the needed capacity.
• Contract out some of the work.
• Develop more efficient manufacturing processes.
• Some appropriate combination of the above options.

It’s important that the selection criteria that are used in a decision matrix are clearly
defined. For example, the 2016 NZ Flag Selection Panel determined that a suitable
new flag should be:

• Recognisable. Would be unmistakably and distinctively Kiwi.

• Enduring. Would not readily become outdated.
• Flexible. Would work with dignity in all situations.
• Simple. Could be drawn by a child from memory.
• Inclusive. Would represent all New Zealanders.

Requirements’ Prioritising Table

54
Suppose the NZ Ministry of Foreign Affairs and Trade (MFAT) needs to decide the
best project option for reducing a Pacific Island’s reliance on fossil fuels for electricity
generation. The selection criteria or attributes are first identified and prioritised as
shown on the previous page.

Decision Matrix

Next the prioritised attributes go into a decision matrix. We give each attribute a
weight (from say 1 to 10) that represents its relative importance, and then evaluate each
option against each attribute, scoring them, where say excellent is 5, satisfactory is 3,
and adequate is 1. In this example, the solar power option is preferred. This matrix
also allows for easy sensitivity analysis in that the results of a trade-off among the
selection attributes is readily observable.

Presenting the Business Case

The final stage of the benefits-focused business case process is to present the business
case to our decision-maker(s). The challenge is to keep the story clear, objective and
believable. If a decision-maker doesn’t understand it, which they may not publicly
admit, they are unlikely to approve it.

If we can, it may be worthwhile to lobby decision-makers before such a decision-making

meeting to check if they are on-board, if they have any concerns and if they believe that
input from their area has been adequately addressed. Fundamentally, a business case
is a tool to sell a new product to our business. If approved, the business case becomes
the key input to the project charter.

55
During the project the business case must be updated to reflect current costs and any
other changes. The latest information will be used by the sponsor to assess whether
or not the project remains viable. At project closure the updated business case should
be handed over to whoever is going to take responsibility for delivering the benefits –
usually the project sponsor. It’s the baseline against which to measure project success.
Yet, too often the business case is just used to sell the project and once it is launched
the business case is shelved.

Project Parameters

Different stakeholders may give different priorities to project parameters. Some project
parameters (ie, objectives or conflicting constraints) are usually more important than
others. If all parameters are non-negotiable and possess no tolerance the project is
over-constrained. The project “driver” is the top parameter – the last to be conceded
when the going gets tough. Knowing the driver helps us better manage our project.
With regard prioritising PM parameters consider for example the extra 3,000 temporary
seating needed at Eden Park to be completed in time for the 2011 Rugby World Cup
tournament. The following paired comparisons assessment identified this project as
time-driven:

Paired Comparisons’ Matrix

The driver is what we’ll be judged on – the one area where we must not fail. Thus, in
this example, any risk that impacts the completion date for this project must be taken
seriously. Also, if time is in jeopardy, we might further degrade product quality or
simply spend more money to accelerate progress. Also, a time-driven project would
encourage us to put a duration or work effort limit on tasks in order that we might detect
schedule slippage as soon as possible. The mantra is “to solve it easily, detect it early.”
Fagan’s Law states that the effort expended in resolving an issue, varies exponentially
according to the period of time that elapses before the issue is addressed. We should
agree parameter priorities with our client and/or sponsor and recognise that project
risk and benefits might be affected by parameter priorities.

56
Some PMs might identify an expanded list of constraints that include the duration
or target date for the project, the availability of the project budget, the availability
of project resources (such as people, facilities, equipment, materials, infrastructure,
tools and other resources) required to carry out the project activities relating to the
requirements of the project, factors related to health and safety of personnel, the level
of acceptable risk exposure, the potential social or ecological impact of the project,
legislative requirements, and anticipated benefits.

Here’s a thought. Quality means that our product meets customers’ needs, is fit for
purpose, and provides value for money. While quality is a traditional parameter,
perhaps “value” is a more appropriate expression. Value adds a dimension to quality,
emphasising that the quality (adherence to specifications) of the solution matters only
to the extent the users derive value from the project product. Perhaps keeping value in
mind shifts our thinking away from the traditional PM approach to a product approach.
Arguably, cost, scope and schedule are only as important as the impact they have on
the value delivered.

We need to ensure that the project justification continues to be valid and that our
project will deliver the solution to the business need. The result of periodic business
case reviews may be to confirm, terminate or amend the project.

In summary, the role of the business case is to show how our project will create additional
value for our organisation. The business case provides the justification for committing
resources to the project and answers the question “Why do it?” A sound business
case underpins a project charter and is a prerequisite for project planning and benefits
realisation. When deciding on the criteria for picking projects, it’s natural to focus
on ROI (profit or savings), but the focus should include the full range of benefits the
organisation will realise from the project, both tangible and intangible.

57
 Chapter Four

Preparing the Charter

The project business case is used by the sponsor and others to decide whether or
not to approve the project. If approved, the business case becomes a key input to
the preparation of the project charter. This charter, sometimes known as a project
definition statement, project mandate, proposal, terms of reference, profile, brief
or project initiation document, announces that a new project has been sanctioned,
formally appoints us as PM, and is sufficiently detailed to enable us to proceed with the
preparation of a comprehensive plan for project implementation, closure and benefits
realisation.

If we aren’t provided with a charter, we should create one ourselves and send draft copies
to our project sponsor and other key stakeholders in order to confirm our understanding
of the assignment. Give time for them to respond with recommendations, then make
adjustments as appropriate and distribute version one. Yes, the charter may need to
be revised as the project proceeds. It’s a business document, and typically not a highly
technical one. Usually the sponsor would create it, but as with the business case our
timely input as the PM would be most appropriate given that it’s essentially a contract
between the sponsor and ourselves.

Project Charter Template

Item Description

Version Number and Select a relevant, unique and concise title by which the
Project Name project will be referred. Usually a name based on the
product to be produced.

Background Briefly explain the situation, circumstance, opportunity,

new legislation or problem that has lead to the need
for the project.

Purpose/Benefits/ Explain the rationale for the project – what it’s designed
Justification to accomplish, what benefits (positive outcomes) will
be achieved. Why do the project?

Goal Express the project output as a single goal complying

with “SMART” criteria.

58
 Item Description

Final Deliverable(s) Describe the features, functions, user-requirements

and performance standards (outline specification)
required of the final product(s) - a high-level product
description.

Success or Acceptance Identify measurable criteria the achievement of which

Criteria will result in project success from the client’s and key
stakeholders’ perspectives.

Scope Prepare a statement of work (SOW) often in narrative

form, which describes the main work that must be
undertaken to realise the project goal. Also list any
significant exclusions to show what is outside project
scope on this occasion that might otherwise be
reasonably assumed to be part of the project.

Related Projects Identify any other proposed or approved projects

that might be related to or impact this project and
where co-ordination might be required. For example,
this project might be part of a programme of related
projects.
Business Alignment Identify which current business goal(s) the project will
contribute towards achieving.

Business Case Refer to an objective and balanced analysis of the

proposed project that demonstrates the project will
add value.

Client, Customer(s) and Identify specifically who will own the final deliverable,
Sponsor who will use it, and who will fund the project.

Project Manager Identify who is to manage the project, their key

responsibilities, and limits on their authority.

Other Stakeholders List other individuals or groups who could significantly

affect project success or be affected by the project
and thus have a stake in the project and its outcome.

Communications Describe the frequency, format and medium for

progress reporting from the PM to the project sponsor
and other key stakeholders.

Assumptions Document any key premises on which project planning

will be based, although don’t make assumptions when
the facts are available.

59
 Item Description

Risk Analysis Identify larger impact risks (including health and

safety) to project success and possibly suggest broad
mitigation measures.

Constraints Anything that dictates, restricts or constraints the

actions of PM other than the usual parameters of
scope, time, cost, risk, quality and benefits required.

Timeframe Identify when the project is to be undertaken, any key

interim milestones, and an estimated (or mandated)
completion date.

Total Cost Estimate the total order-of-magnitude cost for the

entire project and show the approximate level of
accuracy (+/- percentage or range) of this estimate.

Other Matters Include any other relevant matters not separately

identified above.

Approvals/ Contractual sign-offs with dates from appropriate

Authorisations people including senior management, the sponsor
and PM.

Not all these charter items will be applicable in every instance, and in addition the
completed charter might include a cover page, contents page, and summary. A
foreword might also be included – perhaps an expression of support written by the
CEO, sponsor or client, emphasising the importance of the project, endorsing our
suitability as PM, and encouraging stakeholders to support the endeavour. As a
minimum, senior management, the sponsor and PM sign, date and release the charter.
Should subsequent changes to the charter be approved, a new charter would usually
be agreed, authorised and published. Thus, charter version control is important.

60
 Example Project Charter

Prepared by: Pete Smith, PM and Alan Fletcher, Sponsor.

Version Number: One.
Date: 30 January 20XX.
Distribution: Board Chair, CEO, Sponsor, PM, and Project Team Members.

Project Name
ABC Annual Conference 20XX.

Background
ABC is a national not-for-profit charity for the prevention and relief of poverty.
Every year the organisation holds a two and one-half day (2.5 days) conference for
its membership.

Purpose
The purpose of the conference is to discuss matters of importance to the future of
the organisation, including a review of the organisation’s constitution, core values,
purpose statement, business plan, key operational activities, and current and
proposed projects to ensure that the organisation remains effective and efficient in
today’s ever-changing environment. The conference will also provide an opportunity
for productive face-to-face debate among members, will encourage membership,
and will further the organisation’s positive profile.

Goal
To hold a successful ABC national conference at Palmerston North during 8 – 10
April 20XX.

Success Criteria and Benefits

Key Performance Indicators (KPIs) and benefits for this project are:
• To be undertaken on the specified dates and completed within budget.
• To be attended by at least 200 members.
• To be rated successful by at least 85% of those who attend.
• To fully address all agenda items and allow for productive exchanges and debates.
• To receive positive media attention.
• To improve member retention by at least 50% over the next 12 months.
• To increase membership by at least 5% within 12 months.

Scope
The project work scope will include arranging a suitable venue (hotel with
sufficient parking, comfortable chairs, break-out rooms, wifi, security and
conference auditorium), marketing and advertising, preparation of mailing lists,
obtaining sponsorship, organising registration, preparing the conference agenda,
programme, papers, folders, conference packs and handouts, arranging flowers,

61
arranging catering (coffee, tea, drinks, snacks, meals, special diets, conference
dinner), managing and co-ordinating pre-qualified suppliers, organising the opening
address speaker and key-note speakers, arranging photography, press releases
and publicity, running the conference, obtaining participant evaluations/feedback,
and undertaking post-conference administration. Scope exclusions are arranging
transport and accommodation for participants, although ideally accommodation
for participants should be available at the venue or within its close vicinity.

Business Case Summary

The conference, which is to be self-funding, is fully justified given the need:
• To review the organisation’s current situation and develop new strategies where
appropriate to ensure the continuing relevance and viability of the organisation
in our constantly changing and challenging environment.
• To provide an opportunity for our membership to be updated on matters of
current importance and fully participate in the development of ABC strategy.
• To revitalise and grow ABC membership.

Key Appointments
Sponsor: Alan Fletcher
PM: Pete Smith
Project Planning Team Members: Mary Phippen, Mal Meredith, Peter George.

Roles and Responsibilities

Sponsor. The sponsor is accountable to the CEO for the achievement of the
business case and is to arrange project funding.

Project Manager. The PM is accountable to the sponsor for project success and is to
supervise and control the work needed to achieve the project goal and ensure that
the project is delivered on time, within budget, to the required quality standards.

Communications
PM is to provide the sponsor with a weekly status report.

Assumptions
It’s assumed that:
• A suitable venue will be available.
• There will be 3% “no shows” at the conference.

62
Risks
Risks will need to be identified, analysed and appropriate responses developed
and implemented. Based on previous ABC conference experience, some risks are:

• Venue already booked out or becomes unavailable.

• Venue earthquake or fire.
• Guest speaker(s) unavailable.
• Insufficient sponsorship or sponsorship withdrawn.
• Unhappy sponsor(s).
• Inadequate signage at venue.
• Insufficient parking at venue.
• Too many free tickets handed out.
• Budget overrun / financial loss.
• Food poisoning or other medical emergency.
• Excessive alcohol consumption.
• Power failure.
• Audio-visual equipment malfunction.
• Attendance estimate not achieved.
• Attendance estimate (venue capacity) exceeded.
• Diminished reputation as an effective and efficient organisation.

To deal with these possibilities will require clearly thought out risk management
procedures to be included in the project plan. Also, the PM is to select and visit the
conference venue and contact venue staff perodically to be certain that everything
will be satisfactory.

Health and Safety

A health and safety policy statement is to be prepared that describes how we intend
to manage safety. A list of venue safety rules is to be prepared and distributed.
Copies of contractors’ safety policies and risk assessments will be required.

Financials
The conference will be self-funding. Participants are to pay for and arrange their
own travel and accommodation. Venue hire, reception arrangements, catering,
stationery, name badges and other expenses will be covered by sponsorship, a
government grant, fund-raising events and conference fees.

The PM is to establish appropriate systems to control and account for all financial
transactions to include a list of registered participants detailing the amount paid
and when received. Consider too: late registration fees, discounts for students,
deposits and final payments, and methods of payment.

63
Tickets prices are to be set so that the conference will breakeven at 90% of
anticipated attendance. Allow a contingency of at least 10% to cover unanticipated
expenses. Free tickets are only for the project organising team, speakers and
sponsors. Accurate budgeting and prudent financial management are vital for the
success of the conference. Also, the PM is to ensure the follow-up of outstanding
payments and is to produce a detailed financial statement following the conclusion
of the conference as part of the post-project report.

Project Plan and Post Conference

A project plan for the conference is to be prepared for the sponsor’s approval by 1
March 20XX. After the conference the PM is to:

• Resolve all outstanding issues.

• Pay all outstanding accounts.
• Collect and analyse conference evaluations.
• Identify strengths of the conference.
• Identify weaknesses of the conference.
• Assess the extent to which conference benefits have been achieved.
• Prepare and distribute a post-conference report to include lessons learned and
recommendations for the next conference.
• Update the ABC conference risk list.

Other Matters
The ABC Board Chair advises: “Sponsorship provides extra income and reduces
the financial burden for the conference. We must therefore look after our sponsors
and exhibitors with utmost care, making sure their entitlements are fulfilled, they
are fully acknowledged, and we build the rapport that ensures they will come back
next year. I trust we all co-operate to ensure yet another very successful annual
conference.”

Project Charter Approval and Acceptance

The signatures below indicate that the undersigned have agreed to this project
charter and have thus given approval for the project to be planned in detail:

HR Manager: Date:

Project Manager: Date:

Project Sponsor: Date:

64
Our project charter is a critical document in that it authorises the start of the project.
Unfortunately it’s sometimes viewed as a formality in the rush to get a project underway.
The cost of rushing the charter will be felt later during the project with role ambiguity,
slower decision-making and lack of focus. The charter serves as a reference throughout
the life of our project and during the post-project benefit realisation phase. Copies of
the charter might be distributed to the project sponsor, PM, project team members,
functional managers affected by the project, the client, and anyone else who has a
stake in the project.

Project Files

During project conception, the PM would set up a project filing system. Maintaining
information about the project in an organised fashion facilitates new team member
transitions, creates a point of reference for those developing project documentation,
and provides an audit trail for our project. At project completion, the project file may
include items such as:

• Project business case and project charter.

• Product requirements / specifications.
• Project plans and procurement documents.
• Local authority resource consents.
• Contracts with external providers.
• Project audit reports, status reports, timesheets and project completion reports.
• Stakeholder register.
• Logs for lessons learned, risk, issues, variations, and health and safety incidents.
• Photographs and key correspondence.
• Meeting agendas and meeting minutes / action plans.
• Product approval and handover documentation.

At this early stage in the project’s life, stakeholder engagement is initiated as examined
in the next chapter.

65
 Chapter Five

Engaging with Stakeholders

Stakeholder engagement helps us understand what the people involved with our
project want and how best to engage with them to help achieve project success.
There are many reasons why projects may struggle, but a lack of effective stakeholder
engagement is widely acknowledged to be one of the main issues. Stakeholders,
which sounds like something out of Bram Stoker’s “Dracula”, are those people who
can affect our project or may be affected by it. They have a stake in the work or the
resultant product.

There are different types of stakeholders – those who contribute to our project, and those
who are affected by our project - environmentally, socially, culturally or economically.
They may be external or internal to our organisation, each with different needs and
priorities. Indeed, our project may not be at the top of everyone’s personal agenda.
Also it’s a disturbing reality that some stakeholders may not be as co-operative and
helpful as we would like, or in some cases even want our project to proceed.

66
Smaller projects are unlikely to have many stakeholders, but given that happy
stakeholders indicates a successful project, we do need to be aware of who they are
and how best to communicate with them. I prefer to avoid the expression “stakeholder
management” as I have some reservations about the word “manage”, which to me
insinuates that stakeholders need to be controlled in order they don’t upset our
project. Some PMs feel their role with stakeholders is to corral them into obedience.
They must gain their compliance or marginalise them. However, our projects affect
people’s wellbeing and livelihoods, so we owe it to our stakeholders to be ethical
and honest in our dealings with them. Thus, expressions like “communicating with
interested parties” or “stakeholder engagement” seem less patronising or paternalist,
yet not too touchy-feely.

Before we meet with stakeholders some preparatory analysis is usually helpful. Who are
they? How might they be affected by the project? Will they be supportive, negative
or ambivalent? What might be their expectations and concerns? Who else influences
their view of the project? The more we know about our stakeholders, the better we can
plan the project to satisfy their needs and produce the results they expect.

We might ask known stakeholders who else they think should be included in our register
of stakeholders or who they think would most benefit from the project, who they think
might be able to provide advice, or who may not want the project to proceed. As the
project progresses, our list of stakeholders may increase, as it’s only when the project is
being worked on that some stakeholders emerge.

67
 Preliminary Stakeholder Analysis Table

Stakeholder The nature Their likely Their likely The likely The likely What possible
Group? of their level of attitude effect of influence management
(What interest? interest in towards the project of the strategies might
groups or project? the on the group we apply.
individuals project? group? on the
could affect project?
the project (Consult,
or be (High, (Positive, (High, (High, monitor, convert,
affected by Medium or Neutral or Medium or Medium or partner, inform
it?) Low) Negative) Low) Low) etc)

We may get to pick some or all of our project team, but we won’t get to choose every
stakeholder, and as PM it’s our job to undertake stakeholder engagement in order to:

• Understand the needs of those impacted by our project.

• Identify those who have the rights, interests, resources, skills and abilities to take
part in or influence the course of our project.
• Identify and define the attitudes of key stakeholders and understand the manner in
which they might affect or be affected by our project.
• Understand the relationships among the various stakeholders, including real or
potential conflicts of interest and expectation.
• Identify potential winners and losers as a result of our project.
• Clarify, reduce or remove negative impacts and stakeholders’ concerns about our
project and correct misperceptions.
Another important reason for identifying stakeholders is that this may allow us to recruit
them as part of our project effort, which then:

• Puts more ideas on the table than if project development and implementation was
confined to a small group of like-minded people.

• May include varied perspectives from the community affected, thus giving us a
clearer and more complete picture of possible project pitfalls and positives.

• Gains buy-in and support from stakeholders by making them an integral part of
project development, implementation and evaluation. If it becomes “their” project,
they’re more likely to help make it work.

• Seems fair, since stakeholders should have a say in the development of a project
that may affect them. In fact, any time we make a decision it’s sensible to involve
those who will be affected by that decision.

68
 Stakeholder Analysis

• Saves us from being blindsided by unexpected issues. If everyone has a seat at

the table, risks and other concerns can be aired and resolved before they become
stumbling blocks. Even if they can’t be resolved, issues shouldn’t then come as
surprises that derail our project.

• By communicating with stakeholders early and often, we can ensure that they
understand what we are doing and understand the benefits of the project, which
strengthens our position if there’s opposition. Having key stakeholders on board
can make a difference in terms of political and moral clout.

• Creates social capital - a web of acquaintances, friends, family ties, favours,

obligations, and other social currency that can be used to cement relationships and
strengthen our position.

• Increases the credibility of our organisation. Involving and attending to the

concerns of stakeholders confirms our organisation as fair, ethical and transparent,
and makes it more likely that others will work with us in future.

• Allows us to anticipate what people’s reactions to our project will be, and build into
our plan measures designed to win their support.

69
Although stakeholders may be both organisations and people, ultimately we
communicate with individuals. So we need to take care to identify the appropriate
individual stakeholders within stakeholder groups. We may now have a long list of
people and organisations affected by our project, some of which may have the power to
either block or advance our project, and some may be interested in what we are doing,
while others may not care, which information allows us to map or classify stakeholders
on a power-interest grid. So, it’s important to recognise that all stakeholders are not
created equal, some have the potential to generate a much greater impact on our
project than others, and our stakeholder map is not static - it evolves over time.

Stakeholder Power-Interest Map

For example, our CEO is likely to have high power or influence over our project and
also have high interest in it. Our family members or whānau may have high interest,
but may have little power. Someone’s position on the grid suggests the approach we
might then take:

• High power-interested people are those we must fully engage or partner with
and make the greatest efforts to satisfy. Our project customers, whether internal or
external, are primary stakeholders.

• High power-less interested people require enough attention and participation to

keep them satisfied, but not so much that they become bored with our message.
Of course their level of interest could increase as the project proceeds.

• Low power-interested people are kept adequately informed. We consult with

them to ensure that no major issues are arising. These people can often be very
helpful with the detail of our project.

• Low power-less interested people are not of significant priority and shouldn’t
be bored with excessive communication. Of course their level of interest could
increase as the project proceeds.

70
There are a variety of other ways in which to classify stakeholders, one light-hearted
approach is shown here, where for example a project champion would be a person who
is supportive of the project and possesses a high level of power and interest.

Stakeholder Analysis Flowchart

When we engage with our key stakeholders, some useful questions to ask them might
be:

• What interest do you have in the project?

• Are you in favour of the project, and, if so, why?
• If you don’t favour the project, why not, and how might I win you over?
• What information about the project would you like me to provide you with?
• By what means would you prefer we communicated?
• Could you suggest who else might be a stakeholder in this project?

71
People are usually quite open about their views, and asking for their opinions is often
the first step to building a successful relationship with them. They may be flattered that
they have been identified and approached early in the process. Conversely, they may
not be so amenable if they are only contacted late in the project when their influence
would usually be diminished. Here are three strategies for building stakeholder
commitment:

• Engage. The best way to engage with stakeholders is through their participation.
If stakeholders feel part of the project planning, problem solving and decision-
making process, their commitment to the project will usually grow.

• Persuade. If engaging doesn’t work or isn’t possible, the next method is to try to
influence the stakeholder by suggesting how the project will benefit them.

• Reward. If the previous two methods don’t work well, the next option might be to
give the stakeholder an incentive, financial or otherwise, to commit to the change.

Having identified stakeholders, the next thing is to plan our communication with them
so that we might retain their support or win them around to support our project. Some
points to keep in mind are:

• Time needed. The amount of time we should allocate to stakeholder engagement

depends on the level of their influence, our need for their support, the size and
difficulty of our project, and the time we have available for such communication.

• Identify the messages we wish to convey. Decide the messages that we need to
convey to our stakeholders to persuade them to support us and engage with our
project.

• Identify actions and communications. With the time and resources we have
available, identify how we will communicate with our stakeholders – questionnaires,
interviews, newsletters, telephone, email, text messaging, websites etc, focusing
first on our high-power/high-interest stakeholders.

• Get them on-board. Think through what we need to do to keep our supporters
engaged and on-board and work out how to win over any skeptics. Where we need
the active support of people who are not currently interested in what we are doing,
think about how we might raise their level of interest. Also, where appropriate, let
people know as early as possible of any issues that may impact them, and discuss
with them how we might minimise any negative impact.

72
Most stakeholders will appreciate regular updates and status reports. Consult with
them to see how much information they’d like, how often, in what format, and by what
medium. Don’t hide or downplay problems or we might transform them into crises.
If we keep our stakeholders honestly informed, they may turn out to be very helpful
when issues do arise. Yet, despite all our efforts to mitigate disputes with difficult
stakeholders, there will be occasions when issues crop up. In response, there are
things that can be done to resolve issues, gain support and buy-in, and move ahead in
a positive way. Here are a few of the more difficult stakeholder behaviours that we may
sometimes encounter during our project:

• The passive aggressive stakeholder may say they support our project, yet create
obstacles to derail or delay it. They may consistently and unnecessarily find issues
with other stakeholder’s input or contributions, creating unnecessary work, yet all
the while confirming their commitment to the project.

• The antagonist or intimidator may initiate arguments with other stakeholders,

or subtly or overtly put down other’s contributions, creating an environment of
animosity and mistrust.

• The saboteur can be devastating, if not more so because the damage is often
done behind the scenes and is harder to isolate and resolve. Saboteur’s methods,
such as the use of direct action have sometimes led to considerable controversy.
Examples of non-violent direct action (also known as nonviolent resistance or civil
resistance) include sit-ins, strikes, workplace occupations, blockades and hacktivism,
while violent direct action has included assaults, sabotage and property damage.
For example, the current Greenpeace climate change campaign seems to involve
the full range of such tactics.

• The victim of circumstance may look to blame others for work not completed or
missed deadlines and unsuccessful outcomes. There may be times when missed
outcomes can be due to the fault of others, but it’s important to know when this is
really the case.

We may have encountered other non-productive behaviours, or possibly been guilty

of some of these ourselves, but it’s important to note that most stakeholders bring
valuable knowledge and experience to the table. Also, some opposition can be useful
if the purpose is to offer up different perspectives, present alternatives and mitigate
risks for the good of our project, although sometimes the difficult part is being able to
determine a stakeholder’s true intent.

During stakeholder group meetings aimed at clarifying understanding, flushing out

concerns, answering questions, resolving issues, or reaching agreement, there may
be evidence of both positive and negative behaviours. Our aim is to encourage the
positive behaviours and control the negative behaviours. Some tactics to manage
stakeholders in our group sessions include:

• Agree the “ground rules” at the start of the meeting. State what we aim to achieve,
what behaviour we expect, and how we intend to guide the group to keep on
course and get the best contribution from everyone.

73
• Control time assertively, bringing in the quiet stakeholders and closing down the
overly noisy.

• Regularly summarise, gain agreement and move on. Also ensure there are breaks
if it’s a lengthy session.

• Within say 12 hours after the meeting, communicate to all who attended the
meeting to thank them and provide a summary of what was agreed plus any actions
with their agreed ownership and dates for completion.

• If a problem between us and a stakeholder develops into a personal issue, we

need to remember that we are in a professional relationship with our stakeholder
and that can’t be allowed to deteriorate. If the stakeholder gets personal with us
then it’s our job to remind them of this fact. We must work on a resolution with
the stakeholder that doesn’t negatively impact others or impede the success of the
project. However, there will not always be a solution that meets with the approval
of all stakeholders, and in those situations it’s important to at least explain the
reason for our decision.

Stakeholders’ Behaviours

Some Positive Behaviours Some Negative Behaviours

Proposing - putting forward an idea, Undermining - talking down someone

suggestion, or proposal. else’s proposal or idea.

Blocking - disagreeing without reason.

Defending - standing up for an idea “It won’t work!”
or proposal.
Distracting - moving the discussion
Encouraging – supporting, praising off-topic.
and recognising others’ ideas or
building on someone else’s proposal.
Shutting Out - interrupting, ignoring, or
excluding others.
Seeking Information - exploring facts,
opinions, or seeking clarification of
others’ ideas. Withdrawing – not contributing.

Disagreeing - countering with Seeking Recognition - wanting to be

evidence or reasoning. heard or trying to be clever.

Circumventing or ignoring difficult stakeholders’ behaviour is not a strategy that usually

works well. Rather, we should discuss the cause of their concern with them, find an
appropriate resolution and move ahead, while remaining fair, respectful, objective and

74
professional. Some projects may cause staff redundancies, although there may be
suitable alternatives to redundancies that could be explored, such as:

• Change staff employment from full-time to part-time or eliminate overtime.

• Shorten the number of days or hours that staff work each week.
• Stop recruiting staff or using contractors and casual staff.
• Arrange for job-sharing, but ensure respective responsibilities are clear.
• Redeploy affected staff to another position within the organisation.
• Change their employment status to independent contractor.
• Negotiate pay reductions.
• Offer a period of unpaid leave – a sabbatical.

Office Politics

There is no chapter on politics in the PMBOK or PRINCE2 publications, and most of us

view playing office politics with distaste and we’re not good it. But there is no denying
that effective PMs are often those who are willing and able to employ appropriate
political tactics to further their project goal. Projects are rarely easy and office politics
can compound other problems that arise, so such behaviours need to be dealt with
swiftly and firmly. Here are some thoughts:

1. Look at both sides of the conflict. There are always two sides to every conflict,
so we should try and understand both perspectives without losing sight of the
fact that the ultimate goal is a successful project. Be a good arbiter and if we can
understand the underlying reasons for the conflict we are closer to resolving it.

2. Avoid complicating the situation. Don’t listen to overly long explanations of

why someone is behaving in a certain way or why tasks have not been completed;
instead try to cut through the political baggage and simplify the problem. If
necessary employ new ground rules for everyone to follow or even halt the project
temporarily while the problem is resolved.

3. Remind everyone of the benefits for them personally. People can lose sight of
the benefits of a project to them personally once they are embroiled in day-to-day
project tasks, so remind people why the project is being done and what they will
get from it. Of course, job satisfaction is important but if the project politics have
got so bad that they have become a problem then the potential benefits may need
to be something more tangible.

4. Treat people with integrity and honesty. Most people want to trust and be
trusted. Be honest and ethical in our dealings and don’t play favourites. We should
of course treat people the way we would want to be treated, which doesn’t mean
trying to have everyone like us (rarely does everyone like the PM), but we do want
to be known as fair and open-minded.

75
Some further ways to counter office politics and help position our project for success
include:

• Consistently meeting or exceeding the expectations of our stakeholders. Delivering

good results gives us credibility that is not easily negated by the words and actions
of others. This is helped by proactive stakeholder engagement.

• Learn about the political landscape of our organisation. Be aware of how politics
are unfolding around us. Identify the political players in our organisation. Observe
their actions and tactics. Anticipate what they might do next. Identify any power
blocks and alliances. The more we know, the better we can determine an effective
course of action.

• Actively manage our reputation. It’s ok to talk about our successes and to self-
promote in a positive way. And, also we should promote our team and those
stakeholders who are helping with the project’s success.

• Don’t let negative talk fester. If someone engages in negative talk about us, our
team or our project, quickly advise people of the facts.

• Don’t take sides unnecessarily. Try not to become part of an existing power block.
Instead keep our options open.

• Create alliances with people who engage in “good” politics. Recruit people into
our circle of influence by offering them support, encouragement, information,
input, feedback, resources and access to others in our network. Earn their trust
and respect through positive deeds and actions.

• Don’t denigrate others. It’s easy to be trapped into a discussion where negative
sentiments are being expressed about someone, even if we don’t agree. In these
circumstances we might say, “I’m not comfortable talking about them when they
are not present. If you have an issue I suggest you talk about it with them please.”

• “Keep your friends close, your enemies closer” advised Sun Tzu, the author of the
“Art of War”, who understood that we have to be able to think like our enemies
if we want to defeat them. So don’t shut out those who practise “bad” politics –
rather, engage with them and try to understand their perspective.

• Be trusting but expect occasional betrayal. Pragmatic trust is the key to successful
engagement. If we are not prepared to trust people, they won’t trust us.

• Keep power brokers on side. It’s political suicide to alienate those in power. Don’t
disagree with them in public, but rather find ways to make them look good, allow
them to take credit, be a team player, and don’t create problems that make them
look bad. But we need not agree with absolutely everything they do or say – that
may damage our credibility. We must, though, support and remain loyal to those
who can help us most.

76
Some of the biggest risks in projects arise from stakeholders, and we project managers
and our teams need to be aware of these risks and manage them proactively. As
with all risks, there are both positive and negative stakeholders, and it is important to
identify which stakeholders offer opportunities, and where potential threats might lie.

Stakeholder Risk

THREAT IMPACT OPPORTUNITY IMPACT

Low High Low High

High

High
Engage Avoid Engage Exploit
PROBABILITY

PROBABILITY
Low

Low
Monitor Reduce Monitor Enhance

We need to be sensitive to those behaviours that suggest stakeholder reluctance,

resistance or obstruction, which may include:

• Continually asking for more detail before attempting to make any decision.

• Disseminating so much detailed information that no one has a chance of analysing

or understanding it or making a timely decision based upon it.

• Assuring others that the project is important, yet not allocating real time to it.

• Communicating the need for realistic solutions, but dismissing every suggestion as
unrealistic or impractical.

• Disregarding serious project issues with responses such as “I’m not surprised” to
effectively deflate the importance of the message.

• “Head in the sand” attitude towards bad news, possibly demonstrated by a display
of aggression or defensiveness.

• Staying silent, implying that their consent has not been given, and thus frustrating
the whole decision-making process.

• Refusing to commit staff and other resources to the project, either because they are
too busy or because the project is not seen as having a higher priority than their
current business-as-usual assignments or other projects.

77
At the completion of the project we might review the effectiveness of our stakeholder
engagement strategies by asking questions such as these:

• Was the project purpose statement correct?

• Was the project goal correct?
• Were project requirements correctly identified?
• Did needs change during the project due to unforeseen events?
• Were benefits correctly identified and satisfied by the project?
• Were unexpected benefits or disbenefits obtained?
• Were all stakeholders identified at the outset?
• Did new stakeholders appear during the project?
• Did we engage stakeholders effectively?
• Did stakeholders interfere unnecessarily?
• Did any stakeholders fail in their obligations?
• Was every effort made to make the client a participant in project success?
• Was the client asked about their satisfaction with the progress of the project?
• Were there regularly scheduled face-to-face meetings with the client?
• Was the client informed of potential problems?
• Is there a follow-up need to be examined in subsequent projects?

Stakeholder engagement is the process we use to communicate with relevant

stakeholders for the ultimate purpose of achieving our desired project outcomes
and benefits. We PMs who have grasped the importance of actively developing and
sustaining relationships with stakeholders throughout the life of our project, and not
simply during the project conception phase, are helping to ensure project success, and
in particular:

• We should take an early and pro-active approach to engagement and not wait until
there is a problem. And if we make it easy for stakeholders to raise concerns and
feel confident that these will be heard and acted upon, we can reap the benefits of
both a good reputation and better stakeholder relations.

• It’s not practical or necessary for us to engage with all stakeholders at the same
level of intensity all of the time. We should scale the process according to the
stakeholders’ influence, and risks and impacts our project is likely to hold for them.
There is no one-size-fits-all approach. We keep in mind that the situation is dynamic
and that both stakeholders and their interests might change over time.

• Once consultations have taken place, we need to advise stakeholders about which
of their suggestions have been taken on board, and what measures will be put in
place to address their concerns.

78
Effectively engaging with stakeholders is fundamental to project success, as it ensures
higher value outcomes are delivered, misconceptions are corrected, people have a more
positive experience, and risks and cost overheads are reduced. Also, stakeholders can
become project champions. If we have engaged them from the beginning and kept
them involved in or at least abreast of our progress and decision-making, then they are
much more likely to buy into and support our project.

79
 Chapter Six

Outsourcing the Project

Whole projects or parts of projects may be outsourced and completed by contractors.

Contractors are selected and awarded the job, and their involvement usually ends with
the handover of their finished product. Preparing and maintaining the business case,
describing the product scope, developing procurement documents, selecting the
contractor, monitoring their performance, approving variations and contract changes,
authorising and making payments, verifying and accepting products all remain the
responsibility of the client organisation PM, albeit that the contractor or performing
organisation might also appoint a PM. Their respective responsibilities need to be
clear.

Usually businesses choose to outsource projects that don’t pertain to their core
business, such as construction, payroll and accounting, tax preparation, web design,
manufacturing, data entry, research and development, legal services, telemarketing
and corporate training requirements. Outsourcing is an especially useful strategy for
businesses that don’t have the equipment or skilled staff to handle work that requires
special product knowledge. The most obvious advantage of outsourcing is the cost
savings that come with not having to purchase additional equipment, provide office
space and facilities, or having to add to the employee headcount.

Outsourcing means just what it says - going “out” to find the “source” of what we
need. Outsourcing could include both local and overseas contracting. The latter is
sometimes called “off-shoring”, usually motivated by lower labour rates. But some
would argue that off-shoring work to low-paid workers is not an ethical choice, and from
our own workers’ standpoint, outsourcing may contribute to their unemployment and
job insecurity. Some organisations are now doing more themselves in order to develop
or preserve their expertise and self-sufficiency. For example, standing by his election
pledge, USA President Trump is now closing the door on off-shoring to encourage US
manufacturing and the purchase of US-made products and services.

Contracting out work allows employees to focus on their oganisation’s core business.
However, if we do outsource project work, contracts need to be agreed to help ensure
that outsourcing opportunities are realised and associated threats are avoided or
minimised. The resultant contract is essentially a risk management document in which
we aim to have terms to get what we want and terms to avoid what we don’t want,
although of course both parties need to agree to all the terms.

Most importantly, the advantages and disadvantages of outsourcing our project work
are best realised or avoided through selecting the right contractor, rather than by over

80
reliance on contractual terms and remedies. Thus, due diligence is important, which
process involves checking that our prospective contractor can and will do satisfactory
work, although due diligence should be undertaken only where the expected benefits
outweigh the costs of doing so. Likewise, contractors want to be assured that we can
promptly settle their invoices.

Contracting Risks

Opportunities
• We can agree a fixed price.
• A fresh and objective perspective.
• They’re easier to hire and fire.
• Frees up own resources.
• We can avoid undesirable jobs.
• We can learn from them.
• Using them may impress our client.
• Performance penalties can apply.
• We avoid capital investment.
• Competitive pricing.
• We can be selective.
• They want future contracts.
Threats
• Their ability may be over-rated.
• Our schedule becomes less flexible.
• Procurement takes time and money.
• Security and confidentiality concerns.
• Own staff demotivated.
• Conflict and co-ordination issues.
• Our organisation is deskilled.
• We aren’t given priority attention.
• We have less control over the work.
• Scope creep may proliferate.
• They are vulnerable to the market.
• They learn at our expense.

When we outsource project work, there are some sensible practices that we should
observe:

• Do the required due diligence regarding the contractor’s ability and reliability. For
new contractors a test run where practicable with a smaller job might be sensible.

• Do have an early face-to-face meeting to familiarise ourselves with the contractor’s

abilities and help us to establish an effective relationship.

• Don’t reveal our project budget, since to do so may give the contractor an idea
about how much to charge us, although we should accept a fair price.

• Do advise contractors if there is competition, but don’t reveal details.

• Do allow sufficient time for contractors to properly prepare their quotes, otherwise
expect their figures to be inflated to cater for uncertainties. A detailed quote that
shows both labour and material charges, and includes their contingency and profit
margin is ideal.

81
• Do ensure that the contractor has appropriate insurances in place and uses
competent people – preferably those subcontractors who have been pre-qualified
by a third party.

• Do fully review their health and safety record and ensure they have appropriate
systems in place. Advise them of any site hazards and remember that we, their
client, become the “principal” in terms of the NZ Health and Safety in Employment
Act. As the principal we must have a system to make sure that the contractors,
the subcontractors and their employees do not cause harm to our employees or
themselves, or anyone else, while undertaking the work required by the contract.
Outsourcing work to contractors doesn’t remove our obligation to take “all
practicable steps” to ensure contractors and subbies are not harmed while doing
the job – surely a sobering requirement when serious neglect causing manslaughter
might mean several years in a correction facility. Of course, the possibility of
criminal prosecution should not be needed to motivate companies to manage risks.
Everyone is responsible for health and safety on a construction site, big or small,
whether we are the principal client, main contractor or sub-contractor.

• Do have a written contract before work starts. Talking face-to-face is an excellent

way to build relationships, but important information should be written down. NZS
3910:2013 may provide a good base for the contractual arrangements of many
projects.

• Do have periodic meetings with the contractor and monitor their work against the
agreed schedule, quality standards and legislative safety requirements.

• Do be fair and open, don’t exploit the contractor, and should problems arise,
recognise these early and discuss them openly.

• Do co-operate to solve disputes in preference to expensive and often adversarial

litigation. An “arbitration clause” is a provision in the contract that requires the
parties to resolve disputes through private arbitration rather than litigating them in
court. Such arbitration decisions are final and binding.

• Do require that variations suggested by the contractor be approved in writing

(perhaps by an exchange of emails) before they are implemented.

Outsourcing, particularly off-shoring, is sometimes a risky activity, and it’s therefore

important to have a contingency plan to take care of the situation if problems arise.
Remember too that some contractors may under-quote on purpose to get our
business. Then, when they get further into the job, they may demand more money,
citing necessary scope changes. Hence the need for us to be very clear about what’s to
be done (ie, inclusions) and what’s outside the work scope (ie, exclusions), particularly
if we have a firm fixed price contract, when subsequent variations need close scrutiny.

Don’t outsource our company’s competitive advantage. We should retain control over
aspects of our business that make us unique or define our business. Some employees
may feel our decision to outsource reflects poorly on their capabilities. The best
approach is to be forthright with our staff and disclose information promptly once

82
decisions have been made to thus retain their trust and help eliminate fear and rumours.
If work is to be undertaken overseas, consider the risks associated with language barriers,
cultural differences, timezone differences, confusion under whose law contracts will be
administered, and the possible unemployment consequences for Kiwis. Should we
contract out project work, the suggested process is:

1. Decide and document exactly what we want done to what standard and by when.

2. Contact at least two or three reputable and appropriately licensed contractors, give
them each a Request for Proposal (RFP) with the same information and ask each for
a written or email quote (preferably free) rather than an estimate. Before selecting
a contractor for a job, it’s important that we ask them and their clients about their
more recent work. Also, check they have appropriate insurances in place and make
it clear that the lowest or any quote will not necessarily be accepted.

3. Decide which quote we will accept. Consider the price and non-price attributes,
quality of materials and how long the job will take. The contractor must convince us
that they understand our request, can carry out the work in a professional manner,
will provide us with good value for money, and will achieve the intended results.
If we accept a quote, the contractor can’t charge us more than the agreed price.
Make sure the quote includes GST, and since the cost of materials and hourly rates
changes over time, the quote will most likely only be valid for a certain time –
sometimes only seven calendar days, usually 30 days, but occasionally 90 days.
Strictly speaking, if the quote does not mention GST, we are entitled to assume that
the quote is GST inclusive, but best to check.

4. Advise the successful contractor they have the job. We don’t necessarily need to
tell other contractors who won the job or why, although we might provide feedback
to the unsuccessful contractors given it’s in our interests to grow the market. Such
debriefings should include a balanced view of the strengths and weaknesses of
their proposal against the evaluation criteria, and perhaps how they might improve
their chances of future success.

5. Try not to pay a deposit, especially a large deposit, and definitely don’t pay the
total amount before the job is properly finished.

6. Agree the payment method, which might be fixed price (low risk to us but needs
a detailed specification) or cost reimbursement (high risk to us but low risk to the
contractor). So, be wary of a quote that provides only an hourly rate. Prefer a firm
fixed price for the total job.

7. As some projects take months to complete, contractors will want to ensure that
they have some cash flow during the course of the project, so provision should be
made for progress payments usually based on the value of work properly completed
either on a monthly basis or upon completion of readily verifiable stages of the job.

8. Inspect the work to assure compliance with specifications prior to any progress
payments being approved.

83
9. Keep all associated paperwork (quotes, invoices and receipts) and remember that
the NZ Consumer Guarantee Act gives us rights if the goods and services do not
meet the guarantees under this Act.

We use the same process for an estimate, which isn’t a firm or binding offer, but should
be a realistic guess within say 10% of the eventual quote, although this is not a legal
requirement.

For tax and accident compensation purposes, we must decide whether the people
who work on our project are employees or self-employed contractors. It’s important to
note that a person can be self-employed in one line of work and still work for someone
else as an employee. Sometimes there is confusion about whether those we have
employed are contractors or employees, and typical IRD questions to help decide this
issue are these:

• Who decides the work content, workplace, method and hours of work?
• Who owns the tools, equipment, facilities, plant and premises?
• Do they have other clients?
• Do they pay insurances, professional levies, ACC, FBT, PAYE and GST?
• Are they a permanent and essential part of the organisation?
• Are they employed continuously or occasionally?
• Do they have access to the personal grievance procedure?
• Do they receive paid leave?
• Do the parties believe they have an employee or contractor relationship?
• Are they in business on their own account?
• Who assumes the risk and receives the rewards?
• Who is responsible for engaging resources and delivering outputs?
• Does the Consumer Guarantees Act apply?
• Do they have insurance against loss of income and negligence?

A written contract should be agreed and signed before project work starts, and if we
provide project specifications, here are some points to consider:

• Where performance would not be adversely affected, specify off-the-shelf

components rather than one-off specially manufactured items to save cost, reduce
lead-times and help ensure their future availability.

• Where possible specify with figures in preference to adjectives and adverbs. Be

precise and measurable. For example, rather than “light” better to state “not more
than 10 grams.” Rather than “quick” better to state “not less than 20 kilometres
per hour.”

84
• Where performance would not be adversely affected, to help minimise cost and
time, provide a range rather than a single figure. Allow some latitude or tolerance.
For example, rather than “100 grams” better to state “98 – 102 grams.” Rather
than “50 metres per second” better to state “48 – 52 metres per second.”

Should we outsource project work, we need to confirm and control the contractor’s
performance, which may involve any of the following activities:

• Maintain a preferred contractors’ list, approve all sub-contractors, produce effective

solicitation documents and evaluate their proposals fairly and consistently, maintain
confidentiality, and retain records.

• Sign agreements or arrange for their signing, debrief unsuccessful contractors, and
be prepared to justify our selection decisions.

• Negotiate win:win agreements, implement contract obligations, comply with all

applicable legislation, take joint responsibility for the relationship wellbeing, build
trust with the contractor, and pre-empt procurement and contractual issues.

• Identify site hazards and risks, and where appropriate hand over the site to the
contractor.

• Monitor progress and performance, promptly resolve issues, arrange periodic third-
party reviews, have interim and post-contract evaluations, and preferably resolve
any disputes promptly by negotiation.

• Manage variations, retentions, and regularly approve claims for payment.

• Evaluate the final product against specifications.

The contract itself should contain enough information for the intentions of both parties
to be clear. These intentions are set out in the contract conditions and include items
such as:

• Who the parties are, description and location of the job.

• Provider’s responsibilities for design, approvals, and assignment of work.
• Schedules, milestones and completion date.
• Quality testing and defect rectification.
• Payment arrangements.
• Change requests and dealing with unforeseen circumstances.
• Who owns what during the period of the contract.
• Assignment and management of risk and the need for insurances.
• How disputes will be managed.

85
Most contractors are entirely responsible and may typically be guided by the following
practices:

• Manage and control workplace access and security.

• Preserve the profit margin (price less cost) without loss of performance.
• Get agreements in writing – clear, complete, correct and specific.
• Ask for a deposit and be clear when payments are due and if late fees apply.
• Ensure the job is in a known financial state at all times.
• Monitor and maintain progress against the contract schedule.
• Establish a risk and hazard register, and manage risks associated with the work.
• Establish a work health and safety management plan for the site.
• Arrange for first aid equipment, an emergency plan and safety equipment.
• Document all key communications with the client.
• Confirm and claim variations as they arise, rather than let them accumulate.
• Enhance client relationships and behave in a safe, legal and ethical manner.
• Meet (but don’t exceed) obligations under the contract.
• Comply with all relevant legislation – both national and local.
• Settle concerns, disputes and issues properly and promptly through negotiation.
• Ensure all required insurances are in place before work starts.

Should we outsource the project work we need to manage the contract in order to
ensure that risk is minimised and contractor performance maximised, which may involve
any or all of the following activities:

• Determine whole-of-life costs of the purchase and obtain funding.

• Consult interested and affected stakeholders.
• Produce effective solicitation documents.
• Evaluate proposals and tenders fairly and consistently.
• Sign agreements or arrange for their signing.
• Debrief unsuccessful tenderers.
• Be prepared to justify selection decisions.
• Negotiate win: win agreements.
• Pre-empt procurement and contractual risks.
• Identify site health and safety hazards.

86
• Where appropriate hand over the site to the contractor.
• Monitor progress and performance.
• Arrange third-party reviews.
• Implement contract obligations.
• Seek legal advice as necessary.
• Promptly resolve issues.
• Manage variations.
• Resolve disputes by negotiation.
• Comply with all applicable legislation.
• Hold retention funds in trust.
• Maintain a preferred contractors’ list.
• Approve sub-contractors.
• Maintain and retain records.
• Take joint responsibility for the relationship wellbeing.
• Monitor progress.
• Build trust, respect and credibility with contract partners.
• Promptly approve claims for payment.
• Evaluate the final product against specifications.
• Maintain confidentiality.
• Don’t be “bull-dozed” by contractors.
• Use the contract; don’t hide it.
• Have interim and post-contract evaluations.
• Where appropriate implement post-contract recommendations.

87
Procurement and Tender Evaluation

Procurement is the process of acquiring goods and services by a public or private

entity. Private organisations are usually survival and profit-focused, and can source
providers at will and award contracts without a bidding process. However, for more
expensive procurements, government has a transparent, risk-averse and robust process
for procurement by tender.

Whether we are outsourcing work or procuring resources for private enterprise or

government, any tender evaluation process employed should provide for a fair
comparison between the responses we receive. Any conflicts of interest should be
declared and resolved. The same evaluation method should be applied to each tender
response.

The weighted-attributes model is the most common tool used in public sector
procurement. This model seeks to balance the trade-off between price and quality, and
it can be used for goods or services. Under this model, selection criteria or attributes
are each weighted to reflect their relative importance and each submission is scored
against each of the criteria and multiplied by the relevant weighting to give a weighted
score. The weighted scores for each tender or proposal are summed to find the highest
score. Private enterprise is less inclined to provide bidders with the tender evaluation
criteria and their weightings, and are not required to publish evaluation results.

Other than price, which is usually the principal factor, selection criteria might include
the contractor’s experience, track record, methodology, financial circumstances,
compatibility with our organisation, their knowledge, skills, availability, accessibility,
capacity, resources, equipment, materials, health and safety procedures and history,
quality assurance, guarantees, after-sales service, and insurance covers.

Retentions

As the name suggests, retentions, retainage or holdbacks are a portion of a payment

(usually 10%) withheld from a contractor for an agreed defects liability period (often
months but sometimes years) as a guarantee of quality work and to help ensure defects
are rectified. Similarly, most contractors withhold the same percentage payment
from their subcontractors, a practice that has placed subcontractors at risk when
the principal contractor becomes insolvent. However, NZ government has recently
enacted legislation to better protect subcontractors for the work they have done. Also,
retention money can only be used to rectify defects and penalty interest rates now
apply to the late repayment of retention monies. Current NZ retention rates are:

• 10% of the first $200,000 of the value of work completed to date.

• 5% of the next $800,000 of the value of work completed to date.
• 1.75% of any amount in excess of $1 million
• A maximum retention of $200,000 (default) or other sum specified.

88
Contracts

Essentials. A contract is a binding agreement, which to be valid under NZ law must

meet these criteria:

• An offer made by one party must be accepted without qualification by the other
party.

• An intention to create legal relations between the parties must exist and an intention
for the parties to be bound by these obligations.

• A consideration must be passed from one party to the other in return for the
provision of the goods or services covered by the contract.

• Contractual terms must be clear to the parties to the contract.

• Only authorised persons may enter into contracts and contracts must be for legal
purposes.

Standard Agreements. Contractors often use standard form contracts. They are
usually offered on a take it or leave it basis. Sometimes these contracts include a
clause giving the contractor the right to alter the terms and conditions as they see
fit, and might even limit our ability to claim for a breach of contract. This is why NZ
electricity companies can put up their prices, even though we haven’t “agreed” to
this. We can of course challenge such terms, since all contracts are an agreement
between parties and we can terminate a contract when a party to the contract doesn’t
properly complete their part of the agreement, or when the contract can’t be carried
out because of circumstances beyond both parties’ control. And here are two other
relevant items regarding NZ contract law that we should be aware of:

• Postal Acceptance Rule. If we write a letter accepting an offer, the contract applies
as soon as we put the letter in the postbox, unless we are specifically asked to
accept in some other way, or if posting a letter is unreasonable in the circumstances.

• Email. An email message doesn’t necessarily constitute a binding agreement.

Disclaimers on emails help avoid having messages sent for negotiation purposes
only that unexpectedly become enforceable agreements.

Disputes. Dispute resolution procedures should be included in every contract, but

normally we can’t cancel a contract when the other party can still provide their side of
the agreement. But this can change if:

• The contract has a termination clause or termination date.

• The other party agrees to accept our request to cancel the contract.
• We have been given incorrect information in the contract.
• The other party breached an important contractual term.

89
Force Majeure. This French expression that often appears in contracts means “superior
force” and is a clause that allows a party to suspend, terminate, delay or renegotiate
contractual terms. The clause is triggered when certain events outside either parties’
control occur, making the completion of the contract inadvisable, impracticable, illegal
or impossible. Ideally, the specific events that constitute force majeure should be listed
in our contract to avoid later misunderstandings.

Email Contracts. Contracts created via electronic communications, known as

e-commerce contracts are an increasingly popular business practice. Just like any other
form of contract, e-commerce contracts require an offer, acceptance and an exchange
of value. However, these electronic exchanges are sometimes made too quickly, with
scant consideration given to the conditions, which can lead to an unclear agreement,
and possibly not the agreement we thought were getting.

Procurement Fraud. Procurement fraud is about dishonestly obtaining an advantage.

For government purchases examples are:

• Collusion among bidders to reduce competition.

• Providing bidders with advanced “inside” information.
• Submission of invoices for work that was not done.
• Intentional substitution of substandard materials without agreement.
• Use of sole source contracts without proper justification.
• Use of prequalification standards designed to exclude qualified contractors.
• Dividing requirements to avoid tendering and the scrutiny of larger contracts.

Procurement Ethics. PMs must work within the law, and may also be guided by a
code of conduct or ethics, which for government purchases usually includes:

• Declaration of Interest. Contract managers must declare any personal interest

that may affect, or could be perceived to affect, their impartiality in carrying out any
aspect of their work.

• Gifts and Hospitality. Contract managers should not accept gifts or hospitality
from contractors if this could be perceived by other providers as likely to influence
a business decision or prejudice independent judgement. Yet, sometimes its
accepted cultural practice. Maoris call it “koha.” But sometimes gifts are simply
kickbacks or backhanders, provided for services rendered or in anticipation of a
service to be rendered. In many countries it’s how business is done.

• Maintaining Confidentiality. PMs must respect the confidentiality of information

provided by contractors and must not use that information for personal gain or to
influence other providers.

• Invitations to Tender. Specifications and requests for tenders should be sufficiently

general to allow a variety of contractors to bid. They should not be designed to
exclude or include individual providers or specific products.

90
• Fairness. We must not do anything to injure the reputation, image, brand or
business of others.

Contract Interpretation. A contract is a legally binding agreement. However, some

contracts or contract clauses are ambiguous or vague, in which case they are interpreted
according to the following legal principles:

• The content of the contract is paramount. Thus, be wary of “sales talk” or have
such assurances formally included in the written contract. Pre-contractual conduct
or negotiations by the parties are not relevant to the agreement.

• All language is given its ordinary meaning. Where a word has both an ordinary and
a specialised meaning, the ordinary meaning will apply unless it’s proven that the
parties intended that the specialised meaning would apply, usually evidenced by a
glossary of terms in the contract.

• Contracts are interpreted as a whole when determining the intention of the

parties even though the problem may be the meaning of a single word or clause.
The word or clause is interpreted in the full context of the contract purpose and
documentation.

• Contract terms must be definite, precise and specific, otherwise the contract may
be declared unenforceable. Specific terms are given greater weight than general
language.

• When genuinely ambiguous, the document will be interpreted against the party
who prepared it - the “contra proferentem rule.” The reasoning behind this rule
is to encourage the drafter of the contract to be as clear and explicit as possible.

• The “ejusdem generis” (Latin for “of the same kind”) rule means a list is confined
in its meaning to the words that precede it.

• An exemption clause, designed to restrict the rights of those party to a contract, will
not excuse a party from liability for negligence unless the clause does so expressly
and clearly.

• Where the contract refers to other documents, the full text of the other documents
is then part of the contract, and where the contract consists of more than one
document, their precedence needs to be agreed in advance in case of confusion
or contradictions.

Once a contract is awarded, it’s important that the relationship between us and the
provider is actively managed and once the goods or services have been delivered and
accepted, the contract is closed. Closure will involve ensuring that the job has been
properly completed, all financial arrangements have been honoured, all changes to
the contract have been accounted for, and may also involve setting up an on-going
maintenance contract to support and repair the project product.

91
 Chapter Seven

Planning the Work

Most of our time as PMs is spent planning and replanning. Planning, essential for
project success, is the process of making and maintaining a plan. A PM plan is a
statement of intent, not a statement of fact and sometimes people think a PM plan is a
Gantt chart and a budget, but it’s much more than that. It’s a document that describes
how our team will work on the project and covers how the work will be executed,
monitored, controlled, closed and benefits realised. A lack of adequate planning is the
single most common cause of project failure and is usually our single most important
activity as a PM.

While things change when we begin working on a project and we identify things that
we didn’t know at the start, having a plan means that we’ve thought through what
happens and have a basis for such changes. Although, the later we make a change
usually the more it costs, and the more likely the change is to create other problems.
While project plans must be customised to meet the needs of each project, historical
information from similar projects may help us plan. It’s about learning from previous
successes and mistakes. When our project is completed we should archive the various
versions of our project plan and lessons learned so that other PMs can benefit from our
experience.

We’re all PMs at some time, but not everyone knows how to plan a project. Also, it’s
said that there are no good PMs - only lucky ones. But the more we plan the luckier we
get, particularly if our project plan clearly answers Kipling’s what, where, when, how,
why and who questions. Our plan shouldn’t leave any of these items unanswered,
otherwise the project may have a bumpy ride causing a lot of finger pointing in our
direction.

A project kick-off meeting formally recognises the start of the project planning phase.
A kick-off meeting may also be held at the start of project execution. During this initial
kick-off meeting, we share our vision for the project, and guided by the approved
project charter, we explain why we’re doing it, why it’s important, and how it aligns with
organisational goals. We use this meeting to ensure a clear and common understanding
of the project, to discuss roles, and to clarify the steps needed to produce our project
plan. This meeting also allows our sponsor to relay the organisation’s commitment to
the project and provides an opportunity for us and our project team members to review
the charter and ask questions to ensure we fully understand it.

Kickoff is also an opportunity to formally acquaint everyone. It’s important to develop

a team culture where everyone feels engaged, involved, heard and respected. To do

92
that, we need to get to know the team. Project team members should introduce
themselves, describe their skills, and explain how they propose to contribute. During this
meeting we should establish an expectation of collaboration, encourage participants to
share ideas and ask questions, and allow time for networking after the meeting. If team
members are unfamiliar with each other or are embarking on a particularly challenging
project, consider including a team building exercise at this initial meeting to help
everyone interact and feel more at ease. This occasion may also be an opportunity to
walk team members through the project site if it’s that sort of project.

Project Planning Process

There is something sadly wrong with organisations that reward firefighting and project
heroism, by which I mean running around trying to sort out a project when it should
have been planned properly from the start. Yes, sometimes projects need rescuing but
this should be the exception, not the rule.

The PM plan is the core tool at the heart of PM and is the key to controlling the
progress of the project. Project planning culminates in the production of an approved
PM plan. This artifact is important because it provides essential information for the
project execution, closure, change management and post-project benefits realisation
phases. Planning is usually a collaborative effort and the planning process has the
following benefits:

• Ensures the team understands the project purpose and goal.

• Ensures we think about what must be done to achieve the goal.
• Provides a basis for communication with our team and other stakeholders.
• Ensures focused energy, creates buy-in, and gets everyone on the same page.
• Allows the team to proactively address project risks.
• Allows for best use of our scarce resources.
• Produces a basis against which progress and effectiveness can be measured.
• Provides a defence against unrealistic deadlines and budget cuts.
• Produces delegation-sized work packages for team members to undertake.
• Provides for change management, product maintenance, user training and post-
project benefit realisation.

Although planning is a participatory process, we PMs spend more time planning and
need to look further ahead than anyone else on the project team to nullify threats and
capitalise on opportunities as we work towards achieving our project goal. Once work
is underway our team members are more likely to be preoccupied with their assigned
project tasks.

93
A PM plan is finalised or baselined when it’s formally accepted and approved by the
project sponsor. Formal approval acknowledges that the plan is completed, reviewed
and accepted. The PM’s and sponsor’s signatures on the PM plan document indicate
this approval. This sign-off marks the plan as the go-forward agreement. However,
there will be occasions when the plan is not approved due to changed circumstances,
and doubtlessly, during the project execution phase some changes to this baseline
plan will be needed as reality unfolds, but we shouldn’t make changes to the baseline
to accommodate poor performance. Rather we maintain the baseline so that poor
performance is disclosed.

Planning is not a one-off activity; the plan evolves through the life of the project. We
don’t have perfect knowledge of everything that will happen in the future. It would be
foolish to adhere to an original plan that is proving to be unsatisfactory. Updating the
plan to reflect current information is a key PM function. Plan version control is therefore
important to ensure we are all working to the latest update.

We might ask, “What is the minimum level of planning required for a project?” I
suggest that the following six-step approach will help answer this question:

1. Identify the Work. The PM books office space and gathers the planning team
for the kick-off meeting. Team members usually discuss the charter and develop a
task list or Work Breakdown Structure (WBS), which is a “family tree” of successively
smaller chunks of work that need to be completed to achieve the project goal, the
lowest levels of which are called “work packages.”

2. Analyse the Work. Once the work has been decomposed into work packages,
these packages are each analysed to more accurately determine resource needs,
performance standards, costs, work effort and durations to produce a “bottom-up”
estimate of some greater accuracy than the original “top-down” or conceptual
estimate.

3. Sequence the Work. Now we decide the “logic” of our project, which recognises
the relationships between work packages often illustrated by network diagram.
This output is an analytical tool that enables us to identify the project critical path,
estimate project duration and completion date, and undertake a variety of “what-
if” assessments.

4. Schedule the Work. The schedule, or work timetable, is prepared and published
as a table or Gantt chart, showing what work is to be undertaken when (calendar
dates) and by who. A variety of software packages are available to assist us with
this scheduling activity. The result is a resource schedule that shows who and what
is needed when. It’s the basis for project procurement activities.

5. Prepare the Baseline Plan. The PM plan is now completed with sufficient
information to ensure the successful implementation and completion of the
project. It’s a roadmap that shows how the work scope will be accomplished within
defined parameters and includes details about change management and benefits
realisation.

94
6. Pre-empt Problems. The baseline plan is subject to careful analysis, often
involving key stakeholders, to identify possible deficiencies and potential problems
and appropriate responses, which may then necessitate some revision to the plan.
At this step we aim to “future-proof” the plan, although risk management is a
continuous activity throughout the life of our project. Once finalised, the baseline
plan is presented to our sponsor for approval. Should the plan be approved and
its implementation authorised, the project moves to the next phase of its life –
execution.

Most organisations have standard policies and practices for PM, such as project planning
templates, reporting policies, risk tolerances and quality standards. Reviewing these
before planning starts makes our work easier. Although plans must be customised for
each project, historical information from similar projects may provide useful data about
work needed, estimates of time and cost, risks, schedules, and lessons learned.

Let’s now consider each of these planning steps in more detail, appreciating that the
process isn’t necessarily sequential, given that previous steps may need to be revisited
as circumstances change. For example, an approved scope change may necessitate a
reassessment of the budget, schedule, risk and benefits.

Given an approved project charter, we PMs usually hold a project kick-off meeting with
our planning team members at which:

• Our project sponsor typically emphasises the project’s importance, discusses

the charter, planning constraints, authority limits, issue escalation and progress
reporting arrangements.

• Our project planning team may determine their modus operandi and develop their
operating agreement or team rules.

A key benefit of planning is that we gain greater clarity on how long work actually
takes versus how long we first thought it would take. This can lead to some frustration
initially because we have to face the fact that the reality is different than what we
hoped. Planning also doesn’t mean that everything will go according to schedule. But
it does allow us to know early on if something goes off-course, so we can do something
about it.

The commonest cause of plans going wrong is the tendency to under-estimate the
time, cost or resources needed. This is often due to over-optimism about what we can
achieve, but is also sometimes the result of political pressures within our organisation
or commercial pressures when we are working for a client.

Once the PM plan gets approval, we baseline the document and ensure there is a clear
and transparent process in place for managing further changes – variations. A baseline
is a fixed scope, schedule and budget that represents the standard used to measure the
performance of the project. After our project begins, we compare baseline estimates
to current performance to calculate variances, which are deviations from our planned
expectations.

95
 Possible Team Contract

We, the undersigned, will:

• Be punctual and properly prepared for all meetings and

implement all decisions properly and in a timely manner.

• Be open and honest with each other.

• Decide as a team the best way to communicate, keep each other

informed and resolve conflict.

• Focus on problem solving; not blaming.

• Use only constructive criticism.

• Practise participatory planning, problem solving and decision-

making.

• Practise active listening skills and ask questions to clarify as

required.

• Be prepared to carry out our assigned team decisions.

• Recognise we are all of equal rank, everybody is important, and

we all have equal opportunity to contribute.

• If we have an issue with another team member, we will resolve it

with them in a timely and non-confrontational manner.

• We will complete our work assignments properly and on time.

• We will celebrate our milestone achievements.

96
 Chapter Eight

Creating a Work Breakdown Structure

To be useful our project goal should comply with “SMART” criteria, an acronym with
various interpretations, used to provide a more comprehensive definition for project
goal setting, where “S” means specific, significant, stretching, “M” means measurable,
meaningful, motivational, “A” means agreed, attainable, achievable, acceptable,
action-oriented, “R” means relevant, realistic, robust, and “T” means time-bound or
timely. To these attributes I would add the need for clarity and the need to write the
goal down for display throughout the planning process to ensure we remain focused.

Our project goal might be “To plan and deliver a three-day annual conference for
(organisation’s name) to be held in (location) during the period (dates).” If for example,
we don’t know where the conference is to be held, determining the conference location
would then be a project planning task. My preferred interpretation is that the project
“goal” is the “what” and is product focused (eg, “to build a house”), whereas the project
“purpose” concerns the reason for the project, the desired end result, or the benefit
to be realised (eg, “to provide shelter”), and project objectives are the “how” that are
subordinate to the project goal and specifically define project boundaries, parameters
or constraints that include scope, time, cost, quality, risk and benefits. Sometimes the
terms goals, purposes and objectives are used interchangeably and loosely.

Lacking a project purpose and/or a goal is usually a show-stopper. Keeping our project
purpose, goal and objectives in the forefront of every project ensures that our project
and our team are on the same page throughout the project’s lifecycle.

Work Breakdown Structure

Underpinning much of PM is the need to break down the work into self-contained
chunks for easy management. Thus, having clarified the project goal, the planning team
brainstorm the work to be undertaken to achieve this goal. The result is illustrated as a
project Work Breakdown Structure (WBS), which is essentially a family tree of work and
a most useful tool as it’s then the basis for PM budgeting, scheduling, and controlling
activities. Involving the team in creation of the WBS helps to create their buy-in to the
planning process and the resultant plan.

Work chunks are described in verb-noun format (eg, “write report”). This helps
distinguish work from an event (which in PM language is the start or finish of an element
of work) and from the resultant product (eg, “report”).

97
A key event may be identified as a milestone, such as the completion of an important
task. The reasons for breaking the project down or “chunking” it are:

• To further define the project work scope and allow for the codification of work
elements to enable their easy reference.

• To enable us to more clearly identify resources (equipment, materials and skills)

needed to complete the project.

• To enable us to determine what work can be done in-house and what work we will
need to outsource.

• To allow for the assignment of clearly defined elements of work to the project team
members and contractors responsible for their completion.

• To enable us to produce a “bottom-up” time and cost estimate, which is invariably

more accurate than the initial “order of magnitude” or “top-down” estimate.

• To allow for the identification of task relationships (dependencies) and thus enable
the development of a network diagram and a schedule of work often illustrated by
Gantt chart.

• To enable us to identify, analyse and respond to risks associated with the various
project tasks.

• To facilitate measurement of project progress by completed elements of work.

The need to delegate coherent chunks of work may require that work be broken down
until the different skill needs emerge, at which level there is usually no need to further
break down work assigned to team members. They may further break down their
assigned work packages as they need to, otherwise us PMs can appear to be directing
people, usually more technically skilled than ourselves, on how to do their work -
micromanagement.

The WBS takes the project scope and translates it into work packages (also referred to
as activities or tasks) that need to be undertaken to create the product scope. In effect
these work packages or tasks are each small projects any of which might be outsourced.
The WBS then becomes the basis for determining resource needs, estimating costs
and scheduling the work. For costing and scheduling purposes the WBS also needs
to include PM activities such as teambuilding, training, travel, administration, planning
sessions, meetings and reporting, all of which take time and incur a cost. Usually
we simply add a percentage, typically 10%, to the project budget to cover such PM
overheads. Some would argue that PM activities are not an overhead expense, but
a value-add item, which is true assuming that the benefits exceed the costs involved.

What determines a project’s scope is the product that the project intends to produce
with its desired features and functionality, called the product scope. The project scope
includes everything we need to do to ensure the product scope is achieved. So project
scope and product scope are inextricably linked. We need a well-defined product
scope in order to reverse engineer an accurate project scope.

98
WBS Hierarchical Design

WBS - House Build Project

Project and Product Scope

99
The purpose of creating a product scope or specification is to clearly define the
requirements and capabilities for our project’s final product or products. Once we
are clear about what the project is to produce, user requirements may then be sought
and prioritised, which is needed if there are budgetary constraints that mean the
final deliverable may not have all the bells and whistles that all stakeholders desire.
We use this specification to determine the project scope. Should we be involved in
the preparation of a specification some points to keep in mind in order to minimise
misinterpretation and costs are these:

• Use plain English, avoiding legalese and jargon and restricting vocabulary to words
in common usage. Avoid acronyms and abbreviations, unless they are very well
known. And remember “a picture is worth a 1000 words,” which includes drawings,
photos, videos and sketches, whereby a complex idea can often be quickly conveyed
with a single image.

• Consider developing an open or performance specification that describes required

performance without mandating how this performance is to be achieved. An open
specification leaves freedom for the project team or contractor to create a suitable
product. Such specifications must state the acceptable conditions under which the
product is to perform. Most projects will involve a combination of performance and
prescriptive specifications.

• Use the word “shall” to define a requirement rather than “should” or “could.”
Requirements expressed as “shall” must be fully and properly met.

Once the project scope is clear it may be illustrated as a WBS, which for a simple
project is essentially a task list or “to-do” list as for the following recruiting and selection
project:

WBS - Recruiting Project

ID Task Descriptions

1 Conduct Job Analysis

2 Prepare Job Description
3 Prepare Person Specification
4 Decide Remuneration Range
5 Advertise Position
6 Shortlist Applicants
7 Arrange and Conduct Interviews
8 Conduct Testing
9 Arrange and Conduct Final Interviews
10 Check with Referees
11 Make Job Offer
12 Negotiate Employment Contract
13 Advise the Unsuccessful

100
For bigger and more complex projects the WBS usually looks like an organisation
chart. Using MS Project terminology, “Summary Tasks” break down to “Tasks” that
break down to “Subtasks” and so on with default codes assigned. The lowest levels
of breakdown or terminal elements are often referred to as a “Work Packages” (WPs).
Other scheduling software and methodologies may use terms such as “phases”,
“entries” or “activities.”

WBS - Recruiting Project

101
Each chunk of work is usually assigned a unique code for easy reference. A useful
codification system is readily expandable to accommodate any extra work that may be
identified as a result of variations. The following example shows a codified WBS for a
landscaping project. This example includes estimated work package durations where
“d” is an abbreviation for day. A costed-WBS (CWBS) would also show estimated
costs. If we use MS Project it will automatically produce a default number for each task,
the first task in our task list would be number 1. If that task has three subtasks, these
subtasks would be number 1.1, 1.2, and 1.3 and so on.

A WBS may be developed using Post-it Notes on a flipchart page, although these are
inclined to fall off, which is possibly why the planning team photographed in action on
the next page isn’t using them. Anyway, by placing these notes on the chart we create
a family tree structure that allows everyone involved to clearly see and contribute to
what is being produced. There may be a WBS from a previous project that we can use
as a start template.

WBS - Landscape Project

Once the initial WBS is established and agreed it becomes a basis for change. Change
to the scope will occur as our client’s needs evolve, new technology becomes available,
costs escalate, etc. Such changes or variations need to be carefully managed and
their costs and other consequences determined and explained to the client and other
stakeholders as appropriate. During project planning and execution it may be necessary
to reduce project scope as a means of achieving the project time and cost objectives.
This may reduce the functionality of the product. Project scope might also be reduced
to eliminate a risk.

102
Below is another blurry photo of an erudite project team member with his first draft of
a WBS for a construction project where task responsibilities are colour coded.

While a WBS is usually prepared in family tree format, it’s often published as an indented
task list if only to save space as shown on the following page for this landscaping
example taken from the PM Institute’s PMBOK (PM Body of Knowledge).

103
 Landscape Project

Once the WBS brainstorming session is done we need to edit our result by eliminating
any duplication of tasks and any tasks that are outside the project scope (“exclusions”).
Also, some tasks might be too small and others may need to be broken down further.
The finished product can then be published in either hierarchical or list form.

A WBS is not to be confused with a Product Breakdown Structure (PBS) that identifies
the component sub-products needed to produce the final project product. The PBS
might be thought of as a project shopping list. It decomposes the final project product
into its constituent parts. From the PBS a Product Flow Diagram can be produced to
show the order in which components build into the main project product, which seems
simple enough until we attempt to follow the PRINCE2 unnecessarily complicated
procedures and symbols.

104
 Partial WBS - Adele Concert

Project Level One Level Two Level Three

(summary (tasks) (subtasks)
tasks)

Hold Concert 1. Market

2. Venue 2.1 Find Possible Sites

2.2 Visit Sites

2.3 Select Site

2.4 Organise Stage 2.4.1 Arrange Power

2.4.2 Build Stage

2.4.3 Set Pyrotechnics

3. Advertising 2.4.4 Do Rigging

4. Performance 2.4.5 Sort Graphics

5. Close Down 2.4.6 Set Up Sounds

2.4.7 Arrange Filming

2.4.8 Arranging Lighting

2.5 Organise Amenities

2.6 Decide Access Egress

2.7 Set up Media Facilities

3. Advertising

4. Performance

5. Close Down

In contrast to the PBS, the WBS focus is on work and things (eg, “create PM plan”
not simply things (eg, “PM plan”). The PRINCE2 project methodology advocates
that planning should be focused around products rather than tasks, whereas all other
methodologies don’t require a PBS in order to produce a WBS nor do they use a
Product Flow Chart. Thus, a PBS shows products and a WBS shows the work required
to produce them. On the next page is an example PBS that shows the relationship
among components for a mountain bike.

105
 Product Breakdown Structure - Mountain Bike

When developing the WBS we must decide when to stop dividing work into smaller
elements, which decision is influenced by considerations such as:

• The size of the project. A large project is likely to be broken down further than is
a small project. For a small project three levels of breakdown is usually sufficient.

• The project work should not be broken down below the level where each element is
a clearly definable and independent entity of work, its start and finish and resource
needs readily apparent, and results in a measurable output. It’s sometimes suggested
that a task should not be less than 8 hours or more than 80 hours, referred to as the
8/80 rule, but I’ve found no convincing justification for this particular rule of thumb.
For smaller projects, many tasks are appropriately less than eight hours duration.

• Tasks must add up to summary tasks. Summary or parent tasks are mainly for
communication purposes and aren’t executed. They are simply the summation of
related subordinate tasks. Only tasks are assigned resources.

• When the project completion date is firmly fixed, the work timetable (ie, schedule)
will need to be carefully controlled. This may require that no work package exceeds
a specific duration. Thus, the need to carefully track time may influence the level of
breakdown. For example, it may be appropriate for control purposes that no task
exceeds five days’ duration.

106
• When the project budget is firmly fixed, expenditure will need to be carefully
controlled. This may require that no work package exceed a certain cost to enable
more accurate control of expenditure. Thus, rigid funding/expenditure limits may
also influence the level of breakdown and the monetary size of work packages. For
example, it may be appropriate for a cost-constrained project that no task exceeds
an estimated cost of $1,000.

• Sometimes to help with clarity we also mention “exclusions” – those items outside
the project scope. For example, if we don’t require that our house-building project
includes painting then this exclusion should be mentioned. House painting might
be a separate and subsequent project.

• While the lowest level of breakdown will depend largely on project size, it would
often be a waste of time and effort to plan a long duration project in detail, other
than for the first stage. Thus, more immediate work might be broken down further
than is subsequent work. This allows for a rolling-wave or progressive elaboration
approach whereby we prepare in detail for the next stage only when project
continuation is confirmed and sufficient detail is available about the on-going
project scope.

In summary, the WBS provides a global, yet detailed view of the project work scope
and becomes the basis for time, resource, cost, risk and quality planning, and for work
allocation, control and progress reporting. Accurate scope definition clearly showing
inclusions and exclusions is critical for our project’s success. When developing the
WBS, we should involve the people who will do the work.

107
 Chapter Nine

Analysing the Work

Once the WBS is prepared we can then analyse the identified work to produce detailed
“bottom-up” estimates of time and cost at work package level. The Oxford Dictionary
defines an estimate as, “an approximate calculation or judgement of the number or
quantity of something.” Estimating is the process by which we determine how long a
project will take and how much it will cost. Estimating is difficult and the key thing to
remember is that an estimate is only an estimate. The project’s estimated work effort,
duration and cost are living things throughout our project life and should be revisited
when anything significant changes in our project or when we know sufficiently more to
further refine the estimate.

There is no such thing as an exact estimate, whereas an accurate estimate or 50:50

estimate has the same likelihood of being too little as it has of being too much. We
usually only know exactly how long our project takes and how much it costs when it’s
done. Yet as PMs we’re often seen to be as good as our estimates, illustrated by this
diagram analysing time and cost:

Estimating Failure

108
There are many different ways to predict the duration, work effort and cost of a project.
Here are some of the most common techniques:

• WAG Estimation. A WAG or “wild-arse guess” is an off-the-cuff or order-of-

magnitude guesstimate for the cost or completion date for a project, used when
there is insufficient data available to support a more informed estimate. The SWAG
(scientific or stupid wild-arse guess) variation probably involves the use of a math’s
calculator.

• Top-down Estimation. Top-down estimation is based on a high-level WBS whereby

the entire project is estimated to obtain a rough result.

• Bottom-up Estimation. Bottom-up estimating or WBS estimating involves

estimating each piece of project work at work package level and then summing the
estimates. It’s usually the most time-consuming project estimation technique, but
also the most accurate.

• Delphi Technique. Also known as expert judgment, the Delphi technique relies on
surveying experts independently and then averaging their responses. It’s as good
as the experts we ask. The name “Delphi” derives from the Oracle of Delphi who
according to Greek mythology was a priestess who could predict the future.

• Parametric Estimation. Parametric estimating uses mathematical models, such as

cost per square metre or cost per tonne to develop an estimate.

• Comparative or Analogy Estimation. When similar projects have been undertaken

in the past, these may provide us with the data needed to produce an estimate.
This technique clearly can’t be used for unprecedented projects.

• Three-point Estimation. Often, three-point estimates can be combined with other

estimating techniques to produce a more rounded set of values. As the expression
suggests, this technique takes three inputs – the best case, the worst-case and the
most likely, and then averages these three figures: (O + M + P) / 3.

• PERT Formula. PERT (Programme Evaluation and Review Technique), developed

during the US Polaris Missile Project 1960, provides a weighted average estimate
given estimated Optimistic (O), Most Likely (L) and Pessimistic (P) durations or
costs: (O + 4L + P) / 6. PERT aims to account for uncertainty. This typically beta (β)
frequency distribution recognises that here is a limit to how quickly a job might be
completed, but very little limit to how long it could take. Imagine that an Optimistic
estimate is 6 days, a Pessimistic estimate is 20 days, and the Most Likely is 10 days.
If we use the PERT estimation technique, that gives us a Best Estimate of 11 days
and a standard deviation (σ) of 2.33 days calculated by the formula (P-O)/6.

Here’s another PERT example. Say we estimate that writing and designing an e-book
will take 20 hours. That’s our best guess. Now we consider the risks. If the client
approves the e-book upon the first delivery, that’s the best-case scenario. Our optimistic
estimate might then be 15 hours. If the designer is late delivering the files, the expert
is not immediately available for an interview, and the client requires three rounds of

109
revisions, the pessimistic estimate might be more like 30 hours. In this example the
result is {15 + (4 x 20) + 30} / 6 = 21 hours.

PERT Formula

The following table shows PERT calculations for a project of four sequential critical
path tasks, were project duration is calculated at 48.5 days – a single figure due to the
Central Limit Formula (CLT) that says even though the individual task durations follow
the beta distribution (or any other distribution), when they are added up, the resulting
distribution (of project duration) is always Normal.

PERT Calculations

Task O L P PERT

A 7 10 13 10.0
B 6 8 16 9.0
C 6 12 15 11.5
D 10 17 30 18.0

Totals 48.5

110
Chunking the project enables those people with the requisite experience and skillsets
to more accurately estimate resource needs, work effort, duration and cost at WP level,
to produce a project bottom-up estimate against which our financial performance
might be assessed. Some common estimating issues include being too optimistic, not
being clear about what we’re estimating, not factoring in everything that needs doing,
and not distinguishing between effort and duration. Some key points are these:

• Check we’ve identified all the work to be done, including all those jobs we do as
PM – managerial overheads.

• Ask two team members to separately produce estimates for the project. If their
numbers are close, we can be more confident about their accuracy. If they differ
widely, we should discuss why.

• Ask the experts for their estimates, but take into account any tendency they may
have to be overly bullish (ie, an optimism bias) or too cautious. Estimates provided
by those without hands-on expertise will be educated guesses at best. Ideally,
the numbers will come from the team members who will be doing the actual work.
After all, each person has their own work speed and people will be more motivated
to make finish dates and budgets that are based on their own assessments. But
watch for padding - that extra amount randomly added as a safeguard against the
unknown. To pad is bad – it’s unethical and may deprive other projects of funding.

• Don’t confuse elapsed time, duration and work-effort. Elapsed time includes
weekends and statutory holidays, duration is measured in workdays, and work-
effort is measured in person-hours or person-days. Work effort is the usual basis
for costing labour.

Effort, Duration and Elapsed Times

Terms Effort Duration Elapsed Time

What is it? Number of work Time taken to Time between

units to complete complete a task. starting a task until to
a task. the completion of the
task.
What’s it Person-hours, Work hours, work Work hours, work
measured days or weeks. days or work weeks, days or work
in? but excludes weeks, and includes
weekends and weekends and
statutory holidays. statutory holidays.

Example If we work 6 hours If we work 6 hours If we work 6 hours

a day for 9 days, a day for 9 days, a day for 9 days,
work effort is 54 duration is 9 days. elapsed time is 11
hours. days.

111
• Check with those who have done similar projects recently, review any relevant
historical data, reports, lessons learned, and consult published productivity data.
However, estimates based on memory are subject to the cognitive bias of the
estimator, therefore involvement of others usually helps provide some balance.

• Use normal work-package team sizes for estimates. Sometimes it’s not practicable
to add more people or do a particular task with fewer people. And if a task takes
one person two hours, don’t think that 120 people could do it in one minute.

• Where appropriate, conduct trials or dummy runs or build prototypes.

• Focus particularly on the more expensive tasks (Pareto Principle or 80:20 Rule)
given that if we’re 10% out with a $100 task it usually doesn’t matter too much,
whereas 10% out with a $100,000 task does matter. Focus most of our effort on the
important few, rather than the trivial many.

• Adopt phased estimates (rolling wave strategy) to re-estimate in waves as our

project proceeds and details become clearer. Work that is imminent is estimated in
detail, while work that’s some time off is estimated at a higher level. All estimates
need to be re-assessed as more details become available.

• Allow for the unexpected – a contingency sum to cater for identified risks and
approved scope changes, and a management reserve to allow for unidentified risks.

• Learn with experience – update our estimating database.

• Identify and allow for all factors that may affect time such as setup time, learning
curves, weather, weekends, work hours, holidays, skill levels, machine variations,
industrial action, sickness, fatigue, and staff turnover. Climate change means that
weather and “wet days” are now less predictable.

• Find out current labour and material costs, insurance rates, interest rates and
exchange rates for costing purposes.

• Assume people will be productive for no more than 80 percent of their work time,
and recognise that those working on multiple projects take longer to complete
tasks because of the time lost switching between them. Even when people are
assigned full time to our project, they will not spend all day every day working on
it. Most PM software tools allow us to set up an availability profile for our resources,
with task durations automatically adjusted to reflect this availability.

• Be cautious about scheduling overtime since an eight-hour day might easily become
a 16-hour day depending on how project work proceeds. Working overtime is a
contingency we might need to use during execution.

• Develop a spreadsheet, document estimate assumptions, and include the estimate

date and its author. When generating estimates, we’ll often have to base them on
assumptions, especially when requirements are not well defined. Thus, we need
to record these assumptions with our estimates so that this information is available

112
 to others who might need to know how our estimates were derived or need to
update our estimates.

• Strenuously resist calls to reduce our estimate without a commensurate scope

reduction. If it’s proposed to reduce our budget we need to recommend how this
might be achieved – perhaps by using cheaper materials or by reducing product
functionality.

• Provide estimators with feedback on variance – the difference between their

estimates and actual costs and durations.

• Consider using the Delphi technique whereby we gather estimates from several
experts and take an average.

• Use PERT (Programme Evaluation and Review Technique) to obtain a weighted

average estimate of time or cost.

• PMs and team members should feel free to challenge estimates. If something
doesn’t feel right, ask questions and offer solutions. If disparities crop up they may
be due to different understandings of what’s required.

• Recognise Parkinson’s Law that states “work expands to fill the time (and budget)
available,” and Murphy’s Law that states “if anything can go wrong it will,” which
requires we manage the risk and may include contingency money or time for known
but accepted risks.

The total project budget is the baseline estimate plus the contingency reserve plus
the management reserve, where the baseline is the cost of all WBS tasks including
PM overheads. A quote received for any outsourced work will include a profit margin
and GST. The contingency reserve is for anticipated or known risks, whereas the
management reserve is an allowance for unanticipated or unknown risks and variations,
but without detailed history of costs the management reserve is difficult to estimate
and if established is held by the project sponsor.

The contingency reserve is not a slush fund for bailing out the project and may be
determined by costing identified risks and is often reduced as the project proceeds
should these risks not occur. Given the table on the next page, probability theory tells
us that the likelihood of say both risks A and C occurring is 10% x 40% = 4%. Risk D
is an opportunity - money saved.

Another way to determine our project’s contingency is to first decide what level of
confidence we would like for on-time project completion. The PERT formula provides
a 50:50 duration estimate whereby there is the same likelihood of the actual duration
being greater or less.

113
 Contingency Calculations

Project Duration Confidence Level Calculations

O L BET P
22 40 47 100

Where:
O + 4L + P O = Optimistic (best case)
BET = L = Most Likely
6
P = Pessimistic (worst case)

If the BET = (O + 4L + P)/6 = (22 + 160 + 100) = 47 days, the Standard Deviation =
(P - O)/6 = 13 days, and Contingency = Standard Factor x Standard Deviation. The
Standard Factor is the same for all projects. As with all estimates, the accuracy of these
answers depends on the accuracy of the input data. To save us from these laborious
calculations, if they are really needed, we could invest in some pricey software such as
@Risk or Crystal Ball to run a Monte Carlo simulation to determine for example what
project cost or duration would provide us with the confidence level we require, or what
are the chances of finishing our project within budget and on time.

114
 Confidence Standard Project Duration
Level Factor (BET + Contingency)

50% 0.00 47 + (0.00 x 13) = 47.00

60% 0.25 47 + (0.25 x 13) = 50.25

70% 0.53 47 + (0.53 x 13) = 53.89

80% 0.84 47 + (0.84 x 13) = 57.92

90% 1.28 47 + (1.28 x 13) = 63.64

95% 1.65 47 + (1.65 x 13) = 68.45

99% 2.33 47 + (2.33 x 13) = 77.29

Doing time and cost estimating accurately is often the difference between consistent
project success and frequent failure. Organisations often judge whether our PM has
succeeded or failed depending on whether or not our project has been delivered
on time and on budget. To have a chance of being successful as a PM we need to
negotiate realistic budgets and achievable deadlines. We might check our estimating
prowess with the following questions:

Estimating Checklist

Questions Yes No

1. Before I undertake an estimating job I always find out the level

of accuracy required for the estimate.

2. I always clarify the project outcomes and scope of work. A

clear and unambiguous scope definition is essential for accurate
estimates.

3. I always include contingency in my estimate to allow for predicted

risks, but never to compensate for my lack of estimating aptitude.

4. I find it helpful to offer my estimates as a range rather than a set

of fixed numbers. The size of the range implies uncertainty. In
order to get a sense of uncertainty or risk in the estimate, it’s best
to estimate in a range.

5. I always compare my estimates with actuals in order to validate

or improve my estimating technique, assumptions and database
knowledge, and I don’t react defensively to such differences.

115
 Questions Yes No

6. When I have insufficient time for a comprehensive assessment,

I focus on the bigger chunks of work, recognising the Pareto
Principle or 80:20 Rule.

7. My completed estimates are always accompanied by

documented assumptions on how they were derived. I
don’t make assumptions when the facts are available, and my
assumptions are always reasonable (ie, low-level risks).

8. Should my client wish to alter the project scope, I always advise

them about the impact of such changes on the project estimates
of time and cost, and don’t undertake the change until my client
formally approves the additional estimated expenditure.

9. I base my estimates on normal numbers of people completing

each task, and don’t overload the job or plan that my team work
overtime, weekends or statutory holidays.

10. My estimates are always accompanied by an indication of their

accuracy (range or percentage), and a date until when the
estimate remains valid.

11. I proactively seek feedback about the accuracy of my estimates,

maintain an ongoing “actual cost and hours” database, avoid
contributing poor results to “uncontrollable situational factors”
and good results to my own brilliance, and attempt to uncover
the true cause of my estimating errors in order that I might
continuously improve.

12. I consistently apply a standard and valid estimating process,

which I update with experience.

13. I’m sensitive to my estimating biases and common mistakes,

and always seek colleagues’ opinions, appreciating several
viewpoints provide some safeguard against my excessive
optimism or pessimism.

14. I’m familiar with the use of the following tools and techniques
which can help me with estimating:

• work breakdown structure (WBS)

• trade-off analysis
• network diagramming
• sensitivity analysis
• expected monetary value (EMV)

116
 Questions Yes No

• learning curve
• parametric modelling
• phased estimating
• PERT formula
• Delphi technique
• wide-band Delphi technique
• estimating spreadsheet
• bottom-up and top-down techniques.

15. I realise that a person doesn’t work at 100 percent productivity

and 70-80% is a more realistic expectation.

16. I understand the difference between elapsed time, duration

and work effort.

17. I can determine the true cost of employees’ labour and express
this as an hourly rate for accurate work effort costing purposes.

18. I realise that resources who work multiple projects take longer
to complete tasks due to time lost switching between projects.

19. I realise that adding resources will not necessarily reduce

duration. There is a diminishing return.

20. I realise that only by reducing the duration of critical tasks will
I complete my project earlier.

21. Wherever practicable I always involve in the estimating process

the people who will actually do the work.

22. I always revise my estimate whenever the following occur:

• scope changes (variations)

• risks events happen
• assumptions prove to be wrong
• new completion dates are advised
• deliverable specifications change
• labour or material costs escalate
• exchange rates alter.

23. I always allow myself sufficient time to undertake proper

estimating.

24. I always use more than one method to arrive at an estimate.

117
 Questions Yes No

25. I always undertake estimating with a colleague or invite them

to check my figures.

We should avoid giving our sponsor and other stakeholders any firm commitments
about our project cost and duration until we complete our research and calculations,
and when we do, range estimates are much more realistic than are single figure
estimates, that’s say $4,750 to $5,500, or $5,000 - 5% or +10%, rather than a $5,000
single figure. The final budget is the total cost of the project, including reserves, which
is the amount of funds the organisation needs to have available for our project. If that
number exceeds the cost constraints imposed by the project charter, we must suggest
options to our sponsor such as removing some scope or obtaining more budget.

Our project budget includes both direct and indirect costs. Direct project costs include
team members’ wages, travel, project materials, supplies and equipment. Indirect
project costs include overhead costs such as office space, heating, lighting, furniture,
fixtures and equipment, and the project’s share of our organisation’s administrative
costs. From a cost viewpoint, the ideal project duration would be when total costs are
lowest.

Project Costs

118
There is no easy way to produce accurate estimates, except with experience. Remember,
it’s also prudent to re-estimate periodically throughout the project, and always record
the actual costs so that we and other PMs may benefit from the experience. Importantly,
don’t be bullied into a budget or timeframe we cannot achieve and don’t bully team
members into committing to something they cannot achieve. Seeking more funding
may be perfectly valid, particularly if we agree the requirement for increased funding
and the reasons for this in advance with our sponsor. Similarly, we should declare
any surplus. At the start of a project it is worth identifying and agreeing what type of
issues could increase expenditure beyond the budget and warrant additional funds or
reduced functionality.

Project Bottom-up Estimate for Recruiting Project

ID Description Labour Total Non-Labour Total Project

Labour Non- Totals
PM Panel Other Cont Items Cont Lab
$50 $120 $40 15% 5%

1 Conduct Job x1 x2 x1
Analysis $49.50 $379.50 $200 $10 $210 $589.50
$50 $240 $40
2 Prepare Job x3 x1 x1
Description $46.50 $356.50 $0 $0 $0 $356.50
$150 $120 $40
3 Prepare x1 x1
Person $13.50 $103.50 $0 $0 $0 $103.50
Specification $50 $40

4 Decide Pay x1 x4 x2
Range $31.50 $241.50 $0 $0 $0 $241.50
$50 $120 $40
5 Advertise x1
Position $6.00 $46.00 $3,000 $150 $3,150 $3,196.00
$40
6 Shortlist x1 x4 x2
Replies $91.50 $701.50 $0 $0 $0 $701.50
$50 $480 $80
7 Conduct $100 $960 $80
$171.00 $1,311.00 $1,000 $50 $1,050 $2,361.00
Reviews
8 Conduct x1
Testing $7.50 $57.50 $1,000 $50 $1,050 $1,107.50
$50
9 Conduct x1 x4 x1
Final $85.50 $655.50 $0 $0 $0 $1,705.50
Interviews $50 $480 $40

10 Check with x1
Referees $18.00 $138.00 $0 $0 $0 $138.00
$120
11 Make Job x1
Offer $6.00 $46.00 $0 $0 $0 $46.00
$40
12 Negotiate x2
Contract $12.00 $102.00 $0 $0 $0 $102.00
$80
13 Advise x1
Unsuccessful $6.00 $46.00 $0 $0 $0 $46.00
$40
Total $10,694.50

119
Once the cost estimate and contingency are agreed, these become our budget. The
simplest way of graphing the planned use of this estimate against time is an “S”curve
that shows the anticipated cumulative expenditure over our project’s duration. The
name derives from the S-like shape of the curve - flatter at the beginning and end and
steeper in the middle, which is typical of project expenditure. Analysis of S-curves
allows us to identify project growth, slippage, and potential problems that could
adversely impact the project if no remedial action is taken.

Project Expenditure Curve

This profile of expenditure allows a cash flow forecast to be developed and a drawdown
of project funds to be agreed. Actual expenditure inevitably varies somewhat from
planned expenditure. A report showing an S-curve for the original budget alongside
a curve of actual spend to date, clearly shows how actual expenditure varies from that
originally predicted. Also, this baseline prediction can be used as the basis for Earned
Value Management (EVM) that is explained later in this book.

When project implementation is underway, tracking actual time and cost as we work is
very important for two reasons. First of all, that data is useful input for future estimates.
Second, we compare our estimated costs to actual cost, and our planned schedule to
our actual schedule, as an important source of lessons learned that may include better
methods of time and cost estimation for our next project.

120
 Chapter Ten

Scheduling the Work

Network Diagrams

Having developed a WBS and produced detailed estimates, we now consider the
“logic” of the project, which recognises that some tasks can’t be undertaken until other
tasks have been started or completed. These task relationships may be illustrated by a
network diagram that enables us to:

• Make task dependencies visible.

• Identify critical paths/tasks and thus enable us to estimate project duration.
• Determine float time, which provides for task scheduling flexibility.
• Show the consequences of changes to project task durations.
• Identify and eliminate unnecessary tasks and dependencies.
• Transfer excess resources assigned to some tasks to others needing more.
• Prepare a task schedule (eg, Gantt chart) showing dependencies.

A typical activity-on-node (AON) network diagram, arrow diagram or precedence

network, looks like this, which shows for example that Task F cannot be commenced
until Tasks D and E have been completed.

AON Network Diagram

121
Dependencies are the relationships among tasks that determine the order in which
tasks need to be performed. There are four types of task relationships:

• Finish-to-Start (FS). Most commonly, predecessors must finish before successors

can start. (Land must be purchased before road construction can start.)

• Start-to-Start (SS). Occasionally predecessors must start before successors can

start. (Road excavating must start before asphalt can be laid.)

• Finish-to-Finish (FF). Occasionally predecessors must finish before successors

can finish. (Laying asphalt must be completed before centreline painting can be
completed.)

• Start-to-Finish (SF). Very rarely used where predecessors must start before
successors can finish. (Road excavating must start before centreline painting can
be completed.)

Task Relationships

Incorrect or unnecessary dependencies may impact the quality and finish date of our
project. The three types of dependencies are:

• Mandatory (hard logic) dependencies are the most common relationship and are
inherent in the nature of the work being undertaken. They often involve physical
limitations (eg, we must dig the hole before we can plant the tree, or we need to fill
a kettle with water before switching it on).

• Discretionary (soft/preferred/preferential logic) dependencies are based on

experience, desire or preferences (eg, we prefer to put sugar and a tea bag in our
cup before filling our cup with hot water).

• External dependencies are based on needs or desires of a party outside the project
(eg, the product of another project).

122
Network diagrams are somewhat like flow charts. They show the series of tasks (WBS
terminal elements, work packages or tasks) that make up a project in the sequence
they must happen. Each task is usually shown as a box (node) with arrows joining the
boxes in the order that they need to be undertaken. Preparing the network diagram
on a whiteboard or large sheet of paper using Post-it Notes allows the entire project
planning team to participate in its development, although once finalised the resultant
network might then be computerised for ready updating and quick “what-if” analysis,
such as the consequence on our project completion date should we increase or
decrease a task’s duration.

“Critical path” is an important PM concept, and it’s something that we as PMs should
understand. Put simply, the critical path of a project is a specific sequence of tasks
that must be completed on time in order for the project to meet its deadline. It’s the
longest time route through the network diagram and thus determines project duration.
It’s critical in terms of the project completion date in that a delay to a critical task will
cause a delay to project completion unless subsequent critical tasks are accelerated.
Thus, our project’s critical path is important since:

• It tells us the shortest time in which our project can be completed.

• It shows us those tasks, which if delayed, will cause a delay to our project.

• It shows us those tasks that must be completed more quickly in order to bring
forward the finish date for our project.

Our project can have more than one critical path, and sometimes the critical path
changes during project execution when actual task durations become apparent.

Below is an AON network diagram developed on a whiteboard using Post-it Notes to

show the sequence of tasks that need to be undertaken for a conference project. In
this example, the bold green arrows depict a critical path of 152 workdays’ duration or
179 calendar days when non-workdays (weekends and statutory holidays) are included.

123
Some network diagram design points are these:

• The length of the arrows is irrelevant.

• Arrows start and finish at task nodes.
• Diagrams usually read from left to right.
• Each task has a unique WBS identification code.
• Common time units, usually workdays, are used for all tasks.
• There is only one start and one finish event node for each network.

Milestones have a fixed date but use no resources. Milestones which are visible
indicators of project progress, typically mark critical decision points, completion of key
project tasks, the ends of various project stages, and serve as reference points in time at
which to assess if the project is progressing according to plan. Senior stakeholders who
are not involved in the project on a daily basis become more engaged and attentive
as milestones approach. In some cases, milestones may determine when payments
are made to contractors. Milestones may be shown on our network diagram as zero
duration tasks or marked with flags at the start or finish of a task node and are usually
on the critical path and often where arrows converge on or disperse from a task node.

AON Milestone Symbols

At this stage of planning we sequence tasks according to their immediate preceding

tasks (predecessors or dependencies). In the following example, the critical path is B -
C - D and totals nine days. Float for non-critical tasks is 1 day for A, 2 days for E, and 2
days for F, which is the time by which these non-critical tasks could be delayed without
the project exceeding its completion date. Tasks on the critical path have zero float.

If resource availability permits, tasks are usually commenced as soon as practicable

except for those non-critical tasks that involve materials, which are sometimes undertaken
just-in-time (JIT) to minimise inventory or holding costs that may include the cost of
capital, warehousing, depreciation, insurance, taxation, deterioration, obsolescence,
maintenance and shrinkage.

124
 Example AON Network Diagram

Tasks Predecessor(s) Durations (days)

Start Nil Nil

A Start 2

B Start 3

C A and B 4

D C 2

E B 1

F E 3

Tasks which are not on the critical path can fall behind schedule, up to a point,
without blowing the project completion date. This leeway for slippage of non-critical
tasks is called “float” or “slack” and provides for schedule flexibility that allows us
to accommodate resource availabilities. Float is one of the few weapons we have
available to manage the schedule and should not be available to anyone other than
ourselves as PM. Given Parkinson’s Law it might be foolish to tell a team member
that their task is scheduled to take 5 days, but they have 10 days to complete the task
because of the available float. Better not to mention float at all. Some PM don’t show
task dependencies on the Gantt charts they use for team briefing and task assignment
purposes for this reason.

125
 AON Network Diagram

A network should feature just the right amount of detail for the people using it. Thus,
something that appears as a single sub-project in one network diagram (strategic
level) may become a network diagram in its own right (tactical level). In this more
complicated network diagram, the arrows in red depict the critical path, which totals 21
weeks’ duration. Note that parallel tasks F and G are both critical.

If the critical path takes our project finish date out beyond the required finish date we
can compress the schedule if necessary by:

• Fast Tracking. Performing some critical path tasks in parallel that were originally
planned to be undertaken sequentially. Fast-tracking can only be applied if the
tasks in question can actually be overlapped, but this technique may increase risk
and cause rework.

• Crashing. We might assign additional resources to critical path tasks to shorten

project duration, which almost always results in increased costs. Cost and schedule
tradeoffs may be analysed to determine how to obtain the greatest amount of
compression for the least incremental cost.

Gantt Charts

We can now convert our network diagram into a task schedule that shows what tasks
are to be undertaken over what periods. The schedule might be in table form or
illustrated as a Gantt chart, which is the most convenient, most used, and easy-to-grasp
depiction of our project schedule. Scheduling software is useful here. MS Project is
the most widely used package. This application is designed to assist us develop plans,
assign resources to tasks, track progress, manage budgets and analyse workloads.

126
Scheduling software is also useful for what-if analysis to quickly show the effects of
various scenarios. But do remember that computers manage data – we manage the
project. To create a Gantt chart we need to know all of the individual tasks required to
complete the project, an estimate of how long each task will take, and which tasks are
dependent on which others.

The Gantt chart is a horizontal bar chart first developed by Henry Gantt an American
engineer in 1915. It shows at a glance project task start and finish dates, milestones and
task dependencies. Tasks are listed down the vertical axis, and the project time span
(work days or dates) is represented on the horizontal axis. Each task has a horizontal bar
that shows the time span required for that task. Initially early start (ES) dates are usually
applied and then adjusted if resources are not available to support this schedule.

For a simple project we can create a Gantt chart freehand on graph paper or use Excel.
For more complicated projects we are better to use a specialised software scheduling
tool, but remember, the schedule produced by a software application is only as good
as the data we provide.

Some things we’ll see on a Gantt chart are timelines or bars that depict task timings
and durations, milestones usually represented by diamond-shaped symbols, vertical
dependency arrows that link tasks, and summary tasks that comprise two or more
related individual tasks. During project implementation, task bars can be filled in to
show the portion of the task that has been completed. MS Project has a tracking Gantt
facility with which we can superimpose timelines to show actual progress and thus
readily detect variance – the difference between planned and actual task progress.

Project Gantt Chart

127
The value of the Gantt chart is that:

• It clearly shows what tasks need to be done and when (start, duration and finish
dates), and as such is a useful communication tool. Even a very small project can
benefit by allowing us to see our task schedule spread over time on a Gantt chart.

• We can look vertically to see when our project will be busiest in terms of resource
commitments (people, money, work effort, equipment and materials), and we can
reschedule non-critical tasks if too much is going on at once.

• We can monitor progress by superimposing actual timelines over planned timelines

to show schedule variance, which differences may be within or outside allowable
tolerance or slippage limits.

• Gantt charts aren’t just a way for us to manage our project schedule. They are a
great tool for team transparency, so everyone can see how their tasks inter-relate
with other’s work.

Based on the more detailed network diagram at page 126, the following Gantt chart
may be constructed. In this example the tasks don’t step down neatly from the top to
the bottom of the chart as usually shown. Alternatively, tasks might be arranged such
that the critical path tasks are grouped at the top of the chart.

Gantt Chart - Critical Path in Red

128
One limitation of a Gantt chart is that it relies upon the WBS to be fully complete and
task durations to be accurate. Should there be tasks missing from the WBS, the Gantt
chart will not tell us this. Nor will the Gantt chart tell us if dependencies are wrong or
missing; hence the value of first preparing a network diagram. Another frustration is
that once the project duration stretches beyond one page, the Gantt chart begins to
lose its functionality and becomes more difficult to view on our computer screens. In
these circumstances a printout and/or an altered time scale may help.

Milestones are usually diamond-shaped icons that we can drop anywhere on our Gantt
chart to reflect key dates. They can be traditional milestones, in that they represent
major phases in the project, but we can also use them to signify important events, team
meeting dates, review points, or whatever we want.

In projects where WBS tasks are clearly defined, scheduling is straightforward. We

estimate task durations, decide the sequence of tasks, and let the computer find our
critical path and calculate float – all illustrated by a network diagram and/or Gantt chart.

Resource Scheduling

Having prepared our task schedule, we now check the actual availability of resources
and identify any resource shortfalls or overloading. Such resourcing problems may be
resolved or reduced by the following practices, usually applied in this order:

• Reschedule non-critical tasks (NCTs) using float.

• Extend NCTs using float (ie, take longer over work).
• Split NCTs using float (which may increase total work effort).
• Remove non-essential task dependencies to create more float.
• Use more productive resources (rather than just add more).
• Subject the project parameters to a “trade-off analysis.”
• Add shifts and/or work longer hours (but sometimes for diminished productivity).

The following example shows how we might reschedule tasks to comply with resource
constraints (ie, three people available for the first four days, and six people available
for the last six days) without extending project duration. In this instance the project
schedule is determined by resource availability – a “resource-constrained schedule.”
Note that resource availability is steeped up towards the end of the project which
suggests a late start schedule. Accordingly, non-critical tasks are started as late as
possible within the 10 day timeframe for this project.

129
 Project Tasks, Predecessors, Durations and Resources

Tasks Predecessor(s) Durations (days) People Needed Each Day

A Start 2 3
B Start 3 3
C A 4 3
D B 2 4
E C 1 3
F D 1 4
G E 3 2

The following is an example of “resource smoothing” used when the project finish
date is fixed. “Resource levelling” is used when limits on the availability of resources
are paramount and thus results in a delay to the project finish date. In some situations
a mixture of levelling and smoothing may be required. If both resource available and
timescales are fixed we may need to de-scope the project, outsource some work, or
work overtime. A fully resourced schedule will usually support our bid for an extension
of time and/or additional budget.

130
The deliverable from this step is a resource schedule that itemises resource needs and
provides a basis for procurement action. Given that sometimes tendering and long
lead-times are involved, procurement might now be initiated, but no contracts should
be finalised/signed until the PM plan is formally approved.

Resources are needed to complete project tasks. A project resource schedule is based
on the project task schedule and documents who, what and how much is needed, when
they’re needed, and for how long. Allocation of limited resources is usually based on
project priorities. Low priority projects may need to make do with what resources are
left over. So they often have resource-constrained schedules, which means that the
availability of resources dictates their schedule and duration. We also need to check
that we haven’t assigned the same person to different tasks on the same dates. The
resources needed for a project include labour, equipment and material and these may
be obtained internally from within our organisation or procured externally:

• Labour. Using the following table, we list the roles required to undertake the
project, identify the number of people needed to fulfil each role, describe the
responsibilities and skills needed to undertake each role, and specify the timeframe
during which the role will exist.

Role Number Responsibilities Skills Start Date End Date

List each Identify the Summarise the Summarise Enter the Enter the end
person’s number responsibilities for the skills start date for date for the
role. of people each role. required to the role. role.
required for fulfil each
each role. role.

• Equipment. Using the following table, we list each item of equipment required
to complete the project, quantify the amount of each item needed, describe the
purpose and specifications of each item, and the timeframe for when the equipment
will be required.

Item Amount Purpose Specification Start Date End Date

List each Identify amount Describe the Describe the List the date List the date
items of of each item purpose of specifications when the when the
equipment of equipment each item. of each item. equipment is equipment can
required. required. needed. be released.

• Material. Using the following table, we list each item of material required to
complete the project, quantify the amount of each item needed, and specify the
timeframe during which the materials will be required.

Item Amount Start Date End Date

List each item of Quantify the amount of List the date when List the date when
material needed. each item of material the material item is the use of the
needed. needed. material ends.

131
Most scheduling software packages can be programmed to level-load resources.
The most common allocation rule or heuristic is the “minimum float” rule whereby
resources are first assigned to our project’s critical path tasks that have no float, then to
the tasks that have the least float, and so on, until resources are exhausted. Also, with
most scheduling tools the computer can be programmed to do either time-critical or
resource-critical levelling.

If necessary, inventory is held as a safeguard against uncertainties in supply and demand

for project materials. Having too much capital tied up in stock is a problem for any
business, and can give us a problem on our project with cash flow. Holding too little
stock is also a problem because we’ll have to buy at short notice if we need some extra.
Buying at short notice is generally more expensive, because we’ll have to add costs for
priority shipping or expedited processing. It’s better to carefully plan our purchases so
that we can avoid those extra costs.

Sometimes there is little or no room to hold supplies at the project site. If we employ
a “just-in-time” (JIT) system, which is mostly used in manufacturing, we will only keep
the supplies we need at any one point, and our suppliers will hold the rest. For a JIT
system to work, we need to be confident that our suppliers can deliver on demand.
Also keep in mind that there is a risk of running out of stock, which we should address
in our project risk management plan. The inability for one or more suppliers to deliver
when needed can cause a delay to our project schedule.

Project Baseline Plan

The project development (planning) phase culminates in the production of an approved

baseline PM plan. This deliverable or artifact is important because it provides essential
information for the project execution phase. An approved PM plan is a commitment
to continue and to dedicate the required time and resources to the project.

Our PM plan is finalised when it’s formally accepted and approved by the project
sponsor. Formal approval acknowledges that the plan is completed, reviewed and
accepted. Signatures on the PM plan document indicate this approval. However,
there will be occasions when the plan is not approved due to changed circumstances
or perhaps the first stage only of the project is approved for implementation.

Doubtlessly, during project execution some changes to this baseline plan will be
needed as reality unfolds. It would be foolish to adhere to an original baseline plan
that is proving to be unsatisfactory. Plan version control is therefore important.

Although risk management must be continuous throughout the project lifecycle,

key stakeholders may be invited to assess the draft PM plan and identify potential
implementation problems. The PM plan might then be amended to eliminate or keep

132
 Project Management Plan

Prepared by: Hori Kingi, PM.

Version Number: One.
Date: 9 February 20XX.
Distribution: Board Chair, CEO, Sponsor, PM, and Project Team Members.

Reference
Project Charter for the annual ABC conference dated 30 January 20XX.

Project Name
ABC Annual Conference 20XX.

Summary
This year the ABC conference to discuss matters of importance to the future of
the organisation, is scheduled for 8-10 April 20XX at a Palmerston North venue
yet to be identified. It’s anticipated that at least 200 people will attend. Financial
sponsorship will be sought, but as for previous ABC conferences, participants
are to arrange and pay for their own transport and accommodation. Conference
fees are likely to be set at about $150 per participant and that fee will mainly
cover the costs of lunches and a conference dinner function.

Purpose
The purpose of the conference is to discuss matters of importance to the
future of the organisation, including a review of the organisation’s constitution,
core values, purpose statement, strategic plan, key operational activities, and
current and proposed projects to ensure that the organisation remains effective
and efficient in today’s ever-changing environment. The conference will also
provide an opportunity for productive face-to-face debate among members, will
encourage membership, and will further the organisation’s positive profile.

Goal
To hold a successful ABC national conference at Palmerston North during 8-10
April 20XX.

Planning Assumptions
It’s assumed that:

• A suitable venue will be available at Palmerston North.

• At least 200 people will attend.
• There will be 3% “no shows” at the conference.

133
Scope
The project work scope includes arranging a suitable venue (hotel with sufficient
parking, comfortable chairs, break-out rooms, wifi, security and conference
auditorium), marketing and advertising, preparation of mailing lists, obtaining
sponsorship, organising registration, preparing the conference agenda,
papers, folders, conference packs and handouts, arranging catering (coffee,
tea, drinks, snacks, lunches, special diets, conference dinner), managing and
coordinating pre-qualified suppliers, organising the opening address and key-
note speakers, arranging photography, media coverage, running the conference,
obtaining participant evaluations/feedback, and undertaking post-conference
administration.

Scope exclusions are arranging transport and accommodation for participants,

although ideally accommodation for participants should be available at the
venue or within its close vicinity.

A project Work Breakdown Structure (WBS) for the project is at Appendix A.

Deliverable Quality
The final deliverable will be a well-organised and efficiently run conference that
meets or exceeds the following key performance indicators (KPIs):

• Undertaken on the specified dates and completed within budget.

• Attended by at least 200 members.
• Rated successful by at least 85% of those who attend.
• Agenda items all fully addressed with opportunities for productive exchanges
and debates.
• Conference received positive media coverage.
• Current membership retained and membership increased by at least 5%
over the next 12 months.
• All risks successfully mitigated.

Organisation
The project organisation structure reflects the project WBS:

134
Key Appointments and Stakeholders

Project Sponsor: Alan Fletcher

PM: Hori Kingi
Project Planning Team Members: Kamielle Tauaneai
Aroha Pohatu and
Renee Love
Public Relations and Safety Officer: Lucy Bush
Other Stakeholders: ABC employees and membership, conference attendees,
sponsors, venue and facility providers, caterers, and media representatives.

Roles and Responsibilities

Sponsor. The sponsor is accountable to the CEO and is to:

• Ensure that this project is aligned with ABC organisation’s purpose, vision
and goals, and does not conflict with ABC core values.
• Keep the project business case updated to ensure that the investment
remains valid.
• Organise and chair a conference project steering committee.
• Ensure project funding and the timely availability of resources.
• Provide high-level direction to the PM.
• Ensure that risks are properly managed.
• Authorise the use of management reserves.
• Review and approve the PM plan.
• Monitor project progress at a strategic level.
• Brief the Board Chair, CEO and senior management on project progress.
• Communicate with senior stakeholders.
• Evaluate and approve where appropriate variations that impact project
parameters.
• Resolve issues escalated by the PM.
• Approve the use of project contingency funds.
• Ensure the project’s outcomes and benefits are achieved.
• Approve the project final report.
• Hold post-project reviews to ensure benefits have been or are being achieved.

135
Project Manager. The PM is accountable to the sponsor for project success and
is to:

• Define in detail the work scope of the project and manage any variations to
this.
• Prepare the PM plan as per the guidance provided in the charter document.
• Further specify responsibilities and performance targets for each team
member.
• Oversee any project procurement contracts.
• Regularly communicate with stakeholders.
• Continuously identify and manage risk.
• Authorise the use of contingency reserves.
• Regularly monitor and control project progress.
• Resolve or escalate project issues.
• Manage the project budget.
• Maintain project files including variations, risk, issues and lessons learned
logs.
• Deliver the conference on time, to budget, and to agreed quality standards.
• Report project status each week to sponsor and key stakeholders.
• Manage the closure of the project.
• Prepare a project evaluation report that includes lessons learned.

Project Team Members. Team members are accountable to the PM and are
responsible to:

• Complete work packages delegated or contracted to them by the PM.

• Ensure their deliverables are properly completed on time and within budget.
• Liaise and work cooperatively with other team members.
• Regularly report progress to the PM.
• Manage the resolution of issues, or escalate these with recommendations to
the PM.
• Inform the PM of any variations that require approval.
• Continuously monitor risk (threats and opportunities) associated with their
work.

136
Benefit Realisation
The conference, which is to be self-funding, is fully justified given the need:

• To review the organisation’s current situation and develop new strategies

where appropriate to ensure the continuing relevance and viability of the
organisation in our constantly changing and challenging environment.

• To provide an opportunity for our membership to be updated on matters of

current importance and fully participate in the development of ABC strategy.

• To revitalise and grow ABC membership.

Following the conference the project sponsor is responsible for benefit tracking
and realisation in terms of revised business strategies, on-going positive media
coverage, and improved organisation image, membership retention and growth.

Network Diagram
The network diagram for the conference is at Appendix B.

Schedule
A schedule of tasks in Gantt chart form is at Appendix C. All tasks are scheduled
to start as soon as possible.

Work Package Descriptions

A brief description of each task is at Appendix D.

Budget
Participants are to pay for and arrange their own travel and accommodation.
Venue hire, reception arrangements, catering (morning and afternoon teas,
lunches and conference dinner), stationery, name badges and other expenses
will be covered by sponsorship, a government grant and conference fees. The
PM will establish an appropriate system to control and account for all financial
transactions to include a list of registered participants detailing the amount
paid and when received. Tickets prices are to be set so that the conference will
breakeven financially with an attendance of 200, which is likely to be about $150
per head. A contingency of 10% will apply to cover unanticipated expenses.
Free tickets will only be provided for the project organising team, speakers and
sponsors.

Accurate budgeting and prudent financial management are vital for the success of
the conference. Also, the PM will ensure the follow-up of outstanding payments
and will produce a detailed financial statement following the conclusion of the
conference as part of the conference report.

137
Estimated income and expenditure for the conference is summarised in the
following table:

Income Expenditure

Ticket Sales $30,000 Venue Hire $8,000

Sponsorship $15,000 Advertising $20,000
Grants $10,000 Printing $6,000
Speakers $5,000

Miscellaneous $11,000
Contingency (10%) $5,000
Total $55,000 Total $55,000

Risk Management
All project stakeholders are invited to submit risks, both threats and opportunities,
promptly to the PM for analysis using the registration form shown at Appendix E.
Based on previous ABC conference experience, some risks are:

• Venue already booked or becomes unavailable.

• Earthquake or fire.
• Guest speaker(s) unavailable.
• Insufficient sponsorship or sponsorship withdrawn.
• Unhappy sponsor(s).
• Inadequate signage at venue.
• Insufficient parking at venue.
• Too many free tickets handed out.
• Budget overrun / financial loss.
• Food poisoning or other medical emergency.
• Excessive alcohol consumption.
• Power failure.
• Audio-visual equipment malfunction.
• Attendance estimate not achieved.
• Attendance estimate (venue capacity) exceeded.
• Loss of reputation as an effective and efficient organisation.

138
Risk scores and responses to be determined using the qualitative matrix shown
here. This project’s tolerance or appetite for risk is marked with the bold line.
After response measures, residual risk should be in the green. A risk log is at
Appendix F.

Issues
An issues log is at Appendix G. There are no issues at present.

Variations
Suggested changes are to be submitted using the template at Appendix H.

Health and Safety

The project public relations and safety officer is to publish a list of conference and
venue safety rules and check contractors’ safety procedures and risk assessments
for strict compliance with NZ legislation.

Communications and Control

The project communications plan is at Appendix I. PM is to provide the sponsor
with a weekly status report as per the template at Appendix J. The project team
will meet once a week.

Advertising and Public Relations

Public relations will be one of the most significant elements in our conference
conduct and marketing strategy. Advertising is what we say about our brand
and organisation. Public relations is what the market says about us. Our job is
to reach our membership, engage and hold their interest, captivate them with
a brilliant conference and inspire them to share their positive experiences with
their widest possible networks. A successful conference will see our organisation
receive positive media coverage and be free from negative publicity. Our public
relations ultimate aim is to improve membership and retention to be realised
through the use of a full range of communications tools and channels.

139
News media is to be advised of our conference and invited to attend. Our
experience is that dealing with the media presents unique challenges in that
the news media cannot be controlled. They have ultimate control over whether
stories pitched to them are of interest to their audiences. Thus, on-going
positive relationships between our organisation and the news media are vital.
Our public relations activities are to include writing news releases and other
content for news and feature articles, working with the press, arranging interviews
for our spokesperson, writing the conference opening address, and making best
use of our magazine and website.

Project Closure
After the conference the PM and team will:

• Hold a closedown meeting.

• Terminate reporting requirements.
• Resolve any outstanding issues.
• Arrange for collection of debts.
• Pay all outstanding accounts and audit accounts.
• Finalise all contractual commitments.
• Collect and analyse conference evaluations.
• Identify strengths of the conference.
• Identify weaknesses of the conference.
• Assess the extent to which conference benefits have been achieved.
• Prepare and distribute a post-conference report to include lessons learned
and recommendations for the 2016 conference.
• Update the ABC conference risk list.
• Prepare and send letter of thanks.
• Release project team members, and return or dispose of equipment and
materials.
• Retain photographs for records and publicity purposes.
• Index and archive records.
• Arrange celebration dinner for the project team.

Lessons Learned
The template for recording lessons learned is at Appendix K.

140
Project Report
The format for the project final report is at Appendix L.

Other Matters
The ABC Board Chair advises: “My very special thanks to the project team whose
hard work has resulted in this thoughtful and thorough plan that should ensure
another very successful annual conference. Remember too that sponsorship
will provide extra income and reduce our organisation’s financial burden for the
conference. We must therefore look after our sponsors and exhibitors with utmost
care - making sure their entitlements are fulfilled, they are fully acknowledged,
and we build the rapport that ensures they will come back next year. I trust all
who attend enjoy and benefit from the conference.”

PM Plan Approval and Acceptance

The signatures below indicate that the undersigned have agreed to this PM Plan
and have thus given their approval for the project to be implemented:

Project Sponsor: Date:

Project Manager: Date:

Appendices:

A. Work Breakdown Structure

B. Network Diagram
C. Gantt Chart
D. Work Package Descriptions
E. Risk Registration Form
F. Risk Log
G. Issues Log
H. Change Request
I. Communications Plan
J. Status Report
K. Lessons Learned Log
L. Project Report

141
Project Value Management

Before we get our sponsor to sign off on our PM plan, we need to have our planning
team check it for accuracy, consistency and completeness, and once checked we might
then see if we can make it even more efficient through a project value management
(PVM) intervention or “pre-mortem” so that the project can be improved rather than
autopsied. We can now improve our project’s chances of success by making it safe for
those who worried about possible weaknesses to speak up.

PVM is usually a formal and systematic study of the PM plan to identify ways to achieve
the functionality needed at the lowest cost without adding risk or without loss of
performance. It’s potentially effective for all types of projects, but best results are
usually obtained with construction projects. PVM usually adds greater value if applied
prior to project execution, but it might also be undertaken periodically during project
execution.

142
 Chapter Eleven

Managing the Risk

Significant accomplishments are rarely possible without taking risks. The “no free
lunches” mantra applies. Those who desire a reward need to be willing to expose
themselves to risk. In fact, a no-risk project would not be worth pursuing, although of
course all projects possess risk and any good project has plenty of risk. It’s said that
there are only two certainties in life – death and taxes. However, there is a third – project
risk. Ideally, good risk management would mean that project risks never materialise as
issues. The reality, of course, is that even the best PMs sometimes have to deal with
risks that they were unable to identify or avoid. Yes, projects are unavoidably risky,
some more so than others depending mainly on their complexity and novelty.

Key Risk Components

Risk management has become one of the most visible aspects of project management
in recent years. Managing project risk is an iterative process we perform during our
project that allows risk to be understood and managed proactively to optimise project
success by minimising threats and maximising opportunities. This proactive approach
may seem peculiar to those accustomed to solving problems once they occur, rather
than preventing problems arising, which is the essential difference between risk
management and issue management. Also, risk management is not just done at the
start of the project, but is an activity undertaken continuously throughout the full life of
our project. It’s one of the main tasks for us PMs.

143
The project team is concerned with finding potential problems before they can
negatively impact the project. Potentially serious threats are identified and eliminated,
and the probability and impact of the remaining threats to project success are reduced
to an acceptable level. We also identify opportunities to exploit. Risk management is
key to running a successful project and while risk is often discussed, it’s surprising how
few PMs truly embrace the process. If we don’t plan ahead for things that might divert
us and our team from successful project completion, we may end up with a very messy
project at some point down the line. Good risk management or poor risk management
can mean the difference between project success and project failure.

Different stakeholders are interested in different levels and types of risk, depending on
their stake. For example:

• Senior management need to know about business risk.

• Project sponsors need to know about risk to forecast benefits.
• PMs need to know about risk to project objectives.
• Project teams need to know about risk to their project tasks.
• Users need to know about product utilisation risk.

Historically, Kiwis haven’t always given risk the respect it deserves, evidenced today for
example by our road carnage. Car accidents are now a leading cause of adolescent
deaths. One theory for our relaxed attitude to risk is that many of our ancestors, Māori
and Pakeha, must have been hopelessly optimistic to sail huge distances to carve out
a life in an unknown land. So perhaps it’s part of our genetic heritage to focus on
the upside and ignore the possibility that something could go wrong. The “she’ll be
right” attitude often prevails. Seems that our risk-taking is a cultural and historical
phenomenon. In fact, today we have an accident compensation scheme that rewards
us for our injuries, regardless of how reckless or stupid we were.

Sometimes macho-style management and project sponsors can be complicit in

keeping project disasters going. Instead of commending PMs whose conscientious risk
assessments recommend early project closure, at best they view such PMs as pitifully
inadequate; at worst they are replaced. We might recognise those who doubt the
value of project risk management from comments, such as:

• “The negative attitude that risk-finding encourages will undermine the project
team’s morale and motivation, and ultimately project success.”

• “There is not enough time to indulge in mere possibilities. It’s much more productive
to get on with the real project work and react to actual problems if and when they
arise.”

• “Projects and the environments in which they are undertaken continuously change,
which very quickly makes a nonsense of any risk management plan.”

144
• “What do you mean you ‘think’ the project is low risk? That’s defeatist talk. You’ll
need to be a whole lot more confident and convincing to ensure we get this project
approved.”

• “Risk management simply drives out innovation, which PM should be all about.”

Due largely to new technology, complex functionality, variations, competitive pricing,

ambitious deadlines and speed to market pressures, projects can usually have much
more go accidentally wrong than accidentally right.

Risk Management Process

145
Although risk management steps are done in sequence, they are each done often
during the course of our project. Risks can be identified at any time, as can responses.
This continuous cycle consists of the following steps:

1. Risk Management Planning. Risk management planning is about deciding how

to approach, plan and execute risk management activities throughout the life of
our project. It’s intended to maximise the beneficial outcome of opportunities
and minimise or eliminate the consequences of adverse risk events. The output
is the risk management plan that describes how risk management will be done on
our project. This plan may be published as a standalone document or more often
included as a section in our PM plan.

2. Identify Risks. Risk identification involves determining which risks (threats and
opportunities) might affect our project and documenting their characteristics. It
may be a simple risk assessment organised by our project team or the outcome of
a specific workshop. Risks to the entire project are identified, but we also identify
risks at work package level. The output is invariably a large list of risks and the start
of a risk log. While risk identification typically occurs at the beginning of the project,
it reoccurs throughout the project lifecycle. It’s a repetitive event, recognising that
new risks arise as the project matures and situations change. However, it’s not
always well understood what a risk is - that it’s an uncertain event that impacts one
or more of the project objectives. Risks must be specific. “Communications,” for
example, is not a risk; it’s a category of risk. Instead, a specific risk might be “Poor
communication of customer’s requirements may cause a wrong design.” “There
may not be the physical space for the required equipment.” “Severe weather may
impact progress.” “Due to the heavy rain, the fields might be flooded, which would
damage the crops.” Also, as our project proceeds, we need to identify residual and
secondary risks, and consider risk interaction:

• Residual risks are those that remain after we develop responses to the project’s
original risks. Residual risks will also need to be responded to if they move
beyond our risk tolerance limits. Contingency plans may be prepared for this
eventuality.

• Secondary risks are those caused by our responses to original project risks.
For example, outsourcing a project task may mitigate a project risk, but now we
may have created other risks as a result of using a contractor. The number and
impact of secondary risks might exceed the primary risks in some instances.

• Risk interaction of two or more risks may result in a greater combined good
or bad effect than each risk would have independently. For example, a project
task with an unrealistically early or late completion date may also be under
or over funded, the worst combination of these being an unrealistically early
completion date for an underfunded task, recognising that more appropriate
funding may have enabled the work to be accelerated. Experience tells us that
related threats are more likely to have a compounding effect than they are to
have a compensating or neutralising effect.

146
3. Qualitative Risk Analysis. Qualitative risk analysis subjectively assesses the impact
and likelihood of our identified risks and develops prioritised risks for our further
analysis or treatment as appropriate. As PMs, assisted by the project team, we
assess each identified risk for its probability of occurrence and its impact on project
objectives, including the impact on anticipated project benefits. Project teams may
elicit assistance from subject matter experts or functional units to better assess the
risks in their respective fields. Qualitative risk analysis is undertaken for all projects.
The location of the divisions or dividing lines between red, amber and green risk
categories on a risk matrix depends on our project’s tolerance for risk as agreed
with our project sponsor. The output from qualitative risk analysis is an updated risk
log. A choice is then made about whether quantitative evaluation is necessary for
selected risks or to move directly to risk response planning.

Qualitative Risk Analysis Matrix

4. Quantitative Risk Analysis. Quantitative risk analysis is usually applied to

more expensive and complex projects where a higher level of investment in risk
management is worthwhile. Rather than use adjectives to describe and categorise
risks, quantitative analysis expresses risk probability as a percentage likelihood, and
risk impact is expressed as money and/or time lost plus the cost to rectify the risk
should it occur. As with qualitative risk analysis, the location of the dividing lines
between red, amber and green categories of risk on the risk matrix depends on
our project’s tolerance for risk as agreed with our project sponsor. The output from
quantitative analysis is an updated risk log. While the probability scale is standard
for all projects, the time and cost impact scales need to be set for each project and
will depend on what magnitude of risk we can tolerate and whether our project is
primarily time-driven or cost-driven. Quality impact might be described in terms of
reduced product functionality or features (ie, what the product can do for the user).

147
 Example Quantitative Risk Analysis Matrix

Example Quantitative Risk Values

Impact Scale Time (days) Cost ($000) Quality

Very High Exceeds 20 Exceeds 200 Functionality reduced

by more than 20%

High 11 - 20 101 - 200 Functionality reduced

by 11 - 20%

Medium 4 - 10 51 - 100 Functionality reduced

by 4 - 10%

Low 1-3 10 - 50 Functionality reduced

by 1 - 3%

Very Low Less than 1 Less than 10 Functionality reduced

by less than 1%

5. Risk Response Planning and Implementation. Risk response planning is the

process of developing options and determining actions to enhance opportunities
and reduce threats. We identify and assign team members to take responsibility for
each risk response and decide which strategies or strategy is best for each risk, and
implement that strategy as required. Sometimes we accept the risk or residual risk
but prepare a contingency plan to deal with the situation should the risk occur. We
might also create fallback plans to be used if our contingency plans don’t succeed.

148
 Risk response implementation requires that risk owners complete their agreed
actions. Response strategies often result in updates to the risk log, PM plan and
risk-related contractual agreements. Risks may be managed in a variety of ways:

• Avoid means to prevent or eliminate the risk impact and/or probability. Some
project requirements may need to be eliminated to avoid associated risk, which
may reduce project functionality and benefits.

• Accept applies to both threats and opportunities and means to do nothing

since the risk is minimal or no other responses are suitable, although we might
develop a contingency plan to be implemented should the risk occur. Thus
this strategy can be passive where we PMs decide to just deal with the risk if it
occurs. Or it can be active where we have a contingency reserve allocated and
a plan in place in case the risk arises. We need to specify an event or warning
sign at which we trigger our contingency plan. Fallback plans are implemented
if contingency plans fail.

• Transfer means to shift the burden of loss for a risk to another party through
contract, insurance or other means. This strategy doesn’t change or eliminate
the risk, it simply gives another party the responsibility to manage the risk.

• Mitigate, reduce or limit the risk is the most commonly used strategy and
means to proactively reduce the impact and/or probability of the risk event and
thereby downgrade its priority to an acceptable level.

• Exploit means to take action to ensure the opportunity occurs, which might
mean we add work or change the project in some way. Suppose our client
tells us that if we complete the project two months sooner, he will reward us
financially. We then do everything to complete the project ahead of time –
work overtime, bring in more resources, fast-track or crash the project schedule.

• Enhance means to strengthen the risk impact and/or likelihood, whereas exploit
is to ensure the opportunity is realised.

• Share is to transfer or allocate ownership of the risk to another party who is

better able to capture the opportunity.

6. Risk Monitoring and Control. Here we track identified risks, implement risk
response plans as required, monitor residual risk, and identify new and secondary
risks. We would ignore green risks, consider amber risks, and take action on red
risks. We carry out risk response plans and evaluate the effectiveness of these
interventions. The main outputs of this process may include further recommended
corrective and preventative actions, requested changes, and updates to our risk log
and PM plan.

7. Review and Revise. A risk review looks forward in time, while a risk audit looks
backwards at what has already occurred. We recognise that risk management is
an on-going process that continues throughout the project lifecycle, and we aim to
improve this process continuously as we learn from each new experience.

149
 However, proposed improvements need to be endorsed by our organisation
before their implementation, otherwise local, well-intentioned enhancements will
soon mean we have no standard approach to project risk management. In an ideal
feedback loop, lessons learned also serve as a base for risk identification sessions
on future projects.

Examples of Risk Reduction

Example Risk Log - Conference

Risk Registered Risk Description Probability Impact Initial Risk Response Risk
No By/Date Priority Status
1 PM Venue becomes High V High Red Book secondary Open
30 Jan unavailable venue
2 PM Guest speaker(s) Medium High Amber Arrange stand-in Open
30 Jan don’t show speakers
3 PM Sponsorship Medium High Amber Sponsorship well Open
30 Jan insufficient recognised
4 PM Medical Medium High Amber Check venue Open
11 Feb emergency occurs facilities
5 PM Attendance over Medium High Amber Wide intensive Open
11 Feb estimated advertising
6 PM Attendance under High V High Red Venue Open
11 Feb estimated requirement
7 PM Insufficient Medium Medium Green Venue Open
11 Feb parking space requirement
8 PM Audio-visual High V High Red Provide backup Open
11 Feb malfunction equipment

150
Appendix Three lists some threats that history has shown may often threaten the
success of our projects, and although no risk list is ever complete, its purpose is to
prompt thought. There may also be “black swan” risks that are “unknown unknowns”;
where we are unaware of our own ignorance. The black swan is a valuable concept
that warns us to expect the unexpected – the wild card. Some further key points about
managing risk within our project are these:

• Applying a proven PM methodology is essential. Risk management is then

integrated with this methodology.

• Risk management is an integral part of good PM and to be wholly effective also

needs to be part of the culture of our organisation.

• Risk management is not an exact science and sometimes the precise figures used
may create an impression of accuracy that simply cannot be.

• Risk management is an on-going process applied throughout the project lifecycle.

Also, the effectiveness and efficiency of the risk management process itself needs
to be continually reviewed and improved.

• Risk includes both threats and opportunities, and both need to be managed
proactively. Opportunities can save time or money, enhance performance, and
help us to achieve the project goal.

• Not all threats can be avoided, and sometimes avoidance is too expensive or takes
too long, so another strategy is required, such as transfer, reduction or acceptance.

• The concept of risk tolerance needs to be understood and practised. Not all
individuals and organisations show the same tolerance towards risk. Attitudes
range from risk averse to risk taker.

• Our fundamental objectives with contemporary project risk management are

twofold: to increase the probability and impact of positive events or opportunities,
and to decrease the probability and impact of negative events or threats.

• We should be careful about rewarding “firefighters” at the expense of rewarding

“fire-preventers”. The firefighting syndrome can be a cultural impediment to
proper risk management.

• Risk management should create value. It’s a scalable activity. The benefits of
project risk management should exceed the costs of doing so.

• If we deal with risk effectively, then we will have fewer issues to resolve.

• “Prevention is better than cure” is the most important risk management principle.

151
Our risk management effort should be reviewed periodically. We can keep the focus
on risk by asking the following questions during every team meeting: “What is the
status of our recorded risks? How effective are our risk response measures proving to
be? What new risks have been identified since our last meeting? What parts of our
project risk management process need to be improved or changed?”

Remember that assumptions are also risks. Assumptions have been described as “The
mother of all fuck ups.” This insightful piece of script comes from the 1995 movie
“Under Siege 2 – Dark Territory.” History is full of disastrous assumptions. One that I
particularly like is “They can’t hit us at this distance...” – an assumption, final estimate
and last words of General John Sedgewick who was shot overlooking the parapets in
1864 during America’s civil war.

Most assumptions are optimistic. This means that they are likely to have a negative
impact if they prove to be wrong. Perhaps the best advice is that if in doubt convert
our assumptions into risk statements and put them in the risk log to ensure their proper
analysis. For example, rather than assume that material will arrive on time, it’s preferable
to express this as a risk “The material may not arrive on time.”

For several organisations, project risk management is a concept embraced in theory,

but neglected in practice. If we are serious about risk management and if we plan to
properly manage risk in our project, then some basic requirements are:

• Communicate the importance of risk management to the entire project team.

• Start the risk management process as early as possible during the project.
• Have a plan for how risks will be identified and monitored.
• Familiarise our PM team with the risk management process.
• Require that risk is properly reported, documented and managed.
• Define which team member will be responsible for each risk.
• Prioritise risks based on their likelihood and severity if they occur.
• Make risk management an agenda item for all project meetings.
• Allow sufficient budget for risk management activities.
• Know how much risk our organisation and project is prepared to accept.

As a minimum, we should not execute our project until we can confidently tick “yes” to
each of the following items:

• Is there a process in place for identifying and documenting risks?

• Is there a process in place to assess the priority of each identified risk?
• Do we understand our organisation’s appetite for risk?
• Has a response strategy or strategies been identified for each risk?

152
• Has a costed contingency been identified where appropriate for each risk?
• Has a trigger event been identified for each contingency?
• Is there a process to track and report the effectiveness of risk responses?
• Has the entire project team been trained in risk management?
• Have we assigned each risk an owner?
• Does everyone know how to access and complete the risk register?

The benefits of project risk management are huge. We can save time and money if
we deal with uncertain project events in a proactive manner. The result will be that
we minimise the impact of project threats and seize the opportunities that occur. This
helps ensure we deliver our projects on time, on budget, to the required quality, and
with the desired benefits.

153
 Chapter Twelve

Working the Plan

“No plan survives the first encounter with the enemy.” von Moltke
“Everyone has a plan until they get punched in the face.” Mike Tyson

While no plan survives its first encounter with the enemy, in PM there are at least six
possible enemies to contend with – estimates, issues, risks, variations, stakeholders
and benefits. Project maintenance is as important as project planning.

With a clear definition of the project goal and a plan to get there, we are now ready
to enter the execution or implementation phase of our project when we put our plan
into action and do the work needed to build our product (ie, inputs are converted to
outputs) and present the finished product to our client for acceptance. This is where
the actual project work occurs and is usually the longest phase in the project lifecycle
and typically consumes the most resources.

Some PMs might think, “I’ve planned the project, worked out by when we need to have
things done, and assigned tasks to team members. Now I can sit back, monitor the
work while it all happens like clockwork.” Well it won’t of course. Things can quickly
go off the rails. In fact, the only thing we can guarantee is that things won’t go exactly
according to our plan.

Our plan becomes the project “canary.” In the past, miners brought canaries into
mines for early warning. If the canary died, it was a sign that the toxic gases were rising
and the miners needed to get out. A methane-detecting canary might have saved the
day at Pike River. Should our grandstanding MP Winston Peters ever head into that
mine there’s bound to be a canary in his pocket. If it karks he’ll scarper for the surface,
but let’s be realistic - he’ll never enter.

Anyway, a plan can provide the same sort of early warning signal. If we veer significantly
off what’s planned, it’s a sign that something is wrong and adjustments need to be
made. Having a plan and checking progress against it allows us to make changes
before our project is in major peril. Starting our project work involves the following
activities:

• Assigning people to project roles. We confirm who’ll perform our project work,
and negotiate agreements with them and their managers to ensure they’ll be
available. It’s very likely that the team members on our project will be involved
in more than one project and will have other work responsibilities. Sometimes

154
 organisational silos and poor communication are the result of “turf wars” in which
project team members value their functional interests over cross-functional co-
operation.

• Introducing team members to each other and to the project. We encourage

our people to develop interpersonal relationships with each other, and help them
appreciate the overall purpose of our project and how the different parts will interact
and support each other.

• Giving and explaining tasks to team members. We agree with our team members
what work they’re responsible for and how they will co-ordinate their efforts.

• Defining how the team will perform its essential functions. We decide how the
team will handle routine communication, make decisions, and resolve conflicts. We
confirm or develop any procedures that may be required to guide the performance
of these functions.

• Setting up necessary tracking systems. We decide how we’ll track schedules,

work effort and expenditure, and establish processes for this purpose.

• Check readiness. Before we implement our project we need to check the following
essentials:

1. Does our project team understand the project purpose and goal?
2. Has the project scope been clearly described?
3. Do we have the right number and type of resources on our team?
4. Are team members’ responsibilities clearly defined and understood?
5. Will the project team meet on a regular basis?
6. Are project tasks defined sufficiently so progress can be accurately tracked?
7. Will progress reports be produced routinely for key stakeholders?
8. Will project issues be documented and resolved?
9. Is there an issue escalation process in place?
10. Is a risk log readily accessible?

Delegate Tasks

Delegation isn’t just a matter of telling someone what to do. The more experienced
and reliable the team member is, the more freedom we can give them to get on with
the job, although we still have a responsibility to ensure they carry out their assigned
tasks correctly. This means having some form of control. Good delegation is about
trusting people and allowing them to get on with it, while still being there to give a
hand if they need assistance. And at the completion of the job it’s always useful to ask
“If we had to do this again, what would we do differently?” since without some change,
improved performance is unlikely.

155
 “Handy” Delegation Guide

Monitor Progress

Once we implement the baseline plan, we need to keep the project on track until work
is completed. The specific performance targets we need to track and manage concern
time, cost, quality, scope, risk and benefits, recognising the priorities associated with
these. Is this a time-driven project where we have a fixed date for project completion?
Is it a cost-driven project where there is a fixed budget, which cannot be exceeded?
We monitor progress and take early corrective action when performance is less than
we can tolerate.

Tolerances are acceptable deviations from the baseline plan and are agreed with our
sponsor before work starts. If performance is outside or predicted to go outside these
tolerance limits, this is classed as an issue that we must resolve or escalate together with
remedial options and recommendations to our sponsor. If the result is a major change
to the work, then a new baseline plan is agreed against which future performance is
then tracked.

Progress is typically determined through reports, meetings, site visits and sometimes
sampling and testing. Some common project implementation challenges are:

• Unrealistic or poorly defined goal, parameters and assumptions.

• Difficult or demanding stakeholders; some with hidden agendas.
• Client /customer uncertainty.
• Unexpected risks.
• Plenty of issues (actual problems).
• Unrealistic estimates of time and cost.
• Multiple variations (ie, authorised changes).

156
• Scope creep (ie, unauthorised changes).
• Significant variance (actual versus planned performance).
• Unhelpful organisation culture / values.
• Miscommunications.
• Project priority down-graded.
• Business-as-usual work is given priority.
• Inert sponsorship.
• Funding and resource shortfalls.
• Lack of formal authority – no written charter or contract.
• Inexperienced team members or poor teamwork.
• External constraints beyond our control.

To help minimise project implementation issues we might first answer these questions:

• Why are we doing this project?

• Do we have a sound project business case?
• Who is funding this project and are there enough funds?
• Have we a clear picture of the project product?
• Has the expected impact of change been identified?
• Is the project aligned with organisational goals?
• Are success and acceptance criteria established?
• Is there stakeholder agreement on the product or products?
• Have the project team members clear roles and responsibilities?

It’s obviously not enough to devise a PM plan and assume that it will progress exactly
as we intended. It needs to be reviewed along the way so we can assess performance
(eg, actual versus estimated progress to date) and ascertain whether we’re progressing
better or worse than our plan predicted. We can then tweak our plan accordingly,
perhaps by reallocating some resources or pushing back a deadline.

Thus, during project implementation, project work packages are formally delegated or
outsourced and work commences while we manage the work, stakeholders, variations,
risks, issues, documentation, report progress, lead the project team, and manage
change. In particular, we check for variance (the difference between planned and actual
progress) and take corrective action where needed to keep on track or sometimes re-
plan the balance of our project.

157
 Project Communications

Of course, we want to get our project delivered on time. But we can only do that
by monitoring the work schedule regularly. We cannot simply “set it and forget it.”
However, there is a trade-off between the cost to monitor progress and the value
of resultant information since project control should be cost-effective. The need to
monitor project performance will typically be influence by:

• Project priority.
• Size of resource commitment.
• Cross-project dependencies.
• Allowable tolerance limits.
• Project team members’ experience.
• Stakeholder expectations.
• Risk assessment.
• Legislation.
• Consequences of failure.
• Project complexity.
• Project novelty.
• Progress to date.

Cross-project or inter-project dependencies is a concern if our project is part of

a portfolio of projects or part of a programme of related projects when a delay to
our project may upset the scheduling of another project, or visa versa, recognising
that some projects or project tasks can’t be initiated until other projects have been
completed or shared resources become available – much like a network diagram of
intra-project dependencies.

158
During project implementation we monitor schedule progress, track costs against
the budget, deal with risks and issues, take corrective action and report progress. In
particular we:

• Engage stakeholders.

• Regularly review planning assumptions.

• Watch for symptoms of risks arising.

• Monitor variances and trends to schedule, cost, quality and benefits.

• Ensure the effectiveness of resources – people, materials and equipment.

• Resolve or escalate issues.

• Apply processes for control, communication, quality, health and safety, variations,
payments, decision-making, problem solving, stakeholder management, risk and
issues.

• Ensure security of physical and intellectual property.

• Maintain a positive cash flow.

• Monitor external factors that may affect our project.

Remember that a project that’s slipped by two weeks when we’re 25% complete, is
likely to be eight weeks late unless we take early action. Regular monitoring and
shorter reporting periods enables us to quickly identify actual or potential problems as
early as possible so that we can make timely adjustments to our PM plan. Tools and
techniques for tracking progress might include:

Tracking Progress

• risk log • questionnaires

• issues log
• lessons learned log
• change log
• accident register
• progress reports
• status reports
• exception reports
• site visits
• variance reports
• milestone slip charts
• personal contact
• meetings
• reviews and audits
• prototypes and trials
• checklists
• telephone conferences
• video conferences
• structured walk throughs
• demonstrations
• simulations
• benchmarking
• interviews

159
Here are four questions that we should regularly ask our team members. These aren’t
stultified performance review questions. They are useful questions that can dramatically
improve a team member’s morale, output and the quality of their work:

• “What’s your biggest accomplishment this week?”

• “What’s your biggest challenge right now?”
• “What should we do differently?”
• “Is there anything I can help you with?”

Reports that are common for most projects include status reports that compare project
performance as at a specific date to that which was planned, progress reports that
describe what has been accomplished over the reporting period, forecasts that predict
future status or performance, and variance reports that document the difference
between actual project results and anticipated results. Periodic reviews and audits are
also appropriate, where:

• A review is a structured opportunity for reflection to compare the project against

good-practice PM, assess performance to-date against original baseline, identify
key issues and risks, and make timely and informed decisions for on-going effective
project implementation. Reviews are usually an internal assessment. While
monitoring is ongoing, reviews are periodic throughout the project lifecycle. It’s
important to bring in someone with project experience for such reviews to give our
project an objective health check. Sometimes our project team and we PMs can be
too close to the project to see lurking problems. Such reviews are best built in at
the beginning, rather than wait for a crisis to occur.

• An audit is an assessment to verify compliance with established legislation,

policies, protocols, rules, regulations, procedures or mandates. The emphasis is on
assurance and compliance – a check to confirm that we are doing the right things
and doing those things right. Audit frequency will usually be determined by the
novelty, size and complexity of our project, and progress to date. Auditors should
be provided with the project charter, PM plan, recent status reports, and an up-to-
date issues log, risk log, and change register. Based on the ISO 19011 standard for
auditing, our project auditor’s should adhere to the following practices:

• Demonstrate integrity and professionalism.

• Comply with all applicable legal requirements.
• Withstand pressures that may affect their professional judgment.
• Present complete, independent and impartial assessments.
• Respect confidentiality and information security.
• Use an evidence-based approach to reach reliable conclusions.

Should project variance look to move beyond predetermined and acceptable tolerance
limits, corrective action is needed. Re-planning or corrections that are likely to exceed
parameters and any contingency provisions in our current charter first need our sponsor’s
approval, followed by the issue of an updated charter.

160
Manage Variations

Variations are changes to the original scope of work. It’s essential for project success
that such variations are carefully controlled and typically comprise four steps:

1. Request. The stakeholder who requests a change must provide relevant information
on the need for and nature of the change. The request is entered into a change
register, which records all such requests and their status (eg, pending, approved,
rejected or deferred).

2. Review. We PMs then review the request to determine its impact on our project’s
parameters, risk profile, products and benefits. If the proposed change doesn’t
add value to the project, the change would normally be rejected. Three key
questions we need to ask are: “Does the variation introduce new benefits? Does
the variation reduce the value of existing benefits? Does the variation improve
existing benefits?”

3. Authority. If changes are major or cumulatively exceed the project budget or

cause a delay to the project completion date, then we usually need to escalate
the issue to the project sponsor with a request for additional funding from the
management reserve and/or an extension of time.

4. Implementation. The decision is communicated to our project team and other

relevant stakeholders. If the change is approved, the PM plan is updated as per
the change order.

Change requests take on a contractual significance where a project or project task is

being undertaken by a contractor. Often an agreed schedule of rates forms the basis
for price changes, which eliminates the need to negotiate a price for each change.
It’s sensible in such contracts to include a provision that any changes must be agreed
in writing and signed by or on behalf of both parties to prevent misunderstandings.
When a contractor does unauthorised work or provides materials of higher quality than
required by the contract, the contractor is not entitled to charge this as a variation.
Thus our contracts usually include terms that provide us with a right to order variations
providing such variations don’t fundamentally alter the original work scope. Generally,
the later a change happens in a project, the more it costs. Of course we can’t unilaterally
delete work and sometimes significant variations are better completed as separate
follow-up product enhancement projects.

Health and Safety

While it’s ok for us to personally use our step ladder with a faulty rung, if we’re paying
a contractor and they have an injury using it we could be fined big bucks. Yes, our
government has produced comprehensive safety regulations in an effort to protect
us from ourselves. There are some ridiculous examples, one concerning the need for
scaffolding. It’s rumoured that if a light bulb needs to be changed and the height is
over five metres, scaffolding and two certified installers are required. Nevertheless,

161
The Health and Safety Reform Bill has been passed and the new law (the Health and
Safety at Work Act or HSWA) has been in force since 4 April 2016 setting out the
principles, duties and rights in relation to workplace health and safety and makes
everyone’s responsibilities clear, where:

• Businesses have the primary responsibility for the health and safety of their workers,
any other workers they direct, and any people at risk from the work of their business.
• Officers (ie, company directors, partners, board members, CEOs) must do
regular due diligence to make sure the business is meeting its health and safety
responsibilities.
• Workers must take reasonable care of their own health and safety and ensure that
their actions don’t adversely affect the health and safety of others. They must also
follow any reasonable health and safety instructions given to them by the business
and co-operate with any reasonable business policy or procedure relating to health
and safety in the workplace.
• Other people who come into the workplace, such as visitors or customers, also
have a duty to ensure that their actions don’t adversely affect the health and safety
of others.

Project Meetings

Good communication is the mainstay of any relationship. Project teams are no exception
and meetings can be productive, engaging and extremely useful. They can also be
boring, demotivating and steal valuable time. We hold project meetings to plan, solve
problems and make decisions. There are more cost-effective ways, such as email and
texting, to share information when face-to-face interaction is not needed, although do
resist consistently sending cc messages to keep everyone “in the loop.”

Admittedly, project meetings may also play a role in developing team buy-in,
communications, leadership and teamwork. But a project meeting should be brief. So
we should book a suitably equipped meeting room for only a limited amount of time,
perhaps no longer than an hour, and everyone should understand the purpose of the
meeting. Single issues that require detailed deliberation might better be deferred to
special meetings where we can discuss the specifics with only those people affected.
Anyway, here are eight commonsense reminders to help us run useful project meetings:

1. Set ground rules. Our project team should establish a code of conduct at the
project kickoff meeting and confirm it again at the start of each meeting. Starting
and finishing on time would be one rule, although we should finish earlier where
possible.

2. Prepare an agenda and distribute it beforehand. A well prepared agenda is

a reminder to the participants what the meeting is intended to cover and what is
expected of them. It gives everyone time to gather the information they need. Our
agenda items might best be arranged in priority order with more time allocated to
the more important and complicated items.

162
3. Repeat the purpose. The agenda should also be a reminder of the purpose of
the meeting and we should state this again at the beginning of the meeting and
during the meeting if discussion is veering off topic. Perhaps write the purpose of
the meeting on a flipchart page and pin it to the wall for all to see throughout.

4. Stay focused. Don’t deal with any unrelated issues – defer them instead to another
meeting. Stick to the agenda. Use a “parking lot.” Appoint a time-keeper. Invite
different participants to chair the meeting or lead a topic.

5. Allow everyone a chance to speak. Nobody wants to sit in a meeting listening

to one person dominate the conversation, so limit the time any one person is
allowed to speak. We might have a ball that gets passed from speaker to speaker.
This makes people conscious that they are asking for something valuable - the
attention of the group. Discourage fence sitting and manage conflict but avoid
premature agreement. We might practise “exception reporting” whereby only
those matters that are abnormal are raised. And don’t necessarily stop meetings
to bring latecomers up to date or this may encourage annoying lateness.

6. Avoid boredom. Little will be achieved if people are not fully engaged in the
meeting. Where possible schedule the meeting for the morning when individual
alertness is likely to be highest and avoid the afternoon slump. An interesting
practice, intended to encourage succinct meetings, is to run them standing up
or hold “walk and talk” meetings , but perhaps shorter people or slower walkers
could be disadvantaged!

7. Assign actions. Assign follow-up actions with realistic finish dates to specific
individuals. Appoint a scribe to create an action plan (perhaps using an electronic
whiteboard or have someone photograph the whiteboard and mail it to participants)
that is distributed promptly and preferably at the conclusion of the meeting, a
useful format for which is:

Project Meeting Action Plan

Item Description Discussion Decision Actionee Due Date

Points
1.

2.

3.

4.

8. Finishing. Summarise what has been discussed, what actions have been assigned,
distribute the action plan, and perhaps confirm a date for the next meeting. Finally
take a few minutes for the group to evaluate what has occurred. This is not a
time to rehash discussion, but to share ideas about how efficient and effective the
meeting was and how future meetings could be improved.

163
In summary, prepare in advance, have an agenda, book a venue, ruthlessly stay on time
and stick to the topic, maximise participation, produce an action plan (who is to do
what by when), evaluate the meeting, and follow-up on assigned actions.

Project Performance

A common method of communicating project performance is “RAG reporting” - Red,

Amber, Green. Green status means performance is clearly within tolerances. Amber is
barely within tolerances. Red indicates performance has exceeded tolerances. Some
people argue that there’s no need for Amber – the project performance is either Red or
Green. For a project, the basis for control is the business case and the PM plan.

Control methods must be appropriate to the scale, context and complexity of the
project. On smaller projects a simple slip chart, comparing actual progress with the
baseline on a Gantt chart will usually suffice. On projects where there is a well-defined
scope, a more sophisticated method such as earned value management (EVM) might
be used.

The project critical path shows those tasks that if they were to slip will cause a delay
to the project finish date. If slippage occurs, the first step should not be to add extra
resources, but rather to identify the root cause of the slippage. We want to know
why slippage has occurred before considering what corrective action to take. Possible
corrective actions to overcome schedule slippage include:

• Renegotiate milestones, finish date, work scope, and/or performance standards.

• Redeploy resources to focus effort on critical and near-critical tasks.
• Deploy more resources and/or more productive resources.
• Stand down any trainees and poor performers.
• Apply the “minimum float” rule whereby we first accelerate critical tasks.
• Undertake more work concurrently (fast-tracking).
• Work overtime and/or contract out work.
• Impose late completion penalties (eg, liquidated damages).
• Set incentives for early or on-time completion and productivity improvements.
• Accept partial delivery (ie, postpone less-essential work).

“Ramp up” time is often required by new project staff, which takes away existing project
team members and puts them in coaching roles. Although, for Brooks’ Law to hold
true, the amount of effort lost to coaching must exceed the productivity contributed by
new staff when they eventually become productive. Remember too, it costs money
to bring people on to our project – hiring costs, admin costs, upskilling, and then the
cost of lost productivity as they work out how to get on in the team and find their feet
in their new role.

164
 Project Control Process

During project execution we have techniques to compress the project schedule or

catch-up when the timely completion of tasks is in jeopardy. As PM, we should analyse
our options to compress or recover a schedule, given the possible impact of these
measures on our project resources and budget. Two widely used schedule compression
and recovery techniques are fast tracking and crashing. Sometimes, when we face the
need to compress or recover our project schedule, we might combine fast tracking and
crashing. To accelerate our project we must reduce the duration of the critical path,
the best candidate tasks for such acceleration being earlier tasks, longer duration tasks,
and those cheapest to accelerate.

To prevent our project from spiralling out of control, we need to constantly monitor
progress, watch out for potential problems, and apply prompt corrective measures.
A cost overrun, also known as a budget overrun, involves unexpected costs incurred
in excess of our budgeted amounts. Most cost overruns stem from poor estimates.
Some means to address such over-expenditure are:

• Check schedule progress. Ahead of schedule work incurs early expenditure.

• Renegotiate the budget, product/project scope, pay rates or material costs.
• Trim unnecessary “nice to haves” from product features.
• Minimise order quantities and/or purchase economical order quantities (EOQ).
• Sell off excess inventory for cash injection, avoid stockpiling, and practice JIT.
• Substitute cheaper processes, labour, materials and equipment.

165
• Eliminate advances, deposits, rework, wastage, theft, spoilage and scope creep.
• Have more progress payments from client. Delay own payments perhaps.
• Optimise schedule-budget. An ambitious schedule is usually expensive.
• Shun perfection and extra audits. Settle for “good enough”.
• Ensure all charges are accurate, legitimate and properly authorised.
• Review delegated authorities, centralise financial approvals, vet all purchases.
• Only pay for satisfactory completed work. Apply retentions.

Yet on rare occasions our project budget may be excessive. This too is undesirable
and surpluses should be declared to avoid unnecessary expenditure and thus free
up money for other purposes. Unused contingency funds should also be declared
when the project moves past exposure to the risks for which these contingencies were
created, although don’t expect contractors to do so.

Quality

It’s easy to lose focus on quality. We often spend most of our time thinking about
budget and deadlines because they’re more visible and easy to quantify. The old
adage about quality being “in the eyes of the beholder” is true - quality is ultimately
measured by our customer. Sometimes there is a tendency to think that “quality”
means the best material, the best equipment and zero defects. However, in most
cases we settle for “good enough” or “fit for purpose” rather than an expensive
perfect solution or one with extra requirements that our customer didn’t request. Also,
a product may be of good quality (no defects) yet be of low grade (few or no extra
features). Quality management is a discipline for ensuring that outputs, benefits, and
the processes by which they are produced, meet stakeholder requirements and are fit
for purpose. Project quality management activities ensure that:

• Customer satisfaction is a key measure of a project’s quality.

• Products meet agreed specifications and requirements.

• Project work processes are performed efficiently and are continuously improved.

• Non-conformance (ie, defect or deviation from a specification or standard) is

identified and prompt corrective action is taken.

• The cost of preventing mistakes is usually less than the cost of correcting them.

166
Trade-offs

Pushing out a deadline or delivering under scope may be fine if we’ve agree to this
with our sponsor and stakeholders. Are they willing to sacrifice some scope to hit
a deadline? Or vice versa? If the deadline takes precedence over scope, then we
must turn our focus to delivering first those things that the client values most. These
possible trade-offs among project parameters should be discussed and decided with
our stakeholders preferably during the project planning phase. We PMs may use trade-
offs during the life of our project whenever we have variance or a variation. Some key
considerations about the relationship between time and cost are:

• Project crash costs and indirect costs have an inverse relationship.

• Crash costs are highest when the project is shortened.
• Indirect costs increase as the project duration increases.
• Optimum project time is at the minimum point on the total cost curve.

Project Cost-Time Trade-Off

Here’s an example of using project trade-offs. Let’s say our schedule has a task that
was originally underestimated. Now that task will take 160 more hours of work than
originally planned. This 160 hours of extra work will take four weeks at the rate of 40
hours a week using one team member, which will take the task duration four weeks
beyond the baseline plan. Because the task is on the critical path, it will cause a four-
week delay to our project’s completion date.

Should our sponsor not accept this slippage, we might then look at a trade-off that
comes from adding say one contractor to the task. Then the existing team member
would do 80 hours of work and the contractor would do the other 80. If each worked
40 hours a week, they might finish the task in two weeks rather than four weeks.

167
 The cost of hiring the contractor is say $100 an hour so the project budget would
increase by $8,000. The trade-off being to reduce duration by two weeks the project
will cost an extra $8,000.

Project Parameter Relationships

Total
Cost
Cost

Cost
Work
Scope

Normal
Crash

Time Time

Ultra-
Perfect
Quality

Fit for
Purpose

Time and/or Cost

There are other types of trade-offs. For example, we might reduce the scope of our
project, which usually reduces the work, duration and cost. There are also trade-offs
for quality, risk and benefits that could be considered. In any project, we start making
trade-offs from the least important constraint, and we only play with the most important
constraint when our project is in a desperate situation. Also, projects need their trade-
off parameters and priorities set at the beginning, not just when trouble appears.

It’s always best to think through our possible trade-offs and contingency plans with a
clear head before something goes wrong and people enter headless chicken mode. A
detailed worked example of a trade-off analysis is at Appendix Four.

168
Managing Issues

In PM lingo an issue is a risk that has now become a reality. We may or may not have
identified the possible issue when it was a risk, or the issue may be a risk that was not
fully mitigated and now threatens project success. When an issue cannot be resolved
by the PM and project team, it’s usually escalated to our project sponsor together with
our suggested remedial options.

Some practitioners argue that all issues are problems, but not all problems are issues.
The distinction sometimes made is that problems can be resolved at PM level, whereas
issues are those matters that need to be escalated to our project sponsor for resolution.
Usually where our suggested solutions require a change to current parameters as
defined in the project charter, it’s an issue that needs to be escalated.

The aim with issue management is to identify and resolve the issue quickly, efficiently
and effectively, and then move on, with as little impact to project progress as possible.
To achieve this we first need stakeholders to record the issue in our Issues Log, a typical
format for which is shown at Appendix Two, where issue status lends itself to a traffic
light system – “red” meaning the project cannot proceed before the issue is resolved,
“amber” meaning that resolution is in process, and “green” meaning the issue has
been resolved. An Issues Log allows us to:

• Have a safe and reliable method for our team to raise issues.
• Track and assign responsibility to specific people to manage each issue.
• Analyse and prioritise issues more easily.
• Record issue resolution for future reference and learning.
• Monitor overall project health and status.

Incidentally, a periodic comparison between our project’s Issues Log and our Risk Log
is one indicator of the effectiveness of project risk management, where a large number
of issue entries and a small number of risk entries suggests a need for improved risk
management, given it’s easier and cheaper to prevent issues than having to resolve
them after they arise.

Our job as PMs is to manage project issues throughout our project’s life. In this regard,
some useful points to keep in mind are:

• We should encourage stakeholders to bring issues to our attention and it should

be easy for them to do so. We need to encourage our project team members and
other key stakeholders to properly record project issues in our Issues Log.

• Once a risk becomes an issue, we should move it from our Risk Log to our Issues
Log and ensure there is only one Issues Log (digital or hard copy) and that it’s
readily accessible.

169
• Taking into account the importance of the issue, we assign a date by when resolution
is needed, and assign its resolution to the person best equipped to deal with it,
who on some occasions might be someone outside the project team.

• Once an issue is raised, recorded and assigned we should regularly check to ensure
that it’s being properly dealt with. Ideally by the end of the project there should be
no outstanding issues.

• Report on significant project issues and measures underway for their resolution in
our routine status reports to the project sponsor and other key stakeholders.

Managing issues involves both problem solving and decision-making. Although these
terms are sometimes used interchangeably, management literature makes a clear
distinction between the two. Problem solving is a larger process that starts with the
identification of a problem and ends with an evaluation of the effectiveness of the
applied solution. Decision-making is a subset of the problem-solving process and
refers only to the process of identifying alternative solutions and choosing from among
them. Problem solving and decision-making might be an individual endeavour or
involve others. Effective PM relies upon individuals and teams solving problems and
making informed decisions on a regular basis. The comprehensive process is:

1. Recognise Issue. First we need to recognise we have an issue and record it in the
project Issues Log. To solve it easily, we must detect it early.

2. Define Issue. It’s useful to develop an issue statement such as “We have insufficient
storage space for project building materials.” “On-site safety procedures are not
being followed.”“The project has fallen behind schedule.” Usually this statement is
clear, concise and specific, and contains no assumptions, likely causes or solutions.
It helps to verify the issue statement by conferring with others. If there are several
issues, they may need to be prioritised for attention in terms of their importance
and urgency.

3. Identify Cause(s). Care needs to be taken to identify the root cause or causes
and not simply issue symptoms. A simple “why analysis” (asking “why” several
times) often gets to the root cause. Other techniques are brainstorming and root
cause analysis. It’s also useful to get input from others who noticed the issue or
are affected by it.

4. Determine Solution Attributes. What will the situation look like when the issue
is resolved? We now determine the characteristics (essential and desirable) of the
ideal solution. Again brainstorming is useful as is a “paired comparisons analysis”
in order to prioritise the characteristics, criteria, features, functions or attributes
inherent in the ideal solution. Once we are clear about the solution attributes, we
can identify possible solutions.

5. Identify Possible Solutions. Here we typically brainstorm various solutions –

new or improved processes, policies, protocols, procedures, products, people etc.
This step in the process may involve a literature review, research, benchmarking,

170
 surveys, questionnaires, discussion groups, and sometimes the issue of an RFP
seeking outside solutions.

6. Shortlist Probable Solutions. Some solutions might not be viable, feasible or

practicable. Short-listing eliminates those solutions that are inadequate in terms
of our essential solution attributes. Also, there may be other constraints that
would rule out possible solutions, such as ethical, political, economic, financial,
environmental, legislative, cultural, social, time, risk and resource availability
considerations.

Problem Solving and Decision-Making Process

171
7. Evaluate Shortlisted Solutions. Here we assess the suitability of each viable
solution against the various solution or selection attributes that we identified
earlier. A useful tool to use at this step is a weighted-attributes decision matrix
where each attribute is assigned a numerical value that represents its relative
importance. This enables us to quantify decision-making and helps us make an
objective assessment.

8. Select Best Solution. The evaluation of options enables us to identify the best
solution.

9. Future-proof Solution. The best solution is then subject to some scrutiny in order
to identify and respond to potential implementation problems. Such risks are
usually assessed in terms of their estimated impact and probability. A risk analysis
worksheet could be employed.

10. Prepare Action Plan. As a minimum, our action plan identifies who is to take
action, describes the activities needed to implement the solution, resources and
timings. In some instances the PM plan may need to be revised.

11. Implement and Control. The solution is implemented, progress is monitored and
action taken where necessary to resolve deviations and accommodate changes.

12. Evaluate Results. Has the issue been resolved? What have we learned? Have
new issues been created? What should be done to prevent this type of issue in
the future? Mention the issue and its resolution in our project report and update
our organisation’s risk list to help us avoid any repetition of this issue.

The decisions made during our project may be categorised in three ways:

1. Authority. These decisions depend on the power or influence of an individual

or small group. This approach may be needed in situations that require a quick
resolution. However, the quality of the decision depends on one individual or a
small group, which could prove problematic.

2. Majority. In this instance, decisions are made based on the preferences of the
majority. While this approach strives for balance and fairness, up to 49% of those
involved in the decision may lose out, which can lead to resentment and resistance.

3. Consensus. Consensus decision making ensures that all input and ideas from
a group or team are considered until a final decision that is acceptable to all
emerges. Consequently, agreed solutions are often innovative and creative, and
more likely to be successful as everyone has helped to shape the outcome. Us
PMs are no longer solely responsible for the decision and its consequences – it
is owned by the team. This approach relies heavily on respectful dialogue and
open-mindedness, but may become time-consuming with larger groups or difficult
decisions.

172
Despite the advantages of consensus problem solving decision-making, on occasions
time constraints may necessitate a more autocratic approach. A detailed assessment
of the potential advantages and disadvantages of group problem solving and decision-
making are shown in the table below.

Group Problem Solving and Decision-Making

Advantages Disadvantages

• new ideas and more ideas
• objectivity and reduced bias
• different perspectives
• develops collective ownership
• authoritarian power checked
• develops others’ abilities
• increases solution acceptability
• improved understanding
• more alternatives assessed
• synergy and cross-fertilisation
• shared responsibility
• increased risk-taking
• takes time and thus costs more
• personal needs may take priority
• minority tyranny – cliques form
• majority tyranny - conformity
• lowest common denominator solution
• dilution of responsibility
• Groupthink, shyness, domination
• “not my problem” attitude
• additional alternatives not explored
• ill-will due to conflict
• confidentiality concerns
• unproductive competition

Knowing When to Say “No”

Whether we’re dealing with customers, business partners or internal colleagues, we’re
certain to encounter unreasonable requests every now and then. We should let our
team know that they are not only allowed, but also expected, to deny requests in the
following circumstances:

• Uncontrolled scope changes. Customers may wish to change requirements or

add products once our project is underway. We can prevent uncontrolled scope
creep by helping our team members understand the parameters of our project,
and empowering them to turn down requests that aren’t part of the formal change
process.

• Unrealistic timelines. Delivering on an urgent request could make us a hero, but

committing to a tight deadline and then failing to meet it can make us a scapegoat.
Let our team members know that it’s ok to say “no” when someone asks for the
impossible.

• Misplaced responsibility. Project teams may be asked to take on work that

rightfully belongs to someone else. Doing someone else’s work can disengage
employees and hurt project performance. To help avoid this situation we must
provide our team members with clear descriptions of their roles and responsibilities
and remind them to be on the lookout for rogue requests.

173
Knowing when to say “no” is one thing, but team members also need to know how to
do so without creating unnecessary emotion. The key to denying a request tactfully is
to show that we understand the request but have sound reasons for turning it down.
We should explain to our team members that when they turn down a request they
should maintain a collaborative demeanour and point out the problems that the request
would create if we tried to comply with it.

Earned Value Management

Earned Value Management (EVM) is a project performance monitoring and control tool
that integrates project scope, time and cost to establish a baseline against which to
assess progress. It’s one of the most sophisticated and accurate methods for measuring
and controlling project schedules and budgets and for forecasting results. Earned
Value requires a WBS with clearly defined tasks, each of which has been assigned a
time and cost estimate, which then allows us to determine:

• What has been achieved of the planned work.

• What it has cost to achieve the planned work.
• Whether the work achieved is costing more or less than was forecast.
• Whether the project is ahead or behind schedule.
• Predicted project cost and schedule performance based on current trends.

The aim is to highlight cost and schedule issues early, thus provide the maximum time to
restore the situation or minimise their impact. There are three key project performance
measures associated with EVM:

• Planned Value (PV). Also called Budgeted Cost of Work Scheduled (BCWS), PV
is the project expenditure that we anticipate over the life of the project. When
graphed it’s usually an S-curve in shape, recognising that expenditure is less in the
beginning, and the end, and is at its maximum during the middle period of our
project.

• Actual Cost (AC). Also called Actual Cost of Work Performed (ACWP), AC is the
aggregate cost that is actually spent on a project as it’s implemented.

• Earned Value (EV). Also called Budgeted Cost of Work Performed (BCWP), EV is
the work that has actually been done, but costed using the authorised budget.

Shown on the next page is an EVM graph showing not only PV or BCWS, but also the
project performance curves to date for AC or ACWP and EV or BCWP. The PV or
BCWS includes contingencies of time and cost for identified risks, but doesn’t include
the management reserve, which is an allowance for the unexpected – unidentified risks
and unplanned variations. In this example, these performance curves show that at this
time our project is both over spent and behind schedule.

174
 Earned Value Graph

EVM employs the following project performance measures:

• Cost Variance (CV). As the name suggests, cost variance calculates the difference
between the cost actually incurred and the planned cost. It shows whether our
project has gone according to our budgeted cost or not. CV = EV – AC. If CV is
negative, it means that actual cost of performing the work is more than planned (ie,
AC > PV).

• Cost Performance Index (CPI). This ratio shows cost performance. CPI = EV / AC
where an index of less than 1 means that actual costs are more than were budgeted,
and an index of more than 1 means that actual costs are less than anticipated.

• Schedule Variance (SV). This measures whether our project has taken more or less
time than we planned. SV = EV – PV where a negative figure means our project is
behind schedule and a positive figure means its ahead of schedule.

• Schedule Performance Index (SPI). This ratio shows schedule performance. SPI
= EV / PV where an index of less than 1 means behind schedule and more than 1
means ahead of schedule.

• Estimate at Completion (EAC). Used to find the estimated cost of our project at
completion, based on present performance. EAC = BAC/CPI. BAC is Budget At
Completion.

• Estimated time to complete (ETC). Used to find the approximate time to complete
the project, based on present performance. ETC = Original Duration/ SPI.

• Critical Ratio (CR). Single measure of overall performance todate. CR = CPI x SPI.
A CR of 1.00 indicates that overall the project performance is on target.

175
 Earned Value Terminology and Formula

Terms Formula Comments

Cost Variance (CV) EV - AC Negative is overspent or behind

schedule; positive is underspent or
Schedule Variance (SV) EV - PV ahead of schedule.

Cost Performance Index (CPI) EV/AC Performance under 1 is less than

Schedule Performance Index (SPI)
Critical Ratio (CR)
planned, performance over 1
EV/PV is better than planned, and if
performance equals 1 progress is
CPI x SPI as planned. These measure may be
shown in control chart form.

Estimate At Completion (EAC) BAC/CPI Estimate is in dollars.

Estimated Time to Complete (ETC) Original Duration/SPI Estimate is in units of time.

EVM accuracy depends on the timeliness and reliability of input data. The main
challenges with EVM is that every task must have an estimate as to the number of hours
it will take to complete, and the actual hours spent on each task need to be tracked.
EVM has no measurement of quality, which could mean that we have done all the work
on time and within budget, but the product doesn’t meet specifications or isn’t fit for
use.

Here’s an example. Our project team had planned to accomplish $25,000 worth of
work to date. It has spent $23,000 to date, and accomplished $20,000 worth of work.
Thus the EV is $20,000, and the AC is $23,000.

Here’s another example. Our project has a total budget of $100,000 and is estimated
to take 10 months to complete. After 5 months, it is estimated to complete 50% of its
work at the cost of 60% of its budget, but it actually accomplished only $40,000 worth
of the work, and spent 50% of its budget. Thus the PV is $60,000, the EV is $40,000,
and the AC is $50,000.

The project performance shown on the next page for this cable laying project is not
good. At eight weeks this 15 week $15,000 project is already overspent by $5,080,
is more than one week behind schedule, with a predicted total cost of $27,777 (ie,
$15,000/0.54) and a duration of 25 weeks (ie, 15 weeks/0.6).

These predictions of cost and duration for this cable laying project assume that the
project continues without remedial action, which in this instance would need to be
dramatic if the project is to be completed within the original 15 weeks at a cost of
$15,000. Perhaps the only solution now if the project is to continue is to considerably
increase the budget and extend the completion date, or rigorously de-scope the
project, but whatever action is taken, the hapless PM will doubtlessly be castigated,
since variances of this size should have been detected and acted on much earlier.

176
Example Earned Value Graph

177
Various combinations of these project performance curves are possible, some of which
are shown in the following graphs. Of course, if all is going exactly to plan all EVM
performance curves would coincide – something we’ll probably never experience.

Earned Value Performance Curves

178
Since EVM performance indices (CPI and SPI) measure deviations from the plan, they
can be used to indicate whether the risk process has been effective in addressing
uncertainty and controlling its effects on project performance.

EVM - Performance Indices

Plotting the trend of CPI and SPI over time against thresholds gives useful information
on the type of risk exposure faced by the project at any given point and possible action
to be taken.

SPI and CPI Relationship

179
Why isn’t EVM used more often? There are two things we have to do to use EVM -
establish a baseline and track progress. Unfortunately, it’s these two things that many
organisations don’t do well. In the absence of either one of these basics, we won’t get
far with EVM. But given these basics EVM works for all kinds of organisations that have
projects to plan and a need to deliver those projects on time and on budget.

So, in summary, during project execution we lead our team, assign tasks, engage with
stakeholders, check and report project progress, manage variance, issues, risks and
change requests, and where necessary re-plan the project.

180
 Chapter Thirteen

Quitting the Project

“You’ve got to know when to hold ‘em

Know when to fold ‘em
Know when to walk away
And know when to run.”

Kenny Rogers – “The Gambler”

“The Gambler” reminds us that in poker, folding is part of the game. It allows us to
take risks, knowing that if things don’t take a positive turn, we can always abandon the
pursuit, although as in poker our project might be seduced by sunk costs - irreversible
financial “investment.”

In 1996 there was a fatal attempt to climb Everest, when five people died on the
mountain unwilling to heed the mandatory turnaround time and pull the plug on an
expedition that faced deteriorating conditions. How do these projects continue in the
face of evidence that the plug should have been pulled? How can we make sense of
this compulsion to continue? While there’s no single root cause, some factors include
executive pressure, lack of contingency planning, organisational recognition and “no
quitters” culture, and the sunk cost trap.

There are two main reasons for closing a project. The first, and most common, is
that all project work has been completed and our project sponsor and client have
confirmed that the final product sufficiently meets their requirements. The second
reason for closing our project is when the decision has been made to halt the project
prematurely – project extinction. Not every project makes its way to the finish line, and
not every project should. As PMs we may find ourselves, at some point in our career,
running a project that has little or no chance of success.

In this situation we might arrange a workshop for those involved at which we highlight
the positives from the project so far, learn from our mistakes, get everyone on-board
with PM plan version 2 and move forward with renewed confidence. However, without
re-writing the business case, slimming down the requirements’ list, extending the time
frame or increasing the budget, sometimes it might be better to stop our project or
recommend it be stopped.

Nobody usually thinks about stopping a project at the time of its conception when
big ideas are being thrown around and plans are being made for success. There is
often unbounded enthusiasm. However, since too few unsatisfactory projects aren’t
cancelled, this short chapter devoted to early closure is much warranted. Some sponsors

181
may believe that it’s a lot easier to let the project just roll on and have someone else
take the blame if, in the event, adequate benefits fail to materialise. My view is that
organisations need to get much tougher about terminating unrecoverable projects as
early as possible in order to free-up resources, rather than prop up failures.

We might legitimately abandon our project mid-course for a variety of reasons – the
product is no longer needed or has become obsolete, the completion date can’t now
be achieved, costs are excessive, withdrawal of funding and other resources, benefits
are now unachievable, the needed expertise is unavailable, scope creep is rampant,
project priorities have changed, the project doesn’t comply with new legislation, market
circumstances have changed, or someone else has produced a better solution or more
competitive product. We shouldn’t expect all our projects to succeed. However, when
we encounter these sorts of scenarios, our emotional response is often to feel that we
must continue because of how much we’ve already put into the project. It’s about
throwing good money after bad. In the financial world it’s called “the sunk-cost fallacy.”

When project sponsors consider aborting a project, they may view the past investment
in the project as wasted resources and this aversion to waste leads them to continue
investment in the project in the hope of using rather than losing the investment to date.
Therefore, sponsors may pursue unsuccessful project investments, throwing good
money after bad. Also, project sponsors have been known to continue a losing project
in order to avoid or delay their own or their organisation’s reputation loss. Sending a
message that project termination threatens careers may tempt sponsors and PMs to
continue projects that should die. However, failure to stop death-march projects is a
failure of governance.

Most organisations value persistence and perseverance. We may hear business leaders
exhort their PMs to demonstrate a “can-do, never give up” attitude. This “no one
likes a quitter” rhetoric means that individuals are discouraged from admitting their
mistakes. People may not report or cut their losses out of fear of being blamed for the
failure. But, perhaps we should strive to create an organisational culture that makes
admitting and learning from mistakes as valued as persistence and perseverance.

Sponsors and PMs launching a project might do well to consult with skeptics along with
the believers from the outset, paying particular attention to those who will be directly
involved in making decisions. De Bono suggests that every project team would benefit
from a “black hat” - a devil’s advocate who identifies project investment difficulties and
dangers.

182
The original true believer is the project champion, who often holds an unyielding
conviction, based, often as not, on a hunch rather than on strong evidence that the
project will succeed. While the importance of project champions is well documented,
the value of an exit champion or someone who recommends pulling the plug on a
project before it becomes a money sink, hasn’t generally been appreciated. Exit
champions would need to be fearless people, willing to put their reputations on the
line, and even face the likelihood of exclusion from the camaraderie of the project
team.

The difference in return between a chosen project and one that is passed up is opportunity
cost. Say we invest in a project and it returns a paltry 2% over the year and in making
this investment we gave up a similar risk opportunity for another investment yielding
6%, our opportunity cost is then 4% (ie, 6% - 2%). By sticking to the current project, we
forsake other possible uses of the time, material, money and human resources. Imagine
what we could do with the money and other resources freed up earlier from failed
projects. However, sunk costs should not be considered when making the decision to
continue investing in an on-going project, since we cannot recover sunk costs.

Of course, a strongly held conviction and the refusal to let inevitable setbacks undermine
our project are often just what we need to get a project up and running. But as our
project moves forward, faith can blind us to increasingly negative results. Fortunately,
catastrophic trouble rarely happens all at once and usually develops over time. This
provides us with ample opportunity to act, but we have to be paying attention. It’s very
easy, and all too common, for us busy PMs to get too close to our project and not see
the signs of trouble such as:

• Insufficient planning.
• No formal PM methodology.
• Progress is not going as planned.
• Major milestones are being missed on a frequent basis.
• Interim products are not performing as expected.
• Scope creep is rampant.
• Our project team is under-performing and their morale is low.
• Lack of effective engagement with project stakeholders.
• Senior management interest in the project has diminished.
• The project’s priority has been downgraded.
• Status reports are continually negative, reporting excessive variances.
• The project schedule and completion date changes every day.
• Project resources are insufficient, under-skilled and constantly changing.
• No one can find the sponsor, business case or requirements document.

183
• Few of the project team show up for status meetings.
• Poor team communications and no formal communication plan is in place.
• Market conditions have changed, such that the ROI will not now be met.
• The competition has launched a better product.
• The final product will become obsolete earlier than expected.
• We may not be able to provide on-going support for the product.
• There are technical difficulties beyond our ability to rectify.
• Key resources have left the project.
• The project is experiencing a significant cash flow problem.
• Stakeholders’ attitudes are poor, with persistent conflicts and disagreements.

If our project is stopped prematurely, best we adopt some key end-of-project best
practices that include:

• Meeting with stakeholders to review what can be salvaged from the work in progress.
There may be some benefits we don’t know about.

• Staying away from blame is a good idea. Blame is generally useless and focusing
on who to blame instead of what to do can rob us of any opportunity to get some
positive result out of this otherwise unhappy event.

• Having a wrap-up meeting to close off the project and thank all the team members
for their participation. Make sure that any lessons learned are communicated.
Some useful questions might be:

• What if the requirements had been right when planning started?

• What if the schedule had been created before the end date was decided?
• What if risks had been mitigated instead of ignored or accepted?

• Making sure there is a final accounting of the project so the true cost can be
calculated. And don’t forget sub-contractors. Make sure all their outstanding
invoices are promptly resolved.

• Rewarding the team, perhaps with a dinner or a least a letter of thanks, even when
our project closes on a sour note, will show that even though the project may have
failed, their efforts were recognised.

Early closure isn’t necessarily all bad news. As part of our review, there may be some
returns on the project’s investment to date that are worth recognition:

• The first and most obvious benefit is the new-found availability of the project-team
members. If they aren’t now working on our project, they will immediately become
available for other work.

184
• Next is salvage. It’s sometimes surprising how much work-in-progress can be
adapted to other purposes. In some cases, there can be a useful product or
recoverable stuff that is immediately available for other projects. Throwing out
everything that has been accomplished is usually a mistake.

• A soft benefit is improved morale. Almost everyone working on a project that needs
to be stopped knows it should be stopped before it happens. There is almost
always a sense of relief that the issue is out in the open rather than something to
be feared. Also, the knowledge that the end of the project doesn’t mean the end
of their employment is usually welcome news for those staff that can now work on
something more productive.

We must periodically re-evaluate the anticipated ROI on our projects. All our projects
must have a business case that argues the rationale for the investment. However, the
business case must be regarded as a “living document” that is reviewed and updated
periodically as new data comes to hand and circumstances change. If the rationale for
the project has diminished, it might be time to stop work for a comprehensive review,
but to do so is not usually our call as PMs. This is the project sponsor’s and senior
management’s decision, although it might be our recommendation. Often the reasons
for a failed project can be traced back to an overly optimistic or outdated business
case.

This “kill” decision needs good information, careful analysis, clear thinking and courage
to act on the available data. Unfortunately, this type of decision is not always based on
rational thinking - emotions and innate biases may have a big influence. There is no
magic bullet that makes it easy to decide when to stop a project. It takes courage to
admit that mistakes were made and that lessons can be learned so the same mistakes
are not repeated. Stopping projects early may be a hard decision, but when we are
sure that the project is failing, stopping sooner rather than later is always the better
answer.

PMs are usually the primary whistleblowers on projects that will no longer achieve
their promised intentions, regardless of the money, resources, and time that have been
invested to date. But when is the point reached that it’s better to stop a project than to
continue? What are the criteria we should use to assess and weigh against continuing?
Who are the decision-makers? I suggest that these factors should be decided before
our project commences. It’s important to set limits on how far a project is able to go
before it’s recognised as a lost cause. The inability to admit defeat has the potential to
create a lot of headaches.

Having to close our project earlier than planned can be a big disappointment and
source of concern for PMs. On the other hand, premature closure might be considered
as a learning opportunity and possibly a chance to salvage some work. Perhaps the
only real failures are projects from which nothing is learned. Of course, learning doesn’t
happen from failure itself, but rather from analysing the failure, and making changes
where appropriate to avoid future failures.

185
 Chapter Fourteen

Closing the Project

Once the project product has been produced and accepted by our sponsor and
customer, our PM responsibilities continue to ensure that the project is properly closed
down. A stakeholder acceptance meeting, as the name implies, is when our project
team meets with other key stakeholders to review the project product and ensure that
it is acceptable. But sometimes projects take on a never-ending characteristic. They
go into limbo land and are never allowed to close, often because stakeholders keep
coming up with bolt-on extras and change requests, whereas properly closing our
project has several benefits:

• Ensures we deliver what we promised.

• Provides us with the opportunity to consolidate what we have learned.
• Allows us to recognise our team members for the work they have done.
• Releases team members for other work opportunities.

Project closure is sometimes poorly done and is best treated as a “project within the
project” when we identify, schedule and complete everything needed to properly close
the project, which might involve all or any of the following activities, but not necessarily
in this order:

• Finalise any contractual commitments.
• Measure customer satisfaction.
• Prepare and distribute letters of thanks.
• Debrief project team members.
• Complete team member performance reviews.
• Make final payments once contracted work has been properly completed.
• Ensure lessons learned are disseminated to interested parties.
• Reassign people to their functional areas or new projects.
• Release equipment so it can be disposed of or used for other work.
• Complete the final financial accounting for the project.
• Document the results of the project and make recommendations for the future.
• Decide distribution of project documentation.

186
• Hold a closedown meeting and make closeout assignments.
• Agree post-project review requirements with the sponsor and business.
• Terminate reporting arrangements.
• Close risk and issues logs.
• Identify any issues for further study and follow-on work.
• Arrange customer/end-user training/user manuals.
• Finalise delivery instructions.
• Audit final changes.
• Complete our PM diary or journal.
• Obtain client acceptance of project work.
• Advise client of any risks that may affect the achievement of benefits.
• Tidy the worksite and return stores.
• Ensure all deliverables have been installed or properly implemented.
• Integrate deliverables into business-as-usual.
• Initiate retention, warranty and defect notification periods.
• Conduct project evaluation.
• Confirm transition and benefits realisation plan and reviews.
• Update the lessons learned database.
• Collect all debts.
• Close all project sites and the project office.
• Arrange photographs for records and publicity.
• Prepare maintenance manuals and as-built drawings.
• Update the asset register.
• Photograph the deliverables.
• Complete test certificates.
• Prepare spares lists.
• Arrange repair and maintenance contracts for the product.
• Dispose of waste material.
• Close and audit project accounts.
• Index and archive records.
• Celebrate – gifts, certificates, party, dinner.

187
The essential order for project closure is obtain formal acceptance, close contracts,
evaluate project performance, identify lessons learned, and then release the team.
One important activity during closure is to evaluate project performance, as no learning
takes place without feedback. Such reflection is something we don’t always allow
ourselves to experience because we are often too busy getting on with the next task.
And who wants to relive the mistakes of the past? We do, because taking a closer look
at the problems we faced on our project might help our next one go better, although
often we neglect to formalise the lessons learned identification and recording process.
Lessons learned are best posted at the time of their occurrence, and common mistakes
are:

• There is no lessons learned log.

• No one is assigned the responsibility to maintain the log.
• The log is used to chastise people.
• Lessons learned means admitting our less than perfect performance.
• We assume that lessons learned have already been learned.
• We haven’t documented lessons as we progressed through the project lifecycle.
• We’ve already moved on to other more pressing endeavours.
• Lessons learned are personal and not relevant to others in our organisation.

However, without learning lessons, our next project may repeat the same mistakes.
Problem areas worth capturing on projects, detailing what worked well and where
improvement is needed may include:

• Requirements management.
• Scope management.
• Schedule development and management.
• Cost estimating and budget control.
• Quality planning and management.
• Resource procurement and allocation.
• Leadership and team performance.
• Problem solving and issue resolution.
• Communications.
• Stakeholder identification and engagement.
• Status reporting.
• Risk identification and management.
• PM processes.
• Variation management.
• Change management.
• Benefit realisation management.

188
The project evaluation and lessons learned session might take the following form:

• Evaluate the business case. Did the project create or is it creating the business
benefits that were used to justify the project. This question is less about how well the
project team did and is more focused on the project selection and approval process.
The lessons learned at this point aim to improve the ability of the organisation to
select projects and develop realistic business cases.

• Evaluate the project plan. This question addresses how well the PM and project
team planned the project. It concerns topics like the identification of tasks, cost
and schedule estimates, risk factors, and team integration and communication.

• Evaluate the PM methodology. Was our organisation’s PM methodology useful

for the project or not. Were procedures effective and efficient? Were checklists
and templates current and useful? Were the audits and reviews appropriate?

• Evaluate team and individual performances. The team then considers how well
they executed the plan and followed the methodology. This is normally a self-
assessment by the team and can be aided with techniques such as 360 reviews.
The method for conducting individual performance appraisals would normally be
accomplished in accordance with our organisation’s HR practices.

Typically a report is prepared by the PM at the conclusion of the project, possibly based
on PMBOK Knowledge Areas or the six Ps format. Not “Proper Preparation Prevents
Piss Poor Performance”, which of course is usually true, but in this instance six Ps mean
we assess project performance from the following six perspectives:

1. Purpose. Did the project realise its purpose; its rationale for being undertaken?
What business case benefits have been realised or are still to manifest?

2. Parameters. How did the project perform in terms of its goal, scope, time, quality,
cost, risk and whatever other parameters or objectives were relevant? Were time
and cost estimates accurate? Was there scope creep or an excessive number of
variations?

3. Participants. Were stakeholders (including project team members) effectively

engaged, how did they perform and were their needs satisfied? What level of
satisfaction or dissatisfaction (accomplishment, enjoyment, pleasure, anger, conflict,
frustration) exists for each of the key project stakeholders?

4. Processes. How effective and efficient were the processes used during the project?
Such processes may include those for communication, estimating, project approval,
outsourcing, scheduling, team building, conflict resolution, meetings, problem
solving, decision-making, negotiation, reviews, risk and issues management,
variations, monitoring and control, managing change and realising benefits.

5. Products. Were the final products satisfactory in terms of design, performance,

functionality and uptake? Is their use generating the anticipated benefits? How
well are the products meeting the functional and business objectives that were

189
 used to establish the business case? How well do the products achieve their Key
Performance Indicators (KPIs)?

6. Politics. Project success is directly linked to the ability of PMs to understand the
importance of organisational politics and how to make this work for the success of
the project. Office politics are part of organisation life and PMs are political beings
by virtue of their position. What impact did good and bad politics have on the
project?

Project reports culminate in conclusions that may be followed by recommendations. If

so, this section of our report is probably the most useful part where we make suggestions
based on our report’s conclusions. Recommendations in project reports tend to be less
tentative than those of academic reports. For example, a vague recommendation such
as “Perhaps the procedure for recording variations should be updated in due course”
will not be as effective as a more action-oriented and SMART recommendation that in
preference might read “The project sponsor is to update and publish the procedure for
recording variations by 1 June.”

Recommendations must flow logically from our report’s conclusions and it’s usually
helpful to involve others in their identification. Also, our recommendations should be
capable of implementation, match any terms of reference, be prioritised since they
require resources to implement, and be consistent with our organisation’s purpose,
goals, core values and desired culture. Our recommendations may spawn further
projects.

We send the report to the sponsor and finally all project information is held for future
reference. Sometimes the client, for reasons of intellectual property or security might
want records returned to them, including digital files. At project completion, project
files may include items such as:

• Project business case and project charter.

• Product requirements, specifications and photographs.

• PM plans and procurement documents.

• Contracts with external organisations.

• Project audit reports, status reports, timesheets and project reports.

• Stakeholder registers.

• Logs for lessons learned, risk, issues, variations, and health and safety incidents.

• Photographs and key correspondence.

• Meeting agendas and action plans.

• Handover documentation.

190
Project closure can be a time of mixed feelings for our project team. Hopefully they will
feel satisfied about the job, but we need to ensure they aren’t:

• Worried about what the future will hold for them.

• So eager to get on with the next project that things go unfinished.
• Elongating project life because they don’t want to leave.

The exit strategy for the project staff must be clear so that they feel adequately
supported whether they are going on to new projects, returning to routine jobs or
leaving the organisation.

A post-project team celebration recognises the contribution of project team members

and those who have supported the team’s efforts, boosts morale and contributes to a
motivated staff who will look forward to working on future projects.

After product handover the productive life of the project product begins. This is when
product owners and users realise the benefits of the investment, providing that the
business is prepared to accept and adapt to the changes involved.

191
 Chapter Fifteen

Managing the Change

He aha te mea nui o te ao

What is the most important thing in the world?
He tangata, he tangata, he tangata
It is the people, it is the people, it is the people.

Māori Proverb

In recent years change has become more frequent and more dynamic, so much so that
a whole new branch of management has been developed to address the subject. A
lot of what we as PMs do are transformation projects that involve people working and
behaving in a different way. Change management is key to embedding any change.
Thus, PMs, to be effective, must also know about managing change, but in PM lexicon
to confuse the unwary, change management has two meanings:

1. Variations. Managing changes to the scope of our project is often needed to

accommodate risk, revised requirements and new product performance standards.
Also, change might be driven by external factors, such as new legislation. But
most often a change request arises when our client wants an addition or alteration
to the project product to secure some extra benefit. Because change requests
are beyond the scope of the initial agreement, they generally mean that the client
will have to pay for the additions and possibly accept a later project completion
date. Of course no such change should proceed unless the associated benefits
exceed the costs involved. Change control is the process by which all such change
requests are captured, evaluated and then approved, rejected or deferred.

2. Product Adoption. Managing the transitioning of individuals and organisations

as they adopt new project products is another type of change management that
is becoming integral to the PM function. We aim to bring stakeholders from
awareness to acceptance of the new reality that the change creates. We build
support, address resistance and develop the required knowledge and ability to
properly implement the change. Ineffective management of people during such
change is a top reason for unsuccessful projects across all industries. While there
is no progress without it, change often freaks us out. The conversion of project
products into outcomes and benefits invariably requires some form of behavioural
change. So we need to spend time understanding what the desired behaviours
are and how we might encourage our product users to adopt these behaviours.
Managing such change in a controlled manner is essential if business case benefits
are to be realised.

192
This chapter is about the latter type of change management – “product adoption”
for want of a better name. PM and change management both aim to increase the
likelihood that our projects deliver their intended results. They are complementary
disciplines. Although these two disciplines can function independently, the most
effective approach is to integrate change management and PM.

Gone are the days of one large change every three years. Today’s organisations are
facing faster, more complex, more interdependent and more cross-functional change
than ever before to survive and thrive in today’s changing landscape. Even small projects
require changes that include new behaviours, new skills, new jobs, and often with new
staff. To an increasing extent PMs are no longer asked to just manage tasks and people,
and focus on project products, but we’re also expected to help manage change to
ensure our project products are properly embedded in order that they produce their
forecasted benefits. We need to ensure that our project products become part of
how our people work, and that there is a clear and beneficial difference between the
business-as-usual before the project and the business-as-usual after the project.

While this integration of PM and change management increases the workload for us
PMs and adds some cost to our projects, it’s worthwhile if more projects then realise
their promised benefits. The more dependent a project’s benefits are on project
product adoption and usage, the larger contribution change management makes.
This means that transition activities must be included in our PM plan. Yet, in many
organisations change management is entirely reactive, and only applied as a last resort
when employee resistance jeopardises project success.

When we undertake projects to improve performance, seize opportunities or address

key issues, they often require changes to processes, job roles, organisational structures
and the use of technology. More particularly, it’s employees who have to change. If
our people are unsuccessful in their personal adjustments the project will likely fail.
However, if our employees adopt to the required changes, the project is much more
likely to deliver the required results.

In effect, our project is a vehicle for delivering change and successful change is about
getting people ready, willing and able to properly use our project products. Change is
very much a psychological disturbance, as people lose the certainty and comfort of their
familiar situation and have to swap this for the uncertainties of new ways of working.
A successful change initiative requires we prepare people for the change, obtain their
buy-in, and engage our project sponsor and functional managers to champion and
support the change before, during and after product launch.

In the following diagram PM and change management are shown as parallel and
integrated activities. They both support moving operations from a current state,
how we do things today, through a transition state to a desired future state - the new
skills, attitudes, behaviours, equipment, processes, organisation structures and job
roles needed for the proper adoption and exploitation of our new product. Thus the
movement from the current to the future state occurs on two related dimensions:

• The product is designed, developed and delivered – project management.

• The product is adopted and used to realise benefits – change management.

193
While all changes are unique and all individuals are unique, decades of research show
there are actions we can take to influence people in their individual transitions. Change
management provides a structured approach for supporting the individuals in our
organisations to move from their own current states to their own future states, although
the behavioural effects of change are not always predictable and sometimes impulsive.

Even the most carefully planned and structured change is likely to have elements of
emergent change, as the unpredictable surfaces during the change process, which
emphasises the need to be responsive and adaptive in the implementation of change.
With any change initiative there needs to be space and time to adjust or amend
direction and expectations in the light of what is actually taking place. There has to be
a balance between planned and emergent change. Organisations and people are so
complex that it’s nonsensical to imagine that every aspect of change can be precisely
anticipated, planned and controlled.

Project and Change Management Integration

There are many change management models and organisations need to avoid seeking
the “one best way” approach to change. Nevertheless, as the diagram shows, one
long-standing, simple and practical approach to planned change management
(Professor Kurt Lewin’s model) is to break the change into three stages, although the
process may not proceed in an entirely linear manner as the above diagram suggests,
and the effectiveness and time needed for the change process will vary depending on
the extent of the change and the degree of resistance encountered.

It’s the third stage of this classic model, the “future” stage (previously referred to as the
“refreeze” stage) that has provoked some recent criticism from those who argue that
the modern world is changing at a pace and frequency that gives us no time to settle or
freeze before further changes occur. While there are other change management models
such as Kotter’s eight-step model, Bridges’ transition model or Prosci’s ADKAR model,
I suggest that Lewin’s simple change management approach, which is endorsed by the
NZ Change Management Institute (CMI), remains particularly valid and especially so for
smaller and medium-size projects.

194
There is a lot of cross-over between the skills needed for PM and those needed for
change management. In particular, both need strong stakeholder engagement skills.
Also, PMs who become effective change managers have tapped into their emotional
intelligence. They appreciate the challenges, fears and anxieties that projects generate
and are willing to spend time listening to those affected; letting them talk their way
through their concerns.

Some organisations prefer the rapid, disruptive and riskier “big bang” approach to
change whereby simultaneous initiatives are implemented on many fronts on a specified
date, whereas other organisations prefer incremental change or a “phased” change
over a longer period at a speed that ensures change can be properly managed and
timely corrective action taken to keep on track as needed. Both approaches have their
advantages and disadvantages, although a product implementation strategy doesn’t
have to be limited to these two options. Sometimes a big bang approach can be used
to implement the “must have” functionality, followed by phased implementation of
the “nice to have” functionality. Change management is often political, emotional
and error-prone and when change occurs too quickly or is undertaken ineffectively we
might expect any of the following consequences:

• Change may exceed people’s capacity to cope.

• Organisation and individual productivity may dramatically decline.
• Passive and active resistance may escalate.
• Frustrated employees may leave the organisation.
• Employee morale and motivation may deteriorate.
• Employees may revert to their old way of doing things.
• Disagreements may occur between those with differing attitudes to the change.

Let’s consider in more detail what needs to happen during each of these three stages
or states to help ensure effective change:

Current State is the collection of behaviours, processes, tools, techniques, organisational

structures and job roles that constitute how work is done at present. This current state
may not be working well, but it’s usually stable, predictable and familiar, and it’s where
we have been successful and where we know how we will be measured and evaluated.
Above all else, the current state is the comfortable known. So, communication of
change needs to start as early as possible so that people have time to understand and
accept the change before they have to start working in new ways. During this state we
prepare for the pending change, and in particular we should:

• Clarify exactly what will change and what will remain the same, so that we minimise
confusion and prevent rumours from developing about the likely extent and impact
of the change. Project team members and users work collaboratively to identify
what needs to change and what can be retained from the current business-as-usual
environment.

195
• Ensure there is strong support for the change by creating wide awareness of the
reasons for the change and the anticipated benefits. We need to communicate
a compelling and positive vision of what things will look like once the project is
completed.

• Consider how to manage risks associated with the change and resistance to the
change. Ignoring this and pretending that there are no downsides to change is
naive. People are likely to adjust quicker when we are honest about the losses
involved as well as the gains.

• Communicate often, describe the anticipated benefits, explain how the change
will affect those involved, listen to their concerns, and answer questions fully to
provide the facts, and thus help dispel the rumours. Being upfront and clear with
our employees about what the change means to them and the way they work is a
biggie in the lead up to the transition stage.

• Provide training, coaching and mentoring to those who will effect the introduction
of the new product. This includes preparatory training on the use and maintenance
of the new product, and the development of user guides. These tasks need to be
captured in the PM plan and appropriately resourced.

Transition State is sometimes disorganised and unpredictable, and may create

emotions such as despair, anxiety, anger, fear or relief. During the transition state
productivity may decline while users learn new ways of working, while we create an
environment that encourages experimentation and minimises the fear of failure. Thus,
in summary this often challenging state is when we:

• Involve users in the testing of project products, which enables us to benefit from
their input and provides them with some feeling of ownership.

• Monitor change reaction and progress, encourage learning, tolerate mistakes,

pro-actively search out anything that could impede product uptake, and deal with
emerging changes, risks and issues promptly and effectively.

• Gain and publish information about progress and success stories to reinforce the
value of the change, and continue to answer questions and provide facts to avoid
or help dispel rumours.

• Provide on-going training, coaching, mentoring and counselling to those affected.

Future State is the new norm and where we wish to go. Without this step, people
may revert to their old practices and behaviours. This new state is sometimes not fully
defined, and with user feedback might have shifted while we were going through the
transition state. The future state is most likely to be better than the current state in
terms of organisation and individual productivity. However, the future state can be
worrisome. It may not match personal and professional expectations and goals, and
there is a chance that those involved may not be as successful in this new state. Above
all else, the future state is somewhat unknown. Our goal is to reach the point when we

196
have stopped thinking about the project product as anything other than normal practice.
Useful strategies during this period of reorientation and familiarisation are:

• Ensure that the handover to business-as-usual operations is complete.

• Make sure that the new product is recognised across the organisation.
• Acknowledge, reward and celebrate change successes.
• Develop and reinforce ways to sustain the change.
• Provide for on-going training, coaching, mentoring and counselling.
• Assess the success of the change initiative and take corrective action as required.
• Watch for signs of a relapse to the old ways.

Having a project product that is the “right” answer is important, but this does not
guarantee that employees will make the necessary changes in their behaviours and
work processes. It takes more than the right solution to move employees out of the
current state that they know well and into an unfamiliar future state. Today’s workforce
is often sceptical and questioning. Embracing change and helping others embrace
change is often very difficult depending mainly on the degree of change involved.
Fortunately, change management is not rocket science, and here are some well-proven
principles to help ensure that the change process works effectively:

• People issues. Whatever the level or degree of organisational change, the people
on the receiving end are the ones who will ultimately cause the change to be a
success or a failure. Invariably, changes create people issues. For example, new
leaders may be asked to step up, jobs may be created, changed or eliminated, new
skills and capabilities may be needed, and as a consequence some employees may
be uncertain and resistant. Dealing with these concerns on a reactive basis usually
puts morale at risk, so a proactive approach for managing change risks is much
preferred.

• Start at the top. Because change is often unsettling for people at all levels of our
organisation, eyes are likely to turn to the CEO and the organisation’s leadership
team for strength, support and direction. So our leaders themselves must be
committed to the change, speak with one voice, and model appropriate behaviours.
One of the worst possible scenarios is to have the leaders ignore the process rather
than participate actively and visibly throughout. Also, our project sponsor cannot
disappear once they’ve attended the project launch. Their sustained presence is
essential to build and maintain change momentum.

• Make the case. Most people will question to what extent change is needed,
whether the change is headed in the right direction, and whether they want to
commit personally to making the change happen. Thus, the development of a
sound business case for change is essential. But we should not mistake natural,
normal, healthy resistance to change as a subversive attempt to destroy what we’re
trying to accomplish. Some individuals oppose change simply because they don’t
like the idea of an upset to their routine. Others might oppose the change because

197
 they feel it threatens their status within the organisation. As an example, someone
who is considered a subject matter expert for a particular software program may
feel ill at ease at the prospect of a new, unfamiliar application replacing the current
system. In cases like this it’s important to identify why this individual feels ill at ease,
so their concerns may be addressed, and in this example timely retraining might
help.

• Create ownership. Leaders of change must over-perform during the transformation

period and be the zealots who create a critical mass among the work force in
favour of the change. This usually requires more than passive agreement that the
change is acceptable. It demands ownership by leaders and willingness to accept
responsibility for making change happen in all of the areas they influence or control.
Ownership is often best created by involving people in identifying benefits and
implementation problems, and together then crafting solutions.

• Communicate the message. The first step toward change is awareness. The
second step is acceptance. Too often, change leaders make the mistake of believing
that others understand the need for change. The best change strategies reinforce
core messages through regular, timely communication that is both inspirational and
practical, and solicit timely input and feedback from users. Be wary of expressions
like “mindset change”, and “changing people’s mindsets” or “changing attitudes”,
because this language often indicates a tendency towards imposed or enforced
change, and it implies that the organisation believes that its people currently have
the “wrong” mindset, which is seldom the case.

• Provide end-user training. Some organisations sabotage their own productivity

by skimping on end-user training. End-user training is a very important requirement
for the successful implementation of any new project product. Thus, in anticipation,
we need to provide training for the users and for those involved in maintaining the
new product. A training needs analysis (TNA) will help identify those who need
training, what kind of training they need, and what training materials and facilities
are required. To adequately resource training helps ensure employee buy-in,
confidence and productivity.

• Risk management. No change process goes completely according to plan. There

will be unexpected issues and teething problems. Effectively managing change
requires continual monitoring of its impact. As far as possible change impediments
should be identified, prioritised and responded to proactively. Contingency plans
might also be developed in anticipation of some issues. In determining the risk
involved in the change, the following factors are often relevant:

• Few employees impacted versus many employees impacted.

• Few aspects of work impacted versus many aspects of work impacted.
• Small departure from current state versus large departure from current state.
• Something similar versus something vastly different.
• Few recent disruptive changes versus many recent disruptive changes.

198
• Speak to individuals. Change can be a very personal thing. People often spend
many hours each week at work and may think of their colleagues as family. People
need to know how their work will change, what is expected of them during and
after the change, how they will be measured, and what success or failure will mean
for them in the new state. Providing personal counselling to alleviate any change-
related fears is appropriate. We need to recognise that for some, change may
affect people in ways that we may not have foreseen. For example, people who
have developed expertise and have earned a position of respect from the old way
of doing things, might see their status undermined by change.

• Recognise success. Change won’t last long without confirmation that it’s benefiting
the organisation. Visible rewards, such as promotion, recognition and bonuses
could be provided to those who embrace the change. Early adoption and successes
should be recognised, advertised and celebrated.

Most stakeholders who resist change do so for genuine reasons. They have real
concerns that need to be addressed, such as:

• Change seems unnecessary. Employees cannot understand why the change is

needed when the status quo seems to be satisfactory and has not previously been
questioned. Expressions such as “this is a waste of time, it was working well before,
and they never tell us what’s going on” might be the immediate reaction from some
of those affected.

• Personal status threatened. Employees are anxious that their current status in
the organisation will be diminished or undermined, or that they may be made
redundant. The association people have with their routine work defines them to
some degree. People who have been improving their work methods for years to
become very good at what they do, may resist planned change or possibly only
comply to prevent disputes. They may also be concerned about the “what’s in it for
me” (WIIFM) factor. On balance, the change may appear to be to their disadvantage.

• Fear of the unknown. Employees may be unsure what the future holds for
them. Their jobs might be dis-established and they might be “let go” or their job
descriptions might be altered in some way to their personal disadvantage. They will
recognise that not all change is for the better and perhaps recall some previously
bad experiences with change. In the absence of complete, accurate and timely
information, unsettling rumours may proliferate.

• Coping anxiety. Stakeholders are unsure that they will be able to cope with the
change – that their current skills may be obsolete and the new work required of
them will be well beyond their comfort zone. Acute and chronic stress can be a
consequence. If an employer fails to adequately address workplace stress, they
could face a claim under our Health and Safety in Employment legislation.

199
We might consider which of the following reasons are behind an employee’s negative
reaction to the proposed change:
• Change threatens feelings of competence and/or commitment.
• Not enough information is available.
• Individuals have low tolerance for change and ambiguity.
• Misunderstandings about the change and its implications.
• Desire not to lose something of current value (eg, security, position, title, status).
• Belief that the change does not make sense.
• Concern that the change will have a negative effect.
• Fear of having to learn new skills.
• Feeling overwhelmed due to too much change.
• Concern that there will be insufficient support to help them cope with change.

The reality is that change is never foolproof. There will be doubts about the wisdom of
the change, the change will most likely disrupt work, may take some time to implement
and even longer than originally thought, there will be risks to contend with, unforeseen
issues to resolve, and while the change will likely be overall beneficial, some stakeholders
may be disadvantaged as a consequence of the change.

We should encourage those impacted by the change to make suggestions and become
involved in the change process. Other than participation, some further strategies to help
obtain buy-in might be to sell people on the benefits (WIIFM), be positive ourselves about
the change, publish early change successes, be approachable, welcome ideas, keep
everyone updated, anticipate and prepare for objections, explain the consequences
of change success or failure, get key stakeholders on side, and appoint visible and
powerful change advocates. The change curve shown on the next page is a popular
model used to understand the stages of personal transition and organisational change.

Faced with resistance to change, some leaders might attempt to drive through change
regardless, but this often deepens the resolve of the “resisters” and can lead to
outcomes that are in nobody’s interest. To help overcome or reduce resistance to
change, the sponsor and PM must become change leaders or appoint a team member
to this role to communicate the change, help those affected understand the purpose
and benefits of the change, plan for the change, seek input and ideas to improve the
change process, and support those impacted by the change. Possible approaches to
address the four most common reasons for resistance to change are these:

• When change seems unnecessary. To help overcome this concern we need to

acquaint those involved with the actual problem or opportunity that has caused the
project to be initiated. To be convincing, accurate figures and information will be
needed rather than adjectives and rhetoric. We might also demonstrate that there
will be negative consequences if the change doesn’t proceed.

200
 Impact of Change

• When current status is threatened. As far as possible we would assure

stakeholders that they are highly valued and their positions and relative seniorities
will be respected, and any proposed changes to their job descriptions would be
freely negotiated, agreed with them, and accompanied by appropriate training as
required.

• When there’s fear of the unknown. As appropriate, we would reassure staff that
current remuneration rates and other conditions of employment would continue
and that no redundancies were planned and that any changes to current policies,
procedures and processes would be thoroughly discussed with them and all
questions fully answered. If necessary, we would explain that should any staff
members leave or wish to leave as a consequence of the change, they will be given
adequate warning, be appropriately compensated and provided with a reference or
detailed record of their service.

• When there’s coping anxiety. Where appropriate, we would emphasise that few
changes were likely to current person specifications and job descriptions, and any
changes in which new skills were needed, these skills would be taught to them
through formal courses and on-the-job training. However, if we identify or have
been notified about anyone who is suffering stress caused by the change, we might
allow them time-off to recuperate and later ease them back into work (maybe part-
time, or reduced hours), or identify alternative less stressful roles for them.

In summary, while projects may successfully produce a new product, the management
of change needed for the successful adoption of this new product is often poorly
planned and executed, such that business case benefits that justified the investment
are not realised or fully realised. Many projects fall short of their objectives because us
PMs often don’t see ourselves as change agents. We need to become more educated
about change management and the approaches necessary to ensure it’s part of all
our project initiatives. Accordingly, our job as PMs is broadening from that of product
delivery to include the management of change.

201
A robust change management approach assesses the readiness for change and will
only authorise projects to go-live when our organisation has properly prepared for
the change and has sufficient capacity to cope with any initial fall in productivity as
employees adapt to new ways of working.

Reality is that some staff may not be able to pick up the new skills or cope with the
change, or despite assurances, they may have little faith or confidence in their own
ability to adjust to the new ways of working. For them, the prospect of having to learn
and apply new skills and knowledge may have little appeal.

Each of us has experienced poorly managed change - either as a victim or sa an

offender. When projects are mismanaged from the people perspective, outcomes are
not achieved, the speed of product adoption is slower, and ultimately product use
is much diminished. While some of the resultant costs and risks may seem to be of
the “soft” variety, many are quantifiable. Such costs may include lost investment, lost
opportunity cost, reduced productivity, loss of valued employees, reduced quality of
work, expenses not reduced, efficiencies not gained, revenue not increased, market
share not captured, waste not reduced, and regulations not met.

Projects may conclude with the delivery of a product that is handed over to a client or
user organisation other than our own organisation who then take responsibility for any
change management required to ensure that product benefits accrue.

The next chapter discusses benefit realisation. It’s important that changes are successfully
embedded in order to deliver benefits, which are the measurable improvements
resulting from our project outcomes. The achievement of project benefits depends on
the speed and extent to which employees embrace, adopt and use the new product,
which is more likely with effective change management. Benefits will be particularly at
risk if we don’t proactively address the people side of change.

Thus, change management and benefit realisation have a symbiotic relationship.

Benefits come only with change, and change must be sustained by benefits. Benefits
are realised when something changes. This usually involves permanently changing
attitudes and behaviours as well as physical workplace changes. The failure to embed
new attitudes and behaviours so that they become normal practice is often the greatest
risk to the realisation of project benefits.

Finally, project are vehicles for change, but we don’t want to continue with change if
the likelihood of benefits has evaporated. The problem might be that we focus on the
cost of the investment (the money we have sunk into the project) rather than future
performance. Yet to quit a project is to own up and loss becomes obvious. No one is
keen to do that, but regular updating of the project business case is essential.

202
 Chapter Sixteen

Securing the Benefits

“A project is successful only if it

delivers the benefits that the
stakeholders seek.”
Mark Langley, PMI President and CEO

While closer integration of PM and change management increases the workload for us
PMs and adds some cost to our projects, it’s worthwhile if more projects then realise their
promised benefits. The more dependent a project’s benefits are on project product
adoption and usage, the larger contribution change management makes. Traditionally
projects were considered finished when their products were completed. However,
benefit realisation doesn’t occur until products are used.

Traditionally, it’s us PMs who produced the products and the project sponsors who
ensured that benefits accrue. This conventional division of responsibilities between
project sponsor and PMs has its close equivalent in NZ government where Ministers
of the Crown are accountable for outcomes and our public service is accountable for
outputs. The principle behind this split is that managers should only be held accountable
for things they can control. Outcomes, while supremely important, are seen as more

203
difficult to control because they are affected by many external factors that better reside
in the political arena. This similar historical division of responsibility between project
sponsors and us PMs was understandable, since:

• Immediate PM success, rewards and recognition are usually measured in terms of

project objectives (scope, time, cost and quality) and not whether products yield
their intended benefits.

• Most organisations have no formal process for managing benefits. Like their PMs,
the organisation is often preoccupied with producing products, while benefits are
left to chance.

• Most or all benefits arise after project closure when PMs are likely to have resumed
their involvement with business-as-usual activities or refocused on other projects –
new projects and on-going projects.

However, in today’s environment, we PMs are now expected to understand the

project business drivers, and help ensure that our projects deliver the benefits that
were specified in the project business case, which is how an increasing number of
organisations now view project success. Yes, it’s becoming more common to assess
project success according to benefits realised rather than evaluating success solely in
terms of the traditional measures of scope, time, cost and quality. Few could dispute
that PMs are well placed to monitor if a project is on course to deliver such benefits.

Although “benefits” may sound more like health insurance or something obtained
from NZ Work and Income, rather than anything to do with PM, every project is an
investment with the purpose of obtaining benefits. Even when projects are completed
on time and on budget, they may not deliver sustainable benefits. When that happens
we are left asking, “What was the real value of our investment? What can we now do
that we couldn’t do before? Did we just waste our time and money?”

Without first properly identifying benefits, there is no clear basis for planning or
measuring project success, yet most organisations still have no formal process for
securing and measuring project benefits. Benefits realisation is probably the most
ignored area of PM except perhaps at the start of a project when sponsors might
highlight or even exaggerate the anticipated benefits of their project propositions and
downplay the costs to help get their projects approved. As a consequence any benefits
management regime is then built on unsafe foundations.

While project benefit estimation is of pivotal importance during project acceptance

decisions, once the project is underway many PMs are then exclusively focused on
specifications, timelines, budgets and products. Also, many organisations, including
those keen to describe themselves as learning organisations, have no formal process
in place to manage and realise benefits, don’t appoint anyone responsible for their
tracking, have no post-implementation benefits review, and consider the project
finished when project products are released. However, the mark of a more mature PM
culture is that their PM methodology is extended to include a post-project benefits
realisation phase.

204
Thus, our understanding of project success is changing from products to benefits.
Also, there is growing agreement that we PMs must assume greater responsibility for
change management and benefit delivery. As a minimum we should include measures
for managing change and securing benefits in our project plans, and appreciate the
impact of proposed variations on anticipated benefits, which encourages us to stay
focused on why the project was initiated in the first place.

Nevertheless, project delivery still remains a vital step to achieving benefits. Completing
our projects on time, within budget and to expected standards of quality sets the
platform for on-going success, but ultimately it’s the realisation of expected, and
sometimes unexpected benefits that determines project success, and such benefits
should outweigh the costs of achieving them if the project is to add value.

To better understand the process we need to define some terms, including project
goal, objectives, processes, outputs, outcomes and benefits, where:

• Project goal is a single SMART target to achieve something of value.

• Project objectives are measurable parameters or constraints of scope, time, cost,

quality, risk tolerance, and benefits, in keeping with which us PMs must build our
creations.

• Processes are a series of actions or steps taken in order to transform one or more
inputs into one or more outputs.

• Outputs or deliverables are created by PM processes and may be any of the project’s
products (interim or final, tangible or intangible). An output has no intrinsic value
because it’s the change caused by the use of the output that brings value and not
the output itself. The project’s outputs are used to create outcomes.

• Outcomes are the results of the change caused by integrating the new output
into the operation of our own or our client’s business. Such change needs to be
managed to ensure that planned benefits emerge.

• Benefits are measurable improvements or positive impacts resulting from outcomes

and are perceived as advantages by one or more stakeholders, such as a reduction
in business costs by say 10% over the next six months, or an increase in sales by
say 15% per annum. Benefits answer the question “What value is derived from this
outcome?” and should be supported by key performance indicators (KPIs).

• Benefits Realisation Management (BRM) includes the activities of identifying,

defining, planning and tracking to achieve and sustain benefits throughout the life
of the project and its product. Benefits are tracked to ensure they’re delivering
value.

205
 Benefits Realisation Process

By themselves, products do nothing. When that product is used it causes changes

which are outcomes. Measured outcomes are benefits that add value through
improvements. Benefits may be quantitative or non-quantifiable (qualitative), monetary
or non-monetary, direct (primary) or indirect (secondary), anticipated or unforeseen,
one-time or recurring, and immediate or longer-term. Also, benefits are not necessarily
assured – they possess uncertainty and have different likelihoods of realisation. Benefits
anticipated at the commencement of the project may change during the project life
and/or during the product life, often due to uncontrollable external factors. Thus, the
project business case needs to be regularly reviewed and updated. Of course, not
every benefit carries the same weight with every stakeholder. Here are some common
benefit categories:

• Direct monetary benefits (tangible) are those benefits that can be quantified
and valued in financial terms, such as cost savings and revenue generation. These
readily dollarised benefits are usually the most persuasive. Examples are:

• To increase revenue by 30% over the next 12 months.

• To reduce costs by 15% within 12 months after product launch.

206
• Direct non-monetary benefits (tangible) are those benefits that can be quantified
but are difficult, undesirable, insensitive or impossible to value in financial terms,
such as fewer customer complaints, lower staff turnover, reduced lead times, and
improved response times. Specific examples are:

• To reduce customer complaints each month by 80% by 1 June XX.

• To gain 20% more customers over the next year.

• Indirect benefits (intangible) can be identified but cannot be easily quantified,

such as enhanced end-user satisfaction, better access to information, enhanced
organisational image, and better morale. Further examples are:

• To improve customer and staff satisfaction, morale and motivation.

• To improve our business image.
• To promote the company’s trade brand.
• To enhance our users’ experience.
• To increase favourable press coverage.

• Disbenefits, a clumsy expression, are seen by one or more stakeholders as negative

outcomes from the intended change. We should ensure that disbenefits represent
a price worth paying in the process of obtaining the positive benefits. For example,
during a road repair or upgrade project there may be peak period congestion or
traffic may need to be diverted onto other roads, to thus increase travel times,
which road users would usually see as a disbenefit.

Some may argue that indirect benefits are too tenuous to legitimately include in our
project business case and if a benefit can’t be measured numerically it shouldn’t be
claimed. I suggest any benefit might be relevant, providing we also consider the
associated cost and include a realistic assessment of their probability. For example,
if an indirect benefit has an estimated 70% likelihood of occurring, assuming a direct
or primary benefit of similar likelihood first occurs, the secondary or indirect benefit
would then only have an estimated 49% likelihood of occurring (ie, 70% x 70% = 49%).
However, such probability predictions are usually very difficult to make and particularly
so for pioneering projects about which we have no history.

Since benefits are not certainties, best and worst case benefit scenarios may be
developed and risk management techniques employed to help safeguard or enhance
potential benefits. Also, the likelihood and impact of anticipated disbenefits should be
mitigated. Disbenefits should be identified and analysed as part of the project business
case to ensure that they don’t outweigh expected benefits. If managed proactively
some disbenefits could be nullified or even turned into benefits.

207
 Project Products, Outcomes and Benefits

Products Outcomes Tangible Benefits

New order processing Faster processing of Reduce the average processing
software installed. customers’ orders. time for customer orders by
at least 20% from the current
average of 15 minutes.

Sales campaign Attract new customer. Add a minimum of 20 new

revitalised. customers each month for the
next year.

Website updated. Attract more viewers. Increase visitors to the website

by an average of at least 5%
each week for the next year.

Core values Enhanced culture, morale Staff absences and turnover

published. and image. reduced by at least 30% during
the next year.

Team-building Improved teamwork. Team productivity increased by

programme at least 20% during the next
Introduced. year.

Also, benefits might be measured in terms of the “triple bottom line” where they are
categorised as:

• Economic or financial benefits determined through such techniques as cost-

benefit analysis, net present value, internal rate of return, and economic value
added computations.

• Social and community benefits that encompass health and safety, cultural factors,
improved social justice, welfare and environmental impact factors.

• Corporate benefits such as revenue, profitability, innovation, growth, market share,

shareholder value, community perception, and ethical and probity considerations.

“A benefits-lead change initiative” is a pertinent and concise way to describe a project.

This definition emphasises the rationale for any project – to realise benefits that
hopefully, sooner rather than later, considerably exceed the costs involved and thus
add value, where:

NET VALUE = BENEFITS – COSTS

ROI = (BENEFITS – COSTS) / COSTS

208
Financial benefits such as cost savings and increased revenues are readily quantifiable.
However, non-financial benefits such as a reduction in hospital emergency wait times,
an improvement in educational outcomes, or compliance with government legislation
may be more difficult to quantify, but can usually be measured by way of surveys.
However, if a benefit is definitely not measurable perhaps it should not be recognised,
as there will be insufficient evidence to prove that it has been achieved. Thus, ideally,
benefits should be measurable and evidence-based to show that they provide value,
but if all project benefits are not measurable, then arguably we should accept that
there is insufficient evidence to justify the investment.

Benefit Variance

Net Actual Variance

Project Benefits
Baseline to Date to Date

1. Disposal of redundant stock $5,000 $5,000 Nil

2. Faster response $12,000 $14,000 $2,000

3. New customer sales $40,000 $25,000 ($15,000)

4. Headcount savings $100,000 $100,000 Nil

While projects have benefits, some projects don’t have obvious benefits such as
compliance projects that are undertaken in response to changing legislation when
deadlines are fixed and set externally, although perhaps one benefit might be we
avoid court cases, jail and fines. Incidentally, compliance benefits can be measured
immediately at the end of the project when we know straightaway if we are now
compliant. Also, there are enabling projects that don’t have benefits themselves, such
as the installation of a new computer network that allows other projects to run that do
deliver benefits. Perhaps reading this book is an enabling project.

The process for benefit realisation starts with the end in mind. Obtaining some sort
of benefit, whether financial, economic or otherwise is the reason we undertake
our projects. If no worthwhile benefit is envisaged we should not embark on the
project. Also, our project should not include any products that don’t produce sought-
after benefits. A benefits map, benefits flowchart or benefits dependency network
is occasionally used to illustrate and track outcomes and benefits, particularly when
benefits lead to more benefits, an example of which aimed to increase sales revenue
is shown here. To develop this map, we work backwards, or right to left, from the
ultimate benefit or benefits that are desired. Benefit mapping should involve key
stakeholders and might be undertaken as a workshop at which we identify benefits and
their dependencies to each other and to the changes required to achieve them.

209
 Example Benefits Map

We can’t expect benefits to materialise without some effort. Benefits evolve over
time as people adapt to and use the new product. However, some projects declared
successful, never deliver the benefits originally envisaged. Also, different projects
sometimes claim the same benefits. In fact, if any two projects claim the same benefits
they are arguably the same project. Also, we need to recognise that one benefit may be
dependent on first achieving another benefit as illustrated by a benefits map. Benefits
management is essentially about remembering why we are doing the project and the
process typically involves the following steps:

Benefits Realisation Process

1. Define benefits management plan. A misunderstanding is that benefits just

happen. Rather, they need to be planned for. We must determine how and when
benefits will be managed and by who. Priority is usually given to those benefits with
the greatest potential value. Benefits are identified by users and other stakeholders
and depend on the delivery of outputs and the achievement of outcomes. Both
benefits and disbenefits need to be measured. Informed and accurate decisions
around business cases cannot be made unless disbenefits are also identified and
measured. Each benefit (and dis-benefit) should be documented in terms of their
priority, value (or loss), timescale and ownership.

210
2. Plan benefits realisation. This step requires we first determine baseline
measurements and agree targets. Baseline measurements identify the current
performance of an operation so that post-project improvements can be measured.
This will enable the success (or otherwise) of the initiative to be established. The
benefits plan identifies the anticipated benefits and our confidence level in them
being achieved, assigns responsibilities and timelines for their achievement, and
identifies their relationship to project outputs. Accountability and responsibility for
benefit realisation is key to successful benefits management. Benefits are owned
by project sponsors and business managers and not usually by PMs.

Example Benefits

Required
Benefit Owner Benefit KPI Achievement Timeframe
Outcome
Increased Sales Manager. $10,000 additional Each month for a 12-month
income from revenue from monthly period commencing in two
sales. sales. months’ time

Improved Customer Elimination of customer No customer complaints

customer Service Team. complaints. received during the next year.
service.

3. Implement change. Benefits only happen when something changes. This usually
involves changing individual attitudes and behaviours as well as material changes.
While implementing change, new opportunities for additional benefits might also
become evident. Unless benefits are progressively tracked and reported, there
is no opportunity for us to implement timely corrective measures (if needed) to
ensure benefits
are delivered in full.

4. Realise benefits. Each benefit should be given an overall benefit ranking based
on its total impact and importance to the project, and highest priority benefits
should receive greatest attention, resourcing and monitoring. Required changes
to the way people work need to be embedded to ensure that benefits continue to
be realised. Failure to formally assign accountability and responsibility for benefits
creates a significant risk that benefits will not be properly measured or tracked. And
it’s important that responsibility for benefit realisation remains with those business
units affected. The project sponsor, specifically appointed change managers, and/
or operations managers should track benefit realisation and ensure that changes
are permanent. Actions needed for continued benefits realisation should be
agreed and documented as part of the product handover process. Benefit owners
are ideally assigned at the start of the project and may or may not be members of
our project team. Typical responsibilities for benefit owners are:

• To provide input for the benefit realisation plan.

• To organise benefit measurement and reviews.
• To identify and remove obstacles to benefit realisation.
• To report benefit realisation progress.

211
The new product progresses through stages known as the product lifecycle during
which time enhancement projects may be undertaken to extend the life of the product
by upgrading it to create new benefits due to extra product functionality, features,
ergonomics, environmental friendliness, sustainability, technology, supply or pricing.
Eventually our product will reach the end of its useful life. For some products there may
then be some residual, salvage or scrap value, although as a general rule, the longer a
product’s useful life, the lower these final values are likely to be. Many high-technology
products now have a very short lifecycle - rapid introduction and growth stages, steep
decline stage and no maturity stage. Despite our recycling efforts, detritus is piling up
in vast electronic rubbish dumps.

Product Lifecycle

There are several reasons why project benefits may not be realised, fully realised or
sustained, including:

• An unsatisfactory business case that doesn’t properly identify benefits and/

or over-states benefits, which occasionally might be deliberate to help ensure a
project’s approval. Also, some benefits are described in only vague terms with
plenty of adjectives and adverbs that make their objective measurement difficult
or impossible. Such business cases have usually not been subject to robust and
objective scrutiny.

• Over-emphasis on products, without thinking much, or at all, about the benefits

that the products are intended to create, and no mechanism in place for benefit
tracking and harvesting. Sometimes this is the consequence of lethargic sponsors
or overly product-driven PMs.

• Product users aren’t properly trained in the use of the new product, have no or little
buy-in, and/or are reluctant to make the necessary changes.

• Project sponsors and champions leave the organisation or become preoccupied

with other responsibilities including new projects.

212
• Believing that the project is over once the final product is produced, expecting
benefits to automatically occur without further effort, or expecting benefits when
there’s been no change.

• Changed external factors (eg, politics, economics, social factors, new technology,
new legislation, and competition) diminish or cancel anticipated benefits. Such
external impacts are more likely and significant when benefits are to be realised
over a period of years rather than within weeks of product launch.

Some argue that PMs should assume greater responsibility for benefit delivery. As
a minimum, I suggest that we PMs should include strategies for benefit tracking and
realisation in our project implementation plans. And whether it’s the business analyst’s,
sponsor’s or the PM’s responsibility, the first step is to ensure that the following
foundations for benefits realisation are in place:

• That the business case clearly identifies anticipated benefits.

• That business case reviews are scheduled to validate benefits.
• That stakeholders who will be affected by each benefit are identified.
• That outcomes required for the realisation of each benefit are identified.
• That measures are in place for each benefit.
• That responsibilities for delivery of benefits are assigned.
• That benefits are prioritised according to their anticipated impact.

Since benefits are mainly realised or not realised after project closure, perhaps
benefit realisation is therefore most appropriately a job for our project sponsor whose
responsibility for the project should therefore extend into the product lifecycle until
benefits are realised or not realised. The growth in other specialisations such as
business analysis and change management mean that PMs are somewhat removed
from the business consequences of their actions. Nevertheless, we PMs should manage
the project with the anticipated benefits clearly in mind and navigate our project to
help ensure that the intended benefits will materialise.

As PMs, our early involvement in a project means that we will better understand the
rationale for the project and the required benefits, and we may then be able to inject
some timely, rational thinking, given our project is to deliver these anticipated results
should the endeavour be approved. In particular we might ensure that the business
case and initial estimates are realistic. Sponsors and other key stakeholders, often very
keen for their project propositions to be approved, have been known to over estimate
benefits, ignore disbenefits, under-estimate project costs, downplay the risks involved,
and promise amazingly optimistic delivery dates for products and their benefits.

The benefits part of our PM plan should contain the following information:

• What benefits will be measured.

• Who is accountable for the expected benefits.
• How to measure expected benefits.
• When to measure expected benefits.
• What resources are needed to review the benefits.
• Baseline measures from which improvement may be calculated.

213
 Benefits Planning Template

Benefit Benefit How When Resource Baseline

Description Owner Measured Measured Needs Measure

Thus, the main focus of every project should be on the benefits and not merely on the
products. The products are the vehicles upon which benefits are delivered. Benefits
are the rationale for undertaking the project and are identified in the project business
case, which is a core reference document throughout the project life and subsequent
product lifecycle. Benefits need to be clear, relevant and measurable, and the business
case, which is a “living document,” needs to be updated as circumstances change.
Sometimes the rationale or value proposition for the project significantly diminishes,
resulting in project cancellation, and this might even occur when project implementation
is proceeding well in terms of schedule and budget performance.

A common misconception is that if we build the project, the benefits will come, benefits
management is seen as an unnecessary overhead, and once projects are approved, no
further justification is sought. Therefore not only are the claimed benefits not leveraged,
but additional potential benefits are also missed. However, benefit realisation has
become a vital driver for projects and it’s now more common to assess the success of
a project in terms of benefits achieved, rather than evaluating success only in terms of
the traditional measures of time, cost and quality.

We need to raise our game so that managing benefits is regarded as a distinct and
central component of PM, ingrained in the culture of our organisations. The realisation
of benefits to create value must be a core competence of every successful organisation,
where the following good practices for managing benefits are evident:

• We PMs, sponsors and line managers work together.

• We assign clear responsibilities for benefit delivery.
• We involve all stakeholders in planning benefit delivery.
• We include benefit delivery in our PM plan.
• We develop benefit metrics for every project.
• We integrate risk management with benefit management.
• We communicate the benefit delivery plan to all stakeholders.

Benefits realised should be viewed against the business case. Only by comparing
results against the business case can the degree of project success be fully determined
and our future business cases improved. A comprehensive benefits report might

214
include mention of benefits planned, benefits realised, disbenefits, benefits not yet
achieved and why, actions to retrieve unachieved benefits, benefits discarded, further
benefits available, and lessons learned. Project product user surveys are very helpful
for gauging benefit realisation progress and effectiveness.

Product users should be required to track, record and report performance against
anticipated benefits. We also need to think about when we are going to stop measuring
benefits. For example, we could take the benefit in this financial year and then not track
it next year, considering it a business-as-usual product by then. But it is not unlikely
that some organisations will select a “benefits sampling period” that is favourable
rather than representative. Sometimes enhancement projects are implemented when
benefits don’t materialise as planned or products under-perform. A post-project
product implementation report that assesses benefits realised may be prepared by the
project sponsor or project manager in co-operation with operational managers and
product users, a possible format for which is included at Appendix Two.

Where a project is delivering a product for an external client under contract we PMs
usually have no formal involvement in benefit realisation. However, we should be
familiar with the client’s business case. The contract with the customer is to produce
the project product, and it will be the customer who then obtains the benefits from the
product’s use.

In conclusion, contemporary PM aims to transition project outputs into new operational

business-as-usual capabilities and follow through to the achievement of outcomes,
benefits and finally the organisation’s strategic objectives. Benefit realisation has
become a vital driver for projects and it is increasingly common to assess the success
of a project by achieved benefits rather than evaluating success based entirely on the
traditional measures of time, cost, quality and scope.

Remember that the ultimate purpose of our project is to deliver product(s) into the
business-as-usual or operational area of our customer, and that this product will
ultimately realise the benefits that have been described in the business case.

Although benefits are not the only criteria used to evaluate project success, they are
a very good measurement of how valuable a project is. A project is truly successful
only if it delivers the required benefits. That’s why benefits realisation is now an added
focus for us PMs and as a minimum we must consider the benefits and their realisation
as they influence our planning and decision-making throughout the life of the project.
But, while project benefits are always listed in the project business case, many PMs
still drive their project toward generating a specified product, while not giving enough
attention to the expected benefits.

Tailpiece

While there is an air of finality about publishing, I’m well aware of the wealth of new
insights, examples and information that will now rapidly come to my attention. This is
of course another example of Murphy’s famous law, which is evident in all projects, and
on which thought I conclude this writing project.

215
 Appendix One

Common Terms

Effective communication is a key element for successful PM, which makes a common
language essential. Every profession has its specialised language and project
management is no exception.

Activity
An element or unit of project work. Also called a task or work package.

Bar Chart
A schedule (also called a Gantt chart) where project tasks are shown as horizontal
timelines denoting their durations, start dates and finish dates.

Baseline
An original plan used as a basis for changes and tracking project progress.

Benefit
A measurable improvement or positive change resulting from an outcome perceived as
an advantage by one or more project stakeholders.

Benefit Realisation Management

The process aimed to ensure that anticipated benefits from an investment in change
are achieved.

Benefit Types
A benefit type can be financial or non-financial, and tangible or intangible.

Budget
Planned cost for a project, activity or task.

Business Case
Provides justification for undertaking a project. It evaluates the benefits, costs and risks
of options and provides the rationale for the preferred solution.

Business-as-Usual (BAU)
An organisation’s normal day-to-day operations.

Client
Person or organisation for whom the project is undertaken.

Change Control
The process through which requests to change the project scope are captured,
evaluated and approved, rejected or deferred.

216
Change Management
A structured approach to moving an organisation from the current state to the desired
future state.

Charter
A formal document that authorises a project manager to undertake a project.

Contingency
Time or money set aside to be used if and when known risk events occur.

Contingency Plan
Plan that identifies strategies if the project doesn’t go as expected.

Contract
Legally binding agreement.

Control
Process of comparing actual and planned performance, analysing any differences, and
if need be, taking corrective action.

Cost Variance
Difference between budgeted and actual cost of work performed.

Cost Benefit Analysis

An evaluation of a proposed project whereby estimated costs are compared with
anticipated benefits.

Critical Path
Longest path through the project network diagram and thus shortest project completion
time. A project may have more than one critical path.

Critical Task
A task on the critical path. Such tasks have no float time.

Deflection
Transferring all or part of a risk to another party, usually by some form of contract.

Deliverable
Products, services, processes or plans created as a result of a project or task. The result
or output of project work. There are final deliverables and interim deliverables.

Dependency
The relationship of one task to another. The most common dependency is finish-to-
start.

Dis-benefit
A measurable decline resulting from an outcome perceived as negative by one or more
stakeholders.

217
Duration
Work-days needed to complete a project or task.

Effort
Number of person-hours needed to complete work, often expressed in staff hours, staff
days, or staff weeks. Also referred to as “work effort”.

Elapsed Time
Number of calendar days during which period a project, activity or task is undertaken.

Earned Value
An approach that integrate scope, schedule and expenditure for measuring project
performance.

Estimate
Prediction of a quantitative result applied to project costs, work effort, durations, and
resources.

Event
Completion or beginning of a project or task. Has zero duration. Important events
might be designated as milestones.

Extended Lifecycle
A project lifecycle model that includes the realisation of benefits.

Fast-Tracking
Reducing the project schedule by overlapping tasks.

Float
Difference between time available for performing a task and time required to complete
it. Time by which a task can be delayed without delaying project finish. Originally the
term “float” was used for CPM diagrams, and “slack” for PERT charts.

Gantt Chart
A horizontal bar graph. Activity (task) durations are shown by horizontal time lines.

Intangible Benefit
Also known as a soft benefit that is usually qualitative rather than
quantitative to measure, such as the level of client satisfaction or loss of reputation.

Key Performance Indicators (KPIs)

Measurable indicators used to report project progress and success.

Lifecycle
The process used to build the products produced by the project.

Management Reserve
A sum of money held as a contingency to cover the cost impact of unexpected events
sometimes called “unknown unknowns.”

218
Milestone
An important event in the life of a project.

Mitigation
Lessening risk by reducing its impact or probability of occurring.

Monitoring
Capture and reporting actual performance against planned project scope, quality, time
and cost.

Murphy’s Law
The law that says, If anything can go wrong, it will. It’s named after Captain Edward A.
Murphy, an engineer working on US Air Force Project MX981 in 1949.

Network Diagram
Schematic display showing the logical sequence of project tasks.

Outcome
The changed circumstances that result from the use of an output.

Output
What is left behind on project completion. Also referred to as a product or deliverable.

Overrun
Increased time or cost compared to the plan.

Plan
Intended future course of action.

Predecessor
Task that must be completed before another task can begin.

Process
A recurring series of actions whereby an input is transformed into an output (product).

Product
A tangible or intangible output or deliverable.

Product Scope
Product requirements – features and functions.

Programme
Broad effort encompassing related projects.

Project
A temporary endeavour undertaken to produce a unique product.

Project Lifecycle
Sequential phases through which projects proceed.

219
Project Management (PM)
Use of leadership, planning, scheduling and control techniques to achieve the project
goal.

Project Manager (PM)

Person responsible for managing the project.

Project Management Plan

Document describing how the project goal is to be achieved.

Project Scope
Work required to complete a project and deliver the product. It includes management
activities.

Project Team
Co-operative group of people of various disciplines responsible for executing the
project.

Quality
Features and characteristics of a product that bear on its ability to satisfy stated needs.
Quality is about conformance with specifications and producing a product that is fit for
purpose.

Quality Management
The discipline for ensuring that products and the processes by which they are delivered,
meet stakeholder requirements and are fit for purpose.

Requirements
A requirement is a feature or function that a product must have in order to be useful to
its stakeholders.

Resources
Items required to complete the project.

Resource Driven
A project in which resource availability determines the schedule.

Resource Levelling
A scheduling calculation that delays project tasks such that resource usage is kept
below specified limits. It’s also known as resource limited scheduling and often causes
a delay to project completion.

Resource Schedule
Timetable showing when project resources are required.

Resource Smoothing
Rescheduling project tasks within their float to ensure resource needs comply with
resource availabilities without delaying project completion. It’s also known as time
limited resource scheduling.

220
Risk
A potential threat or opportunity. The consequence of uncertainty.

Risk Management
Organised control of risks.

Rolling Wave Planning

The process whereby short term work is planned in detail and longer term work is
planned in outline only.

Schedule
Timetable for completion of project tasks.

Schedule Variance
Difference between planned and actual completion of project tasks.

Scope
Defines the boundaries of the project – what will be done and what won’t be done.

Scope Change
Change to the project scope.

Scope Creep
An unauthorised modification to the project scope.

Slippage
Amount of time a project or task has been delayed from its baseline plan.

Specification
Documentation prescribing product performance standards.

Sponsor
Project business case owner and project funder.

Stakeholder
One who has a stake or interest in the outcome of the project. They may affect the
project or be affected by the project.

Status Report
A report stating the condition of the project or task at a certain date.

Sunk Costs
Costs already incurred.

Tangible Benefit
A benefit that is readily quantifiable in financial terms such as cost savings
or increased revenues, or can be non-financial such as greater
productivity.

221
Task
Unit of project work. Also referred to as an activity or work package.

Team
Two or more people working inter-dependently towards a common goal.

Team Building
Influencing a group of individuals to work together effectively.

Team Members
Individuals, who report either part-time or full-time to the PM, who are responsible for
some aspect of the project work.

Tolerance
Permitted cost and time variance.

Trade-off
Allowing one aspect to change, usually for the worst, in return for another aspect of
a project getting better. Most typically trade-offs are made between scope, cost,
schedule and quality.

Variance
Difference between actual and planned performance, in terms of schedule or cost.

Variation
Change to a contract, specification, or project scope.

Waterfall Method
A type of lifecycle where phases are sequential.

Work
Effort to complete a project or task.

Workaround
An alternative solution to a problem.

Work Breakdown Structure (WBS)

Work needed to complete a project, usually shown in a hierarchical structure of
successively smaller elements of work.

Work Package
Lowest level of work element in a work breakdown structure.

222
 Appendix Two

Templates

Templates are designed to give us direction, confidence, quality, consistency and

save us time. Essentially they’re checklists. We simply fill in the blanks. They are not
strait jackets, but to be useful their format needs to be controlled, otherwise local
amendments soon diminish their value. Some common templates are listed here,
although they may need some modification to better suit particular project needs.

Stakeholder Analysis Table

Stakeholder Nature Level of Attitude Effect of Influence of Communication

Group of Their Interest to Project Project on Group on Strategy
Interest (H, M, L) (Positive, Group Project
Ambivalent, (H, M, L) (H, M, L)
Negative)

Work Schedule

Task Task Description Estimated Start Finish Immediate

Number Duration Date Date Predecessor(s)

Risk Log

Risk Identification Risk Analysis and Response

Risk Registered Risk Probability Impact Priority Risk Trigger Risk Risk
No By/Date Description Response Event Owner Status

223
 Issues Log

Registrered Date
Issue Issue Assigned Solution Issue
Resolution
Number Description To Summary Status
By Date Required

Change Request

Project / Task:

Proposed Change:

Reason(s) for Proposed Change and Benefit(s):

Estimated Cost and Time to Implement:

Consequence(s) if Change Not Approved:

Approval Authority

Date Received: Change Request Number:

Consequences for Project of Proposed Change:

Project Manager: Approved / Not Approved / Deferred

or
Recommended / Not Recommended

Date: Signature:

Project Sponsor: Approved / Not Approved

Date: Signature:

224
 Status Report

Status: Description:

Green All performance parameters on target.

Amber Issues have not significantly impacted project parameters.
Red Issues have arisen that will or are significantly impacting project
parameters.

Performance Status (Green, Amber or Red) and Remarks:

Parameters:

Time

Budget

Scope

Quality

Issues

Risks

Benefits

Stakeholder
Communications
and Satisfaction

Other Matters

Lessons Learned Log

Lesson Registered
Lesson Recommended Action
Number
By Date

225
 Project Management Communication Plan

Type of Purpose From To Frequency

Communication

Initial Definition Describes a Sponsor Business Analyst As Required

Statement possible project

Business Case Evaluates a Business Analyst Sponsor As Required

possible project

Project Charter Authorises Sponsor Project Manager As Required

project planning

Project Plan Describes how Project Manager Sponsor for As Required

the project is to approval
be implemented

Status Report Shows the current Task Manager Project Manager Weekly
state of the
project in terms Project Manager Sponsor Fortnightly
of its objectives

Change Request Seeks authority Task Manager Project Manager As Required

for change to
project objectives
Project Manager Sponsor As Required

Meeting Agenda Advise attendees Project Manager Project Team As Required

of meeting Members
details

Meeting Minutes Record of Project Manager Project Team As Required

discussion and Members
decisions

Project Audit Review of project Project Auditor Project Manager As Required

Report health Sponsor

Project Finish Evaluates Project Manager Sponsor At Project Finish

Report completed
project

Project Finish Report

Here is one format for this report, but there are other options for the analysis including
a sequential or project lifecycle analysis of each project phase – conceive, develop,
execute, and finish, or using PMI Project Knowledge Areas, or the six Ps assessment
whereby performance is assessed in terms of purpose, parameters, participants,
processes, products and politics. Whatever the selected format, the analysis needs to
be clear, objective, relevant, coherent and comprehensive. Headings are important as
are photographs, graphics and tables. Unwieldy but relevant data is usually put into
appendices, which might be tagged for easy reference.

226
Executive Summary Provides a quickly read version of the report - purpose, main findings,
main conclusions and key recommendations. One or two pages only.
Call it an Executive Summary, Précis, Abstract, Synopsis or Epitome if
you like. It’s sure to be read. It’s written last.

Introduction Secures the reader’s attention. Orientates the reader, describes context,
project rationale, background, and/or origin.

Purpose To assess project performance and recommend improvements to

project management processes and practices.

Evaluation Methodology Explain briefly how you tackled the evaluation process, method of
research, scope of the report, sources of information, assumptions, and
limitations if appropriate.

Purpose Explain briefly and clearly what the report aims to achieve – presumably
to evaluate our project.

Project Success in terms of • Scope • Quality

Project Parameters • Cost • Risk
• Time • Benefits

Effectiveness of Management • Selection • QA

Processes • Estimating • Control
• Risk • Reviews
• Issues • Reports
• Variations • Change
• Variance • Benefits
• Communications

Stakeholder Engagement and • Client • Employees

Team Performance • Sponsor • Contractors
• Project Team • Consultants
• Users • Suppliers

Unresolved Issues Sometimes there are issues about our current PM practices and
processes to be resolved after project finish. Also, there may be
outstanding issues concerning product training, use and maintenance.

On-going Support Users always need support. We could have a bulletproof product,
excellent training and documentation, but someone will find a way to
break it or just not read the information provided.

Conclusions and Lessons These are the result of the evaluation and follow logically from the
Learned above analysis. Lessons learned should be unbiased and clearly
stated. There is usually no discussion in this section nor is there new
information.

Recommendations Recommended follow-up actions and suggested changes to

methodology, policy, practices, processes and procedures.
Recommendations follow logically from conclusions. They are capable
of implementation, action-oriented, and look to the future. They may
be goals. They may result in new projects.

227
 Product Implementation Report

This post-project report is usually prepared by the sponsor once the project product
is implemented into business-as-usual routine and assesses the extent to which
anticipated benefits and disbenefits have been realised. This benefits review focuses
on measuring the success of our project by measuring and evaluating the operational
impact of the project product generated as a project outcome. The report describes the
transition of the product to operations and should include any difficulties or challenges
faced during this period. The report should also highlight what went right during the
transition so future projects may reference and use best practices to improve project
performance. The report would also have a title page, distribution list, amendment
record and contents page. “Reader-friendly” is an important principle.

Summary A quickly read version of the report – purpose, main findings, main
conclusions and key recommendations.

Introduction Identify the product and provide a brief description about the product’s
transfer to operations.

Report Purpose To assess the product’s performance and benefits realised.

Key Questions • Did the project solve the problem that it was designed to address?
• Are the anticipated business benefits being realised on schedule?
• Have any unanticipated benefits been identified?
• What has been the magnitude of disbenefits?
• Can we deliver further benefits?
• What is the level of user satisfaction?
• Was user training adequate and timely?
• What are the product’s strengths and specific areas of success?
• Which are the most frequently used features?
• Which are the least used features?
• What features are not used at all?
• How might the product be improved – possible enhancements?

Variances Identify and explain any significant variations between actual results and
expected benefits and costs.

Outstanding Issues Sometimes there are outstanding issues concerning on-going product
training, use, repair and maintenance, and enhancements.

On-going Support Provision of on-going product training, use, repair and maintenance, and
enhancements.

Lessons Learned Identify any lessons learned that can be used to improve how future
projects and product perform.

Conclusions These are the result of the evaluation and follow logically from the above
analysis.

Recommendations What recommendations follow from the report’s conclusions? They may
recommend product enhancement projects.

228
 Appendix Three

Risk Checklist

Here is a risk list of threats that history has shown may imperil the success of our projects.
If a risk happens once, that’s understandable. If the same risk happens twice, that’s
most unlucky. If the same risk happens three times or more, that’s unacceptable. No
risk list is ever complete, but some of the more common culprits from my experience
are printed in bold. Your experience may be different.

Accelerated schedule Inaccurate dependencies

Acts of God
Blaming culture
Budget cuts
Business-as-usual priorities
Change in sponsor or key appointments
Change in PM or team membership
Change management ignored
Competitors’ activities
Complexity underestimated
Complicated deliverables
Confidentiality infringement
Contractor bankruptcy
Contractors’ claims
Cross-project dependencies
Delayed approvals
 Non-performing components
Denial of risk
 Novel pioneering-type project
Dispersed team
 Other projects in the programme
End-users not committed
End-users not consulted
Excessive time spent planning
Extended working hours
Failure to delegate
Feature creep or gallop
Force Majeure impacts
Frequent scope changes
Funding delays
Groupthink
Hidden agendas
Health and safety infringements
Hostile organisation culture
Inaccurate and/or late reporting
Inadequate functional support
Inconsistent expectations
Inexperienced PM
Insufficient authority
Insufficient planning
Insufficient resources
Intellectual property disputes
Lack of stakeholder engagement or
commitment
No benefit realisation process
No substantive risk management method
No valid PM methodology
No written charter or contract
Non-compliance with regulations
Overly optimistic schedule
Political interference
Poor communications – internal and external
Poor product specifications
Poor teamwork

Price increases
Procedures undocumented
Project benefits unclear
Project team members unavailable when needed
Property damage
Resource consent delays
Rework
Risk impact or likelihood wrongly assessed
Risk responsibilities unclear

229
Risks not clearly define Unstable work environment
Risk responses unclear Unexpected overtime
Risk log not maintained Uninterested sponsor
Roles and responsibilities unclear Unlawful activities
Scope ill-defined Unproved technology
Site accidents Unproven contractor/ subcontractor
Staff turnover and unexpected departures Unrealistic estimates
Stakeholder conflict Unrealistic expectations
Stock theft or deterioration Unrealistic performance standards
Subcontractors’ poor performance User requirements unclear
Terrorism and sabotage Vague success criteria
Theft of materials Vague work scope
Unclear product specifications Vandalism at project site
Under-qualified people Variations proliferate
Unreliable suppliers Wage/salary increases
Unstable requirements Wrong assumptions

230
 Appendix Four

Example Trade-off Analysis

Scenario

To meet the commissioning date for the water purification programme, work on the
remote control building project needs to be completed more quickly than originally
planned. At present the plan is to complete the project in 12 weeks at an estimated
cost of $61,000. Sub-contractors have also advised us of their normal costs (shown in
the table below) and those that would apply should the project be accelerated, where
“all crashed” is the fastest time in which tasks can be completed.

Task Description Immediate Normal All Crashed Extra $K

ID Predecessor Cost/Week
Weeks $K Weeks $K

A Procure materials Nil 3 5.0 2 10.0 5.0

B Prepare site Nil 6 14.0 4 26.0 6.0

C Prepare request Nil 2 2.5 1 5.0 2.5

D Prefabricate and deliver A 5 10.0 3 18.0 4.0

E Obtain council approval C 2 8.0 2 8.0 N/A

F Install connecting lines A 7 11.5 5 17.5 3.0

G Erect building B, D, E 4 10.0 2 24.0 7.0

Project Duration and Cost 12 61.0 7

Task

Determine the minimum cost in which to do the project within various timeframes – 7,
8, 9, 10, 11, 12 weeks.

Approach

Draw the network diagram showing normal task durations, identify the critical path, and
then reduce critical path task durations to meet the new target durations, recognising
that some tasks are cheaper to accelerate than others, but where necessary also reduce
other task durations to ensure that no path exceeds the new critical path duration. We
then determine the extra cost incurred for each task accelerated and add this to the
normal cost ($61K).

231
Solutions

Project Duration Minimum Total Cost

(weeks)
7 $100,000
8 $87,000
9 $77,000
10 $69,000
11 $65,000
12 $61,000

The following series of networks shows how the project can be progressively shortened
from twelve to seven weeks.

Case Project Length = 12 weeks

Critical Path - ADG - Total Cost = $61,000

232
Change from 12 to 11 weeks

Alternative Action Incremental Cost of Action

$
I Reduce A by 1 5,000
II Reduce D by 1 4,000
III Reduce G by 1 7,000

Best alternative is II

Critical Path ADG - Total Cost = $61,000 + $4,000 = $65,000

Change from 11 to 10 weeks

Alternative Action Incremental Cost of Action

$
I Reduce A by 1 5,000
II Reduce D by 1 4,000
III Reduce G by 1 7,000

Best alternative is II

233
Critical Paths ADG, AF, BG - Total Cost = $65,000 + $4,000 = $69,000

Change from 10 to 9 weeks

Alternative Action Cost

$

I Reduce A by 1 and 8,000

Reduce G by 1 and
Reduce D by 1

II Reduce A by 1 and 11,000

Reduce B by 1

III Reduce G by 1 and 10,000

Reduce F by 1

Best alternative is I

Critical Paths ADG, BG, AF

Total Cost = $69,000 + $8,000 = $77,000

234
Change from 9 to 8 weeks

Alternative Action Cost

$

I Reduce F by 1 and 10,000

Reduce G by 1

II Reduce F by 1 and 13,000

Reduce B by 1 and
Reduce D by 1

Best alternative is I

Critical Paths ADG, BG, AF - Total Cost $77,000 + $10,000 = $87,000

Change from 8 to 7 weeks

Alternative Action Cost

$

I Reduce F by 1 13,000
Reduce D by 1 and
Reduce B by 1

235
Critical Paths ADG, BG, AF - Total Cost - $87,000 + $13,000 = $100,000

236

A D
Activity 216, 218
B
Bar Chart 216
Baseline 94, 209, 211, 213,
214, 216
BAU 216
Benefit 30, 52, 137, 188,
209, 211, 214, 215,
216, 217, 218, 221, 224
Benefit Realisation
Management 216
Benefit Types 216
Budget 47, 63, 137, 138,
175, 216, 225, 229
Business-as-Usual 216
Business Case 37, 48, 50, 55,
59, 62, 216, 226
C 163, 172, 211, 217,
Change Control 216
Change Management 194,
217
Charter 24, 27, 58, 61, 64,
133, 217, 226
Client 59, 156, 216, 227
Contingency 114, 115, 138,
146, 198, 217
Contingency Plan 217
Contract 54, 90, 91, 96, 100,
119, 217
Control 74, 139, 149, 164,
165, 172, 216, 217, 227
Cost Benefit Analysis 52, 217
Cost Variance 175, 176, 217
Critical Path 128, 217, 232,
233
Critical Task 217
Index
Deflection 217
Deliverable 59, 134, 217
Dependency 217
Dis-benefit 217
Duration 111, 114, 115, 127,
175, 176, 218, 223,
231, 232
E Network Diagram 121, 125,
Earned Value 120, 174, 175,
176, 177, 178, 218
Effort 111, 218, 222
Elapsed Time 111, 218
Estimate 50, 60, 109, 119,
120, 175, 176, 218
Event 218, 223
Extended Lifecycle 218
F 132, 133, 141, 154,
Fast-Tracking 218
Float 124, 125, 218
G Process 10, 25, 93, 145, 165,
Gantt Chart 128, 141, 218
I 212, 215, 219, 228, 237
Intangible Benefit 218
K
Key Performance Indicators
61, 190, 218
KPIs 61, 134, 190, 205, 218
L 133, 220
Lifecycle 212, 218, 219
237
M
Management Reserve 218
Milestone 124, 219
Mitigation 219
Monitoring 149, 219
Murphy’s Law 113, 219
N
126, 137, 219
O
Outcome 211, 219
Output 219
Overrun 219
P
Plan 23, 28, 29, 51, 64, 94,
219, 220, 226
Predecessor 125, 130, 219,
223, 231
171, 206, 210, 217, 219
Product 30, 53, 65, 99, 104,
105, 106, 190, 192,
Product Scope 99, 219
Programme 219
Project 219
Project Lifecycle 219
Project Management 20, 25,
133, 220, 226, 237
Project Management Plan
Project Manager 32, 33, 59,
62, 64, 136, 141, 220,
224, 226
Project Scope 220
Project Team 34, 61, 133, 69, 71, 77, 78, 158,
136, 220, 226, 227 188, 190, 221, 223,
225, 227, 230, 237
Q Status Report 141, 221, 225,
226
Quality 29, 57, 85, 134, 147,
Sunk Costs 221
148, 166, 188, 220,
225, 227
T
Quality Management 220
Tangible Benefit 221
R
Task 100, 110, 121, 122, 217,
219, 222, 223, 224,
Requirements 45, 46, 47, 48,
226, 231
49, 54, 100, 188, 220,
237 Team 17, 18, 34, 36, 37, 61,
62, 94, 96, 133, 135,
Resource Driven 220
136, 208, 211, 220,
Resource Levelling 220 222, 226, 227
Resources 28, 29, 130, 131, Team Building 222
220
Team Members 18, 34, 36,
Resource Schedule 220 37, 61, 62, 133, 135,
136, 222, 226
Resource Smoothing 220
Tolerance 222
Risk 113, 114, 138, 139, 141,
143, 144, 145, 146, Trade-off 222, 231
147, 148, 149, 150,
151, 158, V
Risk Management 138, 145,
146, 221 Variance 175, 176, 209, 217,
221, 222, 227
Rolling Wave Planning 221
Variation 188, 222
S
W
Schedule 28, 29, 94, 137,
175, 176, 188, 220, Waterfall Method 222
221, 223, 237
Work 222
Schedule Variance 175, 176,
Workaround 222
221
Work Breakdown Structure
Scope 36, 59, 61, 62, 81, 99,
28, 94, 97, 134, 141,
134, 157, 183, 188,
222
219, 220, 221, 225,
227, 230, 237 Work Package 137, 141, 222
Scope Change 221
Scope Creep 36, 221
Slippage 221
Specification 100, 119, 131,
221
Sponsor 31, 59, 61, 62, 64,
133, 135, 141, 221,
224, 226, 227
Stakeholder 46, 65, 66, 68,

238
239
240