Common Project Management Mistakes - Vanguard Scotland › downloads › VSProjecteBook.pdf · 2019-01-19 · Common Project Management Mistakes ... 19 Mistakes in the management

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



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



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



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



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 [email protected]

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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 [email protected] 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



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



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



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



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 [email protected]

Documents

Common Project Management Mistakes - Vanguard Scotland › downloads › VSProjecteBook.pdf · 2019-01-19 · Common Project Management Mistakes ... 19 Mistakes in the management