common project management mistakes - vanguard scotland › downloads › vsprojectebook.pdf ·...
Post on 06-Jul-2020
2 Views
Preview:
TRANSCRIPT
Page | 1
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Daniel Rodgers
Stuart Corrigan
Common
Project Management
Mistakes
A guide to help you run your projects on time, in full and on budget
3rd Edition
Page | 2
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Table of contents
Page Content
3 Introduction
6 Section 1: Common problems
7 Section 2: Why traditional approaches to projects don’t work and what to do differently
8 Solutions for planning – the 6Cs
10 Building better networks
13 Mistakes during execution of the project
14 Solutions for delivering early and avoiding student syndrome
17 Exercise (Multi‐tasking)
19 Mistakes in the management of the project
23 6 rules for managing projects
24 Section 3: Six practical steps to building and running better projects
26 Check your project management ‐ questionnaire
Page | 3
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Introduction
Hi, this is Daniel Rodgers and Stuart Corrigan from Vanguard Scotland Ltd.
Let’s start with a little known fact about project management:
The common methods of building and managing
projects don’t work very well.
In compiling this guide we’ve worked with many Chief Executives, project managers,
managers and team leaders and they all contacted us to ask the same thing:
“Why is it that we can’t get our projects to deliver on time, on budget or in full?”
And here is the awful truth, every single one of them is doing exactly what they’ve been told
to do by the traditional project management books, guides, courses and institutions. Yet
they still can’t get what they want, a method that works.
Let me give you some examples:
Example 1:
Mark is an internal consultant for a large German car company. His job is
to make sure that the new designs deliver on time, they work and they
come in on budget.
We worked with him to get baseline data on how well his method
performed. Guess what? He was using the most respected project
management method in the world. In fact if you were to go into Mark’s
office you would find the most beautiful project plan we’d ever seen,
detailing every single task that needs to be delivered and when it needs to
be done. Yet a typical project took too long to deliver, used the wrong parts
and cost €50M a year in additional test equipment.
Example 2:
Jim manages the resurfacing of roads in Glasgow. Compared to our friend
in Germany he has a small team. He manages them tightly, sets them
achievable due dates, starts the projects as soon as he can and gets an
update once every day on how much they’ve completed. Compared to
Mark, he has a small department, but last year he was so over budget and
late that the next year’s plan became redundant before it even began.
Page | 4
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Example 3:
Let’s take one of our own examples. Last winter Stuart was getting a new
bathroom fitted. The owner of the bathroom shop turned up with a
printed Gantt chart and said that they key to getting everything finished on
time was to start all the different work streams as soon as possible. He was
a week late. Months later… aspects of the bathroom were still not finished!
Unfortunately many of the books, courses and institutes are wrong about many things.
What the people in the above cases studies later learned was that what they had been
previously taught not only failed them in delivering a better job, but also that their
assumptions themselves actually contributed to badly run and poorly delivered projects.
Here are some examples of what you can achieve if you move away from the traditional
methods:
Road resurfacing
Results: Improved prioritisation and annual programme completed in 8 months
IT system build
Results: Project finished 4 weeks early and absorbed 4 weeks of additional work
Seagate Bespoke engineering in the electronics industry
Results: 18 month project completed in 9
ABRO Military reconditioning of equipment such as tanks
Results: Project backlog reduced by more than 50% and projects completed 25%
faster than before
No matter what type of project business you work in, we trust you will find something here
to help you. In this guide we’ve set out to share the secrets of great project management.
Specifically:
Common problems in project environments
Why traditional methods of project management don’t work and what to do
differently
Six steps to building and running your next project
Page | 5
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
It is worthwhile remembering that whilst many of the lessons and insights we will share in
this guide are practical and easy to use they may be counterintuitive.
So take time to digest each piece of information one piece at a time. In fact I would
recommend that you separate the different chapters and take a day’s break between each
one, so you can really get your head around the concepts.
Like most guides there is only so much we can teach you without being on site and coaching
you personally but we hope that this guide points you in the right direction.
If you have any questions contact us via office@vanguardscotland.co.uk
And if you need more information on the courses we offer you can visit our website at
www.systemsthinkingmethod.com/sectors‐project.html
Ok the advertisement is over so let’s get on with the guide.
Page | 6
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Section 1: Common problems
Projects suffer from three main problems
Almost every project we’ve studied has had three main issues, poor due date performance,
a failure to complete all the work specified in the project and a failure to bring the project
in at the right cost.
We’ve worked with organisations whose on time delivery of projects is as low as 17%. Based
on the number we’ve seen with similar performance we think that this is considerably more
wide spread than publicised. Oh, and if you think “that’s not me”, we actually mean the
original promised date and not the one you have revised (probably more than once).
The problem is that at the end point there is typically a customer; someone who is waiting
for the delivery of a product or service but has been let down.
We’ve also come across projects where they were not only delivered late but the agreed
specification was not met. How would you feel if you had been the last home in a row of
houses to get its roof replaced but the date for the job had long passed and the housing
association decided that yours would be done next year?
We even heard a story from a prestigious car maker whose engineers were tasked with
delivering a new engine in time to present it to the investors as the next big thing. They
were so late they put a current engine in its place for the press release in the hope that no‐
one would notice.
Finally, projects go over budget a lot and when they do, something suffers, maybe it’s vital
research and development, maybe it’s clients, maybe it’s jobs. Either way money matters.
This eBook is not just about how to survive projects; it’s about how to deliver them on time,
in full and on budget.
Page | 7
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Section 2: Why traditional approaches to projects don’t work and what to do differently
Mistakes during the planning phase of projects
Often project planning takes too long, yet despite this it’s completely normal to be half way
through a project only to find that a required deliverable has been completely missed in the
planning stage or that the deliverables are in the wrong order.
Another problem is that the planning is far too detailed, going down to planning at the task
level. The problem is that there’s now over‐planning and the project never gets started.
And in multi‐project environments the planning never seems to end, as project managers go
through the futile job of rebuilding similar project networks over and over again.
A lack of a list can also hinder the on‐time performance of your projects. The problem is
that because there’s no list, no–one is sure what project to start next which means that they
are likely to work on a project that they like rather than work the priority project.
On the subject of priorities, are your team clear on their priority tasks for the day, does
everyone know the order in which projects should be completed and why? If not you may
find that valuable time is being spent working on tasks and deliverables that are not due for
a while. The problem being that the important task/deliverable runs late because resource
is consumed in low priority work.
Page | 8
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Solutions for planning
Just remember the 6Cs:
Create better networks using just deliverables
Check for necessity
Check for sufficiency
Create a template
Create a list
Create a priority policy
Let’s look at each in detail.
Create better networks using just deliverables The first thing we are going to do to plan properly and save time is to build
the network using the deliverables not tasks.
Difference between a deliverable and a task
Let’s say the deliverable is to set up a new scheduling system
for a heating repairs service. There will be a number of tasks
that require completion in order to reach the deliverable which
is to install the heating system.
So the deliverable is the aggregation of the tasks which form a significant piece of work and
a task is an individual piece of work which must be completed to reach the deliverable.
Page | 9
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Discussion point:
What is so wrong with building your project by identifying all the tasks, will it
not mean that you are ultra well planned and have a better chance of
finishing on time?
No: Often it is not relevant to the Project Manager or the Customer. It only
serves to drag Project Managers into a cycle of micro‐management and build
in a massive number of task due dates, the problem with which we will
discuss later.
Page | 10
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Building better networks
A little understood fact is that the desire to complete projects on time is one of the very
things that make them run late. This is because traditionally not enough time is spent
building the network in the planning phase.
STOP! Let’s define a few terms:
A network is all the deliverables that go together to make up a project
plan, you can see an example below.
As previously stated, a deliverable is a series of tasks (it is not a task)
that when completed becomes a significant piece of work, look below
to get the idea
By planning we mean understanding the dependencies i.e. the order of
priority of the deliverables.
W e b u i l d a n d t e s t t h e r i g h t e n g i n e t o
p r o v id e q u a l i t y t e s t d a t a o n t i m e a n d a t
t h e r i g h t c o s t
M a n a g e s u p p l ie r s p r o p e r l y
M e a s u r e s a r e d is p l a y e d
G o o d t a s k m a n a g e m e n t in
p l a c e
T a s k a r e p r i o r i t i s e d
a c c o r d i n g t o b u f f e r
c o n s u m p t io n o n l yD e f in e d m e t h o d o f t a s k m a n a g e m e n t
T r a i n i n g o f E 2 - E 5 c o m p le t e d
S h o p f l o o r p r o c e s s
i m p r o v e d
P r o b l e m s o l v in g p r o c e s s
i m p le m e n t e d
“ s h o p f l o o r ” K P I s
D e v e l o p e d
“ s h o p f l o o r ” p r o c e s s e s a n a l y s e d
E n g in e e r i n g a r e m a n a g e d
E n g in e e r i n g a r e e d u c a t e d o n t h e o p e r a t i o n o f t h e
b u f f e r s a n d m e t h o d o f e s c a la t i o n
R e s o u r c e P l a n c o m p l e t e d ( 2 0
d a y s )
A l i s t o f c u r r e n t o p e n p r o je c t sI s c r e a t e d ( 1 0
d a y s )
C r i t e r ia f o r p r io r i t i s a t i o n i s
a g r e e d ( a ls o f o r c h a n g i n g p r io r i t y )
A p r i o r i t i s e d p r o je c t
p o r t f o l io i s c r e a t e d
R e s o u r c e s a r e r e a l i g n e d t o w o r k
o n l y o n h i g h e s t p r i o r i t y p r o j e c t s
B o t t o m 2 5 % o f t h e l i s t i s “ f r o z e n ”
W h a t s t e p s a r e c l a s s e d a s
p r e p a r a t i o n a r e id e n t i f i e d
C o m p l e t e p r e p a r a t io n f o r
a l l u p c o m i n g p r o j e c t s
I d e n t i f y d i f f e r e n t p r o j e c t t y p e s
B u i l d p r o je c t n e t w o r k s
D u r a t i o n d e t e r m i n e d
C r i t i c a l c h a i n i d e n t i f i e d f o r e a c h p r o je c t
P r o je c t p l a n s c r e a t e d f r o m
t e m p l a t eA s s ig n r e s o u r c e t r a in e d in
d e v e lo p i n g p r o j e c t n e t w o r k sC o m p l e t e
t r a i n i n g s e s s i o n s a n d
t r a in in g p la n f o r p r o j e c t n e t w o r k s
I n t e g r a t i o n p o i n t i d e n t i f i e d
P r o je c t t e m p la t e s a r e
d e f i n e d
P r o je c t b u f f e r s in s e r t e d
C o m p le t e d p r o j e c t s c h e d u l e
a r o u n d i n t e g r a t i o n p o i n t
M e a s u r e s a r e d is p l a y e d
L i s t o f s u p p l ie r s c o m p le t e d
R e v i e w a n d a m e n d s u p p l ie r a g r e e m e n t
f o r h ig h r i s k s u p p l ie r s
W e m a n a g e t h e p e r f o r m a n c e o f o u r
s u p p l ie r s
P r o c u r e m e n t a r e t r a in e d in t a s k m a n a g e m e n t
I d e n t i f y h i g h r i s k s u p p l i e r
R is k a n a l y s is o f s u p p l i e r s c o m p l e t e d
A g r e e a l i s t o f m e a s u r e
C o l l e c t a n d a n a l y s e p e r f o r m a n c e in f o r m a t io n
D e v e l o p t r a i n i n g m a t e r i a l s p e c i f i c f o r
p r o c u r e m e n t
I d e n t i f y t r a i n i n g p a r t i c i p a n t s
D e l i v e r a t r a in in g c o u r s e
S u p p l ie r s c o n s is t e n t l y
p r o v i d i n g p r o j e c t p l a n s
S u p p l i e r s a r e e n g a g e d in o u r
p r o j e c t p la n n in g p r o c e s s
O u r n e w p r o j e c t p l a n n i n g p r o c e s s i s
c o m m u n ic a t e d t o o u r s u p p l i e r s
S h o p f l o o r s t a n d a r d is a t io n
c o m p l e t e d
F u l l k i t
R e s o u r c e p l a n n i n g
P r o j e c t P l a n n i n g
S h o p f l o o r m a n a g e m e n t
T a s k M a n a g e m e n t
S u p p l i e r M a n a g e m e n t
C u s t o m e r M i t i g a t io n
Page | 11
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Here’s how to build better project networks faster.
Step 1:
Make the end objective clear. It seems obvious doesn’t it, that before setting out on
a journey you should really know where you’re going. Yet many people start projects
not knowing exactly where they want to end up. Also the end objective (and the
deliverables) should be written in present tense, simply so that when you’ve got to
the deliverable it reads like it’s now completed.
Step 2:
Write, just on post it notes at this stage, all the deliverables (chunks of work)
required to achieve the deliverable.
Step 3:
Put the deliverables in the order in which they should be completed (necessity logic),
making sure that ‐ if possible ‐ deliverables are shown in parallel. If there is a
dependency show one after the other.
This is called checking for necessity.
Checking for necessity is done to be sure that the deliverables are in the necessary
order required to complete the tasks.
Step 4:
Check to make sure that you have all the deliverables, i.e. you haven’t missed any
required to meet your end objective. This is called checking for sufficiency. We make
sure that we have all the deliverables that we need so that we don’t have to go back
and re‐plan during the project.
Trust me there is nothing worse than having made a commitment to a chief executive
about when a new product will be launched only to have to go back and tell them you
got your dates wrong.
Step 5:
Allocate an estimation of time to each of your deliverables, note the estimated time
is allocated only at the deliverable level not at the task level.
Page | 12
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Step 6:
Allocate resources to each of your deliverables. You can simply do this by putting
initials against each deliverable.
Step 7:
Check to make sure that there is no overlap of resources on your project network. If
there is a resource contention, re‐order the deliverables on your project network.
Step 8:
Check each deliverable and make a list of the tasks required to complete it.
Step 9:
Put the tasks in order on a master list.
Step 10:
Allocate your first task using the words “Complete this task, do it as quickly as
possible unless you get blocked, in which case tell me (the project manager)
immediately.” (More on this in the next section.)
Step 11:
Having built our template we are going to keep a copy so that if we have to build a
similar project we can simply remove the deliverables that we don’t need. A great
way to save time!
Watch video 1:
Building a plan
Page | 13
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Mistakes during execution of the project
Mistake 1: Using due dates makes projects run late and ensures poor quality
The biggest mistake that traditional project managers make is that they use task due dates
to manage their project. I know what you are thinking…
“Everyone uses due dates, how can you manage a project without them.”
Or,
“People have no sense of urgency if there are no due dates”
You’re right, everyone does use due dates, but that doesn’t make them right! You can
manage your project better if you don’t attach due dates to the tasks and we can guarantee
you will not lose any urgency. In fact there will likely be a greater sense of urgency.
Here’s an illustration of why:
Do you remember your school, college or university days? At some point a teacher
or lecturer asked you to complete an assignment to be handed in at a future date.
Unless you were really enthusiastic about completing essays you probably pushed
the assignment to one side saying to yourself “this essay doesn’t have to be in for a
few weeks so no need to start it tonight, I’ve other stuff to do.” One night’s delay
soon becomes two, then three, and before you know it you are working though the
night to deliver the essay on time for the morning deadline. This is called student
syndrome.
It also happens when a date is attached to a task, the natural tendency is to wait until
the task is near due and start then.
This wouldn’t necessarily be an issue except for one problem. Student syndrome
loves sod’s law. That is the law that says if something can go wrong it will. So you
can guarantee that a few hours before your essay is due there will be a power cut or
your laptop will get a virus. And since you haven’t any time left to sort the problem,
you will be reduced to having to persuade your lecturer (unsuccessfully) that the dog
ate your paper.
Page | 14
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
So student syndrome and sod’s law combine to make projects late, here’s why:
If someone assigned to a task knows when it will be due and it’s not due immediately
then the chances are a natural delay will be built into the project, which means that
the project will never benefit from potential early finishes but will always suffer if
something goes wrong because there will be little opportunity to recover the losses.
Furthermore there is a second problem that occurs when a due date is assigned.
Quality of work suffers. For instance if a project worker has a task to complete and
knows that if they fail they will be punished (which is not unusual), then they will cut
corners to complete the task.
Note that I am not suggesting that projects are inhabited by lazy
incompetent people. Quite the reverse, good people lose their sense of
purpose when a completion date is assigned to a task, focusing on the
deadline not the work.
Solutions for delivering early and avoiding student syndrome
There is only one due date – the one required by the customer
Here’s how to solve the problem of due dates, it’s easy really. There is only one due date,
the date the customer needs the product or service that is within your systems capability. If
we understand the estimated durations for each deliverable we can determine likely start
and finish dates. However, we are not going to manage the project by these dates.
Here’s how it works. When the project plan (we’ll call it project network from now on) is
being built there will be some estimates for how long each deliverable (significant chunk of
work) will take to complete. The deliverable is then broken down into a series of tasks.
Page | 15
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Now the clever bit about how to ensure that your project does not suffer from student
syndrome:
The role of the task manager is to hand out the tasks to those working on the project. When
the tasks are given out this is done with four conditions.
1. The person working on the task should not be told when the task
is due for completion. The benefit of doing this is that the chance
of the task suffering from student syndrome has just been reduced
and as a result if (when aggregated) the tasks finish early the whole
project can finish early.
2. The person doing the task is given a simple rule: “complete the task
as quickly as you can and do it correctly, in the event that you
cannot continue in the task contact me (the project manager)
immediately”.
3. The project manager will check on a daily basis to get an idea of
the estimated completion date of the task. Note again that he is
not telling the person doing the task whether they are on schedule.
4. The tasks are released either one at a time or in small work
packets. This means that the opportunities for multi‐tasking
(constantly picking up and putting down tasks), and hence late‐
running projects are vastly reduced.
The project may now even finish early.
Watch Video 2:
How to hand out and manage tasks
Page | 16
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Mistake 2: Bad multi‐tasking between and within projects
First, let us define the term multi‐tasking, and understand why it
is bad. Multi‐tasking means moving from task to task without
finishing. This is normal in projects. Consider this example:
Three deliverables worked on one after another to completion
Now let us see what happens in a system where there is prolific
bad multi‐tasking
There are a number of things going on in this example. Each task
takes longer because the resource doing the task has to re‐learn
what went before. What is worse though is that all deliverables
are completed much later than before. Look at how much later
“A” is completed in the second example – It’s staggering.
The problem is that because there is constant stopping and re‐starting some tasks need re‐
work, problems occur because the task has been left, or maybe just some thinking time is
required before the task can be re‐started. The cumulative result is that the whole project
takes longer.
In environments where there are multiple projects going on the problem is made even
worse when multi‐tasking occurs across projects. Here the result is that all the projects will
take longer.
Page | 17
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Here is an everyday illustration:
Say a tradesman is doing some work at your home, perhaps fitting your bathroom.
He sends in some other tradesmen to work in parallel. The electrician gets called
away to another task so they start doing the tiling before the electrics are finished. As
the electrics are not sealed, some water gets into the wires and fuses are blown. The
work has to be stopped to safely seal the wires and replace the fuses. The project is
now running late.
It gets worse still. The tradesmen get a call to go another job; whilst they are away
nothing is happening on your job. In the end you discover that they are actually
working on four jobs at the same time. Guess what happens? All four jobs run late.
EXERCISE
You will need some volunteers, some paper, a pen and a stopwatch.
We will do this in two stages. Imagine we have three projects to deliver. We have to write a
column of numbers, a column of letters and a column of shapes.
In the first pass I want you to do some prolific bad multi‐tasking. You must work across the
page completing one entry in each of the 3 ‘projects’ or columns before moving down to the
next row.
Like this:
Numbers Letters Shapes
1 A
2 B
3 C
4 D
Complete the table until you get to 20 entries in each column. Record the time you took to
complete each column.
Page | 18
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Now, repeat the exercise this time with no multi tasking. You must work down the columns.
Completing the 20 rows in each one before moving on to the next column, like so:
Numbers Letters Shapes
1 A
2 B
20 T
As with the last time you need to record the time you took to complete each column.
Which way do you work? The first or the second way?
It’s no secret that multi‐tasking goes on everywhere, but few people recognise it is
happening and even fewer know what to do about it. But we are about to change all that.
At this point you may kick yourself because the solutions are almost too easy.
Solutions for Multi‐tasking
On reading these solutions we’ve no doubt you will say, “common sense”. You’re right, but
not common practice.
Step 1: Create a priority list & policy
In multi project environments you must put the projects in their order of priority and
stick to that priority. This might sound like a no‐brainer but you would be surprised
at the number of organisations with no such list.
If your projects are not in priority order then that’s your priority!
One of the biggest mistakes we see in multi‐project environments is that there is no
priority policy for the order of projects in the list. There is no point in creating a list if
you are going to change the order every few days.
Step 2: Choke release across and within projects
There’s always an urge to start more projects, and the earlier you start projects the
earlier you finish, right? Wrong! Actually because there are more open projects
there’s more temptation to jump onto a lower priority project in order to keep busy
Page | 19
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
or because there’s a task that’s more enjoyable. The problem is that when the
urgent task pops up the resource needed to complete it is not available and as a
result the whole project can run late.
And here’s the secret to releasing tasks within projects. Once again restrict the
release of the tasks. What this means in practice is that within projects you only give
out one task at a time. When that task is finished another is provided.
This stops those doing the work jumping from task to task because another might be
easier, more convenient or more enjoyable to complete.
The best way to do this is to have your tasks printed on small cards in the order that
they need done. In the morning you give out the card and explain that when the task
is done, come and get another.
We can promise another benefit. The project workers will love it, the opportunity to
work on one job till the end, undisturbed.
Of course you also need to communicate to anyone more senior than the project
workers that they are not to be pulled off a job without consent from the project
manager.
Step 3: Freeze and accelerate multi‐projects
If you already have a number of projects live then freeze at least 25% of the open
projects. Yes that means stop work on some of the projects you’re currently working
on.
Take the resources and put them into the other more urgent projects.
Only defrost projects as others are completed.
Watch video 3:
Creating a priority rule and a list
Page | 20
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Mistakes in the management of the project
Mistake 1: Asking the wrong questions to manage tasks
When checking on the progress of a project, traditionally managers are taught to ask a
simple question, they don’t know it will hurt the delivery of their project. The question they
ask is:
“What percentage of the task is complete?”
(Don’t ask this.)
If you have Microsoft Project, you will see the basis of its updates are to show the
percentage of the project complete.
We have bad news! As everyone who has employed a tradesman and is still waiting on their
job to be completed knows, asking how much they have finished tells you nothing about
when they are likely to actually finish.
To return to the earlier example of Stuart’s bathroom, the plumber said he was 95% percent
complete at the end of one week, months later the bathroom is still not finished.
A further issue with asking this question is that you won’t know if your project is going to
run late until it actually is late. For example, let’s say a project worker tells you he is 95%
complete (though he doesn’t precisely know) you know that you have another week before
you need the task completed. You think you have lots of time no need to plan any recovery
actions he only has 5% of the work content left. Then before you know it you are running
late and the task still has 5% of the work left to do. Now you are playing catch up and the
whole project is jeopardised.
Solution
So what question should you ask? Its beautifully simple… you just ask:
“How many days until you complete your task?”
This way you can get an update every day of how each of the tasks are doing and have an
early warning system to tell you if you are going to run late. So, if you think there might be a
problem then you can create, and if necessary execute, a recovery plan.
Page | 21
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Mistake 2: Using the wrong measures
We are now left with a question of how to measure the progress of projects.
The problem is that project measures are traditionally taken after the event. There’s no
point in knowing that your project is late after it’s late!
We need to be able to take action before the situation is terminal.
So will discuss how to monitor progress with a method from Goldratt’s Critical Chain
methodology called buffer management.
This means that the project manager will have an awareness of the project running late and
will be able to assign extra resource if required to a task. The job of the person doing the
task is to do it right and in the quickest time possible.
Can you see how combining this practice with limiting the release of work into the system
would help people to fully concentrate on one task, get it started as soon as possible and do
it right? The outcome of these practices is faster throughput of projects, higher motivation
and higher task quality.
Solution ‐ Buffer management
Definition of Buffer Management:
Buffer management is the process of removing some of the
assumed safety margin built in within a series of tasks and placing
it at the end of the project.
Let us imagine a situation where we have 3 tasks, each of which is 10 days long (remember
only the project manager knows this) giving a total deliverable time of 30 days.
Due to the desire to deliver projects on time, a sensible safety margin will be built into the
tasks at the planning phase (have you ever had an important interview and left really, really
early to make sure you get there on time?). So you’ll estimate how long the task will take
and add a few days to be safe in case there are problems. Too much safety is often built in.
Eli Goldratt assumes about 25% is about right so in this case you’re adding about 10 days.
The chain of work then is really 40 days, 30 day’s work and 10 day’s safety margin. That
safety margin may or may not be needed in any one task so it may be wasted but it’s only
Page | 22
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
wise to have some sort of safety margin because there is always the chance of delays on a
task at some point.
So here’s what you do.
You take the safety margin away from each individual task and pool it in a buffer at the end
of the chain. Split your project Buffer in to three sections (in this case of 3.3 days each) and
colour each green, yellow and red (see the example chart below).
What happens is that when the project manager is asking about when the tasks will be
completed, any late‐running tasks will start to eat up the buffer. You now not only have the
opportunity to finish the project early if you don’t use up your entire buffer, you also have
an early warning system if it’s running late. As soon as the buffer goes into the yellow a
recovery plan is built. When it hits red the plan is put into action. Here is what it looks like:
The measures are then the number of reds per project and over all projects you can gather
data on what happened each time and learn from it.
Watch video 4:
Managing a project and using buffer
management to predict and cure a late finish
Page | 23
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
So there you have it, 6 rules for managing projects:
1. Take more time to plan your networks
2. No due dates when assigning tasks
3. Limit the work release to avoid multi‐tasking
4. Restrict the number of open projects
5. Check completion date not percentage complete
6. Measure the project using buffers
In the final section we will take each of these rules and put them into logical practical steps
so you can get started building networks and running projects.
Page | 24
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Section 3: Six practical steps to building and running better projects In the previous section we told you what to do and why, in this section we will do a final
summary to make sure that you’ve got everything you need to build, execute and deliver
your project on time, in full and on budget.
1. Take more time to plan your networks
a. Start by verbalising the end objective
b. Using post it notes write out all the deliverables (substantial pieces of work
needing done) to get you to your end objective.
c. Sequence the deliverables. To do this pick up two post it notes and ask “in
order to do this deliverable do we first have to do this other deliverable?” If
there is no dependency, show them in parallel, if there is a dependency show
one after the other.
d. Check for sufficiency. Having built your networks, and working from the front
to the back, ask this question, “if we complete x+y+z (go through all
deliverables) is it sufficient to complete our end objective?”
e. In multi‐project environments decide on a policy for the order of the projects.
f. Put the projects in that order.
Page | 25
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
2. Assign tasks without due dates
a. Make sure the little 3x5 cards have no due dates on the tasks, just tell the
project team “work on this task as fast as you can but do it right”.
3. Limit the work release to avoid multi‐tasking
a. Write out all tasks required to complete the deliverables in order (necessity)
and check for sufficiency for each deliverable. Then give out each task one at
a time.
4. Restrict the number of open projects
a. Take all your open projects and immediately freeze the bottom 25%.
b. Take the resources previously working on the frozen projects and allocate
them to the top priority projects.
5. Check completion date not percentage complete
a. When checking for progress ask the question “when do you estimate you will
finish?”
6. Measure the project using buffers
a. Use buffer management to keep your projects on time.
The purpose of this guide is to get you going if you are a beginner and to get you to question
some of your assumptions if you are an expert. We hope you will agree that we’ve delivered
that and more.
As with all written guides, there is only so much you can learn without actually speaking to
an expert…
If you would like to have us assess (with you) how your projects are currently working e‐mail
us at office@vanguardscotland.co.uk for more details.
We’ve appended a questionnaire to help you get clarity on where your project management may
have issues. Try it and see how you score.
Page | 26
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
Check Your Project Management Questionnaire
COMPROMISES TO SCOPE
1. Study the paperwork for the last 10 projects that were run in your organisation. Do this with the
project manager and some of the people who carried out the tasks and in each project simply
ask the question.
a. How often did the scope change on this project?
__________________________________________________________________
__________________________________________________________________
b. What were the main changes to the scope of the project?
_________________________________________________________________
_________________________________________________________________
_________________________________________________________________
c. What was the FIRST estimated due date of this project?
_________________________________________________________________
_________________________________________________________________
d. Did it come in on the due date?
_________________________________________________________________
_________________________________________________________________
e. What was the FIRST estimated budget for this project?
___________________________________________________________________
_________________________________________________________________
f. Did the project come in on the first estimated budget?
________________________________________________________________
________________________________________________________________
Page | 27
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
2. Get some project managers, task managers and project workers in a room and ask them the
following questions?
a. Think about the last 10 projects that you were involved in, how often were there changes
to scope?
__________________________________________________________________
_________________________________________________________________
b. What were the common types of changes?
_________________________________________________________________
__________________________________________________________________
_________________________________________________________________
c. How much did this impact the time and budget of the projects?
_________________________________________________________________
__________________________________________________________________
_________________________________________________________________
THE LIST AND PRIORITIES
1. Go and find out if a list exists. Ask to see it. Ask who else knows about the list. Check to see if they
really do know the order in which projects are to be completed.
________________________________________________________________________
_________________________________________________________________________
_______________________________________________________________________
2. Ask about the priority rule, is there one? If there is, is it adhered to? If not how often is it changed?
________________________________________________________________________
_______________________________________________________________________
______________________________________________________________________
Page | 28
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
MULTI‐TASKING WITHIN PROJECTS
1. Is it common for the project manager to pull you from one task to another?
______________________________________________________________________
______________________________________________________________________
2. How many tasks are you given at any time? (If they are given more than 2‐3, they are probably
multi‐tasking).
_______________________________________________________________________
_______________________________________________________________________
3. Is it common on projects to have lots of open tasks?
_______________________________________________________________________
_______________________________________________________________________
PROCESS MAPPING
(Ask these questions for each individual deliverable).
1. Did anything go wrong at this step in the project? If so what?
__________________________________________________________________________
________________________________________________________________________
_________________________________________________________________________
2. Is it common in other projects?
_______________________________________________________________________
________________________________________________________________________
4. What was the impact on time or money?
__________________________________________________________________________
________________________________________________________________________
__________________________________________________________________________
Page | 29
www.systemsthinkingmethod.com
©Vanguard Scotland Ltd 2011
MEASUREMENT: DUE DATES AND PERCENTAGE COMPLETE?
1. Do you give project workers due dates for their tasks?
________________________________________________________________________
_______________________________________________________________________
2. What measures are used to determine the project progress?
_______________________________________________________________________
__________________________________________________________________________
_______________________________________________________________________
This questionnaire is just to help you get clarity on where management of your projects could be
improved and made more robust but if after completing it you feel in need of support in effecting
change contact us to discuss your needs on 0131 440 2600 or via office@vanguardscotland.co.uk
top related