Projects don't exist in a vacuum. On the contrary, projects are part of an organizational continuum. Therefor the purpose of a project is not the project itself nor is the the sole creation/production of the project deliverables.

What ever gets created/delivered by the project has a purpose in that continuum. When starting up and initiating a project don't focus on the output alone, ask yourself:

"why do we/they need that project (output)?"

Below is a diagram that shows the relation between the project output, what you as a PM are expected to deliver and the project benefits, what your project sponsor wants to achieve with it.

If you make it a habit to draw this simple diagram at the start of each project and discuss it with your sponsor, project board/steering committee and your team then it will be much easier to avoid scope creep and keep your team focused.

It will also be valuable after the project in assessing the success of the project.

Email can be a great thing. It can also be a source of a lot of friction, tension and time waste. In a recent discussion on one of the LinkedIn groups the following question was posted:

How do you respond to a senior project member who wrongly accuses you and have your bosses and team copied on email?

 

Within a few days more than 10 reactions had been posted and all of them had some really good things to say. Here we'll share with you some of those insights and suggestions.

First of all ask yourself what the reason could be:

1) That person does not have the right information and is mistaken
2) That person has the right information and is misleading.

Case 1) Facts. Provide the real facts. Try not to fall in the email trap. Go to that person and show the facts and ask him/her to retract the errand email

Case 2) A bit more difficult. Ask your self why that person might want to do that. Again, facts will be the key. If you can talk to that person (try to have a witness) and explain what is not correct in the message. Again ask to have the email retracted. Don't get sucked into an email exchange. Talk with your bosses and explain the situation and show them the facts. Same for your team. You have to nib this in the bud.

A few other quotes:

We've all seen the job adds that ask for experienced Project Managers (or any other function). The thinking behind this is clearly that an experienced project manager can hit the ground running and be of value to the organization immediately.

In a very interesting and sort of disturbing article in the Harvard Business Review the authors discuss a so-called Experience Trap.

They found, through various software development project simulations in which both experienced and junior project managers participated, that although the experienced managers had encountered similar situations on their jobs in the past, they still struggled with them in the simulations. As a result the authors came to the conclusion that they had not really learned from their real-life project work, either.

In the context of the project simulation three possible reasons are given for why the learning breaks down:

• Time lags between causes and effects.
• Fallible estimates
• Initial goal bias

In all three cases the separate simulations they ran clearly show that experinced managers do not learn from past mistakes or past experience.

As a result the authors conclude that that managers find it difficult to move beyond the mental models that they have developed from their experiences in relatively simple environments or that have been passed on to them by others. When complications are introduced, they either ignore them or try to apply simple rules of thumb that work only in noncomplex situations.

This has significant implications for the organizations these experienced managers work for they argue:

• Impressive backgrounds have little bearing on project results
• Since it does not matter whom you put in charge managers will ascribe responsibility for failures to other factors and not their own decisions.

 

Fixing the learning - doing gap

The authors provide the following 5 approaches to fix the learning doing cycle:

• Provide more cognitive feedback
• Apply model-based decision tools and guidelines
• Calibrate your forecasting tools to the project
• Set goals for behavior, not targets for performance
• Develop project “flight simulators

 

All in all a very good and sobering article. My experience is not worth anything if I don't fix my own learning - doing cylcle.