Introduction

This will probably become the most extensive document on my website. Here I will try to share over 20 years of lessons learned. A lot of the information is about the recipes for failure. I hope you can learn from it and that it helps you avoid some, if not all of them.
Writing this article even helps me not to repeat past mistakes.

In the top right corner of this article you can click on the PDF button. The length of this article makes reading a paper version advisable.

1. No lessons learned?

Unfortunately project history is hardly ever recorded. Does this mean history has no value?

For me history has a lot of value, I try not to repeat my mistakes and if possible I would like not to make mistakes others made before me.

Relating this to sound project management, Prince2 describes writing down the lessons learned as mandatory. Common sense agrees with writing them down.

I can only state the obvious: "There should be a log evaluating every aspect of a project. It does not mater if this project was a success or not."

What happens if the lessons learned are left to the collective memory, can be illustrated by the failure rate of Dutch government related projects. SVB, Internal Revenue and lately UWV, they all failed and although we know why, it is not documented.
Even now, knowing that you should document the lessons learned, we can't even gloat about the stupidity. This stupidity is paid with our tax money.

2. Not learning from the lessons learned

The previous situation was one you, the project manager had no influence on. However some projects are finished with a lessons learned report. Some organisations do record their project history. Now you can make two mistakes:

• 1.You forget to ask if a documented history exists
• 2.You do not read it

I do not think this needs further clarification.

3. Adopting an approach is no guarantee for success.

Adopting an approach is only one of the first steps towards good project management, it is not the only step and not the last step.

3.1 When adopting becomes adapting.

I first encountered this phenomena during a very large government project. I was a junior project manager with the System Development Methodology (SDM) training fresh in my mind.
The organisation that employed me "adopted" SDM as the de facto standard. The problem was, they also adapted it.
Formally SDM rules and structures where followed. In practice the basics where totally undermined by creating an internal flavour of SDM. In the internal flavour it was possible that parts of the project where almost finished while the complete project had not been defined yet.

"We have finished the wheels, but we just found out that we are actually supposed to be building a boat."

Although I warned against this way of implementing SDM (This was also part of the SDM training), nobody really cared. It took several million guilders before the project was cancelled. It was concluded that maybe tweaking the method was not such a good idea.

This was not the last time I ran into an adapted flavour of a sound method.

The only advise I can give you if this sounds familiar to you is;

• talk about it
• point out the risks
• if the responsible people do not wish to listen, resign, do not let it drag you down

3.2 Lack of knowledge.

Apart from adapting a method, lack of knowledge is the second way adopting leads nowhere.
Just declaring an approach as a mandatory standard does not make it happen.
I have read nice ISO certifications where the adopted approach was clearly defined.
I have heard upper management preaching the validity of the chosen standards.
I have read local government mandatory standards demanding the use of a method.

The problems where:

• there was not a person in these organisations that had the knowledge to implement the method
• there was not a person in these organisations that had the knowledge to control the implementation of the method

This situation is solvable, staff can be trained, people with knowledge can be hired, it is your responsibility as a project manager to do so.

4. Commerce and politics vs. reality.

Commerce and politics are part of your daily encounters with conflict as a project manager.
Deadlines are more often than not dictated by commercial pressure and political pressure. Reality is hardly ever the decisive factor for a project end date.

You know that you, the responsible project manager, will have to face reality at a certain point in time. Accept that you have to face it and document it.
As much as you would like it, if the numbers don't match, they don't.

I can only advice you to summate what can be done within the available timespan. Prevent being dictated a date for failure. You do not help yourself and you do not help your project.
Remember that some projects are not feasible no mater what amount of budget is available.

Nine woman do not reduce the length of pregnancy to one month.

5. We are equal.

I love the sound of that. "We are equal" is supposed to stand for beneficial democracy in project management. "We are equal" sounds nice, but remember that you will drown alone.

I do believe you should cherish your team, listen to ideas and discuss the options but YOU decide.
A project needs leadership and decisive action to meet it's deadline. You manage it, you lead it and you decide. It is you that people will hold responsible. Live up to that responsibility and take charge of your project.

6. The 99,99% myth

Ask a software developer the progress he has made and he will answer you it is almost done.

Ask your contractors when the foundations of the building will be ready and they will answer you it is almost done.

Ask anybody about progress on any type of project and they will answer you somewhere between 90 and 99,99 percent done.

"Time to become very worried"

If a bungee rope is 0,01 percent to long you have a good chance to get hurt, just remember that.

You have to realize that you did not get an answer. There are a number of reasons why you did not get an answer.

• 1. The need to succeed
• 2. Fear
• 3. Underestimation
• 4. Incompetence
• 5. Poor description of the expected result

All of these points can be managed. I will explain the risk in more detail and give you my approach to preventing it.

6.1 The need to succeed

Most people feel the need to succeed. They experience a call for help as failure.

These people are in a catch22 situation.
They will not reach out for help because they perceive reaching out for help as failure.
They know that without help they won't finish the task in time.
The are very worried about their situation, they blur their vision with the hope that in some magical way all will end well.

To be continued..