1

Sean Whitaker, BA, MSc, MBA, PMP

[email protected]
www.seanwhitaker.com
www.crystal.consulting

Version 2.2
© 2024

You only need to buy this book once and you are entitled to all future updates.
Check the version number above and email me occasionally to see if there is a new
version.
Contents
Welcome .................................................................................................................................................... 5
Chapter 1. The Practical (& Professional) Project Manager .................................................... 7
Chapter 2. Foundational Concepts.................................................................................................13
Chapter 3. Initiating, Planning, Changing and Closing Your Project .................................37
Chapter 4. Managing the Project Scope ......................................................................................58
Chapter 5. Estimating Cost and Time ............................................................................................68
Chapter 6. Creating a Project Schedule ........................................................................................78
Chapter 7. Managing Project Costs and Budget .......................................................................94
Chapter 8. Managing Risk .............................................................................................................. 107
Chapter 9. Managing Project Quality ......................................................................................... 117
Chapter 10. Managing Project Contracts.................................................................................. 123
Chapter 11. Project Communications ........................................................................................ 128
Chapter 12. Managing Stakeholders .......................................................................................... 140
Chapter 13. Managing and Leading People ............................................................................ 149
Chapter 14. How to Build Your Own Project Management Methodology ................... 159
The End ................................................................................................................................................. 171
Glossary ................................................................................................................................................. 172
Te Reo Māori Glossary ..................................................................................................................... 187
Tools and Templates ........................................................................................................................ 191
Welcome
I’m delighted that you picked up this book. I’m particularly delighted because of what
I know will come out of it. Mastering the art and science of practical project
management isn’t just about increased efficiency or improved bottom line—although,
of course, those are benefits. It is also about effectiveness, about feeling like the work
you do directly contributes to the outcomes and about avoiding the frustrations that
are so common to projects. This book will help you be more effective at your job.

How to Use This Book

This book isn’t necessarily meant to be read all at once, end to end, although you can
certainly do that if you have the time or the inclination. Its primary purpose is to be a
quick, accessible guide giving you the most practical project management tools for
you and your project, presented in no-nonsense language to make them easy to
understand and apply.
If you are starting from scratch, you can go through the book and pick out those bits
that will actually add value to your project. You may be an experienced project
manager with a great methodology in place who just wants to improve certain areas.
On the other hand, if you’re having problems with an existing project and approach
being used, you can use this book to address just those issues you need to resolve.
If you do have the time to read more than one chapter you’ll find that many sections
are interrelated and even depend on each other. You may spot problems in cost
estimating that actually originate in scope definition, or you may have a problem with
managing changes that actually has its roots in risk management (or the lack of risk
management). Be open to exploring these interrelations between different parts of
the project.
Each chapter starts with a general description, and then presents some processes,
tools and techniques you can choose to use if appropriate. Please take from this book
only those processes, tools and techniques that are appropriate to your project. Think
of this as an opportunity to pick and mix just the right ingredients for your project.
You may need a particular mix for one project and perhaps a slightly different mix for
another project. As a rule, the smaller the project the fewer processes and tools you
will need. Conversely, the larger the project, the more processes and tools you’re likely
to need.

Who Should Be Using this Book?

This book is written to be used by a wide variety of people involved in managing

projects. Because it’s all about scalable, practical and appropriate project
management, it can be used for any sized project from any industry. It doesn’t matter
if you work in construction, IT, health, agriculture, government, telecommunications,
software development or any other industry; you can use the tools and tips in this
book to increase your chances of project success.

5
You’ll also find this book useful if you own a small business that does projects, or even
if you’re about to start a small project around the home or neighbourhood. This book
is also useful for students of project management not just for the technical information
it contains but also for the emphasis on adaptability and customizing your approach
to project management.
There are some limitations to this book though and it’s worthwhile mentioning them.
First, it is aimed at those relatively new to project management and a lot of the material
is offered at introductory level. This will give you both an awareness of the possible
tools, and then the chance to apply them. It serves best as a broad and general
overview to the profession of project management with a focus on selectively
choosing those tools and techniques that actually work for you. In order to achieve
this there are some areas that are not explained in depth. You should pursue your own
research if there is an area you wish to know more about. You can also contact me
and I will steer you in the right direction.
Second, it is conversational in style and this means it should be easy for everyone to
understand. I have written text book style books and they are great for formal study
and tuition but if you haven’t been in a formal study setting for some time then they
appear dry and boring. The conversational tone of this book should make it easier to
understand the content.
Much of the book content is based upon what is generally considered best practice in
project management plus my own experience. At points in the book you will find my
opinion pieces, in italics, which started out as blogs on my website. These are purely
my opinion and I would be more than happy to hear your opinion about the same
issues.
It may be that you already know a thing, or two, about managing projects, and that
you’ve heard of this profession called project management. However, most
importantly, you have an inkling that somehow you could be doing better with your
projects. Maybe you’re constantly having arguments with your clients, or staff, about
what work was supposed to be done and what work was not supposed to be done.
Maybe you have difficulty getting your invoices paid because of this. Maybe you’re
not getting your time or cost estimates correct, and are losing business because they
are too high or losing money because they are too low. Perhaps you’re having trouble
documenting and assessing the impact of any change requests, or are having
continuous encounters with scope creep.
You know there is something you could and should do about these issues, yet the
sheer amount of available tools and processes seems overwhelming. This book aims
to break down the profession of project management into appropriately sized chunks
that you get to use when and where you see fit. Wherever you get to in this book, you
are always welcome to contact me at [email protected] with any questions you
may have.

6
Chapter 1. The Practical (& Professional) Project Manager

Why Practical AND Professional?

I deliberately choose the words practical AND professional to represent the approach
to project management that has the greatest chances of success. Managing any
project successfully takes skill and experience. Perhaps even more importantly, the
way in which the project is managed must be just right for the industry, type, size and
complexity of the project.
Many project managers take an off-the-shelf, or readymade, methodology, add in
someone else’s tools, techniques and processes, apply the mixture to their own
projects and organization—and then become surprised when it just doesn’t work.
Project management is not a one size fits all solution for all projects. Each project is
different, each organization is different, and each project manager and project team
is different. As such, the best approach to project management is one that best suits
you and your project right now. That is the essence of practical project management.
It is about applying those tools, techniques and processes that are practical and
perfect for your project.
Those project managers who indiscriminately apply as many tools, techniques and
processes as they can without proper consideration are, in fact, giving the profession
of project management a bad name. Additionally, those project managers who don’t
include enough best practices, and prefer an ad-hoc, make-it-up-as-you-go approach,
are also giving the profession a bad name. Being practical (and professional) is a
balancing act between too much and too little.
This is where project management as a profession differs from other professions. If
you are an accountant, there are generally only a few acceptable ways to compile a
profit and loss, cash flow statement, and balance sheet and there are generally
accepted accounting practices governing these rules. If you are an engineer, there are
acceptable engineering solutions to design which must be followed as lives are at
stake, although you are able to select from several alternatives, you still have to follow
expected standards. Of all the professions, project management is the most adaptable,
customizable and flexible in its application of best practice.
There are many fine books about project management, but I’ve always felt a bit
uncertain at the end of them. They present lots of information about project
management but don’t tell me which tools I should use and which ones I don’t need
to use. Once again, these books result in the implementation of tools, techniques and
processes that may not be appropriate to a particular project. As a result, they deliver
little benefit and in some cases actually contribute to project failure. Practical project
management is about choosing appropriate, professional, scalable and value-adding
tools, techniques and processes.
In my experience, this approach works best. You choose those tools, techniques and
process that deliver real benefit to your project and that are useful to your
organization, keeping in mind that what works for one project may not work well for
7
another. It’s not just the technical output or deliverable that determines the best
approach. It’s the personalities of the project manager, the project team, the client
and other stakeholders. It’s also the environment in which the project is being
completed in relation to time, risk, money and quality issues. All of these factors can
mean that two projects delivering very similar products can have very different, yet
professional approaches.
You’ll see me use that word, ‘appropriately’, a lot. I believe it’s one of the keys to
successful project management; it’s certainly an essential element in being
professional. You want to choose just the right processes and tools that will actually
add benefit to your project. Too many, and you’ll find yourself mired down in
processes and using tools that don’t actually add value. Too few, and your project can
easily spiral out of control. It’s all about being appropriate. Just as every project and
business is different, so too are the processes and tools that you will use in an
appropriate way to increase the chances of project success.
So what exactly is ‘appropriately applied practical professional project management’?
Let’s start by breaking it down.
First, ‘appropriately applied’ means making sure you don’t overcook or undercook a
project. It means choosing from the wide range of available project management
methodologies, processes, templates and tools those that are appropriate for your
organization in terms of size, dollar value, and complexity of the projects that you
undertake. Then, once you have the best and most appropriate ones to use, it also
means applying them in the right way at the right time. Use your discretion and keep
things flexible but always appropriate. The level of project management practices
applied in a NASA space project is different from the level of project management
applied in a small landscaping business or software development business. However,
both need project management to increase their chances of success.
Technically, ‘professional’ means being connected to a recognized profession.
However, in this context, it means a body of practice that knows what actually works
and that has a commitment to continually improving it. Surrounding this core of
knowledge are institutions, credentials and a way to distinguish the good from the
bad in terms of process and practitioners.
The globe’s largest professional body dedicated to the advancing the profession of
project management is the Project Management Institute (www.pmi.org). The
processes and tools in this book are based on The Guide to the Project Management
Body of Knowledge (the PMBOK® Guide). Your chances of project success will increase
when you use proven and supported best practice such as the PMBOK® Guide. Please
be aware that the PMBOK® Guide isn’t a methodology or a prescriptive way of doing
projects. It contains a wealth of best practice from which you are encouraged to
choose those processes, tools, and techniques to create your particular methodology
that suits your projects.
You should also be aware of the ISO standards relating to the profession of project
management as they will become more important in the future. At the time of writing
this book these were the available ISO standards:
8
 ▪ ISO 21500, Project, programme and portfolio management – Context and
concepts
▪ ISO 21502, Project, programme and portfolio management – Guidance on project
management
▪ ISO 21503, Project, programme and portfolio management – Guidance on
programme management
▪ ISO 21504, Project, programme and portfolio management – Guidance on
portfolio management
▪ ISO 21505, Project, programme and portfolio management – Guidance on
governance
▪ ISO/TR 21506, Project, programme and portfolio management – Vocabulary
▪ ISO 21508, Earned value management in project and programme management
▪ ISO 21511, Work breakdown structures for project and programme management

Over time these standards will become more widespread and it is expected that you
will be able to get individuals and organisations certified as aligning with each of them.
So there we are. Put all those things together and you can see exactly what it is to use
appropriately applied practical professional project management.
I will add in just one small disclaimer, which is that there are certain elements that are
essential and mandatory for any business or project, no matter how small. These are
scope definition, cost and time estimating and change control. In my experience, these
facets have the greatest contribution to project success; conversely, when done poorly,
they will almost certainly lead to project failure. I’m not suggesting you need to have
all the work on these processes completed before proceeding, as often this is just not
possible, but you will definitely need these things at some point in your project, and
the earlier the better. You may, for example, define the scope, and then estimate time
and costs incrementally and in an iterative manner as the project progresses.
At the end of the day, though, once you have read this book you are the final judge
on what is mandatory and what is optional. Remember, it must be professional for
you.

Consequences

By now, I’m sure it’s sunk in that being a practical project manager means choosing
only those tools, techniques and processes that are right for your project. In choosing
some aspects to use, we must leave behind other potentially valuable tools.
In order to be successful at this professional approach you need to realize that there
many consequences of the choices you make. Of course, most of the consequences
will be good ones as you choose only those parts of the profession of project
management that are actually of use and providing benefit to your project. There are
however, consequences of choosing not to adopt or implement certain aspects of the
profession. This is where experience comes in handy. Unfortunately, experience only

9
comes with time and often many mistakes. Be adaptive and revisit decisions regularly
about what you choose to adopt and implement as part of being professional.
There are consequences from just applying tools indiscriminately with little regard for
whether or not they are appropriate for your project, including inefficiencies,
confusion about roles and scope, unnecessary bureaucracies, and increased chances
of project failure.
In your pursuit of practical perfection you will learn when to apply a more thorough
approach to project management and when it is better to err on the light side. You’ll
become skilled at understanding the potential impacts and be prepared to change
your approach if necessary.

Weighing the Costs and Benefits

So, how exactly do you go about choosing just the right tools, techniques and
processes? I don’t advocate using your gut feeling and I don’t advocate simply
copying others. I do recommend becoming proficient and experienced as a project
manager and I have more to say on this later on. Perhaps the most effective way to
make decisions about what you choose to use and what you choose to set aside is to
undertake some form of cost benefit analysis. Now, when performed by financially
minded people, a full cost benefit analysis can be a wonderful tool for looking at all
the costs involved in a particular option and all the benefits, usually financial, that that
option is expected to deliver. This can be used to make informed decisions about
whether to go ahead with a project or whether to take certain decision while project
is going on; I’ll cover this thoroughly in the chapter about selecting the right projects.
But however good and effective full financial cost benefit analysis is, it just isn’t right
for what we want to achieve here. What we’ll apply here is the concept of comparing
costs of certain decisions against the benefits they generate. So, as you look through
this book and wonder if a particular tool or technique is a good investment for you, I
want you to consider the time, cost, and energy of putting it in place, and then look
at the benefits in terms of cost, reputation, and efficiency. Only if the benefits of
adopting and implementing the particular tool, technique or process outweigh the
costs should you choose to do it.
Here is a little set of questions to help you help in deciding which tools to adopt and
implement and which to leave behind.
• Will it cost less to implement than the benefits it will deliver?
• Will it make us more efficient?
• Do we have previous experience in using it?
• It is easy to learn to use it effectively?
• Do our project managers and team members support its introduction?

10
If you answered yes to most of these questions then it’s probably a good tool,
technique or processes to have as part of your practical project management
approach.

Does This Guarantee Project Success?

Does using all the right processes, tools and techniques guarantee project success?
Does having all the right credentials and training mean you cannot fail?
The short answer is no, it doesn’t.
Managing projects well is all about increasing the chances of project success and
reducing the chances of project failure.
You can be the most experienced project manager in the world with all the right
credentials and experience. Furthermore you can be using the most appropriate
methodology and constantly reviewing progress and yet still somehow, the project is
a failure through events you simply cannot control. Conversely there are many
incompetent people inappropriately called project managers with no sense of best
practice who make things up as they go along that somehow, against all odds, deliver
a project successfully.
So why bother?
Because, there is a far greater chance of success for those experienced and practical
project managers. There is also a far greater chance of project failure for the
inexperienced unprofessional project leaders. The problem seems to be when one of
the inexperienced ones has a success they tend to crow about it and highlight the fact
they finally succeeded and make it seem the norm when it’s not.
Here are some tips to help increase the chances of project success.
1. Define exactly what metrics are being used to define a successful project. Is it simply
time and cost, or does it include other factors such as health and safety, customer
satisfaction, environmental impact and reputation.
2. Make sure your stakeholders know that you can’t guarantee project success –
don’t set unreasonable expectations but balance that with a realistic appraisal of the
chances of success, and don’t paint too gloomy a picture.
3. Get the experience your need to be able to positively affect the chances of project
success. This experience can come from your own experience on the job; it can also
come from mentoring.
4. Rely on the experience on others, often captured in a professional body of
knowledge such as the PMBOK® Guide.
5. Get the training, and if necessary the credentials, appropriate to the type of
projects you are working on. Formal training takes your experience and helps it grow
faster.

11
And finally, when you do have a successful project make sure everyone knows about
it!

Review Exercise

1. Visit these websites and see what you can learn about the profession of project
management:
▪ Project Management Institute www.pmi.org
▪ Project Management resources www.projectmanagement.com

12
Chapter 2. Foundational Concepts

At the end of this chapter, you will have a clear understanding of the foundational
concepts of the profession of project management, a guide to your own development
as a project management practitioner, and an overview of where your organization is,
and where it needs to be, using an organizational project management maturity
model. This chapter is useful for giving some broad background information on
project management.

What is Practical & Professional Project Management?

Let’s start right at the beginning: what exactly is practical and professional project
management? Project management has been around a long time; in fact, many of
humankind’s most remarkable physical achievements were also great projects. From
the ancient wonders of pyramids in Egypt, Nazca lines in Peru, Stonehenge in England,
and the Great Wall of China right up to modern wonders such as NASA’s moon project,
Palm Island in Dubai, the Millau Viaduct in France and the rebuild of the World Trade
Center Towers in New York, projects have contributed to some of our greatest
treasures. Each of these had a start, middle and an end, and they all had a defined
goal or objective.
We will never really know how the ancients approached project management, what
their metrics for success were, or whether they met them, but the results are very clear.
In modern times, however, project management has become a defined and repeatable
set of professional practices, all designed to improve the chance of project success.
Despite project management having been around for a long time it has only fairly
recently begun the process of becoming a separate profession from other professions
such as engineering, IT and architecture. This is one of the reasons why there is still so
much confusion about what the role of a project manager is, what the profession of
project management is, and how it fits in with other professions.
Projects are now being completed and managed in a wide range of industries; you’ll
meet project managers working in construction, IT, software development, health,
agriculture, aeronautics, government, telecommunications and more. Within each of
these sectors there are hundreds of thousands of projects being completed by
hundreds of thousands of project managers all around the world.
Furthermore, many different approaches, methodologies, tools, and processes can be
used to enhance the chance of project success. There are professional organizations
promoting the profession, and opportunities for continual research and improvement.
Instead of being limited to the experience you gain on the job, you can now complete
international credentials and tertiary qualifications in project management. All of these
are based on both the experiences from the past and the study of project
management.

13
However, as already mentioned, we are still a relatively young profession without the
history of other professions such as medicine, law and engineering. As such, it is not
uncommon to encounter a variety of ways to approach the same problem or people
using different terminology to mean the same thing. This is all part of the growth of
the profession.
Professional project management is built upon a growing body of knowledge, based
on the collected experience and best practice from project managers out there in the
field. By documenting the experiences of what worked and what didn’t, and by
collecting it in a single document, all other project managers can learn from it. It also
features a commitment to continuous improvement and practicality.
The opposite of professional project management is ad-hoc management of projects
while continually reinventing the wheel and never learning from your mistakes. There
is still plenty of non-practical project management occurring, which is a real shame
when the profession of project management is so readily accessible.
As you can probably tell by now, I’m a strong advocate of following a defined body of
knowledge, learning from others and contributing back to the profession. This is the
core of professional project management and is what separates the professional (and
practical) project managers from the amateurs.

What is a Project?

Broadly speaking, there are two types of work in the world. Project work and
operational work.
Operational work is repetitive and ongoing and is led by a general manager. A key
focus for a general manager of operational work is to make sure that the work keeps
going. On the other hand there are projects and the best definition of a project is an
initiative that has a defined start and end, it has a defined deliverable, is subject to a
variety of constraints such as time, cost, and quality, and is subject to progressive
elaboration. I often say that a project manager can be seen as the general manager of
a business that will put itself out of business one day and apart from that there isn't
much difference between a project manager and a general manager.
An important aspect of project management is that, generally speaking, you cannot
know everything there is to know about a project at the outset and, thus, project
management is highly iterative. This means that you may be able to define the work
to be done for the next few weeks accurately, but beyond that you can’t plan as well
because there is more uncertainty, so you plan in an iterative manner, meaning that
you plan many times, each time with more information. This is known as progressive
elaboration and is an iterative process that acknowledges that you will know more the
more you do. For example, at the beginning of a software project you may know the
general expected outcome and the first steps on the path to delivering it, but as you
move along in the project you become more aware of the magnitude of the work and
can plan the project schedule, budget, and risks better.

14
Rolling wave planning is another type of iterative planning where you plan in detail
the next appropriate time period and, as you keep progressing throughout a project,
you keep planning that same length of time in detail. For example, you may do a
rolling 3 month plan for a 2 year long project. Both progressive elaboration and rolling
wave planning are important concepts to communicate to stakeholders who may be
under the impression that it is possible to know and plan everything about a project.
A program (or programme if you follow the UK way of spelling it) is a group of projects
that derive benefit from being managed in a coordinated way. It could be that they all
use the same resources, or they're all producing parts of a larger deliverable. The role
of the program manager is to make sure that each of the separate projects is able to
work as a efficiently as possible and contribute to the overall goals of the program.
A portfolio of work refers to all of the projects and programs that an organization or
distinct business unit will be undertaking. The role of the portfolio manager is to make
sure say it programs and projects are selected according to a rigorous process and
then oversee the financing and risks associated with the entire portfolio.

What Exactly is a Project Manager?

It’s great that you have made a commitment to understand what professional and
appropriately applied practical project management is and to be the best project
manager you can, so that your projects and business can produce better results. In
order for you to fully understand what you are getting yourself in for and to set the
scene a little further, let’s start by defining exactly what a project manager is.
There are many types of professionals working in the field of project management, all
with different levels of responsibility and authority. There are project directors, project
managers, contract managers, project administrators, project coordinators, project
facilitators, and project expeditors. How do you know which one you are and which
one you should be? You don’t need to be a project manager to manage small projects,
but you couldn’t run a complex project as a project facilitator.
As mentioned briefly above in the definitions, the easiest way to understand what a
project manager is and does, is to change the job title to general manager of a project.
Just as a general manager of an organization takes responsibility for running all
aspects of the organization, a project manager takes responsibility for running all
aspects of a project. Along with taking responsibility for the project, a true project
manager’s level of authority is as high as his or her level of responsibility.
Here is a description of each of the different roles:
Project Manager The project manager has full responsibility and authority for
all aspects of the project. He or she is the general manager of
the project and has chosen project management as a full time
career.
Contract Manager A contract manager usually comes from an engineering
background and has an excellent technical ability to lead a

15
 project when that project is fully defined by a contract to do
the works. Contract managers, very generally speaking, do not
have the leadership, communication, and stakeholder
management skills that project managers should have.
Project Coordinator The project coordinator reports progress to senior
management and has responsibility for carrying out mid-level
project management tasks and has some limited authority.
Typically he or she is a technical expert doing project work
part time.
Project Administrator The project administrator provides administrative support on
a project and can take responsibility for small parts of projects.
Has very little authority. Often an entry-level position for
people wishing to become project managers.
Scrum Master This is team role responsible for ensuring the team lives agile
values and principles, and follow the processes and practices
that the team agreed they would use. The use a coaching
rather than directive approach.
Agile Coach An agile coach is a person who facilitates the performance of
a team using agile methods. They use coaching techniques to
assist the team become high performing.
Product Owner The person accountable for maximizing the value of the
product resulting from the work of the Scrum Team. The
Product Owner is accountable for effective Product Backlog
management, which can includes developing and explicitly
communicating the product goal; and creating, prioritising
and clearly communicating Product Backlog items.

If you have high levels of responsibility and authority, you are probably a genuine
project manager, but where you are in this list is less important than your commitment
to your own professional development.
If you are just starting out in the profession of project management you must commit
to learning everything you can from formal and informal sources. Enrol in courses and
credentials that teach project management or consider obtaining the Certified
Associate in Project Management (CAPM®) credential. Learn by watching the good
and the bad in the industry – of course, you want to repeat what the good ones do
and avoid what the bad ones do. Perhaps the most important thing you can do is to
go and get yourself a mentor.
If you are mid-level in the profession you might consider formalizing your on the job
training with a credential such as the Project Management Professional (PMP ®), or a
tertiary diploma or degree. This is also the perfect time to start learning by teaching
and consider speaking at professional events. If you are an experienced and advanced

16
project manager or director, you still must make the commitment to on-going
learning. If you don’t, your abilities and experience will become stale. Go out and
network with your peers and exchange ideas and opinions. Attend conferences and
workshops. An excellent way to ensure you are both learning and contributing to the
development of the profession is by agreeing to be a mentor.

Project Manager or Contract Manager?

It’s hard enough making sure you know whether you are a project manager, project
administrator, project coordinator, project facilitator, or project expeditor. But what
exactly is the difference between a project manager and a contract manager? I’ve met
plenty of people who tell me they are project managers or work for consultancies
providing project management services but in my opinion they are not project
managers they are in fact contract managers and their organizations are providing
contract management services.
So what is the difference and does it matter?
The easiest way to explain what a project manager is, is simply to replace the work
‘Project’ with ‘General’ – so a project manager is in fact the ‘general manager’ for a
project. We all know what general managers do. They look after financing,
communications, staff, marketing, risks, strategy and every other aspect of a business.
This is what someone with the title of project manager is supposed to be as well – the
complete manager of a project. Anything less and you are not a project manager;
choose one of the other titles.
I often think of an analogy using cars to describe the difference – contract managers
are Land Rover Defenders – solid, dependable and suited to particular environments
while project managers are more like a Range Rover – all the extras. All you annoyed
contract managers can email me to tell me I’m wrong if you want to :).
So then what is a contract manager? Well a contract manager steps in to develop,
negotiate and execute a contract for project services. It can be a very large and
complex contract but it only requires knowledge of the terms of the contract and
making sure they are followed. Typically contract mangers aren’t great people
managers, they aren’t exceptional leaders, and they aren’t exceptional communicators
– all the things that a project manager must be. Contract managers tend to be
technical experts who have assumed a management role. Their focus is on the delivery
of products or services.
So does it matter which one to use? That depends on the nature of the project. If it
has a contractually defined scope of work and doesn’t require great leadership,
excellent communication skills and exceptional leadership then a contract manager is
perfectly suited. Otherwise a project manager is the better choice.

17
 OPINION: Responsibility and Authority in Project Management
I am constantly surprised by the large number of people acting as project managers who tell
me that they have all the responsibility for the success of a project but little or no authority
on the project.
This means that they have the responsibility to deliver the project on time, on budget and to
the required specifications but they do not have the authority to get the resources they want,
manage the budget or to make decisions affecting critical parts of the project. If you have
more responsibility than authority then you are not a project manager. You are a project
administrator, expeditor, facilitator, coordinator or more often than not, simply a scapegoat
in waiting.
Would you accept the job of General Manager for Microsoft and then be told that you had no
authority to hire and fire, to track and change budgets, to develop and market products and
to influence the organization strategically? Yet the Board of Directors will be measuring you
against all these factors and if the company doesn’t do well you will be fired? No you wouldn’t,
so why accept the same in project management – after all a project manager is the general
manager of a project.
Allowing this situation is setting you up for stress, failure and an early exit from the profession
of project management. If the level of responsibility you have is greater than the level of
authority that you have then it’s like heading to the guillotine with no way to stop the blade
from dropping – don’t do it!
I sense the frustration these people have and I can see the look of surprise and amazement
when I tell them that a true project manager has equally high levels of authority and
responsibility.
So how do you get equally high levels of responsibility and authority?
Start with your job description. If you have the title of project manager then you should have
equally high levels of responsibility and authority. If you don’t, then downgrade your job title
to reflect your actual position. Sure, the job title isn’t as good as you want but you will be
happier. Make it clear that you will not accept full responsibility without full authority.
Furthermore, you won’t accept unequal levels of responsibility and authority.
If you are going to be fully and solely responsible for delivering the project then you need the
authority to get the resources you need when you need them, to control the project costs and
budget, to oversee and manage changes to the project and to maintain and enhance client
relationship to name just a few of the areas you must have authority in.
Only by having equally high levels of responsibility and authority can you truly be a project
manager.

Project Management is Change Management

Do you want to be a better project manager? Then become a better change manager.
It’s a bold statement but true.
All projects involve change, you are making or delivering something new that is
different from the current situation, and given normal circumstances people naturally
resist change.

18
So what is involved in begin a great change manager?
First, realize that generally people don’t like change and will resist it if not managed
properly. Be aware that change is a scary for thing for most people. Let people work
their way through the process of accepting change. You will need to use your well-
developed leadership skills here to understand, appreciate and guide people through
the uncertainty of change.
Create a compelling reason to change. Let people know what the reason for the
project and the change is. If people don’t see the need for the project they will not
support it. Communicate the need for change effectively and regularly. Change
management is one of those situations where in the absence of good communication,
rumour, gossip and innuendo will take hold.
Create capability for change. Get people on board who support your project and the
change it brings and who also have the necessary skills to carry out the project.
Carry out the change as planned. First plan, and then do. Any project or change must
first be properly planned and then executed according to the plan.
Embed the change. Simply doing what you had planned to do will not guarantee that
the change will be permanent. Create a strategy to make sure the change is embedded
and will go on past the end of the project. Create champions and carry out post
implementation reviews.
So, amongst all those other technical and soft skills a project manager must possess,
learning about and becoming proficient at change management will increase your
chances of project success.
Successful project management involves successful change management and
successful change management requires great project management skills as well.

Organizational Project Management Maturity

In the same way that project management practitioners can be described as beginner,
novice, intermediate or advanced, organizations can also be described as having low,
medium, or high levels of project management. These levels of project management
reflect the level of organizational project management maturity (OPMM).
Measuring organizational project management maturity means looking at how the
organization requires staff to become and keep developing as project managers. It
means looking at the project management methodology, processes, tools and
templates the organization uses or does not use. It involves examining the
organization’s commitment to continuous improvement. There are many ways to
assess an organization’s level of project management maturity and just as many tools.
However, before you go assuming that all organizations must be at the top level of
maturity, it’s important to consider that the level of OPMM that is desirable for any
organization is directly related to the size, cost, length, complexity and industry of the
projects being undertaken. Organizations undertaking highly complex, long term,

19
expensive projects should aim to have a higher level of project management maturity,
while organizations and small businesses routinely undertaking short, low cost, low
complexity projects may be perfectly suited to a lesser level of project management
maturity.
On the following pages you’ll find a very simple exercise to enable you to assess the
level at which your organization currently sits in relation to its project management
maturity. While answering it, you may get some ideas on how you can improve your
organization’s level of project management maturity.
There many sophisticated tools for measuring organizational project management
maturity. Some of the more sophisticated ones take many hours to complete and the
results can be a little unwieldy. I have reduced the essence of these tools into a very
simply yet surprisingly professional assessment tool. If you are interested in a more
formal and quantitative assessment then I recommend looking at the P3M3®
assessment which gives an in depth assessment of an organisations portfolio, program
and project management maturity, and provides up to 60 different cores across the
organisation. I have also developed my own tool that it easy to use and gives great
insights. Contact me if you need any more information about this.
Take a look at the questions on the following page and answer from the perspective
of where you are right now. Just tick the box for each of the following questions if you
or your organization does what the questions asks, add up the ticks and see where
you are at in terms of your own project management maturity. Remember to only tick
boxes that you actually do, not those you have intended to do but never got around
to actually doing.

20
Organizational Project Management Maturity Worksheet
1. Does your organization expect project managers to hold a Yes 
certification or credential in project management?
2. Does your organization expect project managers to undergo regular Yes 
professional development through such things as ongoing training?
3. Are project managers in your organization expected to only do Yes 
project management work and not also carry out technical work?
4. Does your organization appoint a project sponsor for each project? Yes 
5. Does your organization have its own, or a proprietary, project Yes 
management methodology in place and does it require this
methodology to be followed in all projects?
6. Does your organization have a standard set of templates to use on Yes 
each project and require them to be used?
7. Does your organization have a defined process to follow for starting Yes 
each project and require it to be used?
8. Does your organization have a checklist for closing a project and Yes 
require it to be used?
9. Does your organization have system in place for reporting progress Yes 
on each project and require it to be used?
10. Does your organization have a documented and appropriate change Yes 
control process and require it to be used?
11. Does your organization measure and evaluate the competing Yes 
demands on people, time and money between projects?
12. Does your organization regularly review its approach to project Yes 
management and seek to improve it?
13. Does your organization have a Project Management Office (PMO)? Yes 
14. If so, what is its function?
a. Common reporting of all projects Yes 
b. A place where all project managers work Yes 
c. Developing and improving the methodology Yes 

TOTAL TICKS ______

Now add up all the ticks and determine which level of Organizational Project
Management Maturity (OPMM) your organisation is at.
Number of Ticks
0-4 Level 1 Very low level of OPMM
5-8 Level 2 Low level of OPMM
9-12 Level 3 Medium level of OPMM
13-16 Level 4 High Level of OPMM
Now, place a cross next to the number where your organization is on the chart:

21
Now that you know where your organisation currently is, think about where you think
it needs to be.
Go through the questions again this time putting a tick against those things you think
your organization should be doing, keeping in mind the size, cost and complexity of
your projects. The difference, if any, between these two marks on the spectrum is your
goal once you are on the path to practical project management.
Here are some questions to get you thinking about the practical project management
tools, techniques and processes to help you get to the level of organizational project
management maturity you need to be at. Given that this is only chapter two of the
book, you may not be able to answer these questions until you have read more of the
book.
• What do you think the top priorities are for your organization to enable it to
improve its approach to project management?
• What actions can you personally take to contribute to your organization’s
project management maturity?

Project Management Definitions

Most books include a glossary of terms at the rear, and just like them so does this
book. However, I thought it best to be up front about the most useful terms we are
going to use to make sure that you don’t go and read a chapter incorrectly because
you understood a word to mean something different from the way I am using it.
The point of this section of the book is to make sure we are using the same word to
describe the same thing. Project management has evolved from many different
professions, each bringing their own terminology. There can be a great deal of
confusion when people use different terms to describe the same thing. Throughout
this book, the terms used will align with The PMBOK® Guide and I encourage you to
standardize the language you use in your organization to reduce the chance of errors.
With your first read through the book, have a look at these definitions and see if any
are different from terms you already use. If they are, make the decision to either
change the term you use or quickly translate between your term and the term I am
using. If you strike a term you don’t know the meaning of then refer back to this
section or to the glossary at the rear of the book. We have also given you a really
useful glossary of te reo words that you can also use in project management.

22
Common Project Management Words

Framework A non-prescriptive collection of professional best practice from

which you are expected to choose the processes, tools and
techniques that suit the size, industry and complexity of projects
you are undertaking. The Guide to the Project Management
Body of Knowledge (the PMBOK® Guide) is the world’s leading
project management framework.
Baseline A project can have baselines for scope, time, cost and quality.
These are used to measure actual progress against planned
progress. The baseline is the original estimated plus any
approved changes.
Methodology A specific and particular way of doing projects complete with
defined processes, templates, and tools. Most organizations
develop their own methodology from a framework such as the
PMBOK® Guide. Some companies buy a readymade proprietary
one such as MPMM, Method 123, TenStep, PRINCE2®, DevOps,
Lean, Scrum, or CPMM.
Portfolio All the programs and projects an organisation (or business unit)
is undertaking.
Program A set of projects interrelated in some way and they benefit from
being managed in a coordinated way, i.e. they may share
common resources or be working toward a common goal.
Project Any work or activity with a beginning, middle, and end
delivering a unique product, service or result usually to time,
cost and quality constraints, and subject to progressive
elaboration. It is the opposite of operational work.
Project The Project Management Office is the center of excellence for
Management Office project management within an organization. It can be many
(PMO) different things depending on the level of organizational project
management maturity. The ‘P’ in the title can also refer to
program or portfolio. It can also be referred to by many other
names including Project Support Office (PSO), Project Delivery
Office (PDO), Investment Management Office (IMO). IT can also
have an ‘E’ for Enterprise in front of it, e.g. EPMO, to indicate it
is organisation wide.
Project Manager To understand exactly what a project manager is, simply
change the title to ‘General Manager of a Project’ and you will
understand the high levels of responsibility and authority the
project manager has. Below this, there are Contract Managers,
Project Administrators, Project Coordinators, Project
Facilitators, and Project Expeditors. Each has a lesser level of
responsibility and authority.

23
 Program Manager The person responsible for managing potential conflict and
reporting on progress on projects that are interrelated in some
way.
Stakeholder A stakeholder is any person, group or organization who can
affect and be affected by the project.

A Brief, Yet Concise, Explanation of All Those Project Management Standards,

Frameworks and Methodologies

Are you a little confused by all these project management documents and credentials
you keep stumbling across in your quest to understand the profession and further
develop yourself as a project manager? Well I’m going to try and explain the situation
to you so you understand exactly what a standard, framework and methodology is
and how they are different from each other. This will be a brief, yet concise, explanation
and if you want more detail just do a search on the internet.
Let’s start the explanation with a diagram. The diagram shows standards, frameworks
and methodologies in descending order of influence and importance.
Standards, Frameworks & Methodologies

Figure 1: Project Management Standards, Frameworks and Methodologies

At the top you have ISO21502: Guidance of Project Management which is the newly
introduced international standard for project management. At this stage it is a guiding
standard only and not a normative one. We expect it to become a normative standard
sometime and when it does you can probably start certifying your organization as
ISO21502 compliant. Until then it represents a fantastic guide for practical project
management and you should probably make yourself very familiar with it as it will
probably become a standard you need to comply with sooner or later. There are also
other international standards in this series relating to program management, portfolio

24
management, and project manager competency and you should make a note to check
them out.
The next layer down is made up of framework documents and their associated
credentials. Here you have project management body of knowledge’s’ which capture
what is considered good practical project management practice across the entire
project management profession. The largest example of this is the PMBOK® Guide
from the Project Management Institute (PMI) which is a global organization – I
recommend checking them out and joining as a member at www.pmi.org.
Frameworks contain much more detailed information about project management
processes, tools and techniques than standards such as ISO21502. The Association for
Project Management (APM), which is largely based in the United Kingdom, also has
its own Body of Knowledge as well. Despite this extra information they do not present
specific ways of completing projects - that’s a job for methodologies which we cover
soon.
There are many similarities between the PMBOK® Guide, APM BoK, and ISO21502, but
also a few differences mainly around slight naming and content differences of some
processes and process groups. We would expect these differences to be ironed out
over the next few years. PMI offers the Project Management Professional (PMP®) and
Certified Associate in Project Management (CAPM®) credential, APM offers its own
certifications for project managers, and the European based International Project
Management Association (IPMA) has its own set of project management certification.
All of these credentials are framework credentials and are at a much more senior and
detailed level than methodology credentials which we cover next. I recommend all
project managers plan on gaining a framework credential at some point in their career
- the sooner the better.
At the bottom of the hierarchy are specific project management methodologies
developed from frameworks which in turn align with standards. Each methodology
can be traced back to a particular framework document, and its ancillary documents
such as extensions to the PMI PMBOK® Guide.
Each methodology is particularly suitable for different projects based on industry, size,
value, complexity and risk. For example Scrum is great for fast moving iterative IT
projects, Prince2 for low complexity IT projects, and Method123 for defined complex
projects from a range of industries.
There are usually no, or very little, prerequisites needed to gain a methodology
certification so they are generally not any guide to a project managers experience,
ability or seniority. My opinion is that you should only look at becoming a certified in
a particular project management methodology if your organization is actually going
to use that methodology appropriately. Otherwise I strongly suggest getting a
framework credential such as PMP® and gain the skills needed to develop your own
project management methodology.

25
OPINION: 6 Tips for Improving as a Project Manager
There are many reasons that may drive you to want to improve as a project manager. You
may be looking for that next promotion or more complex project assignments, or perhaps it
to ensure greater client satisfaction, or to increase the chances of project success. Maybe it’s
for your own increased job satisfaction or simply a desire for personal growth. Whatever the
reason you need to realize that improvement takes time and there will be times that whatever
improvement path you have taken goes ahead in leaps and bounds, and other time where
any improvements seem to move ahead at a snail’s pace.
Here are six steps to help you improve as a project manager.
1. First comes commitment - The first step in improving yourself as a project manager is to
first make the commitment. This means taking the required steps rather than just talking
about doing them. All the good intentions in the world won’t help you improve if you don’t
actually go ahead and do something tangible. This is what separates those who actually DO
improve as project managers and those who SAY they are going to improve as project
managers.
A great way to commit, and to make sure you are accountable, is to keep a journal of your
intentions, plans and goals as it relates to your own professional development. Another way
to commit is to let your project team members, sponsor and clients know that you value and
seek opportunities for your own improvement. They will all appreciate your openness and
drive for improvement.
2. Define Improvement - As a great project manager you know that you have to have a defined
scope of work for the project so you know exactly what it is that you are doing and it’s the
same for any plan to improve yourself as a project manager. Start by taking the time to define
the specific areas you want to improve in. Do you need more technical skills, people
management or greater leadership ability? Be as specific as possible as this will allow you to
better plan how you will achieve your professional development.
Once you have defined exactly what improvement means to you, you can then document
them and be able to develop a clear plan which includes goals, timeframes and metrics to
know whether or not your improvement plan is working. Don’t fall for the trap that there is
an end point in improvement. Once you have achieved one set of goals, you can define and
set your next set of goals. Improvement is a continuous experience so don’t rush to file that
plan away so quickly.
3. Make mistakes (and learn from them) - It may seem like a strange thing to say but let’s be
honest, everyone makes mistakes so try and make a positive out of a negative situation and
use these mistakes as opportunities to grow and improve. The smart people make mistakes
and learn from them. The not-so-smart people make the same mistakes over and over again.
Often the best way to learn something and improve is to make a mistake and learn from it by
asking yourself why, how, what, and when about the mistake. Try to use the 20:20 vision of
hindsight to learn and improve yourself.
4. Seek feedback - Be brave enough to ask those people around you for feedback. Ask your
team members, your boss and your customer about what they see as your strengths and
weaknesses. You can do this formally and informally.
You can schedule a formal 360 degree review during your annual performance appraisal and
career development planning session. Alternatively you can seek regular informal feedback
from those who answer to you and those who you answer to. Learn to listen carefully to all
26
 the feedback both positive and negative. You can improve by both addressing the negative
but also by doing more of the positive things you do.
5. Copy the greats - One of the easiest ways to improve as a project manager is simply to
watch and observe those project managers with skills and experience that you admire and
copy them. You can meet these great people face to face in your daily life, and you may also
see them speak at meetings, workshops or conferences. It may be that you never get to meet
them in real life but instead read about them in books, journals or articles. However you
interact with them, take careful note of what it is about them that impresses you.
One of the best ways to use others in your search for improvement is to formalize this by
asking someone to be your mentor. Don’t be afraid to ask that senior project manager that
you admire to be your mentor, most people I know are flattered to be asked. Take the
opportunity to meet regularly with your mentor and seek guidance on issues that you are
having. I have found the mentors that I have had, have really helped me improve as a project
manager.
Another thing to keep in mind is that by agreeing to become a mentor yourself to someone
less experienced will also help your improvement goals as it forces you to think about what
you can offer them.
6. Continuing education - There are many education pathways you can follow to assist you
become a better project manager. There are many education courses from project
management training providers up to world renowned tertiary institutes offering a full range
of courses of every topic relevant to the profession of project management. You can seek to
get a certificate of attendance, a diploma or degree, or an international credential as part of
your commitment to continuing education.
As part of your own improvement plan you’ve probably identified those specific and general
areas that you want to focus on. Look out for local face to face and online courses that will
help you get this education. Choose the method that best suits your learning style, work
commitments and financial resources.
These are just some of the ways you can follow if you are aiming to be the best you can be as
a project manager. Congratulations on taking the first step simply by reading this. Let me
know what works best for you.

What is Agile?

Agile, in its early inception, was a response to traditional project management

methodologies, which were often seen as rigid, slow, and inflexible. In the late 1990s
and early 2000s, various lightweight software development processes, like Scrum,
Extreme Programming (XP), and Dynamic Systems Development Method (DSDM),
emerged as alternatives to the prevalent waterfall model. These methodologies
prioritized collaboration, customer feedback, and rapid adaptation over heavy
documentation and strict adherence to plan.
The term "Agile" was coined in 2001 when seventeen software developers convened
in Snowbird, Utah, to discuss these lightweight processes. The culmination of their
discussions was the Agile Manifesto, a document that articulated the core values and
principles of Agile. It represented a significant shift in the software development

27
paradigm, moving away from detailed upfront planning and towards iterative and
incremental development.
There are four key foundational elements to Agile, which are captured at
www.agilemanifesto.org:
“We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more.”
There are also twelve guiding principles:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
The Agile movement gained rapid traction in the software industry and, over time,
expanded its influence to other domains. Today, Agile is not just a software
development methodology but also a broader project management and product
development approach, embraced by organizations across industries.
The defining features of Agile are:
▪ Iterative and Incremental: Agile projects are broken into small, manageable
pieces called iterations that can typically run from 1 to 4 weeks duration. Each

28
 iteration results in an increment, a potentially releasable piece of the product.
This allows for regular feedback and adjustments as the project progresses.
▪ Collaboration and Communication: Agile emphasizes open communication
among cross-functional teams and stakeholders. Daily stand-ups,
retrospectives, and planning sessions are common practices to ensure
everyone is aligned and challenges are addressed promptly.
▪ Customer Feedback: Close collaboration with the customer or end-user
ensures the product or service meets their needs. Regular reviews give
customers an opportunity to provide feedback on the product, and the team
can make necessary changes based on this input.
▪ Adaptive Planning: While Agile recognizes the value of planning, it also
understands the inevitability of change. As such, Agile plans are flexible, and
teams are prepared to pivot based on new insights, changes in the market,
or feedback.
▪ Simplicity and Focus: Agile promotes simplicity by emphasizing the work that
adds the most value and eliminating or deferring unnecessary features or
tasks. Prioritization techniques, like the MoSCoW method (Must have, Should
have, Could have, Won't have) or a prioritized product backlog, are employed
to ensure focus on what's most important.
Since the initial development of the guiding principles there have been many attempts
to develop what are called Agile methodologies. There are approximately 40 or 50
different defined Agile approaches, each with their own strengths and weaknesses.
Here are some of the top Agile approaches with a brief description of each:
1. Scrum: Scrum is a time-boxed, iterative framework that divides work into
short cycles called Sprints, typically lasting 2-4 weeks. It emphasizes
teamwork, accountability, and iterative progress towards a well-defined goal
using ceremonies like Daily Stand-ups, Sprint Review, and Sprint
Retrospective.
2. Kanban: Kanban is a visual system for managing work as it moves through
different stages. Its core principles focus on visualizing tasks, limiting work in
progress (WIP), and enhancing flow, making it easier to identify bottlenecks
and areas for improvement.
3. Extreme Programming (XP): XP is a software development methodology
that emphasizes customer satisfaction, flexible responses to changing
requirements, and frequent delivery of high-quality software. It introduces
practices like pair programming, continuous integration, and test-driven
development to improve software quality and responsiveness to evolving
customer needs.
4. Lean Software Development: Inspired by lean manufacturing principles and
practices, Lean Software Development aims to optimize efficiency, reduce
waste, and deliver software faster. Its seven principles, such as "Eliminate
Waste" and "Build Quality In," encourage teams to focus on delivering value
to customers rapidly and efficiently.

29
 5. Disciplined Agile (DA): Disciplined Agile is a methodology that enables
organizations to integrate different Agile and Lean approaches (like Scrum,
XP, Lean, and more) in a manner best suited for the organization's needs. It
is goal-driven, allowing teams to determine the way of working (WoW)
based on their unique context.
6. Scaled Agile Framework (SAFe): SAFe is an expansive framework that
provides a detailed and customizable approach to scale Agile across large
enterprises. It emphasizes alignment, collaboration, and delivery across
multiple Agile teams and integrates principles from Agile, product
development flow, and Lean into its foundation. SAFe structures the
enterprise into four levels: Team, Program, Large Solution, and Portfolio. Each
level has its roles, responsibilities, and activities. This structure aids in
coordinating and synchronizing activities across large numbers of Agile
teams and aligning project objectives with enterprise goals.
7. Feature-Driven Development (FDD): FDD is a model-driven, short-iteration
methodology that focuses on developing and delivering "features," which
are small, functional components of software. It starts with an overall model,
followed by a feature list, and then proceeds with iterative development of
those features.
Each of these approaches has its unique strengths and is best suited to particular types
of projects or organizational cultures. The choice of approach often depends on the
project's requirements, team preferences, and the specific challenges faced.
Although similar in a lot of respects to traditional waterfall, or predictive,
methodologies in relation to the management tools used, Agile differs in one major
respect and that is the speed of iterations.
The following diagrams visually show the difference between waterfall/predictive and
Agile approaches.

Gather
Requirements

Design

Test

Implement

Handover

Months

Figure 2: Typical Predictive or Waterfall Process

30
 Requirements Requirements

Handover Design Handover Design

Iteration

Implement Test Implement Test

Weeks Weeks

Figure 3: Typical Agile Process

Whereas a traditional predictive or waterfall type project may have an iteration that
lasts weeks, months or even years, Agile projects have iterations that last days or a
week or two at most. Refer back to the previous diagram that describes the Plan-Do-
Check-Act (PDCA) cycle for a description of what a project iteration is. At the end of
the iteration a retrospective look is taken at what was delivered and the lessons
learned before moving on to the next iteration of the product (or part of the product).
The type of Agile methodology you choose will reflect the complexity of the project,
what is known and what is unknown, time constraints, budget constraints, risk
tolerance and team/organisational culture. It is up to you to choose the correct
methodology for your project, and it can be a hybrid mix of Agile and
waterfall/predictive if that is appropriate.
For more information about the origins of agile software development I recommend
checking out www.agilemanifesto.org and www.agilealliance.org as beginning points.

The PMO

The PMO plays an important role in whether or not you will have a successful project.
Increasing amounts of research confirm that those organizations with a PMO deliver
more successful projects more of the time than those organizations without a PMO.
So what exactly is a PMO?
Even the name can be confusing because PMO can stand for project management
office or program management office. You can also have a PDO (Project Delivery
Office), EPMO (Enterprise Project Management Office), IMO (Investment Management
Office), PSO (Project Support Office), or VMO (Value Management Office). Whatever
the letters means to you what it actually stands for is the center for excellence in
project management in your organization.

31
A PMO is also unique to your organization and will reflect your current and intended
future level of project management maturity. If you are a small organization doing
occasional projects then the PMO may well be a simple ring binder full of templates
that people use when doing projects.
At the other end of the spectrum, if you are a large organization managing complex
projects essential for delivering strategic goals then your PMO will be:
• The place where all project management staff are located
• The part of the organization responsible for recruiting project managers
• The part of the organization responsibility for training project managers
• Responsible for developing, implementing and auditing the project
management methodology
• Responsible for reporting on all current projects
• Responsible for addressing potential conflicts between projects
• Responsible for the project selection processes

The three broad categories of a PMO are:

• Supportive, which suits organizational with a low level of project management
maturity. It provides templates, guides to best practice and other similar
documents for people managing projects to use. The role of the PMO manager
is part time.
• Directing, which suits organizations with a medium level of project
management maturity. It builds on the role of the supportive PMO and also
provides common reporting, a standardized methodology and project
governance. The role of the PMO manager can be either part time or full time
depending on the size of the organization.
• Controlling, which suits organizations with a high level of project management
maturity that are also large in size and managing complex projects. The
directive PMO completes all of those tasks listed on the previous page and
takes full responsibility for everything to do with project management in the
organization. The role of the PMO manager is full time.

There is also research that tells us that the PMO is not a static thing but a changing
one. It will probably change its form every two years to reflect the changes within the
organization. Whatever the form of your particular PMO it will provide support to
project management practitioners and it will improve the chances of project success.

OPINION: How to Set up a PMO by Stealth

More and more research clearly indicates that organizations with a PMO deliver more
successful projects than organizations without a PMO, yet that same research also tells us that
a lot of organizations fail to see the benefits of a PMO, and some organizations are even
getting rid of their PMO’s. They see them as an unnecessary expense rather than the
investment that they actually are.

32
 Keep in mind that PMO is not a single standardized thing - what it is will reflect the level of
project management maturity, your industry and the size, complexity and duration of the
projects you undertake. It may be anything from a single ring binder full of templates through
to a specific part of the organization that controls all aspect of project management. The one
thing that all forms of PMO have in common is that they are the center for project
management excellence in the organization.
Now, we as practical project managers know that we can do our jobs much better when
supported by a PMO. But how do we go about establishing one in the when top level
management fails to see the benefits? How about a stealth PMO or perhaps a VPMO – the V
can stand for volunteer or virtual?
Here are three simple achievable steps to creating your own stealth or virtual PMO:
1. Establish a project management users group in your organization. Invite all project
managers to be part of it. Then schedule regular meetings – a good idea is 4pm on the 4th
Friday on each month, or a breakfast meeting - and supply some refreshments for people.
Have a specific topic to talk about – it could be improving your change control, standardizing
templates, lessons learned and updates to your project management methodology. Invite a
speaker to attend to present on a particular topic. Have someone document the meeting and
follow up on any agreed actions.
2. Get the project managers to take responsibility for documenting your project management
methodology and then volunteering to carry out audits on each other’s projects.
3. And most importantly of all, when your do deliver successful projects attribute your success
to the support you have received from the VPMO or users group or whatever it is you want to
call it. Let the decision makers higher up see the value. Your goal is to get them to support not
just a PMO but also practical project management within the organization so don’t be shy
about blowing your own trumpet. Take care to first prove the worth of the PMO to practitioners
and the organization before trying to get financial support for a more complex form of a PMO,
or even a paid PMO manager position.
Remember that this stealth or virtual PMO will be your first PMO so it doesn’t have to be
overly complex. The main goal is to prove its worth and get support for a more complex one.

Project Sponsorship and Governance

A key responsibility of a mature PMO is the provision of project sponsorship and

governance. Even in the absence of a PMO each project needs a project sponsor and
some form of governance. The presence of project sponsorship and governance will
increase the chances of project success.
The role of the project sponsor is the be the person who authorizes the project going
ahead, provides financial support for the project, and acts as political champion for
the project helping ensure the project receives the support it needs to succeed. A
project sponsor is not involved in managing the project, that is the role of the project
manager. Usually the sponsor is a senior manager or technician within the
organization with authority to approve projects and provide financial support. The
project sponsor will be part of the project steering committee or group. I strongly
recommend that anyone given the responsibility of being a project sponsor should go
33
on a training course to find out how to be a good project sponsor because a
disinterested or incompetent project sponsor can adversely affect the chances of
project success.
The project steering committee, board or group is there to provide governance to the
project and provide high level support and advice to the project manager. The steering
committee, board or group will be made up of senior managers and stakeholders.
They view the project from a high level and ensure that it is meeting its objectives.
They will ask for regular updates on progress from the project manager and will usually
be involved in assessing significant changes to a project. They will also take
responsibility for making large decisions about the project. They are not involved in
managing the day to day operations of the project.
Ensuring that everyone on the project understands the distinction between
governance and operations is important to ensure the smooth management of the
project. The use of clear written descriptions and organizational charts outlining roles
and responsibilities will asset in this regard. The following diagram shows the hierarchy
of authority and decision making ability, and the difference between governance and
operations on a project.

Project Governance and Operations

Figure 4: Project Governance

Take the time to ensure your project has an engaged and competent sponsor, and
also an appropriate governance group. Also, make sure that everyone understands
their responsibilities.

34
Review Exercises

1. Consider the following scenarios. For each scenario, decide whether it is a project,
a program, a portfolio, or operational work.

A. The implementation of a new piece of software to run an organization’s

payroll
B. The construction of a new house
C. The development of a new housing subdivision
D. Filming the first movie of a movie trilogy
E. Increasing sales from the previous year
F. The design phase of a new piece of software
G. The range of projects an organization is undertaking to increase market
share
H. The installation of new servers as part of a major upgrade to an
organization’s software and hardware systems
I. A new marketing campaign designed to bring in more business
J. The development of a new product that will increase operational profit
K. Several different pieces of software being developed that use the same
developers
L. All the new house projects being undertaken by a construction company

Answers

A. This would usually be a project, but if it was large enough it could be

managed as a program
B. Project
C. Program
D. Probably managed as a program because all of the separate parts that have
to come together
E. Operational work
F. Project
G. Program or portfolio
H. Project
I. Project
J. Project
K. Program
L. Portfolio

35
2. Refer to the simple maturity assessment exercise you completed earlier and take
some time to write down the top 5 things your organization could do to increase
its level of project management maturity? (HINT: look at where you scored a
‘No’ in the above spreadsheet). You may be only able to write down 1 or 2 things
initially but come back to this exercise as you read through the rest of the book
and fill in more ideas.

1.

2.

3.

4.

5.

3. What sort of PMO do you think your organisation needs now?

36
Chapter 3. Initiating, Planning, Changing and Closing Your
Project

This chapter introduces the project lifecycle, as well as the project management plan
and its professional contents. It also introduces the concepts of formally initiating,
justifying, and authorizing a project. Finally, it looks at the process of managing and
assessing changes to a project and the process of planning for project closure.

The Natural Sequence of the Project Management World

There is a generally accepted, and somewhat logical, natural sequence for performing
project management tasks. These are the processes of initiating, planning, executing,
monitoring and controlling, and closing a project. Each part of the sequence has a
different focus and it useful at different parts of the project lifecycle from inception to
completion. These are not a linear sequence where one happens, then stops, then the
next happens, then the next. Rather they represent different stages of a project. This
means you should begin with initiation then planning. But you will be doing planning
throughout the life of the project, and the same for monitoring and controlling. You
will also start planning for closing early on in the project life cycle. The following
diagram shows the relationship between these parts of a project.

Initiating a project is focused on considering all the possible projects you can do,
selecting the ones you should do and discarding the ones you shouldn’t, and getting
them properly authorized and resourced. Obviously all this work is best done at the
beginning of the project life cycle, although there are times when enough changes

37
threaten, or actually happen to, a project that you are forced to revisit this part of the
sequence.
The planning part of the sequence is where you spend the appropriate amount of time
planning how you are going to complete the project. Here you will finalize the scope,
complete any initial cost and time estimating, plan how you will track your initial
forecasts, plan your approach to risk, quality and communications, determine what
people you need and the skills they need to have, plan how you will get external
resources and services, and set in place your change control process.
As you can see, a lot of the initiating and planning work overlaps, particularly on
smaller projects; they can often be viewed as a single combined process rather than
separate distinct processes. Larger, more complex projects may view initiating and
planning as separate and put some sort of approval milestone between the two
processes.
The executing part of the sequence is where the planned work actually gets done.
Remember that the planned work is not just around creating the product. It is also
about all the other work you have said you will do.
The monitoring and controlling part of the sequence is the part where you check what
you planned to do against what is being produced and against changes in
requirements from stakeholders and any other sources. You’re checking the product
against the required specifications, and you’re also properly processing change
requests. Really big errors or changes spotted during these activities may require you
to revisit your project planning to a greater or lesser degree. They may also be so large
as to require you to revisit the initiation process. It is also by doing monitoring and
controlling work that we know when we are ready to start closing the project.
Closing doesn’t start at the end of the project as you might think. Planning for closure
happens at the beginning where you outline and set the conditions under which the
project will be considered finished and the process it has to go through to get there.
Will there be customer sign off? When will final invoices be sent out? Will we collect
lessons learned and will there be a post-implementation review? Clearly setting out
the process and conditions for closure makes formally closing a project much easier.
It also makes it easier to actually complete the process instead of moving onto the
next project before the current one is closed properly.
Although presented as separate things, the five areas of initiating, planning, executing,
monitoring and controlling, and closing are, in fact, highly interdependent. Like
everything else in this practical project management world, you are able to treat them
as guidelines only, albeit strongly recommended, tried and tested guidelines.
However, they aren’t absolutely set in stone. This natural sequence is sometimes
referred to as the project management cycle and many project managers view it as
some sort of nice linear process that you start and can’t help but finish. This simply
isn’t the case.
First of all, it isn’t generally a linear process that involves moving from initiating to
planning to executing and closing. Sure, there may be the occasional simple project

38
that does this but it is the exception rather than the norm. The most professional way
to view these processes is as a constantly revolving cycle for either the whole sequence
or parts of it until the project is closed.
The following diagram shows the individual areas of initiating, planning, executing,
monitoring and controlling, and closing and the constant feedback paths between
each area.

Figure 5: The Plan-Do-Check-Act Cycle

This forms the basis for your methodology as well. The parts of the sequence in a cycle
and how fast you go through each cycle are totally up to you. For fast-moving IT
projects, the entire cycle may be done daily. For larger scale construction projects, the
planning and executing parts of the cycle may be done monthly or six-monthly. This
in essence is the difference between the agile methodologies often used in IT projects,
and traditional predictive, or waterfall, methodologies often used in construction.

The Project Management Plan – What Exactly is it?

Like everything else about practical project management, the project management
plan must be suitable to the organization that needs it. Small organizations
completing small projects will have small project management plans. Large
organizations completing large complex projects will have large complex project
plans. In a practical project management world the project plan can contain some, or
all, of the following plans:
▪ Project Selection Process
▪ Scope Management Plan
▪ Schedule Management Plan
▪ Cost Management Plan
▪ Quality Management Plan
▪ Process Improvement Plan

39
 ▪ Staffing Management Plan
▪ Communications Management Plan
▪ Risk Management Plan
▪ Procurement Management Plan
▪ Contract Management Plan
▪ Milestone List
▪ Resource Calendar
▪ Schedule Baseline
▪ Cost Baseline
▪ Quality Baseline
▪ Risk Register
▪ Project Reporting templates
▪ Project Closure Checklist

Some people are surprised by the project closure checklist, but remember that you
must also plan how you are going to close your project. This part of your plan lets you
know what do in preparation for closure and what processes you need to go through
to get to that point where you can prove your project has been closed. This is just as
important as going through the process of proving your project has a beginning. This
book will take you through all of these but remember, it is up to you to choose the
ones that are mandatory and the ones that are optional.
You may use a variety of software such as word processors, number crunchers or
project management software to prepare your project management plan. You may
use a high tech piece of software or you may simply use handwritten copies of
documents. Whatever your method of preparing a project management plan, you
should make sure that it’s easy to use and actually contributes to your organization’s
success.
The starting point for your project management plan can be a simple set of blank
templates or it can be a place on a hard drive or in the cloud where all manner of
templates, tables, reports and process diagrams exist. It can also be a large piece of
customized software that requires every step to be followed and generates reports
automatically. Whatever form your practical project management plan takes, all staff
should be aware of the project management plan requirements and where to find the
blank versions of documents.
A little tip is that if people don’t use your project management plan, or avoid parts of
it, then there is a good chance it is not professional and you may need to look at how
appropriate that part actually is. Now that you know what can be in a project
management plan, here are some questions to get you thinking.
▪ Which of the above plans, processes and templates do you already have?
▪ Which of these do you think you might need?

40
Portfolio Management - Choosing the Right Projects

With so many projects to choose from, how do you select the right ones? It may sound
obvious, but choosing the right projects will increase the likelihood of project success.
In fact, the more time you spend choosing the right project and setting a project up
for success at the very beginning, the greater the likelihood of success at completion.
This is one of the primary roles of portfolio management within an organization. The
other role is the prioritization and allocation of resources. A portfolio refers to all
approved projects that an organization is completing, or planning to complete.
A program is a group of projects related in some way. They may be delivering different
parts of larger projects, i.e. the Airbus program of projects, or they may each draw on
similar resources, i.e. all using the same engineers. Therefore, the primary role of the
program manager is to manage potential conflicts and interdependencies between
the projects to ensure that they all perform as expected.
The following diagram illustrates an organization with eight projects as part of its
portfolio, and of these eight projects, three of them are part of a program.

Figure 6: Relationship between portfolios, programs and projects

So, before any project makes it into the approved portfolio of projects it must go
through a rigorous project selection process.
Fundamental to this is the ability to apply some professional filters to your project
selection process to ensure the good ones get through and the bad ones are rejected.
This process should be part of your practical project management methodology as it
is the first step in a successful project.
The project selection process starts with all potential projects having to go through a
rigorous, repeatable and appropriate selection process. There are a few exceptions. In
the normal course of business there may be some emergency or legislative compliance
works that must be done that meet none of the following criteria. There are also

41
projects that are supported by someone with enough political power to shortcut a
good selection process. A high percentage of these ones end in failure though.
The project selection process is usually captured in a business case prepared for a
project. The business case provides a robust way for an organization to assess the
merits of each project it might do, and make decisions in a standardized and
transparent way. If an organization is not using a business case it is probably allowing
politically motivated or pet projects, to be done. These projects have a much higher
chance of project failure so think carefully before agreeing to manage one.
The business case should contain the following information:
▪ A description of the issue or opportunity that has arisen
▪ A description of why this project is needed
▪ How will the project solve the issues or opportunities
▪ What are all the potential ways to address or solve the issue (include an
assessment of the ‘do nothing’ approach)
▪ What is the recommended solution, outputs and expected outcomes
▪ How does the recommended solution address the issues or opportunities
▪ What is the timing of the project
▪ A description of known risks to the project
▪ A calculation of the financial and/or non-financial returns to the organization
It is not uncommon for a project manager to be given the project after it has passed
through this process. In a perfect world, the project manager would be involved in this
process in some way. However, in the absence of a perfect world, if you find yourself
receiving a project to manage, make sure you ask if it has been through the project
selection or business case process. Perhaps think twice about accepting a project that
hasn’t been through the process as the chances of project success are less than one
that has been through the process.
The following diagram shows the process that projects can go through from being
part of all potential projects through to being included as part of the approved
portfolio of projects.

42
Figure 7: Project selection and prioritization

Checking Strategic Alignment

We begin this process with a list of all the potential projects that we could do or that
have been suggested to us. The first step that any project must go through is to check
whether it helps the company achieve its strategic goals. If it doesn’t, then the
company shouldn’t support it because successful projects should be viewed as
strategic enablers. It won’t advance the organization, and the organization likely lacks
the core competencies to complete the work. If you don’t have a defined strategy you
can instead use this filter to assess whether you have the necessary skills to complete
the work or whether you’re just tempted by the chance to make a quick dollar. Resist
this temptation! You will not have the necessary ability or motivation to do justice to
the project and it’s a sure fire way to increase the chance of project failure.

Financial Justification for a Project

Once you have ensured that all potential projects meet your organization’s strategies
goals, skills, and abilities, the next step is to consider whether the project meets any
pre-determined financial filters. The process of justifying a project from a financial
point of view is important for two reasons.
The first is to ensure that the investment you are making will provide a satisfactory
return. Does your organization have a requirement for a certain level of financial

43
return? If it does, you need to ensure that all projects meet this. If a project doesn’t
meet strict financial criteria, it must meet some other strategic imperative, such as
generating future work or contributing to charity. However, you cannot do these
projects forever or you will go out of business fast.
The second reason is that you need to keep in mind that it isn’t the client financing
the project. Your organization will pay wages and salaries, materials, and any other
costs until the client pays the first invoices sent out. This means that you need to know
how this project is going to affect your company financially.
There are many ways to assess the financial viability of a project and it is not
uncommon to require that a project be assessed against several financial metrics. Here
are six of the most commonly used financial assessment tools. The first three are
relatively easy to use and set up, while the second three are a little more difficult (i.e.
you are going to need a software spreadsheet to do the calculations); however, the
results tend to be a little more thorough.
▪ Payback period is a nice easy one to use. It is simply a calculation of how long
it takes to earn back the investment you’ve made. You decide on an appropriate
time period, and if the project earns back the investment within that time
period it’s good. If it takes longer than that time period to earn back the money
invested then it’s not a good idea.
▪ Profit margin is also one of the more popular ones as it is nice and simple. The
company sets a required profit margin to be made on all projects and simply
doesn’t do any projects which fail to make that profit margin. Margins are
identified across industries so it’s probably best to check with your accountant
to set this.
▪ Opportunity costs also need to be considered. If you decide to do this project,
what other projects are you not able to do? If the value of other projects is
higher than this particular project you may wish to reconsider which ones you
do.
▪ Present Value is the value in today’s dollars of money in the future. Which
would you rather have - $10000 today or $12000 in two years’ time? That
process you just went through to make your decision meant calculating the
present value of $12000 in today’s money. If the $12000 is worth less than
$10000 in today’s money then you would take the $10000 today. If however
you felt, or calculated, that you would rather have the $12000 in two years’ time
then it is worth more than $10000 today.
▪ The formula for calculating present value is:

Where FV equals the future value of cash flows, r equals the interest rate, and
n equals the number of time periods. So, if we wanted to calculate the value of
$12000 in two years using a discount rate of 10% then the formula would be:

44
 PV = (12000/((1 + 0.1)2)
= (12000/1.21)
= $9917.36

So, at a discount rate of 10% the $12000 in two years’ time is worth $9917.36
in today’s dollars.
▪ Net present value (NPV) is the value in today’s dollars of all future cash flows
for a defined period of time. In some projects you are spending money now to
make money in the future. You want to assess what that future money is worth
in today’s dollars. To do this you take your cash flows, in and out, over a
predetermined period of time and apply a discount rate to them. The discount
rate is usually linked to the level of required return that you, your shareholders
or your accountant has determined is needed to keep the organization
profitable.
If the NPV is positive, it means that the money you are investing today will
generate future cash flows that are earning the required amount of return. A
negative NPV means that the future cash flows are worth less than what you
are investing in today’s dollars and the project may not be worth doing. NPV
calculations between two projects can often be used to select which is the more
appealing project; a rough rule of thumb is that the project with the higher NPV
is the better one to do.
To calculate NPV simply add up all the Present Value calculations for the
expected income and then subtract this present value from the initial spend.
The formula is:

For example, if you project had an initial spend of $100000 in the first year
(remember that this is a negative number), and was supposed to generate
income of $30000 in the second year, $35000 in the third year, $37000 in the
fourth year, and $39000 in the fifth year with a discount or interest rate of 10%
the Net Present Value of your project would be $10634.52.
▪ Return on investment (ROI) is a similar concept to the profit margin discussed
above; it just has a little more accountant-speak around it. The profit margin
generally refers to the net profit made after costs, tax and depreciation have
been removed from the equation. Return on investment can mean the gross
financial return on the investment, expressed a percentage of the investment
made. Once again, you, your shareholders or your accountant should
determine what an appropriate level of required ROI is.
▪ Internal rate of return (IRR) is perhaps the most difficult to calculate but
arguably gives the most accurate financial assessment of a particular
investment a project. It is the annualized and compounded interest rate that

45
 the investment will return. So you need to know the time period, the return on
investment and how to calculate the compounding effect over that time period.
Obviously, a good IRR will be at a minimum more than what you can get by
putting your money in the bank.
As you can see, there are both simple and sophisticated ways to assess the financial
performance of any project you are going to do. It is up to you to decide what the
most appropriate means of doing this is. Don’t get into the habit of simply going
ahead with a project simply because you think, or feel, it will make money. If you don’t
do a thorough and appropriate financial analysis of your projects there is a great
chance they will lose money and eventually you will go out of business.
Additionally, making sure you have completed a robust financial justification process
ensures that you organization has approved investment of its money and will pay the
bills. Remember that often you or your organization has to outlay quite a bit of money
before the first invoices are generated and paid. So having a robust financial
assessment process means less risk to you and your money.

Non-Financial Justification for a Project

In addition to financial criteria, there are several non-financial criteria that can be used
to justify proceeding, or not proceeding, with a project. Typical non-financial criteria
include market share, putting in place barriers to market entry, reducing reliance on
suppliers and to provide for community development or support.
Health, social services, not-for-profit organizations, wildlife conservation projects and
even the Olympic Games are all examples of organizations having non-financial
criteria to help in their decision making process about which projects they undertake.
It is your decision what mix of financial and non-financial criteria you use in your
project selection method. The more professional the criteria are, the greater the
chance of project success.

Prioritising Projects

It may be that you have a few projects that make it through the selection process and
all pass with flying colours. However, it may be that you don’t have resources to do
them all, or need to rank them somehow to determine which ones are the most
important to you. This is the process of prioritizing your projects. To start with you
need to decide which metrics are important to you in choosing between them.
The criteria for ranking them are highly subjective. Most organizations will place a
greater emphasis on financial return. But there are other metrics to use, such as
reputation, difficulty, future growth, repeat business and market share. You may also
want to give each of your selected assessment criteria a different weighting so you
can place a different emphasis on different elements.

46
At the end of this process you want to have a documented list of all the projects you
are doing ranked by order of importance to the company that everyone can see. It
also helps when new projects join the list to put them in their correct position
according to the professional assessment criteria you have developed. Doing this
correctly will help you allocate time, energy and resources to the most important
projects.
The following diagram shows an example of a weighted attribute project selection
process showing the areas being considered as important when prioritizing projects,
the score each project gets for each area, the weighting given to each area and the
total score showing that Project C has the top priority despite Project B having the
greatest financial return.
Weighted Attribute Project Selection

Figure 8: Example of weighted attribute selection

After you have done all of this project selection work to choose the projects that make
it into your approved portfolio of work you may end up with something that looks like
this table. Hopefully you have some software to help you do this, but if not you can
use simple spreadsheet software as well.

Project Name Priority Value Status PM Due Date

Project Delta 1 $1,549,870 Approved Liam October 2024

Project Unicorn 2 $450,870 Approved Mursal July 2023

Project Beta 3 $3,834,900 Approved Malkiat January 2025

Project Popcorn 4 $3,472,800 Approved Alicia September 2023

Project Alpha 5 $173,000 Approved Taika July 2024

Project Sunshine 6 $356,000 Pending Jacinda TBC

Project Omega 7 $780,500 Pending Mai TBC

Project Bluesky 8 $2,350,750 Deferred Whina TBC

TOTAL $12,968,690
Table 1: Example of list of projects in a portfolio

47
Benefits Management

Did you know that, in my opinion, no project ever approved has been approved on
the basis of the thing, output or deliverable it will build? Let that sink in for a moment
because for some people that simply doesn’t make sense. Surely that is the entire
reason for a project – to build a thing, output, or deliverable? What other reason could
there be?
Well, it isn’t, never has been, and never will be.
The reason for the project is to deliver the expected, and desired, outcomes and
benefits. The thing, deliverable, or output is simply the preferred method of achieving
these outcomes and benefits. Too many people get fixated on the deliverable and
there are handshakes, and congratulatory notes, and celebrations of successful
projects one the deliverable appears. Then everyone turns their attention to the next
thing to be built, and that is major contributor to project failure.
Project success occurs when the deliverable produces the outcomes and they in turn
deliver the expected and forecast benefits. If you want proof of this simply refer back
to your business case, project initiation document, charter, mandate, work order or
whatever it is you call the document that captures the reason for the decision to start
the project. Sure it mentions the deliverable but it should make it clear what the
expectations are around outcomes and benefits.
And this is what Benefits Management is so important to successful project
management.
But here’s the thing, there are three important steps to successful benefits
management and if you don’t do all three, don’t bother doing any of them. Here are
the 3 steps to successful benefits management:
1. Benefits Estimating and Forecasting – this first step is focussed on justifying
the investment in any project. It’s outlining the expectations about the
outcomes and benefits the organisation is seeking, the costs and risks of
achieving them, and then choosing the deliverable best placed to help these
be achieved. These can be strategic, operational, financial, non-financial or
other forms of outcomes and benefits that are important to the organisation.
The key thing is to document them, make them measurable, define roles and
responsibilities early for who, how, when, and what?
2. Benefits Tracking – once the benefits have been defined then it’s time to turn
your attention to tracking their delivery throughout the entire project lifecycle.
Yes, even while things are under construction you should be checking that what
you are building is still going to deliver the expected outcomes and benefits.
This information should be part of your regular reporting. I’ve always said that
there is a possible theoretical situation where you may find the deliverable you
are producing is wonderful and shiny and slick and perfect, but you realise it
will no longer deliver the expected outcomes and benefits. In this case you
should be prepared to change it or cancel the project. The achievement of these

48
 outcomes and benefits is the sole reason for the project. Please let me know in
the comments if you have actually encountered this.
3. Benefits Realisation – the final of the necessary three steps to benefits
management is benefits realisation. Despite it being the final step you don’t
leave planning for it until the end of a project. In fact, quite the opposite. You
should be defining who is responsible for this, when it will be done, what
metrics will be used, what reports will be produced, the time period to ensure
full and permanent realisation etc right at the beginning of the project. You
should also make sure that appropriate levels of money, time, and resources
are allocated to complete the work. Remember that different projects have
different time horizons for realisation of benefits – some realise benefits during
the project, some upon the deliverables being completed, but many
organisations complete projects that can’t check benefits realisation for
significant periods of time after the deliverable appears. I’ve often found
difficulties for organisations that do not realise their benefits for months or
years after the appearance of the deliverable. The main problem seems to be
getting agreement on who will be responsible for completing benefits
realisation. Is it the project manager, the asset owner, the product owner, the
client, the PMO, the regional manager, Bruce from accounts? The answer to this
question is unique to the organisation but this often means that it is put into
the “too hard” basket. If you don’t do this essential part of benefits
management, you will never know if you achieved the expected and forecast
benefits and if you don’t do benefits realisation you are giving people
permission to write whatever they want in those project initiation documents.
So, stay focussed on outcomes and benefits, define what they are and how you will
check that your decisions are achieving them, and stop being primarily focussed on
the thing, output or deliverable.

The Project Charter

Once you have put all your potential projects through some sort of appropriate
selection process you need to document the formal approval. This is done via a project
charter, which is the founding document or birth certificate for a project. It proves the
project has support and approval and all projects, irrespective of their size, should
have a project charter. There are other names for this document such as the project
mandate, project initiation document (PID), work authorization, business case and
even the contract. The thing they all have in common is that the are the document
that authorizes the project.
For a large project, a project charter may be a large and comprehensive document,
perhaps even an exhaustive business case. For small projects, the project charter can
be as simple as a work order with the necessary points acknowledged and signed off.
It usually does not have the same level of detail as some of the documents yet to be
prepared such as the scope statement and project budget but it does contain enough
information to commit your time and money to the project.

49
There is also a symbolic aspect to having a project charter for every project. It
demonstrates a commitment to practical project management. It is also important to
have the project manager involved in preparing the project charter. Having someone
else prepare it and get it signed off then presenting the project manager with it will
often result in missed information, poor initial estimates and lack of commitment to
the project right from the beginning. At the end of day you decide how detailed your
project charter will be but you must ensure that all projects have one.
These are some of the questions a project charter can answer:
▪ Does the project align itself with the organization’s strategic goals or its core
competencies?
▪ Does it meet the necessary financial requirements?
▪ Who is the client?
▪ Has the client agreed to this project charter?
▪ What is the known scope of work at this stage?
▪ What is the known budget for the project at this stage?
▪ What are the known time constraints at this stage?
▪ Who will the project manager be?
Use these questions to help put together your own unique and appropriate
professional project charter.

Closing Your Project

All projects must be formally closed in a professional way. Just as you have a project
charter to prove the project exists and has support, you need a project closure process
to prove it did what it was supposed to do, bills have been paid and that energy and
resources will no longer be allocated to it. It is probably fair to say that most projects
aren’t formally closed. This is for two main reasons.
The first is the absence of a defined and documented closure process. The second is
that, by the time a project is getting close to closure we are usually drawn onto other
projects that are just getting started, or are in the middle of execution and they
demand our attention. This inattention is permitted because formal project closure is
seen by many as a luxury rather than a necessity.
There are some key elements of a project closure process; these should all be defined
in the planning stages of a project and not left to the last minute. Take the following
key elements and put them into your own professional project closure process in the
form of a documented process and a checklist for people to use.
▪ Deliverable acceptance: means getting sign-off from the client and other
stakeholders that the project has delivered the product or service it was meant
to and that it meets the documented specifications.

50
 ▪ Financial closure: is the process of paying all the bills that need to be paid and
making sure all your invoices are generated, raised and paid in a timely manner.
▪ Contractual closure: means making sure that all contractual conditions have
been met and that each party to a contact is happy to sign off that it is
terminated.
▪ Reassigning resources: means making sure people who worked on your
project have other work to go to.
▪ Lessons learned: is perhaps one of the most valuable parts of a project closure
process and in fact of the whole profession of project management. It is the
process of taking a look backwards at all the successes and failures on the
project. It involves documenting them and their root causes and storing them
for future project managers to use so they can copy your successes and not
make the same mistakes you made. A great tip if you are a project manager
and have just been assigned to a project is to go and read the lessons learned
from similar projects to give you a head start on your project.
▪ Post-implementation reviews: need to be done sometime after the project
has stopped working. Many people simply assume that the project will meet its
intended goals simply because it delivered the required and specified
deliverable. There is, however, real value in coming back after some time has
passed and checking with project team members, clients and other
stakeholders about whether or not the product is doing what it was supposed
to do. What you learn here will help you deliver better projects in the future. A
specific form of post-implementation review is benefits realization. At some
point there needs to be an assessment of whether the intended outcomes, not
outputs, of the projects were delivered and whether the intended benefits were
realized. This is the main focus of a benefits realization exercise. The best
document to have in order to complete this successfully is the original business
case that outlined the intended outcomes and benefits. Use this document,
gather some performance related data and then go and check with
stakeholders.
The easiest and most convenient way to capture this process is simply to prepare your
own project close out checklist describing what must be done, the order it must be
done in, and who has authority to formally sign off on project closure. You can even
have one single checklist as part of your project management methodology and when
you start a project you note the items that your project is expected to complete as
part of its project closure.

OPINION: Stop Reinventing the Wheel

Why do people insist on making the same mistakes over and over again? Why do project
managers not take the time to learn from the experience of others and also to record their
own experiences for the future?

51
 I dream of a perfect project management world where every time a project manager is given
a new project to work, they spend those first few hours, or first day, sitting somewhere reading
lessons learned from past projects learning what the previous project manager of the team
did well and also learning but they didn't do so well. Imagine a world where you can then
repeat their successes and avoid their failures. These lessons learned could be stored in a
central database or library and be available as hard copy or a searchable electronic version.
Imagine reading about the experience of others in relation to choosing the right projects,
getting the right project team members, defining risks on a project, accurate time and cost
estimating, dealing with stakeholders, quality issues and any other aspect of the project. You
would learn a lot and also get a real head start on project planning. If you don’t do it, you are
condemned to reinventing the wheel again and again.
Gathering lessons learned as a relatively easy process. You can start to do it at any point in a
project; you don't need to wait for the end. You can do it formally through structured
interviews, surveys and feedback sessions. You can also do it informally through your own
observations. Obviously in order to do it successfully you need to plan to do it along with all
your other project activities, and as such you need to have time, and perhaps money, set aside
to carry out the work associated with gathering, documenting and storing these gems. The
cost to any project of doing this work is easily offset by the direct savings and efficiencies
gained on both future projects and an overall increase in organizational knowledge, wisdom
and efficiency.
In addition to the lessons learned gathered during and at the completion of the project, one
of the most underrated pieces of lessons learned is the post implementation review which in
my experience is just not done often enough. The real value in completing a post-
implementation review is to revisit the project some time after it's been completed and you
check whether it did it achieve the things that you thought it would achieve. Too many people
make the assumption that delivering the intended project output results in the planned
outcomes. A simple post implementation review conducted 6 months later will reveal whether
it did or not, and contribute to your future project selection, planning and execution.
So, start recording your lessons learned right now. Sit down and start a document and add to
it over the course of your project. Encourage your colleagues to do the same and over time
you will build up an impressive collection of data that will help increase the chances of project
success.

Managing Project Changes

Throughout the life of your project there will be requests for change, some small and
some large. Some change requests will come from team members, some from clients
and some from other stakeholders.
No matter what the size or the origin of these change requests is, ALL changes to a
project MUST be properly assessed and documented. There is no other place in this
book where I deliberately emphasize two words like this. This is because perhaps the
greatest single cause of project failure is undocumented project change.
Sometimes it seems easier to just get on and do the new or changed work, rather than
spend time documenting and getting it all formally approved. Sometimes we are just
far too nice for our own good and someone asks for something that appears to be a
52
small inconsequential change that probably is small and inconsequential. We don’t
want to cause a fuss and so we just get on and do the new work. All of sudden you
are doing work that isn’t documented and included as part of the official scope
statement.
To be honest, there are plenty of times this approach will not cause a problem.
However, there are just as many times when serious problems will arise from this
approach of undocumented changes. These problems include arguments, unpaid
invoices, disgruntled employees, customers who don’t return, and possibly even
litigation.
The solution to this is to put in place a professional change control process, one that
encourages changes to be recorded in an appropriate manner and results in all
changes being documented and assessed in some way.
For some changes, this means a simple saved email recording a verbal agreement
made. However, for other change requests, there will be documentation to fill out and,
if the change is big enough, a new business case. I recommend having a staged change
control process that has a defined process for simple change requests and a more
comprehensive process for larger change requests. Keep in mind that all times on a
project you must always be delivering to the original scope of work PLUS all approved
changes.
Having a defined and documented change control process that all project team
members are aware of will ensure everyone knows what is expected of them. This
effort in managing project changes will result in increased chances of project success.
Make your change control process easy to understand and use. Make any associated
documents easy to access, store and retrieve. Keep a log of all change requests made
and what the outcome of each was. Some will be approved, other will be declined.
The following diagram shows an example of a change control register.

Figure 9: Change control register example

Also set out who will document the change requests, who will assess the change
requests and who will make the decisions. It is not uncommon for project managers
to be given delegated authority to allow them to make on the spot decisions regarding
53
smaller change requests. Larger change requests may have to be submitted to senior
management, the client or a change control board made up of several people.
You may also want to document the levels of delegated authority that project team
members have to make decisions on change requests. It simply isn’t necessary for all
changes have to go to some sort of change control panel or board that meets every
week or month. The project will just move too slowly. Appropriate levels of delegated
authority mean decisions can be made faster. However, having a path of escalation to
ensure that larger change requests are considered by senior staff or management
makes sure that larger changes that have potentially greater impacts upon a project’s
success are given greater consideration by people with more experience.
The following diagram shows an example of a simple change control process.

Figure 10: Generic change control process

Documenting change on a project is an important part of configuration management.

Configuration management is a system whereby you identify all the plans and the
versions of those plans, cost accounts, parts and software to ensure you are always
using the correct element. I have seen some horrendous mistakes made on projects
because everyone was using different versions of plans or processes, and a simple
version control system would have prevented it from happening. Configuration
management is version control and more and it can include the following:
• Document control and numbering
• Numbering of parts and material used
• Unique identification of each requested change
• Cost accounting codes
Configuration verification and audit is the process of checking that the configuration
management system is being used correctly and that all changes to it are recorded
appropriately.

54
Configuration management activities provide visibility and control of project
elements. It provides accountability, reproducibility and traceability for all parts of a
project. Here are some examples of configuration management elements in your
project:
• Change register numbering
• Cost accounting systems codes
• Work breakdown structure (WBS) numbering
• Parts and materials numbering
• Version control (i.e. version 1.0, version 1.2)
• Document control (i.e. Draft, for comment, for construction)
• Baseline version
• Software releases (i.e. version 1.0, version 2.0)
• User documentation
• Maintenance documentation

You can see that your configuration management systems includes many different
subsystems all designed to make sure you are tracking and using the right account,
document, part, template or process.

55
Review Exercises

1. What are the key elements that should be incorporated into your project selection
process?

1.

2.

3.

4.

5.

2. What are the key elements that should be in your project charter (or whatever it is
you call your project initiation document)?

1.

2.

3.

4.

5.

56
3. What are the key elements that should be incorporated into your change control
process?

1.

2.

3.

4.

5.

57
Chapter 4. Managing the Project Scope

At the conclusion of this chapter, you will understand how define the scope, the
importance of properly defining the scope of the project using a variety of tools, and
the value of a well-defined scope statement in estimating time, cost, and risk. This
chapter also covers the creation of a work breakdown structure and the many areas in
which it can be used.

What is the Project Scope?

The scope statement is the most important part of the project. It is one of the key
elements that I believe are mandatory for all projects. The scope statement defines all
the work that is to be done as part of the project. Just as importantly, it also defines
the boundary of the work that you will not be doing. Many people develop a scope
statement and describe only the work that is going to be done. Very few
disagreements are caused by what is described; rather, most arise as a result of the
assumptions made about what was not described and documented in the scope
statement. If you don’t describe exactly what is in and what is out of the scope of work
then people will make assumptions, and assumptions lead to arguments. So spend
some time getting it right. Once you have a clear scope statement, don’t make the
mistake of doing any work that isn’t properly documented and included in the scope
statement. That is a sure way to increase the chances of project failure.
Developing your scope will generally be quite an iterative process; you may only be
able to define what work you are doing in the immediate future because the final
scope relies on the work you are currently doing. If this is the case, you will need to
keep checking with the project team members and the client that the scope is properly
and appropriately defined.
You can work on the scope statement yourself but it is generally essential to get input
from the team and other stakeholders. You may also be able to refer back to previous
mistakes and misunderstandings as a way to figure you what makes an appropriate
scope statement for the types of projects you work on.
Your project scope can include any known project outcomes and objectives, the
expected deliverables, any known milestones throughout the project, a description of
the technical requirements of the product, the exclusions or work not being done and
any other aspects of the project that need to be documented. If you are putting
together your own scope statement template you should make sure it contains the
most relevant of these.

Product Scope and Project Scope

Most people, when asked, will tell you that the main work of the project is to produce
a product. This is only partly true. There is a lot of work being done in a project and
only a portion of it is directed at producing the product.
58
The project scope is the description of all the work to be done as part of the project.
It is more than just the description of the product to be delivered. It includes a
description of all the planning, executing, monitoring and controlling, and closing
work that also needs to be done. There is work described in some of your other project
management plans that needs to be done that isn’t around the product scope. You
have risk management work, communications work, estimating work and quality
management work that all needs to be done as part of the project and it all needs to
be described in some way in the project scope.
The scope of the product is a description of the features, functions and specifications
of the product or service to be delivered. The product scope is a subset of the project
scope as shown in the following diagram.

Figure 11: Product scope as a subset of project scope

Describing Project Work

There is a generally accepted hierarchal set of terms for describing the work to be
done in a project. You may use some of these terms already; if you don’t, you may
want to start using them to be able to differentiate between various aspects of project
work. With a project where the scope is worked out incrementally, this terminology
may describe different stages in the project. There are some projects where the entire
scope of the project is known and agreed upon right at the beginning, which would
bypass several of these stages.
The following diagram does not describe a linear process that must be followed.
Instead, it describes the terminology that can be used to describe the scope of work
at different stages in its development, from a low level of definition to a high level of
definition.

59
Figure 12: Different levels of scope definition

The statement of work (SOW) is a high level narrative description of the work to be
completed in the project. It is usually done right at the start of a project to describe
what is known at that point about the work. The SOW can be used to help describe
the work in a business case or a project charter, but is not defined enough to complete
the project without further definition.
The project charter contains enough scope description to formally authorize the
project. For some projects, this will be required to authorize money being spent on
fully defining the scope of the project. For others, the project charter may already
contain a full scope description.
Requirements are gathered from clients and users and help provide further definition
to the low level of detail in foundational documents like the statement of work and
the project charter.
The preliminary scope statement is the next stage in an iterative process of defining a
full scope.
The scope statement is the full and complete description of the work to be done, and
not to be done, as part of the next stage of work or even the entire project.
Development is often iterative based on the next stage, time frame or budget of the
project.
The work breakdown structure (WBS) takes the description of the work to be done
contained in the scope statement, and breaks it down into its component parts.

60
Defining the Scope of the Project

You can use a variety of methods to collect and collate the elements of a project scope
statement or any other, less detailed scope description. Your choice of tools will
depend on your unique type of project.
The easiest place to start is with your own knowledge of what the scope will be,
particularly if you have experience in this sort of project. If not, go ask others with
expertise in the area. Keep in mind that the scope includes more than just the product
description; it includes all the work to be done as part of the project and all the agreed
requirements of all stakeholders not just the client so you may ask people with
expertise either in this type of project or in the product itself.
You can ask them for their requirements in person, by email, by survey, by phone or
by a facilitated brainstorming workshop. However you choose to solicit the
information, make sure you feed back your understanding to the people with whom
you’re consulting so you can be confident you’ve got it right. This work will produce
your requirements documentation which clearly sets out the requirements for each of
the stakeholders. You may also wish to produce a requirements traceability matrix
which maps each requirement back to a foundation objective of the project.
You should always discuss with the client what their expectations of the scope are.
Make sure you discuss and document all inclusions and exclusions with the client.
Don’t assume that, because you’re a technical expert and you understand what is
normally in and out of a scope of work, that your client will see things the same way.
As a non-technical person, they may make assumptions about work that is in-scope,
and it is these assumptions that cause misunderstandings and arguments.
You can use your project team members, as they may have done this sort of work
before and will be familiar with what is required.
One of my favourite ways to define the scope of work is to go back to other similar
projects that have been completed and examine their scope statements and their
lessons learned about what they did well and not well in defining the scope.

OPINION: Outputs versus Outcomes

One of the greatest challenges we face as project managers is a focus on outputs over
outcomes.
Generally, projects are initiated to deal with a particular outcome. A problem or opportunity
has been identified and the project has been established to provide a solution. The objective
is that the outcome will be achieved and the problem resolved or the opportunity taken.
As part of the planning process of any project we identify an output, or outputs, which can
deliver that outcome. We then take the steps as project managers to deliver that output but
what often happens is we fail to check whether the output will still deliver the expected
outcome.

61
 Don’t get caught up in the assumption that your project output will deliver the outcomes it
was supposed to do. Stay focused on the outcomes during your project and be prepared to
modify your outputs to ensure that you reach your intended outcomes.
So what’s the difference between outputs and outcomes?
If you work in the IT industry the outcome may be a better user interface leading to greater
customer satisfaction. A project is established to develop a software output that is intended to
deliver the outcome. At the time the project is initiated it is clear that with the information
available that the output will deliver the outcome. But what if new information is discovered
about ways to improve customer satisfaction? That is the time to revisit the output and see if
it is still the best way to deliver the outcome.
If you work in the construction industry you may have identified that a particular public
gymnasium building with a certain floor area, height and fit out will deliver the expected
outcome of greater community involvement in recreation and greater levels of fitness. This
should be your focus, not the building. You should always be prepared to examine your project
from the point of view of the intended outcome and question whether the output is still the
best way to achieve it.
One of the most important roles a project manager can play is to focus on the intended
outcomes and be an advocate for this in their project. At times it may require some changes
to your intended outputs but at the end of the day a focus on outcomes over outputs will result
in a greater chance of project success, happier clients and an improved reputation.

The Work Breakdown Structure (WBS)

Once you have your scope statement documented, you can use it to start the process
of estimating the time you will take to complete the project, the cost of the project
and any risks associated with the project. The best way to do this is to break the scope
down into its component parts, often called work packages. Once you’ve gotten down
to that level of detail, you can accurately assign time, cost and risk to each of the work
packages. This process is called decomposition and can be graphically represented by
a Work Breakdown Structure (WBS). The WBS is often called the backbone of a project
because without it you will struggle to fully define the scope, prepare accurate time
and cost estimates, estimate resources needed, manage risks and check progress. It is
general accepted that all projects should have a WBS.
The process of decomposition can be done quickly by the project manager and people
experienced with the type of work being done, and by using lessons learned from
previous projects. You can do it formally through a series of questionnaires or
brainstorming sessions. You can also do it more informally through an iterative series
of emails or conversations.
When it comes to the question of how far you decompose each element of the WBS,
it’s essential to be professional. Your target level of detail is that at which you can
reliably estimate time and cost for each work package. Also, the work package is still
a deliverable, not how to do the work. There is little benefit gained from the extra time
and effort taken to decompose any further.

62
Once the WBS is completely decomposed, it should capture all the work contained in
the current scope of work. Note that the WBS does not put any of the activities into
any sort of reliable sequence. This step comes as part of the project scheduling work
and it will become the first piece of information you need to successfully build a Gantt
chart.
The WBS can only be developed as much as your scope statement is developed. There
may be portions of your WBS that refer to work some time off in the future and aren’t
yet defined. There may also be portions that rely on another part of the project scope
and can’t be fully defined until that part is complete. These areas where there is less
definition are also areas where your cost and time estimates will be less accurate.
You may have a different WBS for each subsequent iteration of your project scope or
for different phases or stages of a project. IT projects tend to have very iterative scope
development, working on small chunks of the scope at any given time. Construction
projects tend to have the ability to define more of the scope and as such only have
one large WBS defining the entire project.
The following diagram shows part of a simple WBS for a new house project.

Figure 13: Example of a WBS

Those numbers in each box, or “node,” are important. You can use them to identify
each of the work elements and to estimate the cost of completing each one. Also, if
you are charging costs to your job you can use those numbers as cost account
numbers to charge work done as part of that work package. This will give you much
greater transparency over exactly where the money has been spent.
A useful tool to accompany the WBS is the WBS dictionary. Because the WBS shows
only limited information about each work package on the nodes, it is worthwhile to

63
have a dictionary that has further and more detailed information about each of the
work packages.
Typically, a graphical WBS node will contain the work package name, the WBS code,
and in summary form, the duration, cost and resources assigned to the work package.
The lengthier description in the WBS dictionary will contain much more information
about the work package for those who wish to delve a little deeper.
For example, this is a typical node on a WBS showing summary information including
the WBS code, a brief description of the deliverable or work package, a cost, duration
and the number of resources required:

Figure 14: Example of WBS Dictionary

You can see it has some great summary information but a WBS dictionary entry for
the same piece of work might read something like this:
1.3.2.1 Plumbing: This work includes all the internal work to provide water plumbing
throughout the house. It excludes any work related to provision of gas reticulation. It
also excludes any work related to the provision of external irrigation. The cost for the
work is estimated at $13500 based upon the contract provided on 13 January 2014. The
estimate was completed using parametric estimating, expert judgment and published
estimating data and is valid for 3 months. The work is forecast to take 6 days to complete
and it is assumed that the work that can be completed without interruption and that 2
plumbers will be available the whole time.
As you can see, this entry in the WBS dictionary provides much more detail.

Defining the Scope in Agile Projects

Defining the Scope in Agile projects can be a little more difficult due to the highly
iterative nature of these projects. You can start with requirements in the same way you
would for building a WBS, and turn these into User Stories, which then form the basis
for a prioritized backlog of work to be completed. A key element of Agile scope
definition is that you will do it multiple times in short bursts. This does lead to some
difficulties in estimating the total time and cost for the project. Two main ways to
capture the known scope are User Stories and the Kanban Board.
User stories are short, simple descriptions of a feature told from the perspective of the
person who desires the new capability, typically the user or customer of the system.
They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >
User stories are often written on index cards or sticky notes, and arranged on walls or
tables to facilitate prioritisation, planning and discussion. As such, they strongly shift

64
the focus from writing about features to discussing them. In fact, these discussions are
often more important than whatever text is written.
A Kanban board is an excellent way to capture both the work to be done and also the
progress on that work. You can simply use post it notes and a wall, or you can opt to
use one of the many pieces of software that exist to do this. The following figure shows
an example of a Kanban board.

Backlog In Peer Review In Test Completed Blocked

Progress

     
    
   
 
 


Figure 15: Kanban Board Example

65
Review Exercises

1. What are the key elements that should be in your PROJECT scope statement? Make
at least one of these an exclusion.

1.

2.

3.

4.

5.

2. What are the key elements that should be in your PRODUCT scope statement?
Make at least one of these an exclusion.

1.

2.

3.

4.

5.

66
3. Use the following blank WBS (or draw your own) to show what a typical Work
Breakdown Structure (WBS) for your projects look like?

67
Chapter 5. Estimating Cost and Time

At the end of this chapter, you will have an understanding of tools and techniques you
can use to estimate both time and cost on a project. You will also understand the level
of accuracy each tool has. Because both cost and time estimating use similar
techniques, they are grouped here in one chapter. Your estimates for cost will go on
to form the foundation of your project budget, and your estimates for time will form
the foundation of your project schedule. These two topics are covered in the following
two chapters and build on the information from this chapter.

The WBS & Cost and Time Estimating

There are several estimating techniques that you can use to accurately forecast the
duration and cost of any project. However, remember that project estimating is an
iterative process that is only as good as the information you have available to you at
any given time. This information will be in the form of your scope statement; the more
fully developed your scope, the better the estimates will be. Conversely, if your scope
is poorly defined, your estimates will be vague and unreliable.
Your estimates at the beginning of a project, when the scope of work isn’t fully defined,
will be less accurate than your estimates done when the scope of fully defined and
broken down using a WBS. If you are deliberately progressing your project with a
highly iterative process then, once again, your time and cost estimates will only be as
good as the definition contained in the scope of work at that time.
In addition, you may be able to do accurate estimates for the work immediately in
front of you, but your estimates may be less accurate for the work further off in the
distance. Finally, the accuracy of your estimates will be influenced by the accuracy and
detail of your scope statement. The more detailed your scope statement, the more
detailed your estimates are able to be.
If there are parts of your scope statement that are yet to be confirmed or that have
undefined work in them, then the estimates for that work will also lack definition. Since
the most detailed expression of your scope statement is the Work Breakdown
Structure (WBS), using the WBS is the most accurate means of estimating cost and
time.

Quality of Estimates

Any estimate of time or cost is your best guess at what will happen in the future based
on the information you have available today. The more information you have today,
and the greater the level of detail of that information, the better your estimates will
be. We’ve already discussed how the detail, accuracy and completeness of the project
scope are major contributing factors to the quality of the estimates for time and cost.
Now we’ll look at several other factors you need to be aware of that influence the
quality of the estimates.
68
First is the duration of the project, which will affect the quality of the estimates in
several ways. Longer projects may make it more difficult to define the scope in the
future. In addition, the longer the duration of the project, the greater the uncertainty
about external factors such as inflation.
The human factor is an important one, as most estimating is done by people. People
involved in estimating will bring their own bias to their estimates. Some people are
naturally more optimistic or pessimistic than others. The level of experience of the
people being asked to contribute to the estimates will also affect the quality of the
estimate.
Your approach to padding and buffers has an important influence on the quality of
the estimates. People have a natural tendency to overestimate time or cost to give
them enough time to do the task. However, many managers suspect, or know, that
this happens and immediately demand a reduction in the estimates to take account
of it. In reply, people tend to increase their padding so it’s a no win situation. Try to
encourage an environment where people are not tempted to pad their estimates. Try
to create an organizational culture that values accurate estimates that can be backed
up with some data.

Guidelines for Good Estimates

There are some standard guidelines to employ when completing estimating work for
time and cost. Try to use these as a guide for your own estimating activity to improve
the quality of your estimates.
Getting the people doing the work to estimate the work is one of the best guideline
for estimating time and cost for two reasons. The first is that the people responsible
for doing the work know what is involved in completing the work. They are more likely
to know the actual time taken to complete a task or the actual costs associated with
required materials. The second reason to get the people doing the work to complete
the estimates is that it creates buy-in for the estimating process. If you tell someone
what an estimate is for the work they are going to complete they will feel less
obligation to meet that estimate than if they provide the estimate themselves.
If you use several people or sources to complete the estimate, it will have a greater
chance of being more realistic and accurate. This is particularly so when you let the
different parties see the other estimates and have the chance to consider and reply to
different estimates. The process of questioning other estimates leads to more accurate
estimates overall.
Standardize the units you are using for estimates. This is easy for cost estimating when
working in a single currency as you are using dollars and cents, or their equivalent. It
can be a little more difficult when working in multiple currencies. When it comes to
estimating time, it is best to choose which of the possible units you are going to
provide estimates in. You need to specify whether you require estimates to be in hours,
days, weeks or months.

69
Express the amount of risk or uncertainty in the estimate clearly so that you can make
informed decisions about whether to proceed with that work package, seek further
clarification around the estimate or to look at a different way of completing the work.
Finally, remember to always assume normal working conditions for your estimating
process unless you know of some exceptional circumstances that need to be taken
into account.

Cost & Time Estimating Tools and Techniques

At this point, you may have already done some great work defining the scope of the
project. Inevitably, the next thing people want to know is how long it will take and
how much it will cost. What do you tell them? You could just pick a random number,
or you could choose the highest number you think the client will pay. Unfortunately,
both of these estimating methods are used; they both lead to unsatisfied clients and
dysfunctional, nonperforming businesses. Instead of relying on these methods, there
are in fact several proven ways of estimating both time and cost.
Each of these methods has a different level of accuracy and they all have different
levels of effort and cost associated with them. Generally, the more accurate the
forecasting or estimating technique is, the longer it takes and the more it costs.
However, remember that any process of estimating is simply the process of trying to
forecast a future state based on the information we have at hand now. As such, the
quality of the estimate is related directly to the accuracy of that information. The more
accurate the information we have, the more accurate the estimate will be.
So let’s start by looking at the techniques you can use to do these cost and time
estimates. The techniques in this section can generally be used to estimate both cost
and time. Keep in mind that your total estimates for the project will probably use more
than one of these techniques, giving you a wide range of accuracy in your estimates.
It is always a good idea to include a description of the estimating techniques and the
assumptions you made when providing any estimate for time and cost.
Having a template or a checklist that you use to help with estimating is also an
invaluable tool to make sure you use the selected tools and consider all the variables
consistently. You may also want to consider compiling your own database of estimates
to help future estimating processes and improve the accuracy of your estimates.
As with everything else in this book, the final choice about which estimating
techniques are appropriate for your organization is up to you. Document the ones you
are going to use and the circumstances under which you are going to use them, as
they will form an important part of your project management methodology.
The Ballpark Figure: Effort required is very low, and accuracy is very low (usually).
I’ve included this estimating technique because it is one that is used most often at the
start of a project. It is where you ask someone with some knowledge of the work to
be done what they think a project, or part of a project, will cost or how long it will take.
You can see their eyes roll back a little and then, magically, a number is produced. You

70
would be amazed at the number of people who consider this an accurate estimate.
The thing is, we just don’t know how accurate it is. It may be that the person providing
the estimate quickly used a variety of the tools below, such as parametric or analogous
estimating, to come up with a figure that is surprisingly accurate, or it may be that the
figure a total guess. Before using a ballpark estimate for any significant project cost or
time estimating, make sure you understand the logic behind it so you can understand
how accurate it is.
Top Down Estimating: Effort required is low, and accuracy is low.
Top down estimating is simply the process of assigning a total amount of dollars or
days to a particular project and then apportioning percentages of the time or money
to different parts of the scope. For example, you may decide that the project cost will
be $100,000 based on previous experience; and that 10% will go to design, 30% to
construction and its sub-groups, etc. As you can imagine, this is best used when you
have done similar projects before and can use the lessons learned. In this instance,
this method can be quite accurate. Other than that, it is generally considered a less
accurate technique to use.
Bottom Up Estimating: Effort required is high, and accuracy is high.
Bottom up estimating is a very accurate method, which involves aggregating all the
work packages on a WBS and rolling them up to a total project cost. It does require
you to put in the effort and time to decompose the project scope down into its
component parts and, with this information, estimate time and cost for each work
package. Then once you have added all these up you have a very accurate estimate.
Lessons Learned: Effort required is medium, and accuracy is high.
I cannot emphasize how important previous experience is in estimating future cost or
time. The decision to not use past experience is akin to making a commitment to
repeat the mistakes of the past. Hopefully you have processes in place to enable you
and your organization to collect information from past projects.
If so, you can answer questions like: How long did they estimate it would take, and
how long did it actually take? How much did they estimate the whole project or
elements of the project would cost? How much did they actually cost? These are all
questions that you can answer using past experience. By the way, if you don’t have a
lessons learned process in place then make sure you give this a high priority.
Expert Judgment: Effort required is high, and accuracy is high.
Go and ask the people who know: a simple concept, but one that seems hard to use.
There will be people around who have expertise in doing this work and they are the
people to ask, particularly if you are estimating work you really haven’t done before.
Additionally, there is a whole profession built up around the profession of estimating:
quantity surveying. You will have to pay to use these people but in my experience is
well worth the money spent.

71
If you are worried about elements of peer pressure you can choose to use the Delphi
Technique. With this technique, experts are asked anonymously, usually via email, for
their opinions.
Published Estimating Data: Effort required is medium, and accuracy is high.
Along with quantity surveying, which is a whole profession built up around estimating,
there are plenty of sources available for you to access published estimating data. You
own organization may hold information about particular rates or time periods. You
can also pay for access large databases of estimating data.
Analogous Estimates: Effort required is medium, and accuracy is medium.
Analogous estimates involve taking a similar project or work package and
extrapolating from that the new work to be done. Therefore, if you know of a similar
work package from the past that took 10 hours to complete, and the new work
package is twice as big, then your estimate would be 20 hours to complete.
Parametric Estimates: Effort required is high, and accuracy is high.
Parametric estimating is one of the most popular and also most accurate estimating
techniques. It involves taking a known amount of work to be done and multiplying it
by known rates of dollars or days. Therefore, if you know you have 10kms of road to
build and each kilometre of road costs $1,000, then you simply multiply the two
together to get an estimate of $10,000.
Three-Point Estimates: Effort required is medium, and accuracy is high.
The three-point estimating technique originates from the Program Evaluation and
Review Technique (PERT). It is best used when you have a range of estimates that
include an optimistic estimate, a pessimistic estimate and a most likely, or realistic,
estimate.
How do you know which estimate to use? Well, you could simply add them up and
divide by three to get an average, but the three-point estimating technique takes it a
step further and gives greater weight to the most likely or realistic outcome: four times
as much weight, in fact. The formula is:
Optimistic (O) + (4 x Realistic (R)) + Pessimistic (P)
6
Therefore, if you have an optimistic estimate of 10 days, a realistic estimate of 15 days
and a pessimistic estimate of 25 days then the three point estimate is:
10 + (4 x 15) + 25
6
This equals an estimate of 15.83 days.
If you have a particularly statistical mind and want to use the three point estimating
technique to describe a range of certainty by using standard deviations you can
express standard deviation with this heuristic:
P-O
6
72
So in the above example we can say that we have a 95% certainty (2 standard
deviations either side of the mean) that the time taken to complete the work will be
15.83 days ± 5 days.

The Quote: Effort required is high, and accuracy is very high.

Getting a quote for any goods or services you require on a project is the best way to
get an actual agreed price and usually also an agreed time frame for delivery. Getting
a quote takes effort; you need to be able to provide a complete description of the
work required so the person providing the quote knows exactly what has to be done.
In order to reduce the risk around cost and time estimating, you may decide to spend
more time defining the project scope in order to get more quotes for the project.
So there you have it: a wide variety of estimating tools you can use for both cost and
time. There may even be a few more that you use that aren’t listed above. The
important thing to remember is to recognize the accuracy or uncertainty of each one
and the appropriate time to use it. You don’t want to use a technique where the
additional cost of the technique is greater than the increased accuracy it provides!
Once you have finished the process of estimating time and cost, you will have two
important bits of project work complete: the total estimated project cost and the total
estimated time for each work package or activity. The next section takes these pieces
and aggregates them to produce a project budget and a project schedule.

Estimating in Agile Projects

In Agile project management, accurately estimating time, effort, and cost is crucial for
the success of a project. Unlike traditional project management methods, Agile
emphasizes flexibility, adaptability, and iterative progress. Agile estimation differs
from traditional methods due to its iterative nature. Estimates are regularly refined as
the project progresses and more information becomes available.
Effective time and cost estimation in Agile projects is a dynamic and collaborative
process that features:
▪ Continuous Collaboration: Engage the entire team in estimation to leverage
diverse expertise.
▪ Transparency: Keep stakeholders informed about estimation processes and
updates.
▪ Flexibility: Be prepared to adjust estimates as project scope or priorities
change.
▪ Retrospective Analysis: Regularly review past estimations to improve accuracy
over time.

Here are some of the more common techniques for estimating time, effort, or cost in
Agile projects.

73
 ▪ Story Points: A unit of measure for expressing an estimate of the overall effort
required to fully implement a product backlog item. Team members give story
points based on complexity, effort, and uncertainty.
▪ Planning Poker: Team members use numbered cards to estimate story points
for each task. Discussion follows until a consensus is reached. This encourages
team participation and collective understanding.
▪ T-Shirt Sizing: This involves assigning relative sizes (XS, S, M, L, XL) to tasks
based on complexity. It is useful for high-level estimation in early project stages.
▪ Cost Per Sprint: Calculate the cost of each sprint by considering team salaries,
resources, and overheads. This gets adjusted as team size or sprint duration
changes.
▪ Cumulative Flow Diagrams: These help in tracking the progress and
identifying bottlenecks, which can impact cost. This is used to anticipate delays
and reallocate resources.
▪ Burn Rate Analysis: Monitoring the rate at which the project is consuming its
budget to ensure that the project stays within its financial constraints.

By applying these techniques and best practices, project managers can ensure a more
accurate and realistic planning process, which is essential for the successful delivery
of Agile projects.

OPINION: Better Cost and Time Estimating – The Myth of Certainty

So you’ve been asked to provide an estimate for project cost or time. What do you do?
You could simply think of a random number, multiply it by the number of freckles on the back
of your hand, divide it by the number of bites it took to eat your lunch today and then subtract
a 5 digit prime number. That’s an estimate isn’t it? Yes it is and I have seen methods not too
dissimilar to this actually being used to justify investing in a project or a business case.
Sometimes the process of providing an estimate for time or cost is simply a political exercise
to provide people with what they want to hear.
So is there a better way? Of course there is.
The first step is to acknowledge that an estimate is exactly that – an estimate. It isn’t a quote
or a contractually fixed amount. It’s an attempt to forecast what the likely time or cost will be
using all the information you have at hand. Obviously the more information and the more
accurate the information the better the estimate will be.
There are two elements to estimating – clarity and accuracy. When preparing your estimates
there are a range of tools and techniques you can use, each with its own level of clarity and
accuracy. Choose the most appropriate tools and techniques to get the best estimate possible.
Clarity relates to how transparent the information you used to make your estimate is. Have
you acknowledged the sources and methods used to make the estimate? You can have an
estimate that acknowledges a wide range of pricing or time but is transparent in its sources
and assumptions made. You should always acknowledge where your information came from
and how certain you are about its validity. This lets people know how to treat your estimate.

74
Accuracy relates to the size of the margin of error and this links directly back to how well
scoped the work is. Remember that every line item in your cost or time estimate can have a
different range of accuracy depending on what information is being used to make the
estimate. With all of these different levels of accuracy you can then have an overall level of
accuracy for your estimate which averages out all the different ranges of accuracy.
I always find it is better to qualify your estimates by clearly exposing the sources, assumptions
and individual range of accuracy made in preparing your estimates. The better your sources
and the less assumptions the clearer the estimate will be. The more accurate your scope of
work the less margin of error there will be in your estimate.

75
Review Exercises

1. Which estimating techniques do you currently use?

1.

2.

3.

4.

5.

2. Which estimating techniques do you think would be of value to you?

1.

2.

3.

4.

5.

76
3. Can you provide the following estimates and name the estimation technique
used?

1. You worked on a project a year ago and the developers charged you $56,000
for the development work. The project you are currently working on is about
50% of the required effort. What is your cost estimate for the developers on
this project and what technique are you using?

______________________________________________________________

2. You need to buy 100m2 of paving stones for your construction project. You
look up the price online and discover you can get the paving stones for $10
each and each one covers .25 of a square metre. How much is your cost
estimate and what technique did you use?

______________________________________________________________

3. You have a total of $120,000 to complete your project. You have done this sort
of project many times before and feel you know how the costs are spread
across the different elements required. You allocate 7.5% of the costs to the
required designs, 55% of the required costs to the build, and 37.5% of the costs
to the testing and commissioning. What are your estimates for each of these
elements and what technique are you using?

______________________________________________________________

Answers:
1. $28,000 and Analogous Estimating
2. $4,000 and Parametric Estimating
3. $9,000 for Design, $66,000 for Build, $45,000 for Testing and you are using
Top Down Estimating

77
Chapter 6. Creating a Project Schedule

This chapter will introduce you to the tools and techniques for putting together your
project schedule or timeframe using the time estimates you completed in the previous
chapter.

What is the Project Schedule?

The project schedule is the graphical representation of the work packages, tasks and
activities to be performed as part of your scope of work. They are represented in
sequential order with relationships and interdependencies shown to give the amount
of time a stage, milestone or project will take.
The first project schedule produced is the optimal one. Once it has been optimized to
account for time and resources, it is used as a baseline to assess the impact of any
change from what was planned and to assist with corrective actions or reforecasting
time frames.

Creating Your Project Schedule

As with many other processes, the quality of your project schedule is dependent on
the quality of the information going into it. If you have a good quality, well defined
scope and WBS, then you’ll be able to produce a good quality project schedule.
You can do one project schedule for a fully defined project or several iterations as you
learn more about the project. If you plan to do your project schedule in a single pass,
it’s best if your project scope is completely defined and your time estimating for each
of the elements of the WBS is complete.
Creating your project schedule gives you the ability to forecast when milestones will
be completed and when the project or phase will be completed. You can then use
your schedule to track what you had planned to complete against what you are
actually completing.
I’ll describe the following processes as discrete processes, which may make you think
that you have to do one after the other, but this isn’t the case. Unless they depend on
each other, you can always do tasks in multiple processes at the same time. Only break
it down into discrete processes if it is new to you and if breaking it down helps the
definition and estimating process.
If you regularly do the same sort of project work, many of these processes can be
captured in a standardized template. You may have a list of all the usual activities and
their relationships, times and dependencies, and a list of optional ones that can easily
be added in. There is no point in reinventing the wheel and doing it fresh each time if
there is a lot of similarity between each job you do.

78
Defining the Project Activities

As with cost, the first step in making sure you have an accurate and appropriate project
schedule is to take the scope of work that has been broken down to work packages
via the WBS, and break it down even further to the level of activities. For a small scope
of work, you can break it down into its component parts straight away without having
to go through the intermediary process of breaking it down to work package level.
The more you break down the scope, the more accurate your project schedule will be;
you want get it to a level where the time (and cost) of each activity can be reliably and
accurately estimated. However, it may be that you don’t yet know all the work that has
to be done or that future work is dependent on other work being done first. The best
thing to do is to break down all work packages to the level that is possible right now.
Be prepared to do this process several times as activities become more visible
throughout the project, and accept that your time estimates for large packages or
groups of activities of work may not be as accurate as you would like. Mark those areas
of the scope where you are certain of the work and mark those areas of the scope
where there is some uncertainty that has yet to be resolved or defined.
Like the process for estimating cost, these estimates will be better and more accurate
if you get the people doing the work to complete the estimation process. If the type
of work is new or unknown, try to contact people with some experience.
What you should have at the end of this process is a list of all the activities in the
project that you know about at that point in time.

Putting Project Activities in Sequence

Once you have defined the activities and are comfortable with the level of detail they
are at, your next step is to put them all in order in a process called sequencing. This is
where you define which activities come before other activities and which ones come
after, and the type of relationship and dependency between the activities. You can use
project software to start putting together your project schedule, but you can also use
plain old spreadsheet software or even sticky notes and a white board. Simply write
each activity on a piece of sticky note paper, and then arrange them in the order in
which they occur. Draw some arrows between the sticky notes to indicate the
relationships between activities.
An activity that comes directly before another activity is called its predecessor. An
activity which comes directly after another activity is called a successor. If you are using
software to do this, the arrows will automatically be drawn once you define
predecessors and successors.
What you will end up with—if you choose to do this—is a network diagram. This is
definitely one of the times where you only do a network diagram if it is professional
for your project. Otherwise, simply go directly to using software to put together the
project schedule straight away.

79
The following diagram shows a very small network diagram for a project, clearly
showing the interdependencies between activities.

Figure 16: Example of a Network Diagram

If you are going to put together a network diagram of the project activities, then here
are some technical concepts you’ll want to know about to assist you.
A “burst activity” is an activity that has more than one direct successor; two or more
other activities depend on it. A “merge activity” is an activity that has more than one
direct predecessor; two or more other things have to happen before the merge activity
can happen. Activities can be both merge and burst, and it’s just a good way to refer
to them. Burst activities in particular are areas in a project that can cause bottlenecks.
Sequential activities can have different types of relationships that you’ll need to know
to be able to program them. Each type of relationship defines the start and finish of
an activity in relation to its predecessor or successor.
Finish-to-Start (FS) means that the successor cannot start until the predecessor is
finished. This relationship accounts for about 95% of all activity relationships. A simple
example is that you can’t start putting on the roof of a house (the successor activity)
until the walls are built (the predecessor activity). This is how it is shown with a
diagram:

Figure 17: Finish-to-Start Relationship

Finish-to-Finish (FF) means that the successor cannot finish until the predecessor
finishes. This means that the successor activity is waiting on some part of another
activity that started earlier to finish before it can be completed. A simple illustration is
the predecessor is finishing the last chapter of this book, and the successor is getting
it proofed. My editor can start proofreading the chapter as soon as I’ve started writing,
but won’t be able to finish until I’ve finished the chapter. This is how it is shown with
a diagram:

80
Figure 18: Finish to Finish Relationship

Start-to-Start (SS) means that the successor activity can’t start until its predecessor has
started. For example, you can’t start documenting a testing process (the successor
activity) until the testing process (the predecessor activity) has started. This is how it
is shown with a diagram:

Figure 19: Start-to-Start Relationship

Start-to-Finish (SF) is the least used of all the relationships as the successor activity is
unable to finish until the predecessor activity starts. This is how it is shown with a
diagram:

Figure 20: Start to Finish Relationship

Activities can also have dependencies between them to explain how fixed the
relationship is. The four types of dependency are:
• A mandatory dependency means that the successor must always occur after
the predecessor: you can’t build the second story of a house until the first story
is built.
• A discretionary dependency means the successor should occur after the
predecessor but there may be times when it can happen in parallel, in which
case you may need to look at the additional risk caused: it’s optimal, but not
mandatory, to paint first and then install the carpet.
• An external dependency is one where an activity is waiting on some activity
that is outside your project and you can’t control, such as waiting for consent
to be issued by local government.
• An internal dependency is one that is within the control of the project team.
For example, if they team must assemble to software code before testing it then
this is an example of an internal mandatory dependency.

81
A lead is the amount of time a successor activity can start before its predecessor
finishes. A lead of three days, for example, means the successor activity may in fact
start three days before its predecessor finishes. Lag is the amount of time a successor
activity must wait—perhaps for paint to dry or concrete to cure—after the end of the
predecessor activity before it can start.

Estimating Activity Resources

Once you have defined your activities and put them in the correct sequence, you can
then look at estimating the resources required to complete each task. This is not
necessarily a linear sequence, as tasks may be completed concurrently or in an iterative
manner.
Use the tools you find useful from the previous chapter to estimate the time and cost
of the resources required for each activity, remembering that resources can be people
or machinery. Look at each activity and think about how long each resource will be
required to be allocated to complete that activity. Of the possible ways to estimate
resources required for each activity or work package, please keep in mind that, if it’s
possible, the best is to ask the people doing the work.
We generally estimate activity resources before estimating the time for each activity
or work package because time is a function of resource. Two people will generally take
half as long as one person to do an activity. So it’s important to know which resources
you have so you can accurately estimate how long each piece of work will take.
A common scenario is for a project to be resource constrained, which means that you
only have a set amount of people or machinery available. In that case, you don’t have
to estimate the resources required to complete the task as they are prescribed already,
and the time will have to adjust to fit the amount of resources available.
From this information, you can also see your resource loading requirements for the
project. By taking the resources required for each activity, then overlaying the
completed project schedule, you can see when resources will be required. This enables
you to get an early warning of times when you may not have enough resources to
complete the scheduled work. Conversely, it will also let you know when you’ll have
people sitting around doing nothing for whom you may need to find other work.
If you spot a time on your project when you’ve forecast a need for more resources
than you have available, you’ll have to figure out what you are going to do about it.
You can decide to hire in extra people or machinery to do the work, but this generally
costs more money. You can choose to reschedule non-critical work for other times to
make the best use of your resources. This is known as resource levelling.
Take a look at the following diagram which shows the initial estimates of resources, in
this case senior designers, based on the first iteration of our project schedule.

82
Figure 21: Example of Resource Levelling

You can see two points that are not optimal and may need resource levelling. The first,
near the beginning of the project indicates that we do not have enough designers to
do the work and to get the work completed as planned we may have to pay overtime
rates, ask people to work longer or bring in contractors to do the work. Each of these
choices comes with its own cost, risk and quality elements that we need to take into
account.
If we decide to do none of these options then we must reschedule the activities to
level the resources so that they do not exceed the hours we have available. Obviously
moving this work to a later period has an immediate impact on the project schedule
and it extends the forecast duration.
The diagram also shows a period later in the project when we have our senior
designers sitting around with very little work for them to do. This is not optimal as well
especially if we are paying them a salary of fixed contract. Once again we may choose
to level the resources for a more efficient allocation but must take into account the
impact upon cost, time, risk and quality.
You may also have to reschedule critical work, which will most likely extend the
duration of your project. The advantage for you in doing all this planning becomes
apparent at times like this as you are able to forecast likely situations and what you
are going to do about them well in advance. Ultimately, the project team, client and
other stakeholders will receive better, more accurate project information.
There are some very technical and scientific ways to level project resources based
upon slack, duration and task identification numbers. However, most sophisticated
pieces of project management software highlight areas of overloading or conflict and
will do this automatically if you take the time to enter all the appropriate data. If you
are working on small projects, it may not be worth the time to use the software for
this purpose. If you are interested in become more proficient in this area then feel free
to do your own search on the internet. I have found YouTube to be full of a great
number of quality videos on all aspects of project management software.
83
Estimating Activity Duration

Now you have your activities defined to an appropriate level, you’ve arranged them
all in sequence, and you know what resources are available when. With all this
information, you can now estimate the time for each activity, multiple activities and
the project as a whole.
Once again, refer back to the list of possible ways you can estimate time and apply
the ones that are actually useful to your project and appropriate for the amount and
quality of information you have available to you.
Some activities may be time constrained, which means they have to be delivered
within a certain period. In this case, the level of resources needed to complete the
activity will have to be provided. If you ever find yourself in the position of an activity
being both time constrained and resource constrained, and you simply don’t have
enough resources to finish the activity within the specified time, something will have
to change. You will have to either extend the time or get more resources.

Developing a Network Schedule

A final stage in pulling all this information together is to complete your network
diagram with all the activities listed, the order in which the work will be done, the
resources assigned and available to each activity and the duration of each activity. This
forms your project schedule baseline. The baseline is what you measure your actual
progress against, and includes the original baseline and all approved changes to it.
There is a very laborious manual method of completing network diagrams with all this
information you now have at your disposal, but the easiest way to view the information
contained in a network diagram is with software and the very popular Gantt chart,
developed by Henry Gantt. The Gantt chart shows the length of time for individual
activities and work packages, the dependencies between individual pieces of work and
the total time for sections of the project and the entire project.
Another great use of the Gantt chart is as a communications tool. It lets people see
quickly what you are forecasting to do, and if you use it to track actual progress they
can see how the project is going overall.
The following diagram shows a basic Gantt chart using bars to show the duration of
each activity and arrows to indicate the relationship between activities.

84
Figure 22: Sample Gantt Chart

Take your individual time estimates for the activities and work packages in your project
and go through the following process to arrive at your project schedule.
First, put them in sequence. In doing this you will need to define which activities must
come before other activities, which ones comes after and what the interdependencies
are between them. You can map out which activities have multiple predecessors
(merge activities) or multiple successors (burst activities).
You can also clarify what sort of relationship exists between the activities: is it the
traditional Finish-to-Start meaning the successor cannot start until the predecessor
finishes or is it a Finish-to-Finish or Start-to-Finish?
Once you have all this information combined within a coherent network diagram and
it has been transformed into a project schedule, you’ll be able to see things like the
amount of slack (or float—it’s one of the few times in the profession that two words
mean the same thing) and the critical path. Free slack, or free float, is the amount of
time an activity can be delayed before it affects the next activity in the sequence. Total
slack, or total float, is the amount of time an activity can be delayed before it affects
the total project duration.
As I said earlier, there are some very manual and time consuming ways of assembling
the network schedule; these methods let you see exactly how the software does its
job. Instead of learning how to do this work manually, I recommend that you become
proficient at using an appropriate piece of project management software to do it.
There are many great pieces of software on the market so take your time to shop
around. Most good project management software can show you all this information
as a Gantt chart or as a network diagram. The software will also allow to track actuals
against planned, and quickly reforecast the impact of any changes to the schedule.
85
TIP: There are lots of great project management software and online services out there.
Take your time assessing each to see if it meets your actual and future needs before
committing. Take into account the initial costs, ongoing costs and training needed before
making a final decision. If you are looking for a free open source scheduling software
then I strongly recommend ProjectLibre.

Critical Path

Someone once asked me what I did for a job; when I said I was a project manager,
they said that was great and what they knew about project management was the
critical path. I’m not sure they actually knew what a critical path was, but they
somehow associated the entire profession of project management with it.
The critical path is the path through the network schedule that has no slack (or float).
You can have more than one critical path but each one will have zero slack.
It is called the critical path because it describes the path of activities that represent the
greatest risk to the project schedule, as, without any slack, a delay in one of the
activities will delay the entire project. Hence, we like to know which paths are critical
so we can pay attention to it.
There can be many paths through a project, as the following figure shows.

Figure 23: Network Diagram

There are the following paths through this network diagram:

• A-B-E-H-J
• A-C-F-H-J
• A-C-F-I-J
• A-D-F-H-J
• A-D-F-I-J
• A-D-G-I-J
However, you are not able to determine which path or paths are the critical paths until
you complete a full schedule network analysis. The critical path method focuses on
identifying all the paths through a project and, with the aid of a network diagram,
determining which of these paths presents the shortest duration and also the least

86
amount of scheduling flexibility as indicated by the length of slack or float. The path
with the shortest duration and the least slack or float through the project represents
the path of most risk to the project, hence the name critical path.
To calculate the critical path on an activity-on-node diagram, this example will use the
node to represent the information about the activity. The information contained in the
node will be the task ID, the duration of the activity, the early start (ES), the early finish
(EF), the late start (LS), the late finish (LF), and the amount of total float in the activity.
The following figure represents a typical node; however, be aware that in the real world
many different forms of node may be used with information displayed in different
locations, yet they all display the same information, just in different ways.

Figure 24: Network Diagram Node

Now if you take the information contained in the following table and map that out
over an entire network diagram, you will be up to calculate the project duration and
the critical path or paths.

Figure 25: Network Diagram Working Table

The first step in the process is to construct a network diagram showing the
relationships between the activities. In this instance, assume that all activities have a
finish-to-start relationship and there are no leads and lags. The following figure shows
the network diagram:

87
Figure 26: Network Diagram Showing Relationships and Duration.

By examining this network diagram, you can now write out the paths through the
diagram as follows:
• A-B-D-F-H
• A-C-D-F-H
• A-C-E-F-H
• A-C-E-G-H
The next step in the process is to complete a forward pass. The forward pass is
completed by working from left to right and calculating the early start and the early
finish for each task. The earliest a task can start is immediately after the latest early
finish of all its predecessor activities. For example, if Activity A has an early finish of
day 3 (which means it finishes at the end of day 3), then Activity B has an early start of
day 4 (which means it starts at the beginning of day 4). If an activity has more than
one predecessor, the earliest it can start is immediately after the latest early finish of
all its predecessors. The following figure shows the network diagram with the forward
pass completed. You can now determine that the project duration is 25 days.

Figure 27: Network Diagram with Forward Pass Completed

The next step in the process is to complete a backward pass. This time, you work from
right to left, and you calculate the late finish and the late start for each activity. This
time, when calculating the late finish for an activity, you must look to its successor
activities; the late finish for an activity is immediately prior to the earliest of all
successor late start dates.

88
For example, if Activity D is the successor to Activity B, and activity D has a late start
of day 12, then Activity B has a late finish of day 11. As you complete the backward
pass, you can also calculate the total slack for each task by subtracting the late start
from the late finish. The following figure shows a completed backward pass.

Figure 28: Network Diagram with Backward Pass Completed

To calculate which of the paths through the network diagram is the critical path, you
simply look at all the activities that have zero (0) total float, because these represent
activities that if delayed will affect the total project duration. If you do this, you can
determine that the critical path in this network diagram is A-C-E-F-H.

Reducing Project Duration

You may have noticed that we have placed no restrictions on the project schedule at
this stage. The process of estimating the project time based on breaking down the
project scope, estimating the resources available and putting them all in the correct
sequence has given us an optimal time for completing milestones and the project. In
a perfect world this would be all we needed to do. However, it may be that there are
time constraints placed on part or your entire project. In this case, you are going to
have to look at ways you can reduce the duration to meet the imposed deadlines.
It is worthwhile looking briefly at ways in which you can reduce the duration of a
project if required to. Sometimes our estimates represent a best case scenario, but it
may be that the client or sponsor actually wants the work completed faster than the
initial estimates allow. If this is the case, you can choose one or more of the following
tools to assist in reducing project duration. Each of these has its own implications for
project cost and risk as part of the trade-off to get things done faster.
• Crashing: adding resources to the project in order to get things done faster,
which generally costs money.
• Outsourcing project work: increases workforce flexibility but probably costs
more and you may lose intellectual property.
• Scheduling overtime: costs more money.

89
 • Establishing a stable project team: develops the required core competencies
within the team to complete the work as opposed to staff constantly changing
and having to learn new skills.
• Do it twice—first fast and then correctly: it may be that you just have to
accept an interim solution to get a job done faster and commit to coming back
at a later date to do it right. This can have serious cost implications.
• Fast tracking: doing activities in parallel that would normally be done in series.
This can add an element of risk to the project.
• Critical-chain: mapping out the process flow of work on the project, identifying
the potential bottlenecks and ensuring that work is always going through the
bottlenecks. Can reduce project duration by ensuring efficient use of resources
and constant flow of work.
• Reducing project scope: going faster by doing less.
• Compromise quality: going faster by producing a lesser quality product.

Monitoring and Controlling the Project Schedule

Once you have put all the appropriate work into creating a schedule that gives you
and your clients some certainty over when to expect delivery of the project work, you
can use this time baseline to measure progress.
Just because you have created a project schedule doesn’t mean that’s the way the
project is actually going to go. If you have done it correctly, though, at least you will
know that way things should go; and this alone will help in making sure it all works
out. Perhaps the greatest benefit of producing this project schedule is that it now gives
you the ability to track what is actually occurring against what you planned to have
happen.
Of course, one of the main reasons we did all that estimating of time was so that we
could track our actual progress against our planned progress and if necessary re-
estimate the expected time an activity or the entire project will take to complete.
Tracking project time progress using software is a simple process of just recording
actual percentage complete against the forecast total. This is where project
management software really starts to come into its own.
To start this process, you’re going to need some work performance information that
enables you to measure what you have actually achieved against what you planned to
have achieved. You can gather this by simple observation and inspection. Some work
packages and activities are easy to assess. You can look at them and know if they
haven’t started, if they are half way through or if they are finished. There are two
distinct elements you are assessing for each work package or activity: effort (i.e.,
resources) and time. Since your original estimates were made up of these two
elements, you’ll need to monitor them both.

90
Instead of trying to get down into detail with how progress is going on a work package
or activity, you can use the following guidelines to allocate percentage of work
completed. If a task has not yet started then obviously the amount completed is zero
percent. If it has just started you may want to allocate 25 percent of the task
completed. If it is approximately halfway through then allocate 50% of the task
completed. Use 75 percent to indicate a task well on the way through being completed
and finally 100 percent when the task is complete. These are just suggestions as a way
to put a structure around assessing how far through a task is without getting down
into too much detail.
Using these figures you can track actual progress against the original estimate, and
forecast the likely future implications. Project management software is the most
efficient way to complete this work. Once you have calculated the new forecast, you
are able to either accept it or devise strategies for dealing with it. These strategies may
focus on revisiting the sequencing of activities, re-examining the amount and type of
resources allocated to the project, or applying any of the schedule compression
techniques already discussed in this chapter.
Use your change control process to track, assess and document any changes affecting
the project schedule and update your schedule baseline so it includes all approved
changes. Then use your new baseline to continue to monitor actual progress against
planned progress in an iterative manner.
If things aren’t going according to plan, you need to look at the root cause of the
problem. Ask yourself the following questions:
• Is it because the estimates where wrong? If so, why were they wrong?
• Is it because the resources aren’t working as planned?
• Have there been unanticipated issues causing delays?
Being able to answer these questions will not only give you a better chance of
addressing the problem but will also contribute to your lessons learned and future
projects.

Tracking Progress in an Agile Project

You can use network diagrams and Gantt charts to measure the overall total project
progress for an agile project. However given the highly iterative nature it may only be
possible to use these tools for the short term rather than complete project lifecycle.
There are couple of useful tools that you can use for agile projects to determine how
fast you are going for particular sprints or iterations.
A velocity chart is used to compare the amount of committed work and the amount
of completed work for each Sprint so you can determine whether you are maintaining,
increasing or decreasing work velocity. The following diagram shows an example of a
velocity chart.

91
Figure 29: Example of a Velocity Chart

A burndown chart is a way of representing the remaining work left to be done over
time. They are useful for predicting when all of the planned work may be completed .
Their other main use is to tell you if you are working too slow to meet agreed
deadlines. The following diagram is an example of a burndown chart.

Figure 30: Example of a Burndown Chart

92
Review Exercises

1. Draw a network diagram and calculate the critical path using the following
information:

Task ID Duration Predecessor

A 3 days -
B 6 days A
C 2 days A,B
D 4 days B
E 4 days C,D
F 2 days D
G 5 days E
H 3 days F,G
I 8 days G,H

Answer: I deliberately put it upside down to discourage you from looking at this until
you have given it a go

Critical path is A – B – D – E – G – H – I

BONUS EXERCISE: Download ProjectLibre from projectlibre.com and practice using

your new knowledge to turn your network diagram into a Gantt chart.

93
Chapter 7. Managing Project Costs and Budget

This chapter will introduce you to the process of creating your project costs and
project budget. There are many similarities between estimating costs and estimating
time that were covered in the previous chapter. As such, there will be some duplication
of content in this chapter.

What are Project Costs?

What are project costs? It sounds like a simple question, doesn’t it? Unfortunately,
there isn’t a simple answer. There are many aspects of project costs that you need to
be aware of.
At the macro level, the project cost is what it will cost to complete the project as per
the defined scope of work. Where it gets complicated is in determining which costs
are attributed to the project and which aren’t. Obviously, the costs of people working
on the project and materials used to complete the project will definitely be part of the
project cost. What about attributing a portion of company overheads to the project
on a pro rata basis? Does your project include a figure for its fair share of costs like
administration, marketing, finance, rental and utilities? You can include these on the
basis of actual costs incurred—if you can track it that way—or, alternatively, you can
attribute a fair and reasonable percentage of the total cost to your project.
Once you have figured out the actual cost the project will incur, how do you add on a
fair and reasonable profit margin if it’s not already built in? Once again, you need to
determine a transparent process for determining a fair and reasonable margin, and
apply it consistently across all projects. Your accountant will be able to help you out
here.
You need to define what is include in the project costs and what isn’t included. For
best results, you need to use the same formula for all projects you are doing.

Estimating Project Costs

As mentioned above, there is some overlap between the processes for estimating time
and those for estimating costs. As with time, your estimates for the costs of individual
elements of the project and the total project will only be as good as your project scope
statement. If your scope statement has areas of uncertainty in it, so too will your cost
estimates. If it is fully defined, your cost estimates will be much more accurate. In
addition, if you start from a high level scope of work (i.e. one that isn’t broken down
into its component parts), then your estimate will be less accurate than if you build it
up from a decomposed scope of work.
The chapter on Estimating Cost and Time has a full description of the tools you can
choose to use for estimating costs. If you skipped over that chapter to get to this one,

94
please go back now and read it. After reading it, select those estimating tools that are
most relevant to your project.
However well-defined your scope of work, a top-down estimating technique is not
going to be as accurate as an estimating technique or combination of estimating
techniques that build up from individual work packages or activities. Referring back to
my very primitive example of a house build, here is how you can build up your costs
once you have used the correct estimating techniques for each work package or
activity. Remember that you can use a variety of techniques depending on which one
is most useful.
Begin by assigning a cost estimate to each element, whether they’re work packages
or activities, in your WBS. Add these up and provide subtotals under headings
describing different categories of the project. Then add up all these subtotals to get a
total project cost.
The following table shows the individual costs for each activity, the aggregated costs
for each process and the total project cost.

-House Project $102 500

-Design Process $15 000
-Concept Plans $5 000
-Owners Approval $0
-Construction $10 000
-Building Process
Plans $87 500
-Site Excavation $15 000
-Construct Floor $25 000
-Construct Walls $10 000
-Construct Roof $7 500
-Interior $30 000
-House Complete $0

Developing a Cost Contingency

A contingency reserve figure is a sum of money included in the project cost estimate
to account for uncertainty in the project estimating process. The process of developing
this reserve figure can be a highly political affair. Unfortunately, it is not uncommon
for people to simply add in a random figure to account for poor estimating.
There are two types of contingency, or reserve, in a project. They are properly called
the contingency reserve and the management reserve.
The contingency reserve is an amount prescribed and defined by the known
uncertainty in a project because of the scope definition and the risk definition process.
The management reserve is generally a pool of money controlled by senior
management specifically for projects to apply to when genuinely unforeseen events
arise. It can be very useful for the overall budget for the organization to have a defined
95
management reserve instead of having to find ways to finance unforeseen events
when they occur. It may be a simple percentage of the total portfolio value or it may
be worked up using one of the techniques outlined below.
In reality, there are generally only two reasons to explicitly include a contingency
reserve figure for either cost or time. Poorly defined, or undefined, scope represents
uncertainty in the project and this uncertainty can be expressed as a contingency in
the project cost estimate. This contingency reserve can be worked out best using
previous knowledge, expert judgment and lessons learned from past projects. It is best
expressed as a percentage of the estimated costs and can range from large
contingencies of 50-100% for high levels of uncertainty, to a much more refined 5-
10% for lower levels of uncertainty. You can add up all the individual estimates of
uncertainty for each work package or activity and get an overall level of uncertainty or
contingency for the project. If the contingency figure is too high, it may be better to
spend more time defining the scope so you can reduce the amount of contingency
required.
Here are some other common ways to develop a transparent and defensible
contingency reserve:
• Lessons Learned from past projects: Review lessons learned from previous
projects, both within your organization and from industry sources. Identify risks
and issues that were encountered in those projects and the associated costs.
Incorporate these insights into the contingency planning process to avoid
repeating similar mistakes and to ensure that an adequate contingency reserve
is in place.
• Risk Assessment and Quantification: Conduct a comprehensive risk
assessment to identify potential risks and uncertainties that may impact the
project. Assess the probability and potential impact of each risk. Quantify the
risks in terms of their potential cost implications and allocate a contingency
reserve based on the assessed level of risk exposure. This is covered in more
detail in the chapter on Managing Risk.
• Benchmarking: Conduct benchmarking by comparing the project with similar
projects or industry standards. Analyze the contingency reserves allocated in
comparable projects and industries to gain insights into appropriate reserve
amounts. This can help establish a benchmark for developing the contingency
reserve for the current project.
• Contingency Formula or Rule of Thumb: Utilize a contingency formula or rule
of thumb to calculate the reserve amount. This approach involves allocating a
fixed percentage of the project budget as contingency. For example, an
organization may allocate 5% or 10% of the total budget as a contingency
reserve. However, it is important to consider the specific characteristics of the
project and adjust the percentage accordingly.
• Expert Judgment: Seek input from subject matter experts and experienced
project team members. Their expertise can provide valuable insights into

96
 potential risks and the associated costs. Experts can contribute to estimating
the likelihood and impact of risks and help determine an appropriate
contingency reserve based on their knowledge and experience.
• Estimate uncertainty: Use the uncertainty in your estimates to become your
contingency budget i.e. overall there is an average 15% uncertainty so that will
be our contingency reserve.
At all times in a project, you should work to remove the reasons for allowing a
contingency, until you can remove the need for the contingency altogether. The
sooner in the project this is done the better, although it may be that you can’t remove
all the uncertainty in a project until right at the end.
We have focused on cost contingency here but you can use the same principles to
develop a contingency reserve for the project schedule, or resource estimates as well.

Developing a Project Budget

The difference between the terms “project cost” and “project budget” is quite simple.
Project cost is what you forecast it will cost you to complete the project. The project
budget is the project cost over time. The budget tells you when you expect to need
the money to pay bills and when you expect any income to be generated. Once you
have the project schedule, it’s easy to put together the project budget; all you need
to do is add in the costs for each of the elements in your project schedule and
aggregate them by time period (day, week or month). The accountants will love you if
you can do this, as it tells them when you have money expected to go out and when
you expect money to come in.
Using the house build example, this is what a project budget forecast could look like
in table format.

Figure 31: Project Budget in Table Format

Then if we take this information from the table and put it into a graph using bars to
show individual monthly spend, and a line diagram to show cumulative spend over
97
time we can see the forecast project budget more easily, as shown in the following
diagram often called an S Curve because of the slower spend at the beginning and
ends of a project.

Figure 32: Project Budget in Graph Form

Here is another example with all the information in the one diagram:

Figure 33: Combined Project Budget

98
This, in turn, forms the basis for the project cost and budget baseline we will use to
measure how well we are doing against the estimates we made and whether we need
to take any corrective action as the project budget baseline represents our planned
value (PV) and the forecast total it our budget at completion (BAC) which we need to
use the earned value management technique later in this chapter.
Another very important reason for putting together your project budget is so that
your organizations finance and accounting team can then put together all the project
budgets, to work out the cash flow projections for the organization. It is these people
who need to figure out how to deal with any forecast shortfalls in cashflow. In which
case they may ask for some projects to be deferred or ask a project manager if they
are willing to include the cost of financing in order for the project to go ahead.

Monitoring and Controlling Project Costs

As with other parts of this book, it is worth remembering that simply putting in effort
to plan things such as scope, time and cost doesn’t guarantee that that’s the way
things are going to work out. There are many benefits in planning appropriately, but
one of the greatest is that it allows you to track what is actually occurring against your
baseline. This baseline is built up from the individual work package and activity cost
estimates you have done as part of your project cost estimating process, and also the
time-phased spend of the project in your project budget. You can compare actuals
against planned for both.
In order to achieve this comparison between planned and actual spend on a project,
whether it is by activity or time period, you must have a robust tracking and reporting
process whereby you can accurately monitor the actual spend. You can use your
payments and invoice system to track money either as it goes out or as it is accrued.
A loose and ill-defined cost reporting system is a common reason for poor cost
performance on projects.
If you are using a manual paper system, you may wish to consider investing in some
software to help improve your ability to accurately track costs and assign them to
individual projects, project work packages or activities. One of the easiest ways is to
simply use a spreadsheet; input the actual spend in the column next to the planned
spend and calculate the difference. A more sophisticated way, using earned value
management, is outlined in the next section.
Perhaps nowhere is it more important to monitor, assess and document change
requests than to the costs of any project. This why so many people get into trouble
when presenting their final invoices for payment and the client says they did not
approve they money spent on certain items. You must have a rigorous change control
process for recording all change requests that affect project cost.
In addition, keep in mind that it isn’t just changes to materials being used that can
affect project costs. Changes to time frame, people, quality expectations, risks and
contract types can all add costs to a project, and all of these need to be accounted for
and either approved or declined.
99
The simplest way to track costs is to record all your change requests as variations to
the original scope of work and estimate the cost impact of each one. Use these new
estimates to forecast the project costs, and remember that changes can lower costs
as well as raise them. Get all of these changes approved by the client or senior
management in writing.

Earned Value Management

A more sophisticated way to track both time and cost performance and projections is
to use the earned value management system.
Consider the following scenario: A project manager tells you that the project they are
working on is 5 weeks into a 10 week project and they have only spent 40% of the
budget so everything is going great. Or is it?
They have told you that they are half way through a project and have spent 40% of
the project budget (the Actual Cost), but what they have not told you is how much of
the project work was expected to be done by now (the Planned Value) and how much
of the project work has actually been completed (the Earned Value). It could be that
they are half way through the project time, expected to have delivered half the project
work by this time but have only delivered 30% of the project work. In this case there
isn’t a project underspend occurring at all. They would have spent 40% of the budget
to get 30% of the work done. The process of using earned value management is
designed to get around this by comparing all the relevant metrics.
Using this information, it’s possible to easily measure progress of actual spend against
forecast spend and use this information to extrapolate a likely future spend. This is the
heart of the earned value system. This system requires you to know the value of the
work you had planned to do by a particular date (Planned Value, or PV), the actual
cost of doing it (Actual Cost, or AC), and the earned value of work completed (Earned
Value, or EV). Take these figures along with the original Budget at Completion (BAC)
and you can use the following simple formulas to help you forecast likely future spend
based on performance to date:
• Budget at completion (BAC) The original forecast budget for the project.
• Planned value (PV) The amount of value that you should have earned by this
time in the project. Because the total planned value (PV) for a project equals
the budget at completion (BAC), you can determine the planned value by
simply determining how far through the project you are in relation to time, and
mapping this back to the approved cost baseline to establish the planned value.
The following figure demonstrates how to determine the PV from the BAC using
the originally approved budget simply by plotting the point at which the
measurement of PV is being taken in the project.

100
Figure 34: Planned Value (PV) and Budget at Completion (BAC)

Another way to calculate planned value (PV) is to take the percentage complete in
terms of time and multiply the BAC by this. So if you project is 6 months into a 12
month project then it is 50% complete and your PV is 50% of your BAC. This method
is generally less accurate except where your project is experiencing a perfectly linear
spending rate.
• Earned value (EV) The value of the work that has been completed. This is not
the actual cost of the work that has been completed but rather the original
ascribed value from your approved cost baseline for the value of the work. An
easy way to get this is to realise that your PV line is both a combination of
expected cost and expected time to do the work, which is a simple way of
saying the earned value. So once you realise the PV line combines both
expected cost and expected value of the work you can use it to read the EV.
Take a look at when you planned to do the work and compare it to when you
actually did the work - this is your Earned Value (EV).
• Actual cost (AC) The actual realized cost you incurred for the work that you
have done to date. You will be able to get a record of this from your accounts
system.
The next figure shows the budget at completion (BAC), planned value (PV), earned
value (EV), and actual cost (AC) on a single graph. Incidentally, it shows a project in
trouble in terms of both time and cost because the actual cost is above the planned
value, and the earned value is less than the planned value.

101
Figure 35: BAC, AC, PV and EV

I've often found that when calculating the actual cost it is important to remove from
this calculation the value of any material held in stock. On some projects, you may
decide to procure a lot of required materials early to avoid potential cost increases
over time. Therefore, you will have paid for these materials, and this will show up in
your accounts. However, incorporating this amount into your actual cost figure for the
purposes of earned value management will skew the results negatively. Therefore, I
recommend that you do regular stock takes and remove the value of material held in
stock from the actual cost figure that you use for the earned value management
calculations.
• Cost variance (CV) This is simply the difference between the value of what
you expected to have earned (EV) at this point and the actual cost (AC) at this
point. A positive cost variance is good and shows that the project is under
budget; a negative cost variance is bad and shows that the project is over
budget. The formula is: CV = EV – AC
• Cost performance index (CPI) One of the limitations of the cost variance
equation is that it gives you a simple gross figure. You are not able to tell
whether a $10,000 cost variance is significant on your project. If you are working
on a $50,000 project it would be significant; if you are working on a $10 million
contract, it may not be so significant. The cost performance index calculation
tells you the magnitude of the variance. A cost performance index of more than
1 is good, because it means that the project is under budget; a cost
performance index of less than 1 is bad because it means that the project is
over budget. For example, if you have a cost performance index of 1.1, it means
that for every dollar you spend on the project you are getting a $1.10 return.
The formula is: CPI = EV/AC
• Schedule variance (SV) This tells you whether you are ahead or behind your
planned schedule. It is the difference between the earned value (EV) and the
planned value (PV). A positive schedule variance is good and means that you
102
 are ahead of schedule; a negative schedule variance is bad and means that you
are behind schedule. The formula is: SV = EV-PV
• Schedule performance index (SPI) This is a ratio of the earned value and
planned value that allows you to better determine the magnitude of any
variance. A schedule performance index of more than 1 is good, because it
means that the project is ahead of time; a schedule performance index of less
than 1 is bad, because it means that the project is behind schedule. For
example, if you have a schedule performance index of 0.95, it means that every
day you spend working on the project you are getting a 0.95 day return. The
formula is: SPI = EV/PV
A quick and easy way to remember the formula for CV, CPI, SP, and SPI is that each of
the formula starts with EV. If it is a formula relating to variance, CV or SV, then the next
symbol is a minus sign. If it is a formula relating to a performance index, CPI or SPI,
then the next symbol is a divide sign. If the formula is in relation to cost, CV or CPI,
then the final part of the formula is AC. If the formula is in relation to schedule, SV or
SPI, the final part of the formula is PV.
A key aspect of earned value management is the ability to use the cost and schedule
work performance information to complete forecasting. Forecasting is the process of
taking time and cost performance to date and using this information to forecast a
likely future scenario. The time and cost performance measurements are the cost
variance (CV), schedule variance (SV), cost performance index (CPI), and schedule
performance index (SPI). You can use these measurements and the following formulas
to forecast a likely project cost at completion, the amount of money required to
complete the project, and the difference between what you originally thought it would
cost and what you now think it will cost.
▪ Estimate at completion (EAC) There are many ways to calculate a forecast
estimate at completion (EAC). Keep in mind that in order to forecast a likely
future cost or time frame for the project, you are going to be using historical
information. Therefore, the quality of your EAC calculation will depend entirely
on the quality of the historical information that you are using. The following
four formulas use different inputs to calculate the EAC. Each one will give a
difference answer for the same project.
▪ EAC = BAC/CPI This is perhaps the simplest of the estimate at
completion calculations because it simply takes your original budget at
completion (BAC) and divides that by your cost performance index (CPI).
Obviously, this is a useful calculation if your cost performance to date is
indicative of your likely cost performance going forward, and by the same
measure will not be a great calculation to use if your cost performance to
date is not indicative of your cost performance in the future.
▪ EAC = AC+ ETC Simply adding your estimate to complete (ETC) to your
actual cost (AC) spent to date is an effective way to determine your estimate
at completion (EAC). However, the method by which you determine your
estimate to complete calculation will have a great effect on whether or not

103
 this formula is accurate.
▪ EAC = AC + (BAC–EV) This formula takes the actual costs (AC) spent to
date and adds to them the total budget at completion (BAC) with your
current earned value (EV) subtracted.
▪ EAC = AC + ((BAC–EV)/(CPI × SPI)) This formula takes into account
both your cost performance and your schedule performance and applies it
to the value of the work you have left to complete.
When using either the CPI or SPI formula you are able to choose whether you use
cumulative, or non-cumulative, variations of these. The cumulative calculation
calculates right from the start of the project to where you are now in the project, and
obviously if you use this you are assuming that that particular range is indicative and
typical of your cost or schedule performance going forward. If, however, for some
reason there have been some atypical variances experienced in either time or cost on
your project in the past, you may want to avoid using these when you use either CPI
or SPI for forecasts. In this case, you will use non-cumulative CPI or SPI calculations
taken from a specific period of time that you feel is a more accurate representation of
likely future performance.
When using an EAC formula, as a general rule of thumb, I tend to use the BAC divided
by CPI calculation for the first third of the project because the information coming out
at this point tends to be less accurate. After I get past the halfway point on a project,
I will use the AC + ((BAC-EV)/(CPI × SPI)) formula, because it takes into account all
parameters and is generally more accurate.
▪ Estimate to complete (ETC) The estimate to complete calculation is simply
your forecast of the remaining costs to be incurred on the project. The easiest
way to calculate this is simply to subtract your actual cost (AC) spent to date
from your estimate at completion (EAC). The formula is: ETC = EAC – AC
▪ Variance at completion (VAC) The variance at completion calculation is
simply the difference between what you originally thought the project was
going to cost (BAC) and what you now think it is going to cost (EAC). A negative
variance is bad, and a positive variance is good. The formula is: VAC = BAC –
EAC
The to-complete performance index (TCPI) tells you the rate at which you have to work
to achieve either your estimate at completion (EAC) or your budget at completion
(BAC), depending on which one you are targeting. A to-complete performance index
of less than 1 is good, whereas a to-complete performance index of more than 1 is
bad. If you are using the original budget at completion as your target, the formula is:
TCPI = (BAC-EV)/ (BAC-AC)
If you are using the estimate at completion as the target, the formula for TCPI is:
TCPI = (BAC-EV)/ (EAC-AC)
The earned value management system is only as good as the information you put into
it. Whether you use it or not is entirely up to you and your professional approach to

104
project management. If you do decide to use it, you can choose how much detail to
go into to get the maximum benefit. Remember that the main benefit of using the
earned value management system is an early warning of deviation from estimates and
an indication of the likely magnitude of the deviation. This gives you time to plan
corrective actions or to accept the new outcomes.

105
Review Exercises

1. Complete the following figures for a project you are currently working on, or one
you completed recently:

Budget at Completion (BAC)

Actual Cost (AC)
Planned Value (PV)
Earned Value (EV)

2. Now using those figure above, calculate the following:

SPI = EV/PV
CPI = EV/AC
EAC = BAC/CPI
VAC – BAC - EAC

3. Complete the missing Totals and Cumulative Totals for each month, then transfer
this information to the graph below:

106
Chapter 8. Managing Risk

After completing this chapter you will be able to put together a project risk register,
list the potential consequences of risk events, plan risk responses and perform both
qualitative and quantitative analysis. This information can be used to prepare
contingency budgets for cost and time.

What is Project Risk?

So what exactly is risk? The easiest way to understand risk is simply to substitute the
word ‘uncertainty’. Wherever there is uncertainty in a project, the chance of project
failure increases. A proactive approach is the best way to plan for uncertainty, and that
is what is known as project risk management. Risk management is one of those
processes that will definitely increase the chances of project success if done both well
and appropriately.
Keep in mind that risk or uncertainty can be both negative and positive. There are
negative events that you want to anticipate, avoid, or mitigate. In addition, there are
uncertain positive events that you want to increase the probability of happening. If
you do get into a highly complex project with lots of uncertainty then you may wish
to consider bringing in a risk management professional.
If you choose to do your own project risk management, your approach should take
into account the size, complexity and uncertainty in your project. As with other
elements of practical project management, it is important to outline, document and
standardize your particular approach to risk management.
Start at the very beginning with planning your approach to risk management. This
should be a management plan that reflects not only the size and complexity of the
project but also your organization’s tolerance for risk. This will dictate the amount of
risk and risk response planning you will do. What you will end up with is a guide to
the processes you are going to go through, the amount of effort and the expected
outcomes for risk management on your project. You may have a checklist of a process
to follow, possible tools to use and expected outcomes, as well as clarification of who
is responsible. Once you have an overall risk management plan, you can then move
on through the various stages of risk management. Remember that risk management
isn’t a one-off exercise; it is an on-going and iterative process requiring you to
constantly check the risks already identified, look for new ones, and cross off ones that
have passed.

The Project Risk Register

At the end of the process of managing project risk you will have a project risk register
outlining all the identified risks, their impacts, and what you plan to do about them.
So what exactly warrants inclusion on your risk register? A meteor hitting your project
may have a very slim chance of occurring but devastating consequences if it does, so
107
do you include it or not? You wouldn’t, generally, unless your project happens to be a
spacewalk outside the international space station in which case the answer would
definitely be yes. It all comes down to balancing what is prudent and appropriate to
include. It also relates to the amount of effort required to compile, monitor and update
the risk register versus the size and complexity of the project. The larger and more
complex the project, the more effort should be devoted to the risk management
process.
Here is an example of a generic risk register. You can see how the risk management
process progresses as we move from left to right across the register, starting with risk
identification and followed by qualitative analysis, quantitative analysis, and planning
risk responses. Please keep in mind that this doesn’t necessarily mean a strictly
sequenced approach. Just like every other area of project management, it can be done
iteratively and as often as required.
The following diagram shows some potential headings and layout for your risk
register. It shows the elements of risk identification, the qualitative probably and
impact assessment, the qualitative impact assessment multiplying statistical
probability and the dollar impact, and the planned risk responses.
Generally your particular risk register would not necessarily include all of these
categories in a single risk register. You would choose those categories that suited the
complexity and size of your project. This diagram is simply supposed to show all the
elements you could include if they were useful and appropriate.

Figure 36: Sample Risk Register

Identifying Risks

The first part of the process is to identify all the potential risks that could affect the
project. This can be done in a variety of ways and, as with all other aspects of practical
project management, it is up to you to decide which way is the best way to achieve
the right level of proactive risk identification and analysis. The following are some tools
to help you identify the risk your project may face.
Risk Breakdown Structure (RBS): A risk breakdown structure is a great tool to assist
with defining the categories and subcategories of risk that may occur. Start with the
top-level project and break it down into the first level of potential risk. Are there risks
around finance, technology, weather, personnel, design, procurement, or anything
else? Break down each of these categories into sub-categories, and think of specific
108
risk events within each of these sub-categories. Get your team, client, contractors,
suppliers and industry experts involved and ask them to contribute and review.
The following diagram shows a sample risk breakdown structure showing the initial
categories of risk on the project.

Figure 37: Sample Risk Breakdown Structure

From the risk breakdown structure, which gives you a range of categories of risk, you
can move on to identifying potential risks, both positive and negative, in each
category.
Lessons Learned and Historical Information: By far the best source for identifying
risks your project may face is the lessons learned from other projects. Hopefully,
someone has taken the time to document lessons learned from other projects and has
left you with their risk register and their assessment of the risk management process.
Did they miss any risks, did they use the right tools, and did they have the right
responses? These are all questions that a good lessons learned report from a
completed project will answer, allowing you to move ahead quickly with your own risk
identification process.
Risk Professionals: If your project is large and complex, you can bring in a risk
professional to help you identify the risk associated with your project; they will have a
vast amount of knowledge from the industry you are working in and will be able to
help you pinpoint the risk your project is facing. Additionally, they will be able to help
you quantify the risk and plan appropriate risk responses. You can find risk
professionals online; actuaries are also good places to start if you need help.
Brainstorming: This one is a personal favourite of mine. Brainstorming is a great way
to get people to think laterally about all the potential risks that can occur. Get the
project team together and a few other people with knowledge, put on some coffee
and muffins, appoint an independent facilitator and let the ideas flow. A brainstorming
session will inevitably produce some inappropriate ideas (like the risk of getting hit by
a meteor), but you can sort these out later. Record all the ideas and put them into
categories. You can also use brainstorming for qualitative risk analysis.

109
Ask the Experts: You may choose to go straight to the experts in the field you are
working in and ask their opinions about your project risks via email or face-to-face
about. Getting them together in a group is also useful, but then you have to watch
out for peer pressure and groupthink. One way around this is to use the Delphi
technique, which anonymously polls experts of their opinions.
Each time you identify a new risk event, you also need to describe the potential
consequences of that event if it does occur. You can have more than one consequence
for each event. Your risk register should also note whether it is a positive (opportunity)
or negative (threat) event.
Here is an example using the generic risk register I showed you earlier. In this risk
register we have identified weather, financial, personnel and legal categories. In the
weather category we have identified the chance of a hurricane and correctly identified
it as a negative risk and that it is very urgent - it must be hurricane season as less
urgent risks would be further off in time.

Figure 38: Risk Identification

Qualitative Analysis

Once you have completed the process of identifying the risks that may occur you can
then move on to the process of qualitative analysis. The purpose of this process is to
subjectively analyse the probability and impact of the risks and with this combined
analysis be able to rank and prioritize the risks. You will then be able to focus your
quantitative analysis and response planning efforts on just those risks with a greater
probability and higher impact.
The essence of qualitative risk analysis is that it is done quickly and assesses the
probability and impact of the risk occurring on a subjective scale such as 1-5, where 1
means low probability of occurring and 5 means near certainty it will occur. For the
impact assessment on the same scale, a 1 means virtually no impact whereas a score
of 5 means a major impact. Multiply the two assessments together to get a score for

110
each risk, and then sort them from highest to lowest to see which ones have the
greatest probability of occurring and significantly impacting your project.
Because the qualitative process is so subjective, you may want to provide text-based
descriptions of what an assessment of 1 means, what an assessment of 2 means and
so on. The following diagram shows a way to provide some standardization to what
can be a very subjective process.

Figure 39: Qualitative Risk Standardization

Once again, using tools like lessons learned, historic information, brainstorming and
asking experts are great ways to complete this process.
Once you’ve completed the qualitative analysis, you can sort the most important
uncertain events, or risks, from the others and focus your attention on these. You may,
for example, decide to do the next step, quantitative analysis, only on these higher
priority risks.
Here is an example of qualitative risk analysis which shows an assessment of
probability and impact of the hurricane hitting our building site project. It shows a
qualitative assessment of probability of a hurricane occurring of 5 out of a possible
score of 10 (i.e. 50%), and a qualitative assessment of impact of 10 out of 10.
Multiplying these two numbers together gives us an overall score of 50 out of a
possible 100.

111
Figure 40: Qualitative Analysis

Quantitative Analysis

Quantitative analysis of project risks takes more effort than qualitative analysis. Instead
of asking for subjective assessment and analysis of the probability and impact of risk
events, you actually go out and do some serious research about the known probability
and known impact, either in dollars or days, of the risk. Obviously, this takes time and
effort, and so you generally only perform quantitative risk analysis on the highest
ranking qualitative risks. It is also common to apply quantitative risk analysis to the list
of materials required for a project, particularly when the project is completed over a
long period of time and factors such as inflation and price movements due to supply
pressures can be accurately estimated.
You can also use quantitative risk analysis to build up contingency budgets for both
time and cost by applying a full quantitative analysis to each line item of a project
WBS or list of materials. Once you calculate the exact probability of an event occurring
and the exact financial or time impact, you can multiply these two figures together to
get a fairly accurate quantitative risk assessment. For example, a 10% chance of a
$10000 risk occurring means that you should allow $1000 in the contingency budget.
If you add up all the separate quantitative risk assessments, you end up with a fully
defensible and transparent contingency budget for your project. As your project
progresses, risks that were anticipated will either manifest or disappear. If the project
proceeds without the risk manifesting, you can release the contingency budget
assigned to that particular work package or activity.
It isn’t uncommon for the quantitative analysis to be done separately, particularly
when being used to determine financial uncertainty in a project and therefore the
contingency budget. Because of the skills required to perform quantitative analysis

112
well, it is wise to consider using the services of a risk professional or actuary if you
want a good reliable result.
Using our generic risk register, hurricane and building site example again we can see
that this time we have gone along to the metrological bureau and paid them to
produce a quantitative assessment of the probability of a hurricane this season. They
have produced an assessment of 43% chance. We have also asked our accounts team
to calculate the financial impact should the hurricane hit and they have provided us
with the figure of $10000. So, by multiplying these numbers together we can allow a
sum of $4300 for this risk.

Figure 41: Quantitative Analysis

If we add up all the sums in the P$ x I$ column we arrive at a transparent and

defensible contingency reserve for the project.

Planning Risk Responses

A further step in completing a risk register is to plan risk responses and contingency
plans for each event that may occur. You can have multiple responses for a single risk.
You can use your risk responses as a checklist of actions to carry out prior to the risk
event and make sure you have everything in place to deal with the risk. Your planned
risk responses also tell you what to do as the risk is occurring.
You can choose from these four categories for negative risks:
• Avoid: Don't engage in the activity that could lead to the risk; for example,
avoid risk of traffic on motorway by taking back roads
• Transfer: Make the risk someone else's problem; for example, take out
insurance

113
 • Mitigate: Lessen either the impact or the likelihood of the risk; for example,
hold an outdoor event in summer for less chance of a snowstorm or build a
house to certain specifications to lessen the impact of a hurricane
• Accept: If cost or impact of response is greater than the cost or impact of the
risk, the best strategy may be to accept it
You can choose from these four categories for positive risks (uncertain events that
would benefit the project if they were to occur):
• Exploit: Attempt to remove uncertainty and make sure the event will happen;
for example, if there's a risk that the project will be more profitable than
anticipated, make sure contributing factors are identified and continued or
increased
• Share: Improve chances of risk occurring by working with another party; for
example, partner with a complementary vendor to respond to an RFP
• Enhance: Increase either the impact or the likelihood of the risk; for example,
buy more tickets to increase risk of winning a lottery
• Accept: If cost or impact of response is greater than the benefit or positive
impact of the risk, the best strategy may be to accept it
A word of warning; there will often be unforeseen risks that you could not have
reasonably anticipated occurring and therefore have no risk response planned. If an
event like this occurs, it is best to create a workaround and call everyone together into
a ‘war room’ to sort out your response as fast as possible.
Using our example again you can see we have identified a trigger condition that sets
in motion our risk responses. Not all risks will have trigger conditions but those that
do enable proactive steps to be taken.
We have also performed a residual risk analysis that looks at the probability and
impact with our responses in place. In this instance our responses cannot change the
probability of a hurricane hitting but they can change the impact which lowers from a
10 to a 4. It is not unusual for members of project steering committee to insist that
planned risk response bring residual risk analysis below pre-determined point which
reflects the organizations tolerance for risk.
Our risk register also shows who has been allocated responsibility for ensuring these
measures are put in place and monitored.

114
Figure 42: Risk Response Planning

Monitoring and Control

Your risk register is a living document; it is only as good as the information in it and
the attention you give it. You need to be constantly checking it and making sure you
have completed the proactive actions, checking the assumptions you made in
identifying and assessing risks, and keeping an eye out for new risks on the horizon.
If you are on a larger team you may wish to appoint someone to take responsibility
for updating it, but you as project manager and the project team need to be actively
involved in this process. One of the great benefits of actively involving the project
team in risk management is that you create a mind-set that risk management is
effective and appropriate, and everyone takes it more seriously. Organizational culture
will influence how people approach, and handle risk and issues. You need to develop
and maintain a culture of honesty and support that enables the organization to
approach risk at an appropriate level.

115
Review Exercises

1. Use the following simple risk register to define some risks on your project:
Residual
PxI
Residual
I (I-5)
Residual
P (1-5)
Response
PxI
(1-5)
I
(1-5)
P
Consequence
Risk Event

116
Chapter 9. Managing Project Quality

This chapter covers both Quality Control and Quality Assurance; at its completion you
will be able to prepare your own project quality management plan and track progress
against it. All projects require a focus on quality to ensure the deliverable meets the
customer expectations; this is the definition of Quality Control. Of equal importance
are the processes used to ensure the quality of the overall project; this is the process
of Quality Assurance.

Defining Quality

Let’s start be defining exactly what quality means. One definition is the management
of the degree to which a set of inherent characteristics fulfils requirements. Obviously,
this means you need to have a set of requirements to start with, so you can measure
characteristics against them and actively manage your project to achieve them.
Requirements can be about both quality assurance and quality control, as can the
characteristics you will be checking.
Quality is important to you and your customer. You can easily gain customers by
having a reputation for delivering quality and just as easily lose customers by
delivering poor quality. Remember, if you are not worried about quality on your
project, your competitor will be. Put yourself in the position of the customer. Would
you be prepared to pay a little more to get better quality?
Quality, of course, comes in many forms and it isn’t just the quality of the deliverable.
It also includes the quality of communications with stakeholders, the quality of reports,
the quality of scope descriptions, and more.
Now that we know what the definition of quality is there is another concept that is
sometimes confused with quality, and that is the concept of grade. Quality and grade
are two different concepts and it's important to understand the difference between
the two. While quality refers to the degree to which a set of observable characteristics
meets and fulfills defined requirements, grade refers to the number of features that a
product has. So a product described as being of high grade would have more features
than a product described as being of low grade. It is important to note that both of
these products could be built to exactly the same quality standard and what separates
them is their grade. You often see this applied by many manufacturers who want to
have a luxury brand in the market that is separate from their ordinary brand. There are
many car manufacturers for example that build all of their cars to exactly the same
quality but differentiate on grade between the luxury and the ordinary brands. The
luxury versions of the cars will have more features than the ordinary versions of the
cars.
Here are some quality management concepts you should be aware of:
Total Quality Management (TQM): is a quality management approach aimed at
embedding awareness of quality in all organizational and project processes. It requires

117
everyone involved in the project and product to be accountable for, and to contribute
to, quality on the project. Central to TQM is the commitment to continuous
improvement.
Six Sigma: is a quality management approach that seeks to improve the quality of
process outputs by identifying and removing the causes of defects and variability in
manufacturing and business processes, striving for no errors. The name Six Sigma
comes from the statistical properties of 6 standard deviations (or sigma) away from a
mean which includes 99.999 percent of a population. Six Sigma organizations strive
for no more than four defects per million events.
Kaizen: is a Japanese word used in English to mean a commitment to continuous
improvement in your pursuit of quality.

Planning Quality

As part of any good project plan, you should have a quality management plan which
sets out your particular approach to setting, measuring and improving quality on your
project. A quality management plan should itself also be subject to continuous
improvement. It should be kept up to date and checked regularly to make sure it is
still appropriate for the type of projects you are working on.
A general approach to incorporate into your quality management plan is prevention
over inspection: have a fence at the top of the cliff instead of an ambulance at the
bottom. It generally costs more to fix an error than to prevent one!
Keep in mind that there is both a cost of quality and a cost of poor quality. When
implementing any quality management plan, it is obvious that quality can cost money;
pursuing quality makes sense when the amount of money spent on quality processes
is less than the return good quality brings. However, there may come a time when the
cost of achieving a particularly high level of quality means the product you are making
is simply too expensive, or the effort simply outweighs the benefits of doing it in terms
of finances or your reputation. When that happens, you would simply choose an
appropriate level of quality for your project processes and deliverables.
Assessing the cost of quality is an important aspect of practical project management.
There are costs associated with any activities geared towards setting, achieving and
improving the quality processes on a project. Achieving that extra 1% of quality in
your processes and products may add 100% to the cost of the project or product. If
you manufacture lifesaving equipment, that 100% is probably worth it. If you produce
video games, it may not be. This is the cost of quality; you need to be able to assess
what your tolerance and expectations are for quality and for poor quality, and the
extent you will go to, to achieve these standards.

Quality Assurance

The process of quality assurance is all about checking that you are actually doing what
you planned and said you would do. If you said you would document all changes via
118
a certain process, are you doing that? If you said that all projects must have a signed
project charter, do they all have one? If you said that you would have a plan for cost
and time estimating, are you following it? Notice that the quality assurance process is
not about checking the quality of the product. It’s about checking the quality of the
processes you have said you will follow. There is no point having them if you aren’t
following them and also improving them. It’s natural to think that quality management
is about the product, but it is just as important to check the quality of the processes
you are using. Ask continuous questions: what processes do I have and what is
missing? Am I following the processes appropriately? Do I need to update the
processes to make them more appropriate?
The easiest tool to use in this instance is a simple audit of the process. An audit
involves getting someone, usually someone independent, to undertake a review of the
processes and confirm that people are indeed following those processes. Any areas of
non-compliance identified in the report should be rectified. Random audits are usually
more effective. Surprise people and ask them to demonstrate that they are following
the rules set down. By the way, don’t be afraid to change the rules and processes if
they simply aren’t appropriate. This could mean making them either more or less rigid;
the key word is appropriate.
The process of quality assurance is the main focus of the ISO 9000 and 9001 standards.
They require an organization to define quality processes and adhere to them. A
weakness of the system is that the quality process can describe a manufacturing
process that produces a low quality product. This is a good example of the difference
between quality of the process and quality of the product.

Quality Control

Quality control is the process that most people are more concerned with, because it’s
all about checking the quality of the product. This isn’t that difficult a job if you have
taken the time to develop a list of outputs and specifications that you are expecting
to see in the product you are delivering.
If you decided that all your fluffy blue widgets must be 12 centimetres across, 7
centimetres deep, weigh 3 kilograms and bounce 30cms when dropped from a height
of 1 meter, then the quality is easy to check. You simply gather some up, measure
them, record the result and, if everything is ok, keep going. If not, you fix the process
until the product turns out right and within specification. This, in an elementary way,
describes the process of quality control; you can see that the main tool to use is
inspection. Here are some other tools you can use to check and record results of the
quality control process.
A cause and effect diagram, or Ishikawa diagram, allows you to map out all the
potential causes of a particular quality issue. Often there is more than one reason for
a defect. This example shows a major defect as having eight potential causes. You
could then go further in your investigation of the root cause of the causes using 5-

119
Whys analysis where you continue to ask why something contributed to a cause until
you reach the real root of the problem.

Figure 43: Cause and Effect Diagram

A control chart documents measurements taken over time against control limits set
at three standard deviations either side of an expected mean. These control limits are
usually within the specification limits set by the product scope and client. If one
measurement occurs outside the specification limit that means the customer does not
want the product and the production process must be investigated immediately. If a
measurement falls between a control limit and a specification limit, the process may
be out of, or about to go out of, control; further inspection is warranted.
If seven consecutive points of measurement fall above or below the mean but within
the control limits, the situation also warrants further investigation; it indicates there
may be something about to go wrong with the process.
The following diagram shows a control chart with all these elements and some quality
data points recorded. Did you notice the seven consecutive points above the mean?

Figure 44: Control Chart

A Run chart plots a particular measurement over time. The following diagram shows
quality data points plotted over time so you can easily and quickly see the trends and
variations occurring.

120
Figure 45: Run Chart

A Pareto chart lists all the potential quality problems and ranks them according to
frequency. By focusing on those problems that cause most of the quality issues, you
can get the best return for time invested. You should direct your energies to those few
problems causing the greatest number of issues.
The following diagram shows a list of problems and their frequency and cumulative
parentage. It shows that just three of the problems are responsible for 80% of the
quality issues.

Figure 46: Pareto Chart

A scatter diagram plots two independent variables against each other. The following
diagram shows data points recorded the correlation between weight in grams and
height in millimetres.
121
Figure 47: Scatter Diagram

Statistical sampling is the process of selecting a small sample of the total production
amount to test it. This is used when it is unfeasible to test the entire run due to the
time taken, the cost of doing so, or destructive testing methods.
If you are interested in reading more about quality management, I recommend
reading about the life and work of W. E. Deming, the father of modern quality
management techniques.

Review Exercises

1. Mark on the scale of 1-10, how important quality is to your projects? (1 meaning
not important at all, 10 meaning that it is absolute critical to project success)

1 2 3 4 5 6 7 8 9 10

2. Which of the tools discussed in this chapter do you think would be useful to you?

1.

2.

3.

4.

5.

122
Chapter 10. Managing Project Contracts

This chapter introduces you to the basics of contracts and the procurement of goods
or services in your projects. At the conclusion of the chapter, you will have an
understanding of the different forms of contract and the importance of proper
negotiation and monitoring of contracts. You may even make some changes in the
type of contracts you currently use.

Procurement Management

There is a high probability that you will engage in some sort of contract to help deliver
your project. You may be the person buying goods or services from another person
or organization. You may also be the person providing goods or services as part of a
larger project. As such, you need to plan your approach to making decisions about
whether you go to the market for goods or services, or provide them in-house. If you
do go to the market, there are a number of questions that need to be answered. How
will you do it? What selection process will you use? What contractual form will you
use? Once again, in order to be professional, you must select the process that best
suits you and your project. Ideally, you want a documented and repeatable contractual
and procurement process for projects, accommodating their size and complexity. This
is one of the easier sections within project management for developing a checklist and
following it.
The process of making the decision whether or not to use an external party is called
the make-or-buy process. When considering the pros and cons of your options, you
need to take into account such things as current expertise, risk, intellectual property
and commitment to the project. All of these factors play in part in making a robust
decision about whether to make or buy.
Once you have made the decision that an external party is best placed to provide
goods or services (as opposed to you providing them yourself), you can begin the
process of deciding how you will advertise your requirements, how you will select the
successful bidder and what form of contract you will use.

The Selection Process

In this section you can think of yourself in one of two ways. You are either the person
advertising for contract services or goods—in which case you are the buyer—or you
can think of yourself responding to someone else advertising for contract services or
goods—in which case you are the seller.
An important part of this process is deciding how you are going to advertise your
need for goods or services. Are you going to advertise publicly in media, trade
publications and websites, or are you going to go to a pre-qualified group of approved
providers? If you often need to go to external providers of goods and services, there
is a lot of merit in having a pre-selection process.
123
This process will require potential providers of goods and service to provide advance
information about their organization, their ability to provide goods or services at the
level of quality and in the timeframe you require, and any other matters you see fit
such as health and safety record, environmental record, past experience and financial
track record.
The most common ways to go to your potential sellers is either with an expression of
interest (EOI) document, a request for proposal (RFP) document, or a request for
tender (RFT) document.
An expression of interest (EOI) document is when you are certain of an issue that needs
resolving but uncertain of the means to do it. You may release an EOI inviting
interested parties to submit information about themselves, their ability to complete
the work, their experience and any preliminary ideas they may have. This lets you know
the state of the market and who may be interested in providing goods or services. You
may even use this process as part of your make or buy decision making process.
A request for proposal (RFP) is used when you have clear idea of what you want and
can describe it in a document, but are open to other ideas if the sellers want to make
suggestion. It is generally used more for the provision of services rather than goods.
A request for tender (RFT) is a very specific request, usually based upon completed
design drawings or fully developed service specification. The material is presented to
the market with the invitation to respond with a price to supply the described goods
or services.
During the between when the selected method is released to potential sellers and
when the submission period closes, it is important to act fairly towards all sellers
involved in the process. You should plan on holding meetings where prospective
sellers can ask questions. All questions should be asked in public and any answers
provided to all parties to maintain a level playing field.
Once you have received responses from interested sellers, you need a way to select
the preferred one. The best way to do this is with a weighted attribute process, where
you decide which attributes are important to you and give each one a weighting. You
may be tempted to go on the basis of lowest price, but there are a number of risks
associated with this strategy: people may bid so low that the job ultimately puts them
out of business, or they might have arrived at a low bid because they aren’t competent
cost or time estimators. Either way, it will have an adverse impact upon your project.
You may consider using an independent auditor to review the submissions received
to check they are accurate.
In addition to price, you might consider previous experience, current personnel, ability
to complete the work in the required time, culture fit, health and safety record,
environmental record, financial stability and any other characteristics you think are
relevant to you. As demonstrated in the table below, this method may not favor the
bid with the lowest price. Seller A has given the lowest price but overall Seller C is the
most preferred.

124
Figure 48: Weighted Attribute Seller Selection

Contracts

I will start this section with a big word of warning here: be extremely cautious about
ambiguously worded contracts full of good intent. Given the possible judicial
repercussions of misunderstandings and breaches, you may wish to bring in a legal
specialist to help draft, negotiate and monitor your contracts.
Take extra care with your contracts to make sure they are clear and, as they are formal
written forms of communication, always make sure that any communications about
the contract or its clauses, including variations, are also done in formal written form.
You may not ever need these bits of paper, but the day there is a contractual dispute
you will be extremely pleased you recorded everything so well.
When deciding on the financial terms of a contract, there are several options available
to you. Broadly speaking, the type of contract you choose to use reflects the
apportionment of risk between buyer and seller in the relationship.
A fixed price contract puts the risk with the seller as the buyer will pay the agreed
fixed price for the defined goods or services. If the seller has underestimated the time
or effort involved and it costs more to deliver the goods or services, the seller must
wear the extra costs.
A cost reimbursable form of contract spreads the financial risk between buyer and
seller, depending on the exact terms of the contract. Both parties agree that the buyer
will reimburse the seller for the costs incurred; there is usually a margin for overhead
and profit included as well. There are also opportunities to offer incentives for the
seller to come in under an agreed maximum amount.
A time and materials contract presents a lot of risk to the buyer. There is no limit on
the final cost as the buyer has agreed to pay the seller for whatever time and materials
are required to complete the work. The seller has no risk because they can continue
to charge fees until the job is complete with no ceiling in place. This form of contract
is best used on small projects, emergency projects or projects where the scope cannot
easily be defined.
Be aware that not all contracts are created equal with regards to tone and intent. It’s
a sad fact that most contracts attempt to put one party in a position of power over
125
another party. This creates distrust and inefficiencies. It can distort the bidding
process, with the seller deliberately deciding to bid low to win the work and make up
costs on variations once the job is underway. These sorts of lopsided contracts are
also unfortunately the most common. They create an adversarial environment where
neither party fully trusts the other, and where the primary focus is on the money rather
than on the outcome.
There is another way to word contracts that is much more cooperative or collaborative.
There are a number of contractual forms, such as NEC (New Engineering Contract) and
Alliancing, which have at their heart the intention that both parties operate in good
faith, trust, and cooperate towards a common goal. Some alliance agreements even
go so far to remove the possibility of court action between parties. I strongly
recommend that you investigate the use of these more collaborative or cooperative
forms of contract.
The key to setting up a cooperative or collaborative form of contract is to make sure
that, at a personal level, everyone understands the intended outcomes and the
expected way of working together, that everyone can agree to it and can see the
benefits. It takes extra time during the seller selection process to establish this kind of
relationship, and it takes additional commitment from senior management during the
project to maintain it, but these types of contracts have been proven to provide better
results, especially on large complex projects. That extra time is the reason they are
best suited to larger projects. However, we can learn from the cooperative intent
contained within them and seek to apply that same intent to more typical forms of
contract.

Monitoring Contracts

All parties to a contract are responsible for being aware of its contents and for actively
monitoring its terms and conditions. This fact is often overlooked, and not only in the
world of project management. Did you bother to read the contract the last time you
signed a contract for a new credit card, insurance policy, and software package or
airline ticket? Probably not; they’re so long and you aren’t really sure if they’re that
important or binding. The truth is that contracts can have serious consequences; it’s
wise to get in the habit of reading all contracts that you sign and being aware of all
the clauses within them as you could end up in court answering to a judge.
Contracts should always be treated as live documents. Once you’ve decided the type
and tone of the contract you are going to use, agreed the terms with the other parties,
and put ink to paper to sign on the dotted line, you still need to check that work is
proceeding in accordance with what was agreed.
The other reason for monitoring the terms of the contract very closely is that, sooner
or later, there may be a request for a variation to the terms of the contract or the
defined scope of work required by the contract. In either case, make sure all requests
are fully documented. A contract is a formal written document, and all proposed, and
approved, changes to it must also be formal and in writing.

126
If you end up with any disagreements between parties to a contract then there is
generally accepted progression of dispute resolution techniques to try to resolve the
issue.
• Negotiation - the parties try to resolve their differences themselves
• Mediation - the parties bring in an independent third party to help them reach
a mutually agreeable solution
• Arbitration - the parties in dispute agree to use an independent arbitrator to
back a decision which may, or may not, be binding on both parties.
• Litigation - the parties seek a decision in a court of law.

Review Exercises

1. Are you a Buyer or Seller of Goods and Services?

Buyer 
Seller 
Both 

2. Does your organisation use, or respond to, any of the following?

Request for Proposal (RFP 
Tender 
Request for Information (RFI) 
Expression of Interest (EOI) 
NZS3910 
Alliance contract 

3. Choose a recent contract you have been party to and go and read the termination
clauses. What are the main reasons for terminating this contract?

__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________

127
Chapter 11. Project Communications

In this chapter, we outline the importance of good project communications and

explore particular areas of communication. We will end with a sample communications
register. At the end of this chapter, you will have an awareness of the importance of
all forms of project communications and some ideas about how to implement
communications in an appropriate manner to increase the chances of project success.
This chapter should be read in conjunction with the next chapter on Stakeholder
Management as they are very closely related.

The Importance of Good Communication

People are natural communicators, and communication is an essential part of any

successful personal and professional relationship. The world of project management
is no exception. A project manager needs to be a great communicator; in fact, the
success of a project can quite literally depend on the project manager’s ability to
communicate the right things to the right people at the right time in the right way.
The PMBOK® Guide states that a project manager should spend 90% of their time
communicating, with 50% of this communicating with their project team. Get these
things right and you will greatly increase your chances of project success. Get them
wrong, and you’re facing an uphill battle.
The absence of good communication allows rumour, assumptions, and gossip to
flourish. It also sends a strong message to stakeholders that you don’t care enough
about them or their needs to bother communicating with them. If you don’t control
the communication, someone else will, leaving you fighting fires and trying to get
competing messages out. In fact, poor communication has been identified as the
major contributing factor to project failure.
When it comes to the profession of project management, the process of managing
communications isn’t just about the verbal conversations you have or the emails you
send. It is the process of dissemination any information about the project to any of
the project stakeholders. This can be in the form of verbal conversations, emails, phone
calls, memos, meetings, advertising and, perhaps most important of all, the weekly
and monthly progress reports you send out. Also, keep in mind that good
communication management isn’t just about the information you choose to send but
also about the information you choose to withhold.

OPINION: People Skills and Project Management

Nothing matters more in project management than having great people skills.
This statement may come as a surprise to those of you working hard on your technical skills
of time, cost, quality and risk in project management. You can estimate resources, cost and
time to within a 0.5% margin of error; you can use software to produce report after report and
chart after chart; you know the technical specifications of your product better than you know

128
the back of your hand; and you love numbers, spreadsheets and Gantt charts. Aren’t these the
most important project management skills to have? Sure, they are important and you need
these to be successful, but between technical and people skills it the people skills that are most
useful to you as a project manager.
Let me start by recounting an experience I had while managing a large construction project. I
was working on this project and was proud of the fact that early on it was already ahead of
time, ahead of budget and delivering greater quality than expected. I was shocked to be taken
aside by the project sponsor and be told that my project was in no uncertain times considered
a failure! How could this be, on paper the project was doing well? She explained to me that
stakeholders just didn’t know me nor did they trust me. The first because I didn’t build
relationships well and the second because I didn’t communicate effectively.
After recovering from the initial ego bruising I saw that she was right. Despite the project
technically being a great success I had neglected key stakeholders, my communication was
sporadic, ineffective and often sparse; and my focus was too much on the technical aspects of
the project. I made a decision within 24 hours to change to focus of the project from a
construction project to a communications project. We started building and maintaining
lasting relationships with key stakeholders, taking time to find out what was important to
them. I discovered that not everyone is interested in time, cost or quality. Some stakeholders
judge success by other means. We began regular communications using a variety of styles
from face to face, to written. We did all these things regularly, with sincerity and with respect
to the different needs and viewpoints of our stakeholders. Within a short amount of time I
received feedback that my project was now considered a success.
So what exactly are these seemingly mystical magical people skills?
- They are the ability to form and maintain positive professional and personal relationships:
this requires you to truly value people and the interaction you have with them and commit to
maintaining these relationships
- The ability to communicate effectively to a wide variety of listeners this means understating
different points of view, using different styles of communications and receiving feedback
positively.
- The ability to listen empathically – this requires you to understand that other people think
and act differently depending on different viewpoints of the world.
So work on your people skills, give them priority in your project management work and you
will be more successful. A final note though, don’t think that you can be just a great people
person with little or no technical ability and achieve success. I’m sure we have all come across
those people who are exceptionally talented with relationship and communication but have
a lack of technical ability. No amount of people skills can hide technical inability, sooner or
later these people will be exposed as well
So, as a successful project manager you will need both technical skills, and the softer people
skills but it is your ability to form relationships and communicate that will contribute more to
your success as a project manager.

129
A Communication Model

Have you ever played that game where you whisper in someone’s ear and ask them
to pass that whisper along, and then the next person passes it on and so on? By the
time it reaches the tenth person it’s beginning to change slightly. By the time it gets
to the 20th person it has changed quite a bit. This is what happens when trying to
communicate a single simple message. Imagine how this can go wrong in the real
world.
The process of communication of an idea or message isn’t just a simple process of you
forming the idea or message and passing it over to the individual or group you want
to receive it. It’s far more complicated than that.
When you first form a message, its structure and content are based on your
preferences, opinions and particular way of seeing the world. You then send this
message via any one of several different means: verbally, in writing, with pictures,
graphs, or diagrams, via email or phone etc. Each of these different forms of media
comes with its own advantages and disadvantages, and all will allow some form of
interruption to the message. This interruption is called “noise.” Noise in this instance
means anything that can, and does, interfere with the purity of the message being
sent.
Noise can be as simple as someone’s accent or tone of voice. It can literally be
background noise. It can be a verbal message to someone who prefers graphical
reports, or it can be virtual teams. Whatever it is, it interferes with the message.
Once you have decided on your message, encoded it and sent it via your preferred
medium, it arrives at the receiver who then decodes it according to their own
preferences. They may be very selective in what they hear, read, see or experience.
They may receive or perceive something completely different to what you sent.
There a quite a few models and ways to explain the process and potential pitfalls of
project communication. The field of communications is a fascinating one and, if you
wish to improve your understanding of communications and ultimately your ability to
become a great communicator, I urge you to spend time studying this field.
The following model is a simple, easy to understand model that sums up, and presents,
the main roles and impacts of most project communications.

130
Figure 49: A Model for Communications

The model shows a process where the sender, perhaps you as the project manager,
decides to send a message. This can be any idea you want to convey to another person
or organization. You select the information you will send and reject information you
will not send. This decision is based entirely on your preferences and perceived
objectives.
After selecting the message to be sent you then decide how best to send it. You decide
whether the message will be sent verbally in a casual conversation, by written letter,
or by colourful picture. The choice of words and medium is referred to as “encoding.”
The method of delivery is significant and conveys some of your thoughts and beliefs
about the importance of the message and the person receiving it. (For a good sense
of the impact of a chosen medium, think about how you would feel if someone broke
up with you via text.)
Once the message is selected and encoded, it is then sent to the intended audience,
or receiver. Along the way in encounters noise of the form of any effect which begins
to alter the intended message. This can be the medium itself. It can include things like
cultural perceptions and expectations. It can be something as simple as accents.
Anything that can potentially or actually affect the message as it is being sent is
classified as noise.
Finally, the message is received and is available to the receiver for decoding. The
receiver of the message then decodes the message based on their own preferences,
prejudices and filters. Often this decoding process can distort the message quite a lot.
If the receiver decides to pass the message on or to repeat it back, the sender then
goes through the process of encoding it and delivering it via a new medium and the
message is subject to further noise.
You can see that the entire process of communication, from encoding to sending to
decoding a message, is fraught with all sorts of potential frustrations. It takes a skilled
communicator to be aware of these issues. This is true of any form of communication,
whether it is a simple conversation along a corridor, or a formal written report such as
a business case.
There are people who say the onus of ensuring good communication is upon the
sender. I disagree. Any communication is a two way process with more than one party.
I believe that each party in a communication, whether sender or receiver, has an
131
obligation to be aware of the potential pitfalls, their own preferences and prejudices,
and seek to be an active participant in the communication process. The sender must
do what they can to ensure effective delivery and the receiver must do what they can
to ensure they have understood correctly.
You can improve the chances of communications being sent effectively by practicing
and undertaking active listening, effective listening and feedback. Active listening is
the process of making a decision to be actively involved in the communication and to
take steps to be aware of potential problems with the incoming communication.
Effective listening is similar to active listening, and also includes monitoring non-verbal
and physical communication. Feedback is asking for cues from the receiver that
indicates whether or not the message has been understood, and taking the
opportunity to provide further clarification.

Interpersonal Communications

Of all the different facets of successful communications for your project, perhaps the
most important is your ability to communicate on an interpersonal level. This requires
you to be an authentic person who is genuinely interested in people. There are many
skills here that you need to learn to be effective with interpersonal communication.
Here are some of the more important skills and attributes you need to focus on to
improve your interpersonal ability:
• Empathy
• Trust
• Honesty
• Self-confidence
• Clear ability to express yourself verbally and in writing
• Great listening skills and an awareness of effective listening (remember you
have two ears but only one mouth!)
• Awareness and understanding that everyone sees the world differently
• Ability to be an observer and interpreter of other people’s communication
styles and the messages they are sending.
Did you know that when two or more people are sharing information and messages
in person, most of the communication is non-verbal? This might seem a little strange
at first, but it’s true. We humans are fairly advanced at picking up and interpreting all
sorts of subtle interpersonal communication. We observe, often sub-consciously, non-
verbal communication such as attentiveness, body language, posture, etc. We are
skilled at listening to paralingual clues, which are vocal but not verbal and include tone
of voice and volume: how the words are said rather than what words are said.
All of these factors result in our ability to interpret a different message from the one
that may be being sent verbally. If you want an example of this, take a look the movie

132
“The Artist,” a modern silent movie. After watching it, are you in any doubt about the
emotions and feelings being portrayed? You probably picked up on a lot more clues
and messages about the characters and storyline than if the movie featured dialog.
The words can actually distract you from the true meaning.

Reporting as a Communications Tool

Project reporting is the type of communication that most of the stakeholders with an
interest in project progress will receive on a regular basis. It is in these reports that
you outline the progress of the project in terms of finances, scope, time, quality, risk,
and any other matters that the stakeholders need to know about.
You will have different levels of reporting depending on the different levels of
stakeholders. Project team members completing the work may require a higher level
of information on a more regular basis than higher level stakeholders who may get
summary reports once a month. The client may require different information from
sub-contractors in a different format at a different time. These are all factors that will
influence the choices you make in your project progress reporting. You should have
some standard templates that make reporting easy and appropriate. These templates
can define the amount of text, graphs, numbers and even colour that you use to report
on progress.
The frequency, method of distribution (hard copy vs. soft copy, verbal vs. written,
formal vs. informal etc.), amount of information contained, and amount of information
not included and the style of content all affect how different stakeholders view
progress on your project. In order to achieve truly effective communications you may
need to have several slightly different reports with different emphases for different
stakeholder groups.
Here is a list of the typical ways to report project progress to people with an interest
in the project:
• Picture and colour-based project dashboards showing summary information
that can be updated and received quickly. This is a popular method for most
project management software, which is sometimes configured to allow
stakeholders to access certain pieces of information at any time.
• Red, Amber, Green (RAG) analysis is used to quickly convey the status of
different aspects of a project, like time, cost, and quality. Red means trouble,
and you should generally provide an explanation of what you are intending to
do about any aspects coloured red. Amber means there is a potential issue that
is being managed. Green means there are no issues and things are progressing
as planned.
• Graphs are used to display summary information visually and quickly. They can
be bar, line, pie, or other graphs, and are often accompanied by text or numbers
to provide more in-depth information.

133
 • Gantt charts can be a very effective communication tool. While they start out
as a planning tool, they are excellent for communicating progress on many
parameters to the project team or, when rolled up, in summary form to
management teams or external stakeholders.
• Text is of course the standard way to report information on the progress of a
project. Text is a great way to deliver a message in either summary form or as
the primary means of communication in detailed reports and business cases.
However, once you put something in writing and deliver it to the intended
recipient, it is open to a wide amount of interpretation. Keep in mind also that
many people prefer graphical representations that are quicker to process. If you
are going to use predominantly text-based project reporting, you need to be a
very skilled writer.
• Numbers are popular with some people and can often be essential, in the form
of percentages, indices or calculations of some sort. Be aware that numbers can
be easily modified, and can include or omit information to generate a particular
outcome. If you are receiving reports based on numbers, always be prepared
to ask for deeper explanations.
• Photographs are a great way to communicate to people who naturally prefer
visual styles. As is often said, a single picture is worth a thousand words.

Project Team Meetings as a Communication Tool

Project meetings can be a very valuable communications tool that allow the team to
get together to make decisions that allow the project to proceed and succeed. Beyond
making decisions, they are also a useful forum to establish and maintain interpersonal
relationships and define the expected team culture. However, they can also be the
largest waste of time you will ever encounter. Your challenge is to make them a useful
and productive method of team communication and stakeholder engagement.
A good meeting:
• Has a purpose
• Has people who come prepared and stay focused
• Sticks to an agenda
• Generates real value
• Serves as a forum for resolving issues, making decisions and team building.
A bad meeting is one where people turn up unprepared, which includes people who
don’t need to be there, where conversations are held that could or should have been
done before the meeting or left until afterwards, where there is no accountability and
no real reason for the meeting to happen. The room is filled with bored, disinterested
people wishing they were somewhere else. Does any of this sound familiar? If so, then
you’ve probably been in a bad meeting. Think for a moment about the people in the

134
room and their hourly charge out rates. Add these up and you may be surprised about
how much that meeting is costing to run. Are you getting value for money?
Before holding any meeting, can you justify getting these people together? Is a
meeting the best way to get the results you want? Do you know the result you want?
There are plenty of other ways to discuss issues, have debates, exchange ideas, catch
up on personal lives and waste precious time; meetings don’t have to be your first
port of call.
Once you have decided that there is merit in holding a meeting, here are some useful
tips:
• Set a date and time.
• Send out an agenda—and stick to it.
• Set ground rules about meeting attendance, preparation, start time,
participation and finish time.
• Leave non-agenda items for last, or for outside of the meeting.
• Start on time—if you don’t, you let people know it’s ok to turn up late and they
will always turn up late. If people do turn up late, note it on the minutes; they
won’t do it too often.
• Finish on time – if you don’t, people won’t turn up to future meetings.
• Only include the people who need to be there for the time they need to be
there—let them go when their contribution is no longer needed.
• Don’t go longer than an hour—people can’t concentrate longer than that, and
even after 30 minutes you should consider supplying food and drinks.
• Don’t let people talk over each other.
• If irrelevant discussions start, politely suggest people stay behind after the
meeting to discuss or catch up at some other time.
• Have someone take good, concise minutes and circulate them after.
• Follow up on action points to ensure that are being completed.
Too many people schedule a meeting because they think it is the best thing to do
without adequately considering the impact of the meeting on the decision making
process, team culture and project communications. Furthermore, too many people
blindly accept that attending meetings is the best way to achieve results.

Communication with Virtual Teams

The increasing proliferation of communication technologies has made possible the

ability of people in different geographic areas to work together on a project team.
These areas can be different floors in the same building, different cities in the same
country, or completely different locations with different time zones and customs.

135
While virtual teams present us with an efficient use of resources, these gains can be
outweighed by the problems of communicating between people in different
geographic locations. The instant you take people away from face-to-face
communication methods, you increase the barriers to successful communication.
Face-to-face communication is, without exception, always the best means of
communication, as it allows the most complete transfer of information in verbal and
non-verbal forms. The better the communication, the greater the likelihood of
relationships being formed built on trust and clear information flow. The better the
relationship, the better the team work, and the better the team work, the greater the
chance of project success. If not managed correctly, virtual teams can contribute to a
lack of project success.
Here are some tips for dealing with virtual teams;
• Set clear roles and responsibilities for each team member so there is no
ambiguity about who does what.
• Establish clearly documented, expected, and accepted behaviours of virtual
team members.
• Include face-to-face time if at all possible and whenever possible.
• Keep team members informed on how the overall project is going via a variety
of means.
• Don’t let team members vanish; keep them interacting with other team
members.
• Establish clear norms and protocols for dealing with conflicts and be prepared
to act in a proactive manner to deal with them.
• If you have team members in multiple time zones, rotate the meetings times
so everyone has a go at meeting early in the morning or late in the evening.

Your Communications Plan

It’s time to bring together all those things we have considered above to put together
a communications plan that describes and guides your more formal project
communications. The plan generally doesn’t prescribe ways of communicating
casually and verbally, usually focusing more on more formal and planned means of
communication.
The communications plan can be a simple template that you fill out with each project.
You can use historical information from past projects, ask team members, brainstorm
and interview the stakeholders themselves to develop and complete it.
Your communications plan should start with some text describing the overall
objectives of project communications, strategies to achieve these objectives, expected
outcomes and key messages. There can be several of each of these, as rarely is
communicating about a single objective, strategy, outcome or message.

136
Once you have all this documented, you can put together your communications
register for use throughout the project. There are two ways to assemble your
communications register. You can choose to focus on the communication types and
frequency, or you can focus on the stakeholder communications requirements. The
latter choice has a lot of overlap with the next chapter on managing stakeholder
expectations.
A typical method-based communications register contains the following information;
• Types of communication such as, for example, email, reports, verbal, newspaper
releases, posters, meetings or advertising
• The message to be conveyed
• The intended audience
• The frequency of the communication
• The method of gathering feedback
• Who has responsibility
A typical stakeholder-based communications register contains the following
information;
• List of stakeholders
• Description of their interest in the project
• Description of how powerful they are on a scale of, say, 1-5, with 1 being no
power and 5 being lots of power
• Description of either their ability to influence the project, or their interest in the
project, on a scale of, say, 1-5, with 1 being no influence or interest and 5 being
lots of influence or interest
• A prioritized list of the most important stakeholders, derived by multiplying the
power and influence/interest rankings together
• Description of the information they want, when they want it, their preferred
format and who will deliver it to them.
As you will see in the next chapter, it is possible to combine a stakeholder-based
communications plan with the stakeholder expectation management plan.

OPINION: Straight From the Horse’s Mouth

You need accurate information to make sure you are able to track project progress, keep
stakeholders updated and make important decisions. Without accurate information you are
increasing the chances of making wrong decisions, giving inaccurate progress reports and
totally misreading stakeholder expectations. All of these contribute to project failure.
The types of information you are going to want to obtain are both formal metrics for project
progress, opinions from experts and stakeholders, contractual agreements, and also
information communications such as gossip, rumour, and individual opinion. Staying in touch
with the communications that surround a project is an essential skill for a project manager as
137
you must learn to control the communications that are circulating. The best way to do this is
with accurate information. If you use second hand information you run the risk of it being
inaccurate and looking like a fool. Additionally, if you are caught using inaccurate information
then it takes people a while to trust you as a source of information again.
The best way to get accurate information is straight from the source. If you rely on second
hand sources you are running the risk of information being passed on that is affected by all
sorts of potential problems such as natural biases, different communication and listening
styles and political drivers. Always go straight to the source of the information and get if first
hand. If you aren’t getting it straight from the horse’s mouth then you must be getting it from
the other end and we know how reliable that can be.
I heard an urban myth once that there is a culture somewhere in the world that requires any
information to given in conversation to be followed by where exactly the information source
was (if you too read this and can remember the course please let me know). I love this idea
and it’s one that I’ve tried to implement myself.

138
 1.
Category of What How Will We What How Often Will Who Will How Will We
Stakeholder Communications Communicate Information Will We Communicate to Know Its
Do They Need? With Them? We Not Give Communicate? Them? Working?
Them?
Review Exercise

139
Take some time to draft a communications plan using the following categories:
Chapter 12. Managing Stakeholders

This chapter focuses on the process of identifying stakeholders and their expectations.
After reading this chapter, you should understand the importance of stakeholders to
a project, and be able to prepare a plan to identify, manage, meet and perhaps exceed
their expectations. Being successful at managing stakeholders and their expectations
is a great example of practical project management; each stakeholder will have
different needs and it is up to you to decide what is best for each stakeholder. This
chapter should be read in conjunction with the previous chapter on Communications
Management as they are very closely related.

What is Stakeholder Expectation Management?

Before proceeding, let’s revisit the definition of a stakeholder: A stakeholder is anyone

who can affect or be affected by your project, and can also include even those who
just perceive they will be affected. A stakeholder can be an individual, a group or an
organization. Your stakeholders on your project are going to be your project team,
perhaps a wider project team of people working on the project, the client, suppliers,
and contractors, members of the public, local government and any other interested
individual or organization. Knowing what information your stakeholders need to keep
them working towards your project goals—or at least not getting in the way—is an
essential part of your project communications planning.
Managing the expectations of stakeholders on your project can be quite a large job.
But why bother with managing stakeholder expectations at all? Surely, if you just do a
good job, the results will speak for themselves? Unfortunately, this isn’t always the
case. You may deliver a project that gets top marks for cost, time and quality, but is
deemed a failure by stakeholders, either because they care about different matters or
because they haven’t felt any involvement in or ownership of the project.
The process of stakeholder expectation management is a two-way one, where you first
understand what is important to the stakeholders and then increase the chances of
project success by ensuring the stakeholders clearly understand and support the goals
and objectives of the project. Understanding their expectations allows you to act
proactively to ensure they support your project instead of obstructing progress.
A key to stakeholder expectation management is the word ‘management’, which is an
active word. We use it in the profession of project management to mean actively
controlling a project. Managing stakeholder expectations has a similar meaning. You
are responsible for understanding, influencing, modifying, meeting, and even creating
the expectations of your stakeholders in a proactive manner.
You may want to consider adding a measure of stakeholder satisfaction during and
after the project as one way of assessing the success of the project. You can measure
stakeholder satisfaction through your own observations, the number of complaints
and compliments received, structured meetings, and written feedback and surveys.

140
Before you can manage something, you must first know what it is. Begin the process
of managing stakeholder expectations by finding out exactly what those expectations
are.
You have many ways to manage the expectations of your stakeholders. You
communicate with them, negotiate with them, and influence them. All project
managers should be skilled communicators and influencers. You want to be able to
use your influencing skills to proactively manage the expectations of stakeholders on
the project. Be aware that there is a fine line between influencing and manipulation;
don’t be tempted to cross it. Influencing requires great interpersonal skills such as
empathy, persuasion, honesty, authenticity and the ability to motivate people, while
manipulation involves a degree of dishonesty.
As with many other processes in project management, managing stakeholder
expectations is not a one-off process. It is on-going and requires continuous dialogue
to ensure stakeholders remain engaged and their expectations are known and met.
For all projects you should put together a stakeholder register which lists all the
stakeholders, their interest in the project, their expectations from it, and perhaps some
notes on how you will manage them. There is obviously an overlap between the
stakeholder register and the communications plan, and it is possible on smaller
projects to have a single combined stakeholder register and communications plan.
If your project is large enough to have many stakeholders that need managing, you
may wish to consider putting together a robust stakeholder management plan. The
stakeholder expectation management plan, like the communications management
plan, sets out the key areas for managing stakeholders and their expectations.
If you do decide to assemble a professional stakeholder management plan, you can
include an overview of how you will collect information about stakeholders, who will
take responsibility for monitoring the plan, what the desired level of stakeholder
engagement is, what the interdependencies between stakeholders are and what the
specific communication needs are for each stakeholder. Take care, as some of your
stakeholder assessments and strategies for dealing with their expectations may be
quite sensitive information.

Identifying Your Stakeholders

You want to be able to document each stakeholder, their contact details, and their
interest and involvement in the project. Additionally, you will want to note any
interdependencies between stakeholders and assess which stakeholder can influence
other stakeholders. With this information, you will be able to decide the appropriate
level of effort to assign to managing the expectations of each stakeholder.
Meet with your project team members and have brainstorming sessions to identify
potential stakeholders. During this time you can also rank stakeholders qualitatively,
in terms of power and interest they may have in the project.

141
Another place to look for stakeholders is the lessons learned from previous projects.
You may also ask stakeholders to identify themselves through some sort of
announcement about the project. The process of identifying stakeholders is on-going,
as new stakeholders can become interested in your project at any time, and existing
ones can lose interest.
The stakeholder register is the place to store all the information you gather. The
stakeholder register can list names, contact details, expectations, requirements, ability
to influence and any specific management strategies.
The following diagram shows some possible headings for a stakeholder register.

Figure 50: Stakeholder Register

Engaging Your Stakeholders

If a stakeholder isn’t engaged with your project, it is more difficult to manage their
expectations. You can describe their level of engagement and chart where they are
currently at and where you would like them to be. You can focus your efforts on those
stakeholders who have the greatest gap between where they are and where you want
them to be. A standard way to describe levels of stakeholder engagement is
• Unaware of the project and its objectives
• Resistant to the project objectives
• Neutral and neither supportive nor resistant
• Supportive of the project objectives
• Leading and committed to ensuring the project is a success
The following table shows how you can plot each stakeholder and their current and
optimal level of engagement.

Figure 51: Stakeholder Engagement Matrix

142
Increasing the engagement level of stakeholders is a tailored exercise unique to each
stakeholder. Engagement begins with the communications process, and each
stakeholder will have different communication needs. Consistency, appropriateness,
openness, respect, empathy and listening are key elements in ensuring both
communication and engagement levels are high with any stakeholder.
Being a good communicator means knowing what your stakeholders expect of the
project and what information they want. Being a great communicator means also
being aware of the need to proactively include stakeholder expectations to benefit
your project.
Your job as a proactive influencer of stakeholder expectations requires you to
understand exactly what it is each stakeholder wants, and needs, to know about the
project and then give that information in the right way, at the right time in the right
format. Keep in mind that there is a fine line between being a proactive influencer of
stakeholder expectations and a manipulator. The former is good; the latter isn’t good.
Make sure you know where to draw the line.
OPINION: Influencing is Not a Four Letter Word
As projects managers we are supposed to be master of many things. We are supposed to be
great with our technical skills when it comes to defining scope, estimating time and cost, and
managing change. We are also supposed to be masters of soft skills focused on
communications and leadership. In addition to these essential skills we must also master the
skill of influencing.
However, whenever I mention influencing as a key skill to people, I get either a stifled
uncomfortable laugh or a blank look. Those who offer stifled laughs think that I am saying
they should become master manipulators of people, changing their opinion against their will.
Those who give me a blank look simply don’t understand what influencing is or the
importance of it to a project manager. Influencing is not a four letter word that should be
avoided. It is a necessary skill that a project manager must master in order to increase the
chances of project success.
The difference between influencing and manipulating is quite simply the difference between
honesty and dishonesty. Influencing is about being open with your intentions and changing
people’s perceptions and actions by authentic, honest and respectful means. Manipulating
involves dishonesty, deception and a more often than not, some ulterior motive that may not
benefit the person being manipulated. Manipulating may work in the short term but in the
long term it will probably come back to haunt you, if not in terms of project results then
certainly in terms of your reputation.
We all have stakeholders involved in our projects, and these stakeholders can affect the project
in many ways. Our job as project managers is to proactively influence these stakeholders to
maximize the chances of them offering support to the project or at least not actively
undermining the project.
How we do this is by three main ways.
Build relationships with stakeholders so that they understand how you see the world and you
understand how they see the world. Shared experience and a mutual understanding and
recognition of others is a key factor in successful influencing

143
 Model the actions and behaviours you want to see. People respond very well to what they see
in others. Make sure that your words and actions are aligned. Don’t say one thing and do
another, it will confuse people and you won’t be successful at influencing them.
Motivate people with a compelling and inspiring message. Use verbal persuasion, your project
reports, team meetings, external communications and all other forms of communications as
means to sending a consistent message. Reward people with encouragement and praise when
they start to adopt the message you are sending.
Being proactive with your influencing means considering what you want to do, the outcomes
you are aiming for and the people who you will target before you set out to influence people.
You should have a clear picture in your mind of what you are trying to achieve and the
messages you will use to do this. Keep in mind that a particular style of influencing that works
on one stakeholder may not work on others.
You may as well become proactive, purposeful and good at influencing because you are doing
it whether you like it or not. You already influence, albeit without purpose, in your choice of
communications, reports, face to face contact, and implicit and explicit messages sent. Take
your influencing skills to the next level and increase your chances of project success.

The following chart can be used to plot the relative positions of the stakeholders once
you have determined their power and influence rating. There are many ways to assess
the influence of stakeholders as well as power and influence. You can also chart their
power and interest, their influence and impact, or their ability to impose their will and
the urgency of their engagement. You will want to monitor those with little power or
interest, keep satisfied those with high power but low interest, keep informed those
stakeholders with low power but high interest, and closely manage those stakeholders
with lots of power and lots of interest.
The following matrix shows how you can determine who should be most closely
managed. Simply plot each stakeholder on the matrix in terms of their power and
interest in the project to see where they fit.

Figure 52: Stakeholder Management Ranking

You can see that by plotting the location of each stakeholder on this matrix you can
achieve a prioritized list of stakeholders and carefully manage those with most power

144
and interest, while devoting less time and effort to those that just need to be
monitored, mainly for any changes in power and interest, or potential issues.
Another way to categorize stakeholders and their importance to your project is with
the salience model which categorizes stakeholders according to their power,
legitimacy and urgency as either dormant, dominant, discretionary, definitive,
dangerous, dependent or demanding.

Figure 53: Salience Model

Like all other aspects of project management, once you have identified your
stakeholders and developed successful strategies for influencing them you must
continually monitor your stakeholder expectation management activities and check
that was is occurring it what you thought would occur. You are also always looking
out for new stakeholders or changes in the categorization of existing stakeholders and
adjusting your plans accordingly.

SPECIAL SECTION: Engaging With Iwi - Best Practices For Project Managers
Effective stakeholder and communications management is pivotal for project success. In New
Zealand/Aotearoa, this involves the culturally sensitive process of iwi (tribal) engagement.
Engaging with iwi is both a legislative requirement and an ethical responsibility. This guide
provides project managers with the best practices for effective iwi engagement.
1. Understand the Treaty of Waitangi/Te Tiriti o Waitangi
Te Tiriti o Waitangi, signed in 1840, is New Zealand’s foundational document. Its principles
of partnership, participation, and protection guide the relationship between the Crown and
Māori. Understanding these principles is essential for anyone engaging with iwi.
Recommendation: Familiarise yourself with Te Tiriti o Waitangi, its principles, and its
implications for your project. Training courses and resources are available to deepen this
understanding.
2. Recognise the Diversity of Iwi

145
Each iwi has its own traditions, history, and priorities. Avoid the mistake of assuming that all
iwi have the same interests or perspectives.
Recommendation: Research the specific iwi connected to your project. Understand their
history, values, and their previous engagements on similar projects.
3. Recognise and Respect Cultural Values
Values such as kaitiakitanga may influence iwi perspectives. Recognising and respecting
these values can lead to innovative project solutions that benefit everyone.
Recommendation: When assessing project impacts, consider cultural values and how they
might intersect with the project’s objectives. Where possible, align project outcomes with
these values.
4. Early and Continuous Engagement
Begin your engagement as early as possible in the project lifecycle. Iwi involvement from the
outset ensures that their insights, concerns, and knowledge inform the project’s direction.
Recommendation: Develop an iwi engagement plan at the project initiation phase, detailing
how and when iwi will be consulted.
5. Cultural Competency
Understanding of tikanga Māori, mātauranga Māori and te ao Māori. This shows respect
and ensures that meetings and communications are carried out appropriately.
Recommendation: Engage cultural advisors or kaumātua (elders) to guide the project team.
Encourage team members to attend te reo Māori courses or cultural competency workshops.
6. Build Relationships
Iwi engagement is not just a tick-box exercise; it’s about forging meaningful, long-term
relationships.
Recommendation: Identify key representatives or kaumātua within the iwi who can act as
main points of contact. Engage in face-to-face hui and be present in marae when invited.
Showing respect and commitment in this way fosters trust.
7. Effective Communication
Effective communication is two-way. Listen actively to iwi concerns and ensure you provide
clear information about the project.
Recommendation: Use various communication channels - from hui to written
communication. Ensure any written materials are clear, accessible, and translated into te reo
Māori if necessary.
8. Collaboration
Move beyond consultation to collaboration. This means actively involving iwi in decision-
making processes, rather than just seeking their feedback.
Recommendation: Establish joint working groups or committees with iwi representatives.
This provides a platform for co-decision-making and ensures the project benefits from iwi
knowledge and insights.
9. Transparent Feedback Mechanisms
It’s important that iwi see the impact of their feedback and understand how it's being used.

146
Recommendation: Create a transparent mechanism to show how iwi feedback has
influenced project decisions. This could be in the form of regular reports, hui, or updates.
10. Monitor and Evaluate
Continuous improvement is vital. Regularly review and assess your iwi engagement
processes to ensure they remain effective.
Recommendation: Include iwi representatives in post-project reviews. Seek feedback on the
engagement process and implement improvements in future projects.
In conclusion, effective iwi engagement is not just about fulfilling a statutory obligation. It’s
an opportunity to enrich a project with local wisdom, build strong community relationships,
and ensure projects align with a range of values. By following these best practices, project
managers can navigate iwi engagement in a way that respects cultural heritage and
maximises the potential for project success.

147
Review Exercise

Use the following combined stakeholder and communications register to plan how
you will manage and communicate with stakeholders on a current project:
Who?
Frequency?
How?
What Info?
(1-25)
PxI
Impact
(1-5)
Power
(1-5)
Project Interest
Contact Details
Name

148
Chapter 13. Managing and Leading People

This chapter focuses on understanding the importance of project leadership,

developing your own leadership skills, and applying those skills to leadership of
project teams. The success of your project is directly tied to your ability to get, keep,
and develop the right people. This chapter will prepare you to manage and lead
project teams.
The preceding two chapters and this chapter focus on what is commonly referred to
as the “soft skills” of project management; for many people, these can be the hardest
skills to relate to, particularly if you have come from a string technical background
such as engineering or IT.
They are also the most important skills to acquire and master if you want to lead,
manage and communicate with people working on and affected by your project.

Managing Project Team Members

Projects are not planned, executed and controlled by robots. They are completed by
people, pure and simple. Managing these people is a key factor in project success, and
a key factor in good people management is being a proactive manager rather than a
reactive one.
Managing people starts with the execution of your human resources plan and really
kicks into high gear once you have people assigned and recruited to your project. To
manage successfully, you’ll need an understanding of the more important
management theories, but management isn’t simply the application of one theory or
another; it’s a commitment to proactively manage people in the best and most
appropriate way. Below are some of the more popular theories and brief high level
explanations of each. You’ll find further reading on these or any others on the Internet.
A quick word of warning, though; many technical specialists who are promoted to
management level find it difficult to let go of their technical role and focus on being
a manager. But just as a technical role demands that you study, learn, practice and
apply the technical skills, so too does a management role. The more you study
management skills, apply them, and learn from your successes and mistakes, the
better manager you’ll be.
The biggest management challenge is usually identifying the people you need, the
skills they need to have, the way you are going to get them, the way you are going to
reward them, the way you are going to retain them and, because we are talking about
projects with a defined life span, the way you are going to release them at the end of
the project. To do all of this, you need a human resources plan. That plan will guide
all these actions and give you a checklist and a baseline to work to. The human
resource plan can be as big or small as your project requires. If you’re working on a
small project with a small plan, the simple act of consciously thinking about who you

149
need, what skills you need, and when you need them will improve your management
skills straight away.
If your project is a large one, requiring a complex human resource plan backed up by
a dedicated human resource team, then there are many more reasons to ensure that
you have it all planned and that you execute the plan as documented. Whether small
or large, a good human resource plan should appropriately cover the five R’s of
managing people on a project.
The Five R’s of Project Human Resource Management
1. Recognize the skills, experience and attributes you want in team members
2. Recruit the right people at the right time
3. Reward them appropriately
4. Retain them with development plans
5. Release them from the project when their skills are no longer required

Recognising Who You Want

The process of managing project team members begins before they are even working
on the project. It starts with the decisions you make about whom you need, what skills
they must have, when you are going to need them and how you are going to get
them. Recognizing the people you want is an active process, where you proactively
and objectively decide on the skills, experience, attitude, and other key attributes you
want in a project team member.
Obviously, the more defined your project scope statement, the better your knowledge
of the skills you need will be. This is why this process can be quite iterative; you may
not know all the skills your project requires until the scope is fully defined. Given the
often long lead times in acquiring people with the right skills, it pays to begin this
process as soon as possible. This is one of the project management processes that
really pays off, as making an ill informed decision about who you want can lead to
major problems later down the track.

Recruiting the Right People

Once you have decided what sort of person you want for the project, you have to
figure out how you are going to get them. At this point, you should know whether
you’re going to get them from elsewhere in the organization, advertise through the
Internet, or headhunt them. You should also know the sort of interview process you
will go through. These are all important questions, and once you have answered and
documented them you’ll have a plan of action about how you are going to get the
people who will be doing the work.
As part of the process, you also need to consider employment conditions such as
whether they will be an employee or contractor, how much you will pay them, how

150
are you going to review their performance, what rewards you will offer and other
incentive plans. Once you have all this information, you can go ahead and get the
people you need as per the plan you have made.

Rewarding Your People

Getting the right people is only half the equation, though. The next step is keeping
them, by providing the things they need to work for you and not your competitor. This
includes both rewarding them appropriately and retaining them with development
plans.
Rewarding people is not simply about paying them money. You would be surprised at
how many people work for reasons other than money. People work for self-
satisfaction, pride, friendship, excitement, professional development and to make a
positive contribution. The payment of money is definitely important, but take a look
at the number of people who volunteer outside of work hours. For highly skilled
professionals, money may not be the primary driver in their decision to work with you.
In fact, there is a growing body of evidence that once you get over a certain level of
income, money becomes less of a motivator.
The key point here is that, in addition to financial rewards, you need to seek out what
other drivers your staff have for working, and find a way to provide those as part of
the remuneration package. Perhaps they want more autonomy, flexible working hours,
a defined career path, mentoring or a different working environment. Finding out what
they really care about will not only allow you to reward them appropriately, but also
contribute greatly to the process of retaining them.
There are a number of sound management theories about what really motivates
people. Some of the better known ones are Maslow’s Hierarchy of Needs, Herzberg's
Motivation-Hygiene Theory, and McClelland’s Achievement Theory of Motivation. My
own personal favourite is the work done by Dan Pink on what really motivates people,
which you can find online easily by doing a search on YouTube for Dan’s RSAnimate
talk on the surprising truth about what motivates us.

Retaining Your People

Retaining your project team members is critical to long-term success as a project

manager. Chances are, if you think someone was a good person to recruit, then
someone else does as well. The process of retaining someone is about keeping them
engaged in your project while they do the work required of them. Additionally, it is
generally accepted that it costs more, in terms of money and time, to lose someone
and recruit a replacement than it does to ensure the person stays with you in the first
place. As discussed above, it’s important to reward them appropriately, but the
process of retention is bigger than just rewards. It includes explicitly considering the
things that are important to them as an individual. Keep in mind that one person’s
reason to stay may be another’s reason to leave.

151
Your goal is to keep them engaged; you can do this by considering such things as the
work environment, organizational culture, opportunities for professional development
and level of autonomy. Generally speaking, the people working on projects are highly
skilled, intelligent and professional people who will respond well to explicit
consideration of these matters and as result will be more engaged, with the final result
being lower staff turnover.
An optimum time (but not the only time) to discuss these things directly is during
regular performance reviews. It is common for performance reviews to be seen as part
of operational work only and not part of project work. If you are serious about
developing your project team members, you need to schedule in regular reviews of
their work and provide feedback to them. Additionally, it is a good chance for a more
formal discussion about what their plans and aspirations are.

Releasing Your People from the Project

The nature of projects is that they have a defined end. More than that, each of the
work packages or activities has a defined end. The people employed to work on your
project will, sooner or later, have no more work to do. Even your role as project
manager will end. The process of releasing project people is built around this fact; it
involves dealing with it in a proactive manner to ensure team stability. If you don’t
explicitly acknowledge that the role will end and provide some way of helping people
with the transition into a new role, you will have to deal with people either jumping
ship before their work has ended, or hanging around—and charging—after their role
is complete.
One of your jobs as project manager is to acknowledge that everyone’s job on the
project comes to an end, plan for it and take the appropriate steps when the time
comes to release people. For some people it will be a stressful time; for others it will
be a time of opportunity. Your remaining project team members will judge you on
your ability to release people in a thoughtful and considered manner. Additionally,
there may be contractual and financial issues to be resolved at this time as well.
As part of explicitly considering the end of people’s work on a project, you may want
to start looking for other work for the person within your organization or even on your
next project. You can let other project managers know when members of your team
will be available and what their skills are. You may also want to assist people in
applying for positions at other companies.
When a person does leave your project, it is your responsibility to ensure they are
farewelled in an appropriate manner. Simply letting them disappear without an
acknowledgment of their role in the project will have an adverse impact on the
remaining team members.

152
Creating a High Performing Team

So far, we have focused on the proactive management of individual people. Of course,

once you have more than one person working on your project you have team forming.
Managing a team requires a similar set of skills as managing an individual, but with a
slightly different focus. This focus is on the interactions between individuals in the
team and the team as a performing organization. Your goal in managing a team is to
get a group of individuals to work together for the good of the project. The rewards
of getting a well performing team on your project are huge, while a poorly performing
team will dramatically decrease your chances of project success.
A highly performing team will:
• Share a sense of common purpose
• Make effective use of individual talents and expertise
• Have balanced and shared roles
• Have a team culture that values a problem solving focus
• Accept differences of opinion and expression.
All of these elements can be expressed and reflected in the team culture, which you
should actively seek to develop and maintain. If you don’t actively develop and
maintain your desired team culture, the one that arises in the vacuum may not be the
one you want. There will be unique elements to each project team that reflect your
particular project, but the characteristics listed above apply across the board and
increase team efficiency.
Achieving a high performing team culture is easier when there are ten or fewer team
members; once you get above that number, there is the potential for cliques and
subgroups to develop. Factors like voluntary team membership, long service and full-
time appointment on the team also contribute to a high performing team. As the
project manager, you will have a much greater chance of succeeding in your efforts to
build a high performing team if the team members only report to you, rather than to
you and a functional manager as well.
In this age of increasing technology remote teams, keep in mind that the highest
performing teams are generally those that sit within speaking distance of each other.
Being in close proximity allows for relationships between team members to be
developed more quickly and conflict to be resolved more easily. If you can, get all your
team members to work in a shared space, even the ones who are contractors with
other companies. Try to form your own team culture, rather than accept many different
team cultures on the project.
The Tuckman five-stage model is a convenient way to describe the stages a team of
people will go through: forming, storming, norming, performing and adjourning.
Although many models show them as linear stages in team development, this isn’t
always the case; any of the behaviours can be observed at any time. The key point

153
about the model is that your goal is to get your team to the performing stage and
keep them there with proactive people and team management.
The following diagram shows the different stages on the model against performance
and time. Although the diagram may indicate an unstoppable linear nature of the
model, the reality is that team dynamics can be highly unstable and teams will always
be in danger of slipping backwards into storming behaviours.
When a group meets for the first time, or new people join a group, there is a period
of forming as everybody tries to figure out who the other members are, what common
interests they share, where they sit in the hierarchy and what their role in the team will
be.
Fairly soon after a new team forms or a new person joins the team, you will witness
storming behaviours. This is the phase in which the team has to work out what
direction they will all be going in, which ideas take priority, and which ideas will be
cast aside. This phase is often one of conflict and argument; it can also include passive
aggressive behaviour as people within the team jostle for position and power. You will
also see storming behaviours in the life of an established team when conditions
change. While storming is essential, the core issues must be resolved to allow the team
to fully move beyond it.

Figure 54: The Tuckman Five-Stage Model of Team Development

If you observe dysfunctional conflict between team members, it is essential to get to

the root cause in a proactive manner. Don’t be tempted to look the other way or
simply sweep it under the carpet. It won’t go away and will continue to fester, causing
problems and preventing your team from performing at its best. Deal with conflict
openly and in a professional manner. If you find you’re not getting to a resolution and
the issue threatens to escalate, consider bringing in external assistance. You should

154
only consider removing the team member responsible for the conflict as a last resort,
if the issue truly cannot be resolved.
Norming is the process when the team members explicitly and implicitly define and
accept team behaviours and norms. Norming should be the outcome of the storming
phase. During the process of norming, if the issues from the storming phase haven’t
been dealt with, it will be very hard for people to settle down into a normalized culture.
Performing describes the state where the team has moved through the other phases
and begins to achieve a high sense of synergy. This is not a static state, however; it’s
threatened by things such as conflict, team stability, team culture, and external
influences. The goal is to keep the team at this stage with constant attention and effort.
Adjourning is the final stage for groups, particularly in project management.
Recognizing and planning for this stage is an important part of the job of the project
manager. As already mentioned, the way in which you bid farewell to team members
communicates a very strong message to team members who are staying.

The Difference between Management and Leadership

As a successful project manager, you will need to develop and display both your
management and leadership skills and abilities throughout your project and your
career. Understanding the difference and overlap between the two is crucial. So far in
this in book, I have focused on the process of managing, built around having a plan
in many different areas and following it, checking progress along the way.
Management is charged with executing the plans of the leader and monitoring the
work required to achieve the vision. In a project setting, you show your leadership
skills by drawing people together and inspiring them to work toward your project
goals. From a management point of view, it means making sure all the work that has
to be done is carried out by the people responsible for doing it.
Leadership is built around having a vision and being able to take people towards that
vision. It is the ability to motivate and inspire people. It is also about understanding
the relationship that exists between leaders and followers. Leadership is the
purposeful influencing of followers. Being purposeful also means being self-directed.
It involves the leader having a clear vision that they can articulate and use to influence
people to follow.
The most important part of leadership is the followers; without followers there are no
leaders. Followers can set out the terms and conditions under which they will allow
themselves to be led, and if they don’t like the leader they can metaphorically and
literally revolt. A good leader is aware of this relationship and seeks to understand
what the followers expect. On the flipside, being a good follower demands that you
let your leader know what you require from them, and also that you have a
commitment to being a good follower. Without one, the other does not exist.
Leadership can be learned through study and application. It is not some sort of innate
skill that you either have or haven’t got. Just like brain surgeons or Olympic athletes,

155
leaders study, practice and learn. As part of your own personal and professional
development, it’s important for you to develop your leadership skills.
Leadership within the profession of project management is situational and utilizes
different core competencies depending on several contextual factors. The range of
emotional, technical, managerial and intellectual competencies is described differently
depending on which particular leadership model you are using. When you’re a
practical project manager, you must adapt the mix of skills you display to suit the
situation.
However, a good leader will work on all the competencies and be able to use them
when necessary. You will probably have natural strengths that you should use
whenever you can. However, you should also identify your weaknesses as a leader and
work on improving them over time or creating systems to compensate for them. A
great place to determine what your strengths are is the VIA Character Strengths test
which you can take online at www.viacharacter.org. Once you have taken the test and
gained some insights into your top 5-7 strengths, take some time to think about how
you can display this in your own leadership style.
Leadership demands that you are authentic; you cannot fake the required
competencies and behaviours. As a leader, you must be true timber and not a thin
veneer. The need for an authentic personal foundation is central to leadership, as you
will almost certainly face times for which there is no manual and for which you will
need to draw on your core values. A strong, authentic, personal foundation is constant
in all leadership situations and without a strong personal foundation the dark,
narcissistic side of leadership can take hold.
OPINION: The Absolute Importance Of Integrity
Are you a person with integrity? Seems like an easy question to answer, but is it?
Integrity means having a set of values and sticking to them, no matter what.
So to start with you have to have a set of values. Values are those things that you hold most
important in your life. They form the foundation of an authentic life. Lots of people say they
have values but do they really?
It’s easy to say you value honesty but then be less than honest when you think the situation
warrants it. In a professional setting you may not be completely honest with a client about
the fees, scope of work or issues you may face hoping that somehow it won’t be exposed along
the way.
It’s easy to say you value family but then work long hours at the expense of time with the
family. What about saying you value an author’s right to copyright then sharing copyrighted
works with others? Saying your business is driven by helping the customer then being driven
by the need to generate fees? Saying you value openness then participating in gossip? These
are just some of the many examples that test our integrity.
Shared values are what bring people together. A high functioning professional team needs to
have shared values and be led by a leader who demonstrates those values. A group of friends
is held together by their shared values that from the way they see the world. If you don’t stick

156
 to those values then people will know you are not a person of integrity and they may choose
to take their business elsewhere.
Be aware that having integrity means you will lose things sometimes - you will lose contracts
because you have been absolutely honest about the issues and the pricing, you will lose friends
because you don’t share their values, and you may chose not to go into business with someone
because you do not see your primary purpose in the same way. These losses are real, and they
will be uncomfortable. They long term benefits outweigh the short term losses. You will
develop a reputation as someone who can be trusted, someone who is authentic and you will
eventually end up surrounded by those who share you values driven outlook on life.
So if you want to be a person of integrity then you have to stick to your values no matter what.
Start the process by explicitly stating what or values are, write them down if it helps. I met
someone a few years ago now, who printed their values out on a small piece of cardboard
that fit inside his wallet and he carried them around with him. Remind yourself of your values
in all your decisions. Be prepared for the consequences - you may have to change your stated
values if you don’t like the consequences.
In a professional setting look to the code of ethics set out by your professional association. If
you are a project manager then you should read, remember and act on the standards in the
PMI Code of Ethics and Professional Conduct (http://www.pmi.org/About-
Us/Ethics/~/media/PDF/Ethics/ap_pmicodeofethics.ashx) at all times.
Most importantly, be a person with integrity. As Dr Seuss’s Horton the Elephant said "I meant
what I said and I said what I meant...an elephant's faithful 100%."

A quick word on power; as a manager or leader you will be given power over others.
Power comes from many formal and informal sources. Power needs to be wielded
wisely so that it is used for the benefits of employees and followers. Unfortunately
there is a dark side to power. As a leader or a manager you must have an absolute
sense of integrity and a sense of what is right and wrong. Always be on your guard for
any small slippages in exercising that power. People who are brought down by the
misuse of power always start with small abuses.
My final word on the topic of leadership is to ask the following questions of you:
• Think about a time in your life when you have accepted a leadership role and,
as a result of you being the leader, things went really well. What behaviours,
characteristics and traits did you display as a great leader? What do you hope
your followers would say about your leadership style?
Your answer: ________________________________________________________________

• Think about a person in your life who has inspired you with their leadership.
What was it about this person that you admired? What lesson did this person
teach you about leadership that you would pass on to someone wanting to be
a great leader?
Your answer: ________________________________________________________________

157
Review Exercises

1. Think about a time that you have been part of a high performing team - what was
it about that team the defined it as high performing?

2. Its time to find out your strengths and how you can apply these to your unique
leadership style. Go to www.viacharacter.org and complete the free Character
Strengths test. When you get your results take some time to answer the following
questions:
a. What are your top 5 strengths?
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
b. How can you use these in your leadership style?
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
c. What are your bottom 5 strengths?
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________
d. How can you work on improving these?
__________________________________________________________________________________________
__________________________________________________________________________________________
__________________________________________________________________________________________

158
Chapter 14. How to Build Your Own Project Management
Methodology

The focus of this chapter is to bring together everything the book has covered to date
and put it all together as a customized, tailored and appropriate project management
methodology.
As a project management consultant I have often been asked to provide clients with
an off-the-shelf, or readymade, project management methodology. In one sense this
is good thing as it shows a commitment to increasing project management maturity
within an organization. However, I have come to see it as a liability and in fact
counterproductive and very rarely contributing to an increase in organizational project
management maturity.
Too many organizations view an off-the-shelf, or readymade, project management
methodology as the easy answer to all their project management problems. They
assume that if the pay the licensing fee, send people to get accredited and put up
colourful posters around the workplace that people will actually use the methodology,
that the methodology is right for them and that as a result they will have a huge
increase in successful delivery of projects.
They seem genuinely surprised when no one uses the project management
methodology and there is still a lack of consistency and maturity. This also does a
huge disservice to many fine off-the-shelf, or readymade, methodologies that are
available. They are really quite good but they aren’t as good as your own tailored
methodology and the process of developing it yourself.
The alternative to an off-the-shelf, or readymade, methodology is to instead spend
the time and money set aside for licensing and accreditation fees to develop your own
tailored project management methodology. The results will be better suited to your
organization and longer lasting because you developed it yourself, using your own
language and created your own champions.

What Exactly is a Methodology?

A methodology is an appropriate, professional, repeatable, standardized, discoverable

and documented collection of processes, tools, technique and template for managing
projects. The methodology is what you use to deliver your projects.
It should reflect the size, complexity and industry of your projects. It should be based
on best practice such as a body of knowledge like the PMBOK® Guide or standard
such as ISO21500. It should be easily located and understood by all project team
members. It should also be subject to the process of continuous improvement to make
sure it is kept up to date with any changes.
A methodology is your organizations’ particular collection of processes, tools and
techniques and templates that you choose to use. Tailoring is the processes of
choosing which of these are appropriate to use on any given project. One size doesn’t
159
fit all. Your methodology doesn’t suit my projects, additionally your methodology also
doesn’t suit all your projects. Therefore, it should also be flexible and scalable enough
to be able to be used on all your projects.
This must be kept in mind when developing or changing your project management
methodology.
You may in fact have several versions of your methodology and choose the particular
version to use based on factors such as project size and complexity. The following
matrix shows how you might start your projects by choosing which version of your
methodology to use.

Figure 55: Methodology Selection Matrix

Within your organization it is the project management office (PMO) that is responsible
for developing, monitoring and improving your project management methodology.
However, it is the individual users of the methodology that must agree to adopt, use
and improve it so having them onside and involved during the creation of your
methodology will improve it.

Agile vs. Traditional

When looking at what style of methodology you should choose there are lots to
choose from and it can be quite confusing. Do you want what is often called a
traditional or predictive methodology that slowly winds its way through well-defined
stages and phases, or do you want a fast moving Agile, or adaptive, methodology that
can handle a constantly changing scope?
The main difference between the two ends of the spectrum, and all points in between,
is the speed of iterations and the amount of certainty in the project. Traditional
methodologies move through their iterations slowly and usually have very well
defined project. Agile methodologies move through their iterations extremely rapidly
in comparison and deal with much less certainty. Apart from that the methodologies
actually have a lot in common. Have a look again at the PDCA figure 3 in chapter

160
earlier in this book. It outlines a broad framework for the project lifecycle and also for
a methodology regardless of whether it is traditional or an Agile one.
They each feature an initiation process, they each have a formal authorization, they
each estimate time and cost albeit in often vastly different increments and they each
control changes and formally close a project. They also share a focus on quality, risk,
managing people, procurement and good communications.
So, don’t get too caught up in labelling your methodology as one or the other. Simply
be inspired by the right style of methodology for your projects – make your own
hybrid methodology.
However, in saying that, I have found that there are plenty of great things that Agile
methodologies do that people using traditional methodologies could learn from, and
conversely, there are many elements of traditional methodologies that proponents of
Agile methodologies could incorporate. It’s not a case of one or the other. A truly
successful tailored methodology will draw whatever elements it needs from any part
of the traditional/Agile spectrum

Why is Having a Methodology Important?

In the absence of a defined and appropriate project management methodology you

will be doing projects by the seat of your pants, constantly making things up as you
go and each project managers will do things their own way. This leads to many
negative things including inefficiencies, decreased morale, less repeat business,
financial losses and lower chances of delivering successful projects.
Having a defined and appropriate methodology will allow you to extract the most
efficiency from your project management activities. Greater efficiencies contribute to
increased chances of project success. Project managers and project team members
have defined and appropriate processes, templates, documents and guidelines to
refer to, to assist their planning, execution and monitoring of the project. Program and
portfolio managers have access to standardized information for reporting and
assessment purposes. So overall, having a methodology means a great chance of
project success.
The existence of a project management methodology and a commitment to continual
review and improvement is also a sign of higher levels of project management
maturity.

Off-the-shelf or Customized Methodology?

When it comes to the process of developing, or changing, your project management

methodology you have two main options available to you. You can choose to develop
your own methodology or to use an already developed one available as an off-the-
shelf solution usually for a fee.

161
If you choose to develop your own one, the most important part for getting this right
is to have people with the right level of experience, passion and commitment to make
sure the development doesn’t stop half way through. Developing your own
methodology is not a single event, it takes time and iterations to ensure it is correct.
It also requires a champion who will commit to seeing the initial process to
completion. Too many good initiatives have been left to flounder due to the absence
of a champion.
The benefits of developing your own methodology is that you can leverage off existing
intellectual property, accommodate the organizational culture and get by in from the
project management team by seeking their input on what constitutes an appropriately
tailored methodology. A disadvantage to making your own methodology is the time
and effort it takes to get it from initiation to working methodology with processes,
tools and templates.
There are many off-the-shelf solutions for a project management methodology and
of the ones I have seen, most claim they can be customized to suit.
However, most people don’t see this and assume that simply by taking an off-the-
shelf, or readymade, solution that it will solve all their problems. The benefit of getting
an off-the-shelf solution is that it is available right away and it is a known
methodology. The drawbacks are that people assume that because it works for
someone else that it will work for them when this is not always the case. The instant
methodology does not reflect the organizational culture or industry. Also, there is no
control over intellectual property and there can be a lack of buy in and support from
project team members.

The Process of Tailoring

Tailoring, or customizing, your project management methodology is an important

step in organizational project management maturity, and also in getting people to use
and improve your particular methodology. In the absence of an appropriately tailored
project management methodology, people will tailor their own solutions. Here are
some signs that your project management methodology is not tailored correctly:
• Project team members are not using the methodology
• Project team members are independently modifying the methodology
• Your methodology features process for the sake of process
• Your methodology is one-size-fits-all approach to projects of differing sizes
and complexity
The benefits of a tailored approach to your project management methodology are:
• Creates buy in from team members
• Has a customer oriented focus
• Maintains a focus on best-for-project approach
• Is a more efficient use of project resources
There are three stages to tailoring your project management methodology.

162
The first is the initial tailoring you do to select those elements that will form your
project management methodology. Here, you select from a body of knowledge such
as the PMBOK® Guide, all those processes, tool and techniques that are appropriate
to the styles of projects you are doing based on their complexity and size. I believe
that the factors which influence the choices you make in developing a project
management methodology are project size, complexity, organization and team
culture, and internal and external constraints.
Once this initial process is complete you will have a methodology that is able to be
used for your projects. If your projects are all largely similar then the methodology will
be a fairly standardized one used without much change between projects. If however,
the size and complexity of your projects varies considerably, then this first stage in
tailoring your methodology will result in a scalable and flexible methodology that can
be adapted to be used on all your projects. Some specific examples of scalability and
flexibility include the type and size of any project charter, the range of scope definition
and extent of planning completed and, the effort put into risk management and
communications management.
The second stage is the tailoring done before starting a project to determine what
elements of your project management methodology you are going to us for this
particular project. This process should involve both the project manager and the PMO
in deciding which elements of the organizations’ project management methodology
are appropriate for this particular project. An easy way to do this is simply to divide
projects into small, medium and large projects and have a different set of processes,
tools and templates for each category. There are other, more complex ways of making
these decisions as well.
The third stage of tailoring is completed during the execution of the project where
you are checking that the particular combination of elements you have selected is still
appropriate and you are not over cooking or undercooking a project. Tailoring is an
iterative process done throughout the entire project lifecycle. The PMO should have
an input into this review process, and oversee and approve any changes. Adding your
lessons learned about the application of your selected methodology to your lesson
learned process helps other project managers in the future.

Developing Your Own Project Management Methodology

Developing your own project management methodology isn’t rocket science. With a
little bit of knowledge, perseverance and the internet you can quickly put together a
fully fleshed out project management methodology featuring templates, user guides,
processes and checklists.
Here are the key steps to successfully developing your own methodology:
1. Assess current and optimal level of project management maturity (see the exercise
on page 25 or use another commercially available model), the purpose of this exercise
is twofold. First to get a picture of where you are now and where you should be in
relation to project management maturity and capability. The second reason is to
163
provide benchmark against which we can measure future change (hopefully
improvements) in the level of project management maturity bought about by the
newly introduced project management methodology.
2. Gather and document all of your existing templates, software, processes, user
manuals and other supporting material. Complete an inventory of what you already
have so you don’t reinvent the wheel. Note any duplicate templates, processes or
other elements. As part of developing your own methodology you are going to have
to choose which one best suits your purposes. This may mean building a new one with
the best bits of each.
3. Get your project team members together and spend some time mapping out the
process for how projects should work. Make note of the milestones, documents,
processes and other elements that occur at different stages.
4. Now, fill in the blanks of what is missing. Visit websites and download lots of free
templates, processes, user manuals and guides - see pages 54 -55 for handy hints of
websites giving away free, or nearly free, document, user guides, process description
and templates.
5. Build your methodology iteratively by using your team to document a process flow
chart, user guides, standardize templates and other aspects of your methodology.
Don’t worry about building everything straight away; focus on the most important
aspects first. Then take into account the size of your organization and projects, your
organizational and project team culture, the complexity or your projects, the duration
of the project and the level of organizational project management maturity.
By including your team you get their input and their commitment. Make sure you store
all aspects of the methodology where everyone can find it. As a broad overview you
can start by developing an outline or process flow chart using the Plan-Do-Check-Act
cycle, or the PMBOK® Guide process groups of initiating, planning, executing,
monitoring and controlling, and closing to define major parts of your process. See the
PDCA diagram (Figure 3 in chapter 3) for an idea on how to structure your
methodology. After all the only real difference between traditional project
management methodologies in construction and agile methodologies used in IT is the
speed at which you go through these process and the amount of effort in each stage
or phase. Don’t forget to appoint, and encourage, a champion (or two or three) from
your team to develop and implement the new methodology and then commit to
continuous improvement.
Make sure that everyone knows where to find the elements of the new methodology.
I am seen instances of organizations with methodologies stored away that nobody
knew existed.
6. Go ahead and use your methodology as planned. Note whether it is working as
expected and be prepared to make changes to it to improve its suitability.
7. Conduct audits to see if the methodology is being used as expected. The audits will
reveal opportunities for continuous improvement as well. Update your methodology
as required.
164
Perhaps the most important aspect in this process is to acknowledge the role of time.
All good things take time and you simply won’t achieve all of your planned project
management methodology overnight. It will take time as your prioritize those things
that must be done sooner rather than later. Of course you still need to continue with
business as usual and deliver projects.
Here is a checklist to help you decide what elements your project management
methodology needs. Pick and choose those things that are useful to you by answering
whether or not your project management methodology need a template, process or
user manual to describe:
1. Portfolio Management
2. Project Selection
3. Charter Approval
4. Scope Definition
5. Schedule Development
6. Phasing
7. Quality Management
8. People Management
9. Team Development
10. Risk Management
11. Procurement
12. Communications
13. Monitoring
14. Reporting
15. Change Control
16. Delegated Authority
17. Process Improvement
18. Acceptance Criteria
19. Project Closure
20. Benefits Realization
21. Lessons Learned
22. Environmental Management
23. Contracts
24. Health & Safety
25. Cost & Time Estimation
26. Budget Development
27. Training
28. Stakeholder Management
If you are interested I have a card game you can download, print out and use to get a
great outline for a project management methodology. Contact me if you want a copy
of these.
165
Here’s one I prepared earlier . . .

The diagram on the next page shows a typical process flow chart for a fairly generic
project management methodology. I am offering it to you as a starting point only to
get you on the way to developing your own project management methodology. Please
take from it those parts that are useful and customize it to suit your organization and
your projects. You will see that I have clearly labelled each part of the processes in the
methodology. This allows me to quickly see where any of the projects in my portfolio
are at

166
Figure 56: Project Management Methodology Process Flow Chart

167
Here is a brief description about each part of the project management methodology.

P1 Initiate the Project - this is the part of the methodology where projects are
initiated. This process starts with a professional project selection process. It may
feature a business case, a contract that has been signed or a work order. It ends with
a milestone of formal project approval, usually with a signed project charter. The types
of documents and templates you would have here include business cases, project
selection process description and project charter templates.

P2 Plan the Project - This is the part of the methodology where all appropriate
planning actives are carried out. This is a highly iterative process and will be continued
throughout eh project. In this process you need to define the expected level of
planning that should be done before executing any planned work. You also need to
define the type and content of planning documents. Between the planning process
and the executing process you should have a kick off meeting as a milestone. The kick-
off meeting is held with stakeholders once enough planning has been done to start
project execution. The types of documents and templates you would have here include
all the various plans and baselines.

P3 Execute the Plan - this part of the methodology sets out how you will carry out
all the planned project work. This is the doing part of the project. Make sure that
whatever you are doing is guided by an appropriate planning document. Executing
activities also include checking that what you are doing matches what was planned.

P4 Control Changes - This part of your methodology is very important as it is your

approved change control process. This is where you assess the impact of any changes
and assess them via your approved change control process. Any changes will probably
require a change to the planning documents and that it why there is a feedback loop
back to planning here. The types of documents you will require here include a change
control process, change request templates and a change request register.

P5 Report Progress - this part of the methodology is where progress is reported. It

is included as a separate part of the methodology just to emphasize its importance.
You may choose to have it as part of either your executing or change control parts of
your methodology. The documents and templates include project reports, media
releases and status update templates.

P6 Close the Project - this part of the project is where project closure activities take
place. It is represented in the process flow chart as being at the end of a sequence but
in reality you may start project closure actives while still executing and controlling
change. The types of activities you would perform here would be captured in your
project closure checklist that you developed as part of your project planning work.

168
P7 Post Implementation Review - this part of the project methodology is where you
revisit the original outcomes and benefits the project was intended to deliver to see if
they were achieved. Whether they were or not, documenting what actually occurred
will contribute to future project success via lessons learned. You will need to define an
appropriate timeframe to perform the post implementation review and the types of
documents and templates that would be useful to you include the PIR template,
benefits realization guidelines, and lessons learned templates.

Please remember that this diagram is offered as a guide only. It should serve as a
starting point for your own process flow chart, documents, templates and user guides
that you need as part of your own tailored project management methodology. Once
you have put together your own methodology it is a really good idea to represent it
graphically and put it in places where everyone can see it. This assists with getting
people to use the methodology.

The Role of the Consultant

Amongst all these good intentions and commitment to developing you own
customized and tailored project management methodology it is important to discuss
what role, if any, the project management consultant should have during this process.
A typical relationship involves bringing in a skilled project management consultant
who then proceeds over a short period of time to instruct or tell you what you should
do. They then leave and you are expected to have listened to everything they have
said and adopted it overnight. Of course this isn’t the best process for a long lasting
outcome and improvement in your project management methodology.
The key role that a consultant can play during the process of developing your own
tailored project management methodology is one of empowering employees to
develop their own appropriate methodology. In this role the consultant acts as
supporter, subject matter guide, and mentor and change agent. At the end of the day
it is the role of the consultant to put themselves out of a job as fast as possible because
in doing so you have ensured that there is increased professional capability within the
organization which is much longer lasting than a typical transaction with a consultant.

169
Review Exercise

1. Does your methodology need these elements?

1. Project selection, justification and approval process 
2. Project phases, stage gates and/or milestones 
3. Project governance 
4. Project sponsorship 
5. Delegated authority limits 
6. Project roles and responsibilities 
7. Business case preparation 
8. Project charter preparation 
9. Project management software selection 
10. Requirements definition, management and control 
11. Work breakdown structure development and control 
12. Scope definition, management and control 
13. Cost estimating, management and control 
14. Budget development and control 
15. Project financial processes 
16. Schedule estimating, management and control 
17. Monitoring project performance 
18. Managing project changes 
19. Project status reporting 
20. Quality assurance processes 
21. Process audit procedures 
22. Quality control processes 
23. Risk assessment, management and control 
24. Resource estimation, levelling and management 
25. Project team formation and development 
26. Project communications development, distribution and control 
27. Stakeholder identification, engagement and management 
28. Customer engagement and management 
29. Procurement and contract assessment and management 
30. Vendor management 
31. Claims administration and resolution 
32. Health and safety 
33. Environmental management 
34. Deliverable acceptance procedure 
35. Operational handover process 
36. Project, or phase, closure process and checklist 
37. Gathering and documenting of lessons learned 
38. Benefits realization and/or post implementation review process 
39. Methodology tailoring guidelines 

170
The End

So, that’s it, we’ve come to the end of the book.

If you worked through the entire book either sequentially, or in bits and pieces, well
done. If you made it to this point after only reading a couple a relevant chapters, well
done to you as well. The way you use this book is entirely up to you. Some people will
read it cover to cover, others will simply read the chapters most appropriate.
As I said right at the outset, this book is not intended to be an in-depth text book
covering all the project management topics in any great depth. What it does instead
is present an overview of most, if not all, of the relevant topics in the profession of
project management. Some topics it goes in to more depth than others. If there are
topics you know are relevant to your own pursuit of practical project management
then this book should serve as a guide to direct your further education and enquires.
I don’t want to spend too much time repeating myself to reinforce key messages in
this book, so instead I would recommend reading chapters 1 and 2 again if you haven’t
read them recently. Most of all, I don’t want you to be overwhelmed by all the potential
processes, tools and techniques that are at your disposal as a practical project
manager. The trick to being practical and professional is to know which tools to use,
which ones not to use and to understand why you made the decisions you did. Being
practical and professional also means being flexible throughout the life of the project
and constantly reassessing the decisions you have made. It is also about being flexible
enough to know when you are wrong, and applied too little, or too many processes,
tools and techniques, and make the necessary changes to increase the changes of
project success.
After reading this book, your task is to commit yourself to being a practical and
professional project manager, keep learning and to keep teaching others.
If you do have any questions or comments please do not hesitate to contact me.
Thank you for being practical and professional!

Email: [email protected]
Website: www.seanwhitaker.com
LinkedIn: au.linkedin.com/in/seanwhitakerpm/

171
Glossary

Accept A risk response strategy for either positive or negative risks that involves simply accepting the
consequences of risk occurring.
Accepted deliverable A project deliverable that has been through both validation and quality control to
ensure that it meets the requirements and specifications.
Accuracy How close the measured value is to the actual value; compare with precision, which refers to how
uniform measurements are.
Acquisition The tool of advertising externally for project team members.
Active listening A communications technique in which the listener takes active steps to ensure that the
message was understood correctly.
Activity attributes Detail provided about activities on the activity list.
Activity cost estimates The cost estimates developed for each identified activity.
Activity durations estimate The estimate of the duration of a defined activity
Activity list The list of identified activities developed as part of the schedule management processes.
Activity network diagram A tool used in quality planning to show relationships between interdependent
activities and calculate the paths of activities and their durations. The generic term for all network
diagrams, including those used in scheduling management.
Activity resource requirements The resources requires to complete the work of identified activities.
Activity-on-arrow An arrow diagramming method that represents activities on arrows and uses dummy
activities to represent multiple predecessor and successor relationships between activities.
Activity-on-node A precedence diagramming method that represents activity information on nodes and
uses arrows to indicate the relationship between activities.
Actual cost The actual incurred cost of completing project work.
Additional quality planning tool In quality management, a generic referral to those quality tools not
captured in the seven basic quality tools; includes the seven new quality tools.
Advertising A tool for promoting a project’s procurement requirements to a particular audience.
Affinity diagram A graphical representation of ideas and similar concepts grouped by their relationship to
each other. One of the seven new quality tools.
Agreements Any and all formal contracts that initiate a project.
Alternative analysis A consideration of all the possible different ways that a potential outcome may be
achieved and making a decision about which method is best.
Alternatives generation A process tool that considers many potential alternatives in order to determine
whether you have selected the most efficient and appropriate one.
Analogous estimating An estimating process that takes a similar activity and compares it to a planned
activity to generate the estimate.
Analytical techniques A group of mainly mathematical techniques used to forecast potential outcomes
based upon known data.
Approved change request A change request that has been through the documented change control
process and received approval.
Approved change requests review A tool to determine whether approved change requests have been
implemented as planned.
Assumptions analysis An analysis of the assumptions made when calculating estimates.
Audit A tool for carrying out an assessment of whether or not a defined process has been followed.
172
Avoid A risk response strategy for negative risk that involves putting in place measures to avoid the risk
occurring.
Backward pass The process of calculating the late finishes and late starts in a network diagram. After
calculating the backward pass, the amount of total float for each activity and the critical path can be
identified.
Balanced matrix A type of matrix organizational structure in which power is equally shared between
the functional manager and the project manager.
Basis of estimates Supporting documentation for activity cost estimates that provides additional
information about assumptions, constraints, uncertainty, and estimating techniques used.
Benchmarking Comparing a project, or parts of a project, against other projects to judge how they compare.
Bidder conference A forum or meeting where all potential bidders on a procurement request can ask
questions of the buyer for clarification.
Bottom-up estimating The process of aggregating individual activity estimates upward to arrive at a total
cost.
Brainstorming A technique for gathering information that encourages creative and thorough thinking.
Budget at completion The original approved project budget to complete all the work.
Business case A document that examines the objectives, cost, benefits, strategic goals, constraints, and
assumptions and provides s justification for an organization to approve a project.
Business value The sum of all tangible and intangible value in an organization.
Buyer The person or organization procuring external goods or services.
Cause-and-effect diagram Also called a Fishbone or Ishikawa diagram; a graphical representation of a
known and identified effect and the potential causes of the effect. One of the seven basic quality tools.
Change control board A panel of people with experience to consider and make decisions upon any
requested changes as part of the change control process.
Change control meeting A meeting that is defined and scheduled by the documented change control
process. Change control meetings typically occur at regular intervals, and attendees at the meetings have
the necessary skills and authority to make decisions about change requests.
Change control tool Any tool defined by the change control process that can help define and manage the
change requests received.
Change log A log used to document change requests received and manage their status.
Change request A request made in response to new or amended requirements, or as a result of variances
discovered.
Checklist analysis A technique of having a predefined checklist of steps, or activities, that must be
completed and ensuring that they are.
Checksheet A standardized list of activities, process, and steps that need to be completed during quality
management activities. One of the seven basic quality tools.
Claims administration A tool for recording and assessing any claims made by either party to a contract.
Closed procurement A documented output that provides a formal record that a contract has been
completed and closed.
Co-location Putting project team members within the same physical location so that they can see each other
and work together more effectively.
Communications management plan The management plan that guides project communications.
Communications method A tool that recognizes that communications can be interactive, push, or pull.
Communications model A tool that describes how communications move from sender to receiver through
a particular medium.

173
Communications requirements analysis A tool for gathering and documenting the communication
requirements of project stakeholders.
Communications technology A tool that decides the particular form of technology to be used to
disseminate information.
Conflict management The process of resolving conflict.
Conflict of interest A situation in which an individual may benefit personally from decisions or actions they
undertake while acting in the best interests of another party.
Context diagram A method of graphically representing how users interact with a process.
Contingency plan A documented plan of contingent responses to a unplanned risk occurring.
Contingency reserves The reserve developed, usually as a result of quantitative risk analysis, for known
unknowns for time or cost.
Contingent response strategy A risk response strategy for unplanned risk.
Continuous improvement An iterative process of always seeking to improve your overall approach to
quality management and the specific results obtained from quality management processes.
Contract A formal agreement, usually in writing, between two or more parties with obligations, roles, and
responsibilities clearly defined.
Contract change control system A technique for defining how the procurement process can be changed.
Control chart A graphical representation of data points mapped over time against an expected mean or
average; upper and lower control limits are set three standard deviations either side of the mean, and
beyond the control limits there are upper and lower specification limits. One of the seven basic quality
tools.
Control limit A limit used on a control chart, set three standard deviations either side of the expected mean
to get the upper and lower control limit.
Conversation A tool used to communicate with team members about their performance.
Corrective action An action that seeks to realign the project performance with the project management
plan.
Cost aggregation The technique of adding up lower-level cost estimates to arrive at a total cost estimate
for higher-level deliverables.
Cost baseline The approved project cost over time.
Cost forecast A forecast that contains the project costs for a project or part of a project based on the
available information.
Cost management plan The management plan outlining how you will plan, monitor, and control changes
to your project costs.
Cost of quality A consideration of the impacts of manufacturing high quality or low quality over the life of
the product.
Cost performance index A relative measure of cost performance calculated by dividing earned value by
actual cost.
Cost variance A measure of variance between what was planned and what is occurring in relation to project
cost performance, calculated by subtracting actual cost from earned value.
Cost-benefit analysis A tool for analyzing the expected costs to be incurred against the expected benefits
to be gained. Benefits should outweigh costs.
Crashing A schedule compression technique that involves allocating more resources to an activity to speed
its completion. It usually involves additional cost.
Data gathering and representation techniques Techniques and methods of collecting and presenting
data in graphical form for further analysis.

174
Decision tree A tool for making decisions about which option to select based on known probabilities and
outcomes, to calculate the expected monetary value of each.
Decomposition The technique of breaking down high-level descriptions into their component parts. When
used in the creation of a WBS, decomposition is used down to the work package level.
Defect repair A required activity to repair a discovered defect.
Deliverable A unique and verifiable product, service, or result produced by the project.
Delphi technique An estimating technique that involves soliciting information from experts anonymously
to avoid peer pressure.
Dependency determination The consideration given to whether activities represent mandatory,
discretionary, external, or internal dependencies.
Design of experiments A tool for determining quality by using a known set of variables, designing an
experiment, and being able to control different variables to determine the variable responsible, or most
responsible, for quality issues.
Diagramming techniques A variety of techniques of using diagrams to show relationships between related
activities, events, causes, and effects.
Document analysis A technique of analyzing existing documents to gather information.
Documentation reviews A technique of thoroughly examining documents that serve as inputs into
processes to fully understand and review them.
Dummy activity A relationship, represented by a dotted line, between multiple activities in an activity-on-
arrow (AOA) diagram.
Early finish The earliest an identified activity can finish. Calculated by adding the duration of the activity to
the early start.
Early start The earliest an activity can start.
Earned value The value of the work completed.
Earned value management A technique for analyzing past performance and utilizing formulas to forecast
future performance based on planned value, earned value, and actual cost.
Effective listening Similar to active listening, a communications technique that also includes the listener or
receiver monitoring nonverbal and physical communication.
Enhance A risk response strategy for positive risks that seeks to enhance the probability or impact of a risk
occurring.
Enterprise environmental factor A factor that is external to a project that can influence the success
of a project.
Enterprise environmental factors update An update to the enterprise environmental factors as a result
of completing processes.
Estimate at completion The formula for calculating what the forecast cost estimate at the completion of
the project will be.
Estimate to complete The calculation to estimate how much more money there is to be spent on the
project to reach the estimate at completion.
Expected monetary value analysis A mathematical technique, often using decision trees, of calculating
the probability and impact of a particular decision in order to calculate expected monetary value.
Expert judgment The advice and decisions from people with specialist knowledge in a particular area.
Exploit A risk response strategy for positive risks that seeks to put in place strategies to ensure that if a
positive risk occurs you are ready to exploit it.
Exploratory study An initial assessment and review of an issue to gain a preliminary understanding of
potential ways to address it

175
Facilitated workshop A workshop with a focus on a particular issue, directed by an independent facilitator.
Facilitation techniques A broad range of techniques designed to solicit information from groups of people
with the objective of accomplishing project activities.
Fairness One of four key values underpinning the ethical and professional conduct expected of a project
manager. It seeks to avoid conflict of interest, favoritism, and discrimination. See also responsibility,
respect, and honesty.
Fallback plan another name for a contingency plan developed to manage risks
Fast tracking A schedule compression technique that involves performing activities in parallel that were
originally scheduled in sequence.
Feedback Cues from the receiver to the sender that indicate whether or not the message has been
understood.
Fielder’s Contingency Theory A theory that states that leadership effectiveness is contingent on whether
the situation is stressful or calm and whether the leader is task-oriented or relationship-oriented.
Final product, service, or result The deliverable, product, or service produced by the project and handed
over to operations.
Fishbone diagram Also called a cause-and-effect diagram or Ishikawa diagram; a graphical representation
of a known and identified effect and the potential causes of the effect. One of the seven basic quality tools.
Flowchart A tool for showing in graphical form the steps in a process. One of the seven basic quality tools.
Focus group A gathering of a group of stakeholders or participants to address a particular issue or provide
specific feedback.
Forecasting The technique of extrapolating from past performance what likely future performance will be.
Forward pass The calculation of early starts and early finishes in a network diagram that results in the project
duration.
Free slack or free float The amount of time an activity can be delayed before it affects the next activity on
the path.
Functional manager A general manager or team leader in charge of a functional area in an organization.
Functional organization An organization that is structured into its separate functional areas, each having
its own technical specialty and manager or leader.
Funding limit reconciliation A technique for reconciling forecast funding requirements against actual
funding limits.
Grade A measure of the amount of features a product has. Low grade means the product has few features,
whereas high grade means it has lots of features.
Ground rules Rules established by the project manager and project team members for accepted and
expected behaviors for being part of the team.
Group creativity techniques A range of techniques used to get a group of people to generate and consider
a wide range of possible options.
Group decision-making techniques A range of techniques to enable a group of people to reach a
decision.
Grouping method A particular method of deciding how results will be categorized for easy
assessment and prioritization
Herzberg's Motivation-Hygiene Theory A theory that states that hygiene factors will not motivate, but
their absence will make staff unsatisfied, and that motivation will motivate, but only if hygiene factors are
in place.
Histogram Also called a bar chart; a tool for showing amount or frequency of a variable. One of the seven
basic quality tools.

176
Historical relationships Any past information about interactions between variables used in an estimating
process.
Honesty One of four key values underpinning the ethical and professional conduct expected of a project
manager. See also responsibility, respect, and fairness.
Human resource management plan The management plan for planning, acquiring, developing, and
controlling human resources on the project.
Independent estimate A technique that uses an independent professional to provide advice on what seller
responses in relation to cost should reasonably be.
Influencing The technique of understanding, modifying, and changing the expectations and engagement of
stakeholders to ensure that they support your project or do not oppose it.
Information gathering techniques A variety of techniques for gathering information from project team
members, subject matter experts, and other stakeholders, and other sources of information.
Information management system A tool for the management, storage, and distribution of project
information in either hard copy or electronic form.
Inspection The tool of physically checking work that has been done.
Interactive communication A form of communication where multiple parties communicate concurrently.
Interpersonal skills A range of technical, personal, and conceptual skills that a project manager should have
and be able to display at appropriate times in order to increase his or her effectiveness.
Interrelationship digraph A tool for graphically showing the many relationships that exist between
different variables or steps in a process. One of the seven new quality tools.
Interview A formal and structured meeting between small groups of people to solicit specialist information.
Ishikawa diagram Also called a cause-and-effect diagram or a Fishbone diagram; a graphical representation
of a known and identified effect and the potential causes of the effect. One of the seven basic quality
tools.
Issue log A document that lists and describes issues that have been identified and the status of those issues.
Just in time A tool for controlling inventory in which inventory is delivered just as it is needed. Can be used
as a quality management tool, because lack of inventory in stock exposes mistakes very fast and provides
a reason to improve quality.
Kaizen The loose Japanese translation of continuous improvement, which means always seeking to
improve your quality processes and products.
Kick-off meeting A meeting held before project execution activities start.
Lag The amount of time an activity must wait after its predecessor finishes before it can start.
Late finish The latest an activity can finish.
Late start The latest an activity can start.
Lead The amount of time before the finish of its predecessor that an activity can start.
Make or buy analysis A tool for assessing whether work should be done by the project team or procured
from an external source.
Make or buy decision The output from the make or buy analysis that decides whether an organization will
make the required goods or services or buy them from an external provider.
Management reserves A reserve of cost or time for unknown unknowns; under the control of
management.
Management skills A set of skills a project manager should have that include presentation, negotiation,
time management, and public speaking skills.
Market research As tool for examining and assessing current marketplace conditions in order to assess the
impact upon procurement decisions.

177
Maslow’s hierarchy of needs A theory that states that a person will always be motived by lower needs
before being motivated by higher-order needs.
Matrix diagram A tool for graphically showing how one set of variables on a vertical axis interacts with other
variables on a horizontal axis. One of the seven new quality tools.
Matrix organization A type of organizational structure in which projects are completed across functional
lines and a project manager draws on different technical specialties from different functional areas.
Mcclelland's Human Motivation, Achievement, or Three Needs Theory A theory that states that
people will work not for more money, but instead for achievement, power, and affiliation.
Mcgregor’s theory X and theory Y A set of theories that states that managers either view employees as
trustworthy and self-motivated (theory Y) or untrustworthy and needing constant motivation (theory X).
Meeting A gathering of a group of people for a defined purpose and agenda.
Methodology A defined set of processes, tools, techniques, and templates for managing projects in a
particular way.
Milestone list A high-level graphical representation of the milestones to be achieved on the project.
Mitigate A risk response strategy for negative risks that seeks to minimize the probability and impact of a
particular risk.
Modeling techniques A variety of mathematical and computer-based techniques to forecast possible
outcomes based on several different inputs.
Monte Carlo Analysis A statistical and complex mathematical method of extrapolating from observed data
what a likely future scenario or scenarios will be.
Multicriteria decision analysis A tool used to assess the different attributes of prospective team members,
and give each attribute a particular weight so that the overall ranking of the preferred team member can
be assessed.
Negotiated settlement A technique for arriving at an agreed means of terminating and closing a contract
between parties to the contract.
Negotiation A tool for interacting with another party and attempting to come to a mutually beneficial
agreement.
Networking A tool used to build relationships between individuals and groups based on mutual benefit.
Nominal group technique A method of using group members to vote on which ideas generated from a
brainstorming session are most worthy of investigating or using further.
Nonverbal Communication in the form of body language, posture, and similar.
Observation A tool used to observe team members’ performance so that performance appraisals can be
completed and also .the technique of physically observing how people act in the environment and how
they might use a particular product, service, or result.
Organizational chart A hierarchical and graphical representation of the way that an organization is
structured, identifying specific roles and their reporting lines.
Organizational process asset Any formal or informal process that the performing organization has in place
to assist in delivery of the project.
Organizational process assets update Any update that will be made to existing organizational process
assets as a result of information gathered or observations made during the execution of the project.
Organizational project management maturity A method of assessing the level of organizational
maturity in relation to the use of portfolio, program, and project management processes, tools, templates,
and methodologies.
Organizational theory A range of theories describing the way people and organizations interact.
Ouchi Theory Z A theory that states that employee loyalty and productivity can be increased by offering a
job for life and providing full care.

178
Padding The unjustifiable increase in estimates of time or cost.
Paralingual Communication that is vocal but not verbal, and includes tone of voice, inflection, and volume.
Parametric estimating An estimating technique that multiplies a known quantity by a known metric.
Pareto diagram A tool for showing the frequency of events individually, and also cumulatively, so that the
20 percent of events responsible for 80 percent of the effects can be identified. One of the seven basic
quality tools.
Payment system A tool for ensuring that payments due under the terms of a contract are properly paid and
recorded.
Performance reporting A tool for collecting and disseminating appropriate reporting on project progress
to stakeholders.
Performance reviews The process of measuring, comparing, and analyzing actual project performance.
Personnel assessment tools A range of tools and techniques that enable project managers and team
members to assess individual and team performance, strengths, and weaknesses.
Phase A defined part of a project marked by a milestone, stage gate, phase gate, or major decision point.
Plan-do-check-act (PDCA) cycle An iterative cycle developed by Shewhart and Deming to describe
continuous planning and checking processes.
Planned value The value of work that should have been completed at a certain point in time.; calculated by
multiplying the budget at completion by percentage of time elapsed.
PMBOK® guide A collection of what is considered good practice in the profession of project management,
providing a framework from which to draw appropriate processes, tools, and techniques for managing
projects.
Point of total assumption The price point in a contract where the seller assumes total responsibility for all
cost increases.
Portfolio manager The person responsible for managing a portfolio of projects; the portfolio manager
typically operates at strategic level.
Portfolio The range of projects being undertaken by an organization.
Position description A document that sets out the required responsibilities, skills, and experience for a
particular role on the project team.
Preassignment A tool that allocates project team members to a project based on their specific experience
or contractual agreements.
Precedence diagramming method A graphical representation of activities in the project with arrows
indicating the relationship between them. The most common type of precedence diagram is the activity-
on-arrow (AOA) diagram.
Precision The degree to which measurements are clustered together rather than scattered. Compare to
accuracy.
Predecessor An activity that comes immediately before another activity.
Preventive action An action to stop work that will cause the project to deviate from the project
management plan.
Prioritization matrix A tool for prioritizing and weighting issues and events and displaying the results
graphically. One of the seven new quality tools.
Probability and impact matrix A graphical means of displaying the combined probability and impact of
risks in a standardized manner.
Process analysis A tool that follows steps in a process to determine whether they are appropriate and can
be improved upon.
Process decision program chart A tool that links ideas together and graphically represents them as a
means to achieve a particular goal. One of the seven new quality tools.
179
Process improvement plan A plan that identifies the way in which project processes will be defined,
analyzed, and improved. A subset of the project management plan.
Procurement audit A tool for auditing whether or not procurement processes and contracts are being
carried out as per the approved documentation.
Procurement documents A range of documents produced by the procurement processes that provide
additional advice or record decisions made about the procurement process.
Procurement management plan A management plan that provides guidance on how the procurement
management processes will be carried out.
Procurement negotiation A technique of entering into negotiations with prospective sellers that results in
an agreed contract.
Procurement performance review A technique for carrying out a structured review of a seller’s
performance and progress against an agreed contract.
Procurement statement of work A defined and documented description of the scope of work to be
completed as part of the procurement process.
Product analysis The technique of breaking a defined product down into its component parts to fully
understand it.
Program A number of projects that are interrelated in some way.
Program Evaluation and Review Technique (PERT) A graphical technique developed to evaluate the
time and cost elements of a project and the relationship and interdependencies between them.
Program manager The person responsible for managing a program of projects.
Progressive elaboration A process of iteratively defining and planning work to be done on a project.
Project A temporary activity to deliver a unique product, service, or result.
Project calendars The times that activities on the project can and cannot be carried out in completing
project deliverables.
Project charter The foundational document for the project; it provides political and financial support for the
project.
Project communications The output from the Manage Communications process that includes all
information created, stored, and disseminated by the project.
Project coordinator A person given a leadership role in managing a project with less power and authority
than a project manager.
Project documents update An update to any project documents as a result of information gathered, or
observations made during the execution of the project.
Project expeditor A person given a leadership role in managing a project with very little power and
authority.
Project funding requirements The documented timing of when project funding will be required.
Project life cycle The defined stages of initiating, planning, executing, monitoring and controlling, and
closing a project.
Project management The proactive application of practical project management practices to deliver a
project.
Project management information system Any system the project utilizes to gather, store, record, and
disseminate information about the project.
Project management office The center of excellence for project management within an organization.
Project management plan The collection of all planning documents used to guide project execution.
Project management plan update Any update to any part of the project management plan or its
subsidiary plans.

180
Project management software Any software that provides monitoring and reporting capability for
managing a project.
Project manager The person ultimately responsible for all aspects of the project.
Project performance appraisal A tool used to assess individual and team performance against expected
performance, provide feedback to team members, identify individual training needs, and use this
information to plan future team and individual performance.
Project schedule The expected timeframe the project will take.
Project schedule network diagram A graphical representation of all the activities to be completed on a
project and the relationships between them.
Project scope statement The description of all the work to be done, and the work not to be done, as part
of the project.
Project staff assignments A document outlining which project staff members are allocated to the project,
their roles, and contact details.
Project steering committee An oversight group made up of senior managers providing high-level advice,
support, and governance to the project.
Projectized organization An organizational structure that reflects an organization that is divided and
structured along project lines.
Proposal evaluation technique A technique for assessing and scoring all proposals received as part of a
procurement process.
Prototype A technique of producing an example of the finished product, service, or result to seek feedback
from stakeholders.
Published estimating data A database of known quantities or costs relating to completion of activities in
the project. Such databases are usually available commercially.
Pull communication A form of communication where information is downloaded and accessed by the
receivers when they want it.
Push communication A form of communication where information is sent to the receiver.
Quality The degree to which a set of inherent characteristics fulfills requirements.
Quality audit A tool for checking conformity to defined process to ensure that they are being followed.
Quality checklist An input/output that provides a standardized list of steps to be taken. Compare with
checksheets, which are used as a quality tool.
Quality control measurement An input/output that describes the result of Control Quality activities.
Quality management plan A subset of the project management plan that describes how quality
management will be defined, document, measured, and improved in a project.
Quality metric An input/output that describes a particular product or project attribute in detail and how the
Quality Control process will measure it.
Quantitative risk analysis and modeling techniques A variety of tools and techniques for performing
quantitative risk analysis.
Questionnaires and surveys Formal documented methods of asking for information and feedback from
stakeholders.
RACI chart A type of responsibility assignment matrix (RAM) that identifies particular team members and
activities to be completed, and defines whether the team members are responsible, accountable,
consulted, or informed.
Recognition A tool for acknowledging the performance of team members.
Records management system A tool used to record, store, and distribute information relating to
procurement processes and decisions.

181
Reporting system A tool for gathering, storing, and distributing project information.
Requirements The attributes, condition or capability that a stakeholder requires from a product, service or
result produced as part of the project
Requirements documentation A document that describes individual requirements and their priority;
developed in consultation with stakeholders.
Requirements management plan The document that sets out how you will define, document, and
manage your project requirements.
Requirements traceability matrix A document that maps individual project requirements to specific
business objectives and stakeholders.
Reserve analysis An analysis, usually using quantitative risk analysis, that results in the provision of either a
contingency or management reserve for time and cost.
Resource breakdown structure A breakdown, using the process of decomposition, of the categories and
types of resources required to complete the project.
Resource calendars The specific time periods that a particular resource is available to be used on the
project.
Resource leveling The process of optimizing and making most efficient use of resources over a given period
of time.
Resource optimization techniques Any of the techniques that enable a more efficient use of resources
on the project.
Resource smoothing A resource optimization technique that seeks to optimize the use of resources
without extending the total float of any activity.
Respect One of four key values underpinning the ethical and professional conduct expected of a project
manager. It seeks to ensure that respect is provided for. See also responsibility, fairness, and honesty.
Responsibility One of four key values underpinning the ethical and professional conduct expected of a
project manager. It seeks to ensure that a project manager takes full personal and professional
responsibility for all actions and decisions. See also respect, fairness, and honesty.
Responsibility assignment matrix A tool for displaying particular roles in a project and the responsibilities
each role has.
Rewards A tool for compensating high performance.
Risk audit A technique for determining if the processes outlined in the risk management plan for conducting
risk management activities are being followed.
Risk breakdown structure (RBS) A graphical representation of different risk categories and subcategories.
Risk categorization A technique for assigning similar and interrelated risks into identified categories.
Risk data quality assessment A technique for examining the quality and certainty of data being used in
risk analysis.
Risk management plan The particular management plan that outlines how you will approach the planning,
monitoring, and controlling of risk management activities on your project. It is a subsidiary of the project
management plan.
Risk probability and impact assessment A tool for assigning likely probability and impact to individual
identified risks on the project.
Risk reassessment A technique for continually reassessing the information used to identify individual risks,
their probability and impact, the prepared risk responses, and any new risks that may have arisen.
Risk register The documented list, analysis, and planned responses to identified risks on the project.
Risk tolerance The maximum level of risk that an organization is prepared to tolerate on a project.
Risk urgency assessment A technique for assessing those risks that are likely to occur in the short term,
and prioritizing those over risks that will occur at a further point in time.
182
Rolling wave planning A form of progressive elaboration that focuses on planning the immediate future
in more detail than timeframes further off.
Rule of seven A guide for determining when a process may be out of control in a control chart. If seven
consecutive data points appear above or below the mean and within the control limits, this may indicate
that the process is out of control or is about to go out of control.
Scatter diagram A tool for graphically representing the results of two variables. One of the seven basic
quality tools.
Schedule baseline The developed and approved project timeframe.
Schedule compression Any technique that reduces individual activity or the total project duration.
Schedule data The collection of information describing and controlling the schedule, including the schedule
milestones, schedule activities, activity attributes, and any schedule contingency reserves.
Schedule forecast The estimated time the project, or parts of the project, will take based on available
information.
Schedule management plan The plan developed to guide the development, monitoring, and control of
the project schedule. It forms part of the overall project management plan.
Schedule network templates Any templates that an organization has for assisting with developing a
schedule network.
Schedule performance index A calculation measuring the time performance on the project. Calculated by
dividing earned value by planned value.
Schedule variance The difference between what was planned and what is actually occurring in relation to
the project schedule.
Scheduling tool Any manual or automated tool that focuses on the project schedule.
Scope baseline The scope statement, work breakdown structure (WBS), and WBS dictionary.
Scope management plan The document that sets out how you will define, document, and manage changes
to your project scope statement.
Selected sellers The group of sellers chosen to participate in the procurement process either by being
prequalified or by completing a stage in the procurement process.
Seller The individual or organization responsible for delivery of externally contracted goods or services.
Seller proposal A formal response to a procurement request from a prospective seller.
Sensitivity analysis A mathematical technique for determining which parts of the project are most sensitive
to risk.
Seven basic quality tools Initially developed by Ishikawa, graphical ways of showing complex text based
or numerical information. They are the cause-and-effect diagrams, flowcharts, checksheets, Pareto
diagrams, histograms, control charts, and scatter diagrams.
Seven new quality tools A further seven ways to show information in graphical form. They are affinity
diagrams, process decision program charts, interrelationship digraphs, tree diagrams, prioritization
matrices, activity network diagrams, and matrix diagrams.
Share A risk response strategy for positive risks that seeks to increase the probability or impact of a risk
occurring by sharing experience and capabilities with another organization.
Simple average A mathematical average obtained by adding a set of numbers and dividing the total by the
amount of numbers.
Six Sigma A proprietary approach to quality management which seeks to reduce defects and errors to as
close to zero as possible. Named after six standard deviations, which includes 99.999 percent of a
population.
Source selection criteria A tool for developing a range of approved criteria for assessing seller responses
to procurement requests.

183
Specification limit A limit used on a control chart outside the control limits set by the customer. Any
product manufactured outside either the upper or lower specification limit will not be accepted by the
customer.
Sponsor The person who provides financial and political support for the project, appoints the project
manager, and authorizes the project charter.
Staffing management plan An important component of the human resource management plan that
specifically addresses the skills required, the time people are able to work on the project, and how and
when project team members will be obtained to work on the project.
Stakeholder Any person or group that can affect or be affected by your project.
Stakeholder analysis A technique for identifying and documenting stakeholders’ interests, expectations,
power, influence, and level of engagement in the project.
Stakeholder management plan The document that sets out how you will define, document, and manage
stakeholders and their expectations.
Stakeholder register A register of all project stakeholders and information about their interest in the
project, the power they have to influence the project, their expectations, and how their expectations will
be managed.
Stakeholder risk profile analysis An assessment of individually identified stakeholders’ attitudes toward
risk on the project.
Standard deviation A measurement about how widespread a particular set of data is from the mean.
Statement of work A high-level narrative description of the work to be done on the project.
Statistical sampling A tool for sampling a small subset of a large population and extrapolating the result to
the entire population. Used when testing the entire population is not possible or when destructive testing
is involved.
Status meetings Regularly scheduled meetings that focus upon a particular project status metric.
Strategies for negative risks or threats A range of suitable options for dealing with negative risks,
including transfer, mitigate, avoid, and accept.
Strategies for positive risks or opportunities A range of suitable options for dealing with positive risks,
including enhance, exploit, share, and accept.
Strong matrix A type of matrix organization in which the project manager has most of the power and
authority, and the functional manager has little power and authority.
Successor An activity that comes immediately after another activity.
SWOT analysis A technique that analyzes strengths, weaknesses, opportunities, and threats.
Tailoring The process of taking and using only those processes, tools, and techniques that provide benefit to
managing your project.
Team performance assessment A tool used to develop a formal or informal assessment of a project team’s
effectiveness.
Team-building activities A wide range of activities designed to enhance team performance via the creation
of team morale, culture, and ground rules.
Technical performance measurement A technique for checking whether predetermined parameters for
initiating particular risk strategies have been met.
Template Any blank preformed document that can be used to complete processes, documents, or forms on
a project.
Three-point estimating A formula taken from the Program Evaluation and Review Technique (PERT) that
calculates a weighted average of the optimistic, most likely, and pessimistic estimates. The formula is (O+(4
x M) + P)/6

184
To-complete performance index The rate at which you must perform to achieve either the budget at
completion or the estimate at completion.
Tornado diagram A tool for graphically representing the results of sensitivity analysis in hierarchal form to
identify those parts of the project to be affected by risk, from most likely down to least likely.
Total quality management (TQM) A management-led philosophy and approach to quality that involves
everyone in the organization and seeks to continuously improve all aspects of quality within an
organization and a project.
Total slack or total float The amount of time an activity can be delayed before it affects the total project
duration.
Training A tool used to increase the level of skills a team member has through formal learning.
Transfer A risk response strategy for negative risks, which involves making the probability and impact of the
risk someone else's responsibility.
Tree diagram A tool for showing the systemic breakdown of concepts or issues. Used as a quality
management tool and also is the generic term for breakdown structures such as the work breakdown
structure and organizational breakdown structure.
Trend analysis A technique for identifying any trends and observed data and extrapolating from this a likely
future outcome.
Tuckman’s five-stage model of team development A theory that describes the five stages of forming,
storming, norming, performing, and adjourning that a team goes through.
Validated change An approved change that has been acted upon and checked for accuracy.
Validated deliverable A deliverable that has previously been verified and has been checked with
stakeholders to ensure it meets stakeholder requirements and expectations.
Variance The difference between what was planned and what is actually occurring.
Variance analysis The technique of checking what you planned to do against what you are actually doing
and spotting any difference between the two.
Variance and trend analysis The technique of checking what you planned to do against what you are
actually doing and using this information to forecast likely future trends.
Variance at completion The difference between the budget at completion and the estimate at completion.
Variance formula The formula used to determine the mathematical variance; calculated by multiplying the
standard deviation by itself.
Vendor bid analysis The technique of getting an independent assessment of prices submitted by vendors
to check for accuracy.
Verified deliverable A deliverable that has been inspected and has been checked with stakeholders to
ensure it meets stakeholder requirements and expectations.
Virtual team A tool that recognizes that project team members may come from different geographic
locations but can still work together by using technology.
Vroom’s Expectancy Theory A theory that states that the expectation of receiving a reward for a
certain accomplishment will motivate people to work harder, but that this only works if the
accomplishment is perceived to be achievable.
War room A specific form of co-location activity that places team members in the same room.
Weak matrix A type of matrix organization in which the functional manager has much more power and
authority than a project manager.
Weighted average A mathematical average calculated by adding a set of numbers and prescribing different
weights to each of the numbers, then dividing by the sum of the weights given; used to calculate three-
point estimates.

185
What-if scenario analysis A complex mathematical model which examines the probability of different
scenarios.
Whistleblower Someone who reports illegal or unethical behaviour within an organization.
Work breakdown structure (WBS) A hierarchical graphical representation of the work to be done on the
project, broken down to work package level.
Work breakdown structure (WBS) dictionary A document providing additional information about each
node in a WBS.
Work package An amount of work that can have time and cost accurately estimated; the lowest level of the
WBS.
Work performance data The raw data gathered as part of observations and inspections.
Work performance information The refined work performance data presented in a relevant form
Work performance reports The presentation of work performance information to stakeholders.
Workaround An acceptable response to unplanned risk, which involves creating a makeshift solution to
allow work to continue.

186
Te Reo Māori Glossary

NGĀ KARANGATANGA MATUA | FOUNDATIONAL TERMS

Project Hinonga A temporary activity to deliver a unique product,
service, or result.
Project Kaiwhakahaere The person ultimately responsible for all aspects of the
manager Hinonga project.
Project Whakahaere The proactive application of professional project
management Hinonga management practices to deliver a project.
Program Hōtaka A number of projects that are interrelated in some way.
Program Kaiwhakahaere The person responsible for managing a program of
manager hōtaka projects.
Portfolio Kaiwhakahaere The person responsible for managing a portfolio of
manager kōpaki projects; the portfolio manager typically operates at
strategic level.
Portfolio Kōpaki The range of projects being undertaken by an
organization.
Project Kairuruku Hinonga A person given a leadership role in managing a project
coordinator with less power and authority than a project manager.
Sponsor Kaitautoko The person who provides financial and political support
for the project, appoints the project manager, and
authorizes the project charter.
Deliverable Huapuaki A unique and verifiable product, service, or result
produced by the project.
Methodology Whakatakinga A defined set of processes, tools, techniques, and
Tikanga templates for managing projects in a particular way.
Plan Mahere A document used to guide project execution.
Software Pūmanawa rorohiko Any software that provides monitoring and reporting
capability for managing a project.
Tailoring Whakahāngai The process of taking and using only those processes,
tools, and techniques that provide benefit to managing
your project.

TE TAUTUHI I TE HINONGA | DEFINING THE PROJECT

Business case Tono pakihi A document that examines the objectives, cost,
benefits, strategic goals, constraints, and assumptions
and provides s justification for an organization to
approve a project.
Project charter Tūtohinga hinonga The foundational document for the project; it provides
political and financial support for the project.
Scope Te korahi The description of all the work to be done, and the
work not to be done, as part of the project.
Work Hanga raumahi A hierarchical graphical representation of the work to
breakdown be done on the project, broken down to work package
structure level.
(WBS)

TAKI WĀTAKA HINONGA | PROJECT SCHEDULING

Project Wātaka hinonga The expected timeframe the project will take.
schedule

187
Crashing Whakakōpeke A schedule compression technique that involves
allocating more resources to an activity to speed its
completion. It usually involves additional cost.
Fast tracking Whakahoro A schedule compression technique that involves
performing activities in parallel that were originally
scheduled in sequence.
Predecessor Takimua An activity that comes immediately before another
activity.
Successor Takimuri An activity that comes immediately after another
activity.
Lag Tōkume The amount of time an activity must wait after its
predecessor finishes before it can start.
Lead Tōtaki The amount of time before the finish of its predecessor
that an activity can start.

WHAKAHAERE TŪRARU | RISK MANAGEMENT

Risk Tūraru An uncertainty that may impact the project

Risk register Rārangi tūraru The documented list, analysis, and planned responses
to identified risks on the project.
Accept Whakaae A risk response strategy for either positive or negative
risks that involves simply accepting the consequences
of risk occurring.
Avoid Karo A risk response strategy for negative risk that involves
putting in place measures to avoid the risk occurring.
Transfer Whakawhiti A risk response strategy for negative risks, which
involves making the probability and impact of the risk
someone else's responsibility.
Enhance Whakamarohi A risk response strategy for positive risks that seeks to
enhance the probability or impact of a risk occurring.
Exploit Whakapeto A risk response strategy for positive risks that seeks to
put in place strategies to ensure that if a positive risk
occurs you are ready to exploit it.
Share Toha A risk response strategy for positive risks that seeks to
increase the probability or impact of a risk occurring by
sharing experience and capabilities with another
organization.
Workaround Huarahi Autaki An acceptable response to unplanned risk, which
involves creating a makeshift solution to allow work to
continue.

WHAKAPĀPĀTANGA | COMMUNICATIONS
Influencing Whakapakepake The technique of understanding, modifying, and
changing the expectations and engagement of
stakeholders to ensure that they support your project
or do not oppose it.
Meeting Hui A gathering of a group of people for a defined purpose
and agenda.
Stakeholder Hunga whaipānga Any person or group that can affect or be affected by
your project.

NGĀ TŪKAWE TATAU | ESTIMATING TECHNIQUES

188
Analogous Tatau Tairite An estimating process that takes a similar activity and
estimating compares it to a planned activity to generate the
estimate.
Bottom-up Tatau Raupitopito The process of aggregating individual activity estimates
estimating upward to arrive at a total cost.
Delphi Tūkawe Delphi An estimating technique that involves soliciting
technique information from experts anonymously to avoid peer
pressure.
Parametric Tatau Rohenga An estimating technique that multiplies a known
estimating quantity by a known metric.

NGĀ UTU ME NGĀ MAHERE PŪTEA MŌ TE HINONGA | PROJECT COST AND BUDGETS
Contingency Tāpui tūpono The reserve developed, usually as a result of
reserves quantitative risk analysis, for known unknowns for time
or cost.
Management Tāpui whakahaere A reserve of cost or time for unknown unknowns; under
reserves the control of management.
Budget at Mahere pūtea The original approved project budget to complete all
completion whakatepe the work.
(BAC)
Actual cost Utu tūturu The actual incurred cost of completing project work.
(AC)
Earned value Wāriu whiwhi The value of the work completed.
(EV)
Planned value Wāriu The value of work that should have been completed at
(PV) whakamahere a certain point in time.; calculated by multiplying the
budget at completion by percentage of time elapsed.
Estimate at Tatau whakatepe The formula for calculating what the forecast cost
completion estimate at the completion of the project will be.
(EAC)
Estimate to Tatau whakaoti The calculation to estimate how much more money
complete (ETC) there is to be spent on the project to reach the estimate
at completion.
Cost Kuputohu utu A relative measure of cost performance calculated by
performance tutukinga dividing earned value by actual cost.
index (CPI)
Cost variance Te utu whakataka A measure of variance between what was planned and
(CV) what is occurring in relation to project cost
performance, calculated by subtracting actual cost from
earned value.
Schedule He kuputohu wā A calculation measuring the time performance on the
performance project. Calculated by dividing earned value by planned
index (SPI) value.
Schedule Te wā whakataka The difference between what was planned and what is
variance (SV) actually occurring in relation to the project schedule.
Variance at Huatango The difference between the budget at completion and
completion whakatepe the estimate at completion.
(VAC)

WHAKAHAERE KAITAONGA | PROCUREMENT MANAGEMENT

Buyer Kaiutu The person or organization procuring external goods or
services.

189
Seller Kaihoko The individual or organization responsible for delivery
of externally contracted goods or services.
Contract Kirimana A formal agreement, usually in writing, between two or
more parties with obligations, roles, and responsibilities
clearly defined.
Negotiation Whiriwhiri A tool for interacting with another party and
attempting to come to a mutually beneficial agreement.

190
Tools and Templates

The following pages contain some useful, but generic, templates that will serve as a starting
point for your own templates and processes. Please feel free to change them to suit your
projects. Contact me if you want the original MSWord versions.

191
Project Management Methodology Checklist

Mandatory Optional
Project selection, justification, and approval  
process
Project phases, stage gates and/or milestones  
Project governance  
Project sponsorship  
Delegated authority limits  
Project roles and responsibilities  
Business case preparation  
Project charter preparation  
Project management software selection  
Requirements definition, management, and  
control
Work breakdown structure development and  
control
Scope definition, management, and control  
Cost estimating, management, and control  
Budget development and control  
Project financial processes  
Schedule estimating, management, and control  
Monitoring project performance  
Managing project changes  
Project status reporting  
Quality assurance processes  
Process audit procedures  
Quality control processes  
Risk assessment, management, and control  
Resource estimation, levelling, and management  
Project team formation and development  
Project communications development,  
distribution, and control
Stakeholder identification, engagement, and  
management
Customer engagement and management  
Procurement and contract assessment and  
management
Vendor management  
Claims administration and resolution  
Health and safety  
Environmental management  
Deliverable acceptance procedure  
Operational handover process  
Project, or phase, closure process and checklist  
Gathering and documenting of lessons learned  
Benefits realization and/or post implementation  
review process
Methodology tailoring guidelines  

192
Activity Resource Requirements

Project
Title: Date:

Author: Version

WBS Code Type of Quantity Description Assumptions

Resource

193
Change Log

Change Date Details Requeste Process Status Decision Date of Updates Who? Validation
No. d by? decisio
n

Give List Briefly Detail Describe Describe Has the Input Describe Describe Describe
very date descri who the the status change the the who is the date
chang the be the submitt process of the request date docume responsible and
e change nature ed the the change been the nts and for confirmati
reque was of the change change request approv decisi processe ensuring on that the
st a submitt chang request request i.e. ed of on s that the approved
uniqu ed e has to go further decline was will be approved change
e reques through informati d? made updated change is was
numb t i.e. on being as a implement implement
er considere sought, result of ed? ed (or not
d under awaiting an implement
delegated client approve ed) as
authority, approval, d planned
submitted etc. change. and
to change checked for
control correctness
board, or .
client
consultati
on
required.

194
Change Management Plan

Project: Date:

Author: Version

Change Management Approach:

Provide an outline of the change management process. You should specifically
address levels of delegated authority of project manager, project team members,
project sponsor, steering committee, change control board and any other relevant
stakeholders
Identify all people involved in the change control approval process
A clear text and graphical description of the change process
Reference to the correct change control templates
Describe different levels of change and how each is documented and processed

195
Delegated Authority

Name Role Responsibility Authority

Approved
by: Date:
Approved
by: Date:

196
Change Request

Project Name:
Project Manager:
Requested by:
Date:
Change Number: Insert the unique number for this change request. Record all
changes on your change log
Describe the nature of the Change Request
Describe the currently known work to be done as part of the project. Include both
project work and a description of the product, service or result to be delivered.
Attached any relevant documents, contracts, agreements or plans.

What are the implications on project cost and budget?

Describe any known impacts on project costs or budgets and propose potential
solutions. Include any necessary stakeholder approvals or comments.

What are the implications on project scope?

Describe any known impacts on project scope and propose potential solutions.
Include any necessary stakeholder approvals or comments.
.

What are the implications on project time?

Describe any known impacts on project timeframes and propose potential solutions.
Include any necessary stakeholder approvals or comments.

What are the implications on project quality, risk, communications or personnel

requirements?
Describe any known impacts on quality, risk, communications, and personnel parts
of the project and propose potential solutions. Include any necessary stakeholder
approvals or comments.

197
Are there any other impacts?
Describe any known impacts on other areas of the project and propose potential
solutions. Include any necessary stakeholder approvals or comments.

Change process
Describe the change process i.e. considered under delegated authority, submitted to
change control board etc.

Decision
Is the change request approved or declined?

Notification
List all documents and processes that need to be updated as a result of an approved
change and who will ensure the changes are made and validated.

Signatures: insert as appropriate when change approved or declined

Project Sponsor:

Project Manager:

Client:

Date:

198
Communications Plan Template

Project Name:
Prepared by:
Date:
Version:

Stakeholders Stakeholder Key Communication Timing

Issues Messages Methods

199
Cost Estimating Checklist

Project Name:
Prepared by:
Date:
Be certain that all possible needed resources are taken into account, including but
not limited to:

Project Management (figure at 10% of total)

Labor

Materials

Supplies

Travel

Fees for consultants and other outside professional services

Miscellaneous (shipping, copying, couriers, etc.)

Contingency planning

Inflation allowance.

Be as specific as possible, using as many means as you can to quantify the

resources the project will require.

Express cost estimates in units of currency.

Indicate other metrics, such as staff hours/days, as appropriate.

Be sure you consider every activity involved in the project, when computing
potential costs.

Allow for realistic quantities and frequencies of cost items, such as number of days
for equipment rentals, number of workers needed for each stage of the project,
and so forth.

200
Cost Management Plan Template

Project Name:
Prepared by:
Date:
Version:
Person(s) authorized to request cost changes (see Cost Change Request):

Person(s) to whom Cost Change Request forms must be submitted for approval:

Acceptable reasons for changes in Project Cost:

Describe how you will calculate and report on the projected impact of any cost
changes:

Describe any other aspects of how changes to the Project Cost will be managed:

201
Lessons Learned Template

Project Name:
Prepared by:
Date:
Lesson Learned Number:
Lesson Learned Proposed Name:
Project Team Role:
Process Initiating Planning Executing Controlling Closing
Specific
Group:* Project Management Process Being Used:

Specific Practice, Tool or Technique Being Used:

What was the action undertaken?

What was the result?

What might have been a more preferred result:

What might have created the more preferred result?

What is the specific Lesson Learned?

How could one identify a similar situation in the future?

What behavior is recommended for the future?

Where and how can this knowledge be used later in this current project?

Where and how can this knowledge be used in a future project?

Who should be informed about this Lesson Learned: (check one)

Executive(s) Project Project Team(s) All
Other: Manager(s) Staff
How should this Lesson Learned be disseminated? (check all that apply)
e-mail Intranet/Web site Tip Sheet/FAQ Library
Other:
Have you attached reference(s), example(s) and/or additional yes no
Name(s) of attachment(s):
material(s)?
1.
2.

202
Procurement Management Planning Checklist

Project Name:
Prepared by:
Date:
Version:
Identify types of contracts being used

Independent estimates required? Yes No

If Yes, who will prepare?

By when?

Actions that Project Management Team can take independent of Procurement

Department

Source of standardized procurement documents, if needed

How will multiple providers be managed?

How will you coordinate Procurement with the following aspects of the project?
Scheduling

Performance Reporting

Human Resources

Other

203
Product Description Development Outline

Project Name:
Prepared by:
Date:
Version:
Product or Service (intended outcome of project):

How This Product or Service supports the original motive for the project (business
need, market demand, customer request, technological advance, legal
requirement, social need, etc.):
a.

b.

c.

d.

Draft of Full Product or Service Description (with sufficient detail to enable later
project planning), for example:
a. Functional and performance requirements
b. Quality requirements
c. Cost requirements
d. Other

204
Project Archives Checklist

Project Name:
Prepared by:
Date:
Version:
Project Documents Located: Indexed Submitted Date Comments Initials
for
Archives

√
Project Charter
Scope Statement
Performance Measurement
Baselines
Key Staff
Scope Management Plan
Cost Management Plan
Cost Estimates
Cost Baseline
Staffing Management Plan
Role and Responsibility Assignments
Risk Response Plan
Work Breakdown Structure
Major Milestones and Target Dates
Risk Management Plan
Schedule Management Plan
Project Schedule
Quality Management Plan
Communications Management Plan
Procurement Management Plan
Supporting Detail for all Plan
Documents
Procurement Documents
Vendor Proposals
Project Contracts
Project Status Reports
All Change Requests
Performance Reports
Performance Measurement
Documents
Notes and Files of Key Project
Stakeholders
Other Documentation (Specify)

205
Project Change Control System Development Checklist and Worksheet

Project Name:
Prepared by:
Date:
Version:
Determine those responsible for approving or rejecting proposed project changes:
Be sure to provide for appropriate review of all changes.

Define Roles and Responsibilities of approving person or body:

Get key stakeholder agreement on roles and responsibilities (list stakeholders):

Define any types of changes qualifying for automatic approval without review:

Define steps by which contracts may be changed, including:

Paperwork

Tracking Systems

Dispute Resolution procedures

Approval levels required

Describe how contract changes will be integrated with the project's integrated
change control system:

206
Project Charter Template

Project Name: Insert name of the project

Project Manager: Insert name of the project manager and contact details
Project Sponsor: Insert name of the project sponsor and contact details
Client If the project has a client, insert client details
Date: Insert date
Version: Insert the version i.e. Draft, Final
Statement of work
Describe the currently known work to be done as part of the project. Include both
project work and a description of the product, service or result to be delivered.
Attached any relevant documents, contracts, agreements or plans.

Does this project align with the organisation’s strategic goals?

Describe how this project will align with organizational strategic goals.

What is the financial justification for the project?

Describe the financial justification for the project i.e. what is the payback period, cost
benefit ratio, return on investment, expected profit, net present value.

What is the non-financial justification for the project?

Describe any non-financial criteria being used to justify the project i.e. compliance
with regulations or standards, environmental objectives, charitable purposes or
gaining market share.

What is the budget required?

Describe the known budget required for the project or the next phase of the project.
Explain how it was estimated.

What is the preliminary schedule?

Describe the know time the project or phases of the project will take, Explain how
this was estimated.

Are there any known risks?

207
Describe any known projects risks, their consequences, planned responses and who is
responsible for monitoring them.

Are there any known constraints?

Describe any known time, cost or quality constraints affecting the project that may
impact further project planning.

Describe the particular project management methodology that will be used

Does the organization have a defined project management methodology? If so,
name and briefly describe it here

What lessons have been learned from previous similar projects and how will they
be applied to this project?
Describe the lessons learned from previous projects and how this project will use this
lessons to improve the chances of success.

What level of delegated authority does the project manager have?

What levels of delegated authority to make decision about resources, change
requests, budget and time does the project manager have?

Signatures: insert as appropriate when charter is finalised and approved

Project Sponsor:
Project Manager:
Client:

208
Project Closure Checklist

Project Name:
Prepared by:
Date:
Customer has accepted all project results: Accepted by:
1
2
3
4
5
6
Customer has accepted all other deliverables: Accepted by:
1
2
3
4
5
6
Customer has accepted from delivering organization
all other project requirements: Accepted by:
1 Staff evaluations
2 Budget reports
3 Lessons learned
4 Other
5 Other
Explain any exceptions to the above:

Documentation for the above has been filed/archived as follows:

Comments or remaining issues:

Checklist submitted by:

Name/Title: Signature: Date:
Name/Title: Signature: Date:

209
Project Communication Requirements Analysis Worksheet

Project Name:
Prepared by:
Date:
Version:
General Area of Information Optimum How is this Decision
Communication Needed, and Information communication to
Need for Whom? Format(s) essential to success implement
of project? Yes/No
Project
Organization
Relationships
Stakeholder
Responsibility
Relationships
Sponsor
Relationships
Senior
Executive
Relationships
Disciplines,
Departments,
Specialties, etc.
Logistics of
Project Staffing
by Location

External: Media

External:
Community
External:
Government,
Regulatory
Agencies

Other

210
Project Plan Update Template

Project Name:
Prepared by:
Date:
Version/Number:

Update(s) are being made to the following:

Project Charter Project Management Approach

Scope Statement Work Breakdown Structure
Performance Measurement Major Milestones and Target Dates
Key Staff
Baselines Risk Management Plan
Scope Management Plan Schedule Management Plan
Cost Management Plan Quality Management Plan
Staffing Management Plan Communications Management Plan
Risk Response Plan Procurement Management Plan
Updates to Supporting Detail? (explain):

Description of Modifications being made:

1.

Corrective Action:

2.

Corrective Action:

3.

Corrective Action:

Stakeholders being notified:

Name/Title: Signature: Date:
Name/Title: Signature: Date:

211
Project Planning Checklist

Project Name:
Prepared by:
Date:
Version:
No. Item/Comments Y N Planned Actual Actual
Completion Completion Effort
Goals and objectives defined
Scope defined
Major deliverables defined
WBS completed
Top-down planning estimates created
Major milestones defined
Master integrated schedule completed
Product and services requirements defined
Phase Plan completed
Organization Plan completed
Performance, evaluation, and test plan completed
Change Control Plan completed
Problem Tracking Plan completed
Documentation Plan completed
Change Management Plan completed
Communication Plan completed
Legal and Regulatory Requirements Plan completed
Risk Assessment completed
Risk Management Plan completed
Reliability, Availability, Usability Plan completed
Preliminary Support Plan completed
Interdependencies Plan completed
Resources Plan completed
Project Plan completed
Opportunity Costs calculated
Budget specified
Financial Analysis completed
Integrated Business and Realization Plan completed
Functional Deliverables defined
Top-level Architecture Specification Plan completed
High-Level Functional Specifications complete
Bottom-up Task Estimates created by functional groups
Detailed Functional Planning and Schedules completed
Functional Schedule Critical Path Analysis completed
Master Schedule Critical Path Analysis completed
Functional Coach Approval and Commitment
Master Schedule and Plan aligned with functional
groups
Planning Phase Checklist completed

212
Project Report Template

Project Name:
Prepared by:
Date:
Version:
Status of Project Relative to Project Objectives:
Scope (On scope? If off scope, how serious?)

Schedule (On schedule? Ahead or behind by how much, etc.)

Cost (On budget? Under or over by how much, etc.)

Quality

Progress Report: (what is completed, what is in process, key changes made, when and why, etc.)

Forecasting: (estimate of future project status and progress)

Other issues or comments:

Issue: Who Will Address:

Project Report Submitted to:

Name: Title: Date:
Name: Title: Date:
Name: Title: Date:

213
Project Scope Statement

Project Name: Insert name of the project

Project Manager: Insert name of the project manager and contact details
Project Sponsor: Insert name of the project sponsor and contact details
Client If the project has a client, insert client details
Date: Insert date
Version: Insert the version i.e. Draft, Final
Objectives
Describe the reason the project is being undertaken, the expected outcomes and the
purpose of the deliverable.

Project description
Describe the full scope of all the work to be done on the project i.e. the planning
work, the executing work, the monitoring, controlling and change control work, and
the close out work. List the parts of the project management plan that will be
completed as part of the planning work.

Product description
Describe the product, service or result that the project will deliverable. Take care to
describe it in detail and attached any related plans, and documents.

Acceptance criteria
Describe the process of formal acceptance on behalf of both your organization and
the client. List who will formally sign off and their role.

What is not included?

Describe all the work that is not included as part of the project

What are the key project milestones?

Describe the known project milestones

What is the project budget?

214
Describe the project costs broken down into categories, the project budget (i.e. Costs
over time), and any uncertainty in the estimating process.

What is the process for managing change?

Describe the change control process that will be used

Team roles
List and describe project team members, their role and responsibilities

Signatures:

Project Sponsor:

Project Manager:

Client:

215
Quality Audit Template

Project Name:
Prepared by:
Date:
Project Manager:
Project Phase: Overall Project Status:
Audit Date: Audit Number: Audit Leader:
Audit Team:
Goal(s) of This Specific Audit:

Audit of Management of Project:

1. (required project objective #1) Assessment: Comment:
2. (required project objective #2) Assessment: Comment:
: : :
n. (required project objective #n) Assessment: Comment:
Overall Assessment of Management of Project:

Recommended Action(s)/Lessons Learned Regarding Management of the Project:

1.
2.
3.
Audit of the Product of the Project:
1. (required product characteristic Assessment: Comment:
#1)
2. (required product characteristic Assessment: Comment:
#2)
: : :
n. (required product characteristic Assessment: Comment:
#n)
Overall Assessment about the Product of the Project:

Recommended Action(s)/Lessons Learned Regarding the Product of the Project:

1.
2.
3.
Additional Audit Comments:
1.
2.
3.
Have you attached additional material(s)? yes no
Name(s) of attachment(s):
1.
2.
Audit Report Submitted To: Date:
216
Quality Management Plan Template

Project Name:
Prepared by:
Date:
Version:
Description of Project Quality System:
Describe in as much detail as needed specifically what will be required in each of
the following areas to manage quality on this project:
Organizational structure

Roles and responsibilities

Procedures

Processes

Resources

Describe how each of the following aspects of quality management will be

addressed on this project:
Quality control

Quality Assurance

Quality Improvement

217
Responsibility Assignment Matrix Template

Project Name:
Prepared by:
Date:
Version:
PERSON
PHASE
Requirements
Functional
Design
Development
Testing

P = Participant A = Accountable R = Review Required

I = Input Required S = Sign-off Required

218
Risk Brainstorming Session Worksheet

Project Name:
Prepared by:
Date:
Session Facilitator:

Title/Position:

Participating Group:

Location:

Identified Risk Probability Potential Proposed Identified by

of Impact Actions Whom?
Occurrence

219
Risk Identification – SWOT Analysis

Project Name:
Prepared by:
Date:
Project Manager:
SWOT Analysis Facilitator:
SWOT Analysis Participants:

SWOT Analysis Recorder:

Date of SWOT Analysis:

Project Strengths: (What potential strengths exist about the project, the project team, the sponsor, the
organization structure, the client, the project schedule, the project budget, the product of the project, etc.?)
1.
2.
3.
4.
5.
Project Weaknesses: (What potential weaknesses exist about the project, the project team, the sponsor, the
organization structure, the client, the project schedule, the project budget, the product of the project, etc.?)
1.
2.
3.
4.
5.
Project Opportunities: (What potential opportunities exist in regard to achieving the project requirements, the
product requirements, the project schedule, the project resources, the project quality, etc.?)
1.
2.
3.
4.
5.
Project Threats: (What potential threats exist in regard to achieving the project requirements, the product
requirements, the project schedule, the project resources, the project quality, etc.?)
1.
2.
3.
4.
5.

220
 Risk Management Plan Template

Project Name:
Prepared by:
Date:
Version:
Description of Risk Management Methodology to be Used:
Approaches

Tools

Data Sources

Roles and Responsibilities:

Risk Management Action #1:

Team Leader

Team Members

Support

Risk Management Action #2:

Team Leader

Team Members

Support

[Add sections as needed]

Budget:

Timing: (Describe how risk management will relate to the project life cycle, and at what
points it will be reviewed during the execution of the project)

221
Risk Response Plan Template

Project Name:
Prepared by:
Date:
Version:
Description of Risk Identified:

Person(s) Responsible:

Results from Risk Analysis:

Agreed Responses (avoidance, transference, mitigation, acceptance):

Response #1

Response #2

Response #3

Residual Risk Level:

Action Steps:

Budget & Time for Response:

Contingency/Fallback Plans:

222
 Risk Register – remove the parts that are not needed

Risk Identification Qualitative Risk Analysis Quantitative Risk Risk Response Planning Residual Risk Analysis
Analysis

Risk Risk Risk + Urgency Probability Impact PxI P$ I$ P$ x I$ Risk Response Trigger Residual Residual Pr x Pi Who?
Category Event Consequence /- Assessment (P) (I) Probability Impact

(1-10) (1-10) (Pr) (Pi)

223
Schedule Management Plan Template

Project Name:
Prepared by:
Date:
Version:
Person(s) authorized to request schedule changes (see Schedule Change Request):

Name: Title: Location:

Name: Title: Location:
Name: Title: Location:

Person(s) to whom Schedule Change Request forms must be submitted for

approval:
Name: Title: Location:
Name: Title: Location:
Name: Title: Location:

Acceptable reasons for changes to Project Schedule (e.g., delays due to material or
personnel availability; weather; need to resolve related issue before proceeding;
acceleration permitted due to early completion of a phase or process, etc.):

Describe how you will calculate and report on the projected impact of any schedule
changes (time, cost, quality, etc.):

Describe any other aspects of how changes to the project schedule will be
managed:

224
Schedule Variance Analysis Worksheet/Template

Project Name:
Prepared by:
Date:
Reporting Period:
Project Activity Analysed Target Actual Amount of
Start/Finish Start/Finish Schedule
Dates Dates Variance

Cause of Variance(s):

Anticipated Impacts:

Planned Corrective Action:

Signature Name/Title: Date:

Signature Name/Title: Date:

225
Scope Management Plan Template

Project Name:
Prepared by:
Date:
Version:
Describe how Project Scope will be managed:

Assess the expected stability of the scope of this project (how likely is it to change,
how frequently, and by how much?):

How will scope changes be identified and classified?

Describe how changes in project scope will be integrated into the project:

Additional Remarks:

226
Staffing Management Plan

Project Name:
Prepared by:
Date:
Project Manager:
Version:
Project Team Role:
Approach to Identifying Human Resource Needs:

Approach to Determining Timing Needs for Adding and Removing Project Personnel:

Human Resource Needs:

Description Estimated Projected Timing Projected Completion
Number
1.
2.
3.
4.
5.
6.
7.
8.
9.
Projected Approach and Schedule for Updating Staffing Management Plan:
Triggering Event Expected Timing

Additional Notes:
1.
2.

227
 Stakeholder Analysis Template

Project Name:
Prepared by:
Date:
Version:
Project Specific Best Source Planned Timing
Stakeholder Information of Method of Considerations
Needs Information Delivery
Project Manager Needed

Customer #1

Customer #2

Customer #3

Performing
Organization

Project Team
Members

Sponsor

Senior Executive

Other Internal
Stakeholders

Other External
Stakeholders

228
Stakeholder Communications Register

Stakehol Contact Interest Power Interest PxI What? When? How? Who
der details (1-5) (1-5)
List the List their Describe their interest in Describe the Describe the Multiply Describe what sort Describe the Describe the Describe who
individual or contact the project power the level of interest power and of information frequency with means by is responsible?
groups of details stakeholder has the stakeholder influence they need which they will which the
stakeholders in terms of their has in the scores be supplied information
ability to affect project on a together with will be
the project scale of 1 -5: to get a information delivered
either negatively ranked list
1: No discernible
or positively on of
interest in the
a scale of 1 -5: stakeholde
project,
rs – pay
1: no discernible
2: some interest particular
power,
in the project attention
2: some power to all
3: Moderate stakeholde
to affect the
interest in the rs scoring
project
project 12 or
3: Moderate higher.
4: significant
power to affect
interest in the
the project
project
4: Significant
5: Is interested in
power to affect
all aspects of the
the project
project all the
5: The power to time.
affect the entire
project

Power x Interest scores:

1-6: These stakeholders can usually be ignored but keep an eye on them in case the situation changes.
7 -12: Communicate regularly with these stakeholders to ensure they get the information they require
13 – 18: Take careful notice of these stakeholders and their needs.
19 – 25: These stakeholders need to be closely monitored and kept satisfied to ensure they provide support for the project, or at least don’t oppose the project

229
Statement of Work Template

Project Name:
Prepared by:
Date:
Version:
Vendor Name:
Description of Deliverables or Procurement Items (in as much detail as needed to accurately
define the proposed work):

Required Timeline and Milestone Dates:

Collateral Services Required of Vendor (e.g., performance reporting, post-project operational

support, etc.):

Cost Parameters:

230
Template for Formal Acceptance and Closure

Project Name:
Prepared by:
Date:
Name of Client or Sponsor:

Statement of Formal Acceptance:

The undersigned formally accept as complete the above-identified project, and do

hereby state that this project, project phase, or major deliverable meets or exceeds
agreed-upon performance standards for scope, quality, schedule, and cost, and
state that we have seen documentation that all relevant legal and regulatory
requirements have been met or exceeded.

Additional Remarks:

Accepted by (name of client, sponsor, or other official) Date

Accepted by (name of client, sponsor, or other official) Date

Accepted by (name of client, sponsor, or other official) Date

Signed form distributed to:

Stakeholder name Date

Stakeholder name Date

Stakeholder name Date

231
 Thank You!

Please remember to stay in touch to ensure you have the latest version of this book,
and as always, if you have any questions at all please just send me an email and I will
do my best to answer your questions.

Sean Whitaker
[email protected]

232