Before you say 'I do' as a project manager to a new project assignment it is best to ask a simple but very important question.

WHY?

You need to ask the project sponsor what the business justification of the project is. Does it make sense? You really need to consider saying 'NO' if the project sponsor can not make clear what the business justification is. If the why does not make sense the likely hood of achieving success is greatly reduced. The reason being that a lot, if not most, of the people you'll have to work with during the project will know/sense that and as result will will be less motivated to work on the project. Who wants to be associated with silly projects?

In the wake of the big WHY question follows a set of equally important question:

Register to read more...

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 deliverable(s).

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 project manager 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.

See also:

• Business Case Checklist;
• Project Business Case Template;
• Benefits Review Plan Checklist;
• Strategic Decision Checklist;
• The most important question(s) to ask before starting a project;
• Initiating a Project Checklist;
• TheBrain Context Diagram Example

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 non complex 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 behaviour, 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 cycle.

Below is a comment Erik hamburger of Ambidexter Management Inc. made on a discussion board on Linkedin. See here for the original posting.

I did read Bill's rant and will address that later but I'd first like to address the statement Colin made about Prince2 (P2).

Planning is not a phase in Prince2. It was not so in the 2005 edition and neither is it in the 2009-refreshed edition. In Prince2 phases (called stages) are what they are supposed to be, a management instrument! Prince2 also clearly makes a distinction between management stages and so called technical stages. Technical stages can be used to group work by the set of techniques it uses, e.g. design, build and implement. Technical stages can overlap, management do not. Each Prince2 project always has at least two stages: The initiation stage is mandatory, and there should also be at least one more stage to cover the rest of the project.

Prince2 has a process based approach, The Prince2 process model contains the following processes: Starting-up a Project; Directing a Project; Initiating a Project; Managing Stage Boundary; Controlling a stage; Managing Product Delivery and Closing a Project. Planning is done throughout the process model. Note that these are processes and not phases! "Plans" is one of the seven principles that are also part of Prince2

Register to read more...