A project metaphor – The Minefield – Part 1

There are many different ways to describe a project and the project manager’s role. Very few of these descriptions, however, takes into account the project’s retrieval of knowledge. These next couple of blog posts will show the project metaphor The Minefield that is based on the concept of minimum amount of transferred knowledge and the metaphor aims to provide a new perspective on the fruits of a project and the approach on harvesting these.

A project is a minefield over which the project manager is inexorably pressed by time. As if it weren’t enough to force the manager to find their way on their own, he must also keep track of all project members. Neither he nor any of the others in the project may take a misstep because it would then crosscut/prime the mine and, in the worst case, set it off.

No minefield is quite like another. Maybe it shares some of the terrain as the last one travelled but it may still differ in size, amount of mines, the direction of passage, and the team members along on the journey. Even the time pressure on the project manager’s back varies from case to case.

We’ll wait a bit with the most important parameter of the minefield…

The projects path over the minefield

This illustration above shows the, in places, very narrow path along which the manager need to steer the project. Sometimes there are margins of error, but sometimes it’s almost impossible to get around without stepping on a mine that delays the project. A triggered mine usually doesn’t mean that the whole project is wrecked, but when it happens the project manager must take hold of the project and ensure that the project member that triggered the mine is okay and can continue. If not, it’s the project manager’s task is to replace the project member so that the project can proceed towards its goal.

Once at the goal, it is important that the manager looks back at the minefield that has just been passed and tries to remember as much as possible about the journey. Which mines did the project manager and the other project members set off and which of the mines could have been avoided through better planning?

Minimum amount of transferred knowledge

Now it is important that the acquiring of knowledge starts in earnest. The project ran into a lot of mines, and these must be flagged and documented properly so that no other projects sets off the same mines in the future. Sure it is important having the goals of the project described and marked on the map, but for the next project manager, it is more useful to know where not to go than in the distance seeing monuments of past projects having reached their goals.

A minimum amount of transferred knowledge that the project must leave behind is to describe where detonated mines were found in the recently passed terrain. It also includes in which areas the project team identified potential mines that the project managed to avoid. In addition to thoroughly describe uphill terrain and where the time consuming mines are, it is also important that the project manager reviews all minefield parameters: size, number of mines, direction, project members and time pressure.

Identified mines.

Questions regarding these parameters could be:

  • Did the scope and size of the minefield cause any trouble in regard of the success of the project?
  • How many mines were there approximately and how densely were they placed over the minefield?
  • Did the project specifications mean that the project was conducted in a direction over the minefield terrain that was not advantageous?
  • How did the project members and/or team composition affect the crossing of the minefield?
  • Did the pressure of time make the project unable to dodge mines actually discovered in good time?

The answers to all of the questions above form the final minefield parameter: Experience from previous voyages across the minefield. The reason that this parameter is not always available is that it is not included in the project specifications in the same manner as time pressure, size and direction. It would have been quite possible to include this factor in the project specification, e.g. “The project must transfer a minimum amount of knowledge of the terrain, many mines, size,” etc.

Now, why is this never done? (To be continued…)

One thought on “A project metaphor – The Minefield – Part 1

Comments are closed.