Lessons Learned Do not make a mistake more then once!Raising_Hand

Here are some of the insights we have acquired over the last two decades.Remember though that Lessons Learned are only really learned if you act upon them!
… and only good news is bad news.
Projects thrive in an environment of trust. It is therefore critical that a Project Manager has clear expectations and has been entrusted with clear boundaries for authority and decision-making without having to ask permission from Executives every step of the way.
Under these conditions, a project can move along involving Executives at predetermined moments and gates such as the end of a project stage and beyond that knocking on the doors of the corner offices only if certain predetermined tolerances are passed and serious events may occur. This is called management by exception.
 
Considering this approach and reflecting further on the title of this article, if reports up to Executives from a Project Manager are always good this can also mean that problems may be going unreported or unnoticed. Think about, on any project there are very likely moments things go not as planned or simply go wrong. Therefor, Executives who only receive good news reports, should take this with more than a grain of salt - more like a very bad sign - statistically speaking.
On a project, enough is enough.
What this means is that you must provide any person only the level of detail of information that person needs at that time. Think of it, when you are packing your suitcase for a vacation, do you really need to know that the average temperature over the last 50 years for that month is 28.53987 degrees? No, you do not. All you need to know is that the average temperature is between 25 and 30 degrees, or between -10 and 0. It will make a big difference on what you pack, or not.
 
Providing too much (too detailed) information, particularly to executive levels of authority, is not only a waste of time and effort but also a big risk. The risk being that people get caught up in details, and that they completely miss what is really important.
 
We see this time and time again in project meetings; Project leads/manager/members being grilled about an apparent incongruity of details between reports. The issue at hand, that the project is over budget, gets ingored and the project member gets send back to write yet another report explaining the reason(s) for the difference.
 
In the same way that just-in-time management streamlines processes, just-enough-information management streamlines communication and decision-making. Don’t give people an excuse to talk about details that do not matter at that moment. Enough is enough already!
 
“Alice came to a fork in the road. 'Which road do I take?' she asked.
'Where do you want to go?' responded the Cheshire Cat.
'I don't know,' Alice answered.
'Then,' said the Cat, 'it doesn't matter.”
 
- Lewis Carol
Alice in Wonderland 
 
In other words, if on one hand you don't mind what a system does there is no need to know why it works the way it does. If on the other hand you do mind what a system does and you do mind that it works and that the people using it use it correctly then you better explain early on and often the 'why' behind the choices that are being made in the organization project.
 
We once worked for a client who did not explain to the end-users the selection of a certain system had more to do with dislike of the previous system and its system provider and less to do with like for the new. This turned out to be a costly mistake as the users really liked the old system and never really accepted the new system. After a few years the organization had to back track on its steps and go through a costly revision of the system.
 
If this organization would have explained the reason for switching had more to do with a falling apart between them and their provider they would have probably still have had to do a lot of convincing but in the end the system would have been accepted.

At the end of the day, two of the most fundamental components of any successful project must not be short-changed: people and time.

 

Better to have a project take longer and to involve more people rather than involve less people and rush.

 

With more people we do not mean more people working on the projectt but more people being involved with the project. In other words, stakeholders. The largest group being the end users, those who will be impacted by the project output most. The success of the project, in terms of acceptance and adoption, is greatly driven by the people who will, or will not, be using the end product the most.

 

Adding and/or increasing stakeholder involment throughout your project will very likely add to the cost as well as to the duration but it is more than worth your consideration.

{jcomments on}Plans are like food - they have a limited shelf life!

This may seem obvious but is often forgotten. Nobody can predict/estimate what will happen for a very long period of time. Review progress on a regular basis and adjust your plans accordingly.

This does not have to be a cumbersome or tedious process, nor does it have to be time consuming. The key requirement for this is to adopt so called management stages to your projects from the get go.

A management stage of a project is a sub division of  the project solely around management decisions.

It provides a control instrument for the project manager and the project board / steering committee to check progress of the project and to make informed decisions on how to proceed (continue, alter course, stop to name a few of the most common options).

management stages

Register to read more...

Subcategories