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!

Just Keep Your Eyes on the Prize

  • Print
Project Managers by nature like to take on new stuff. And this can be problematic. From the outset, you should have a clear picture of what needs to be achieved by your project and EVERYTHING you do needs to be focused on this end result. There are two benefits to keeping your eye (and your team member’s eyes) on the prize. The first is that people on your team are empowered to make decisions and work effectively even when the boss is not there. The second related benefit of always keeping your eye on the prize is that it increases your probability of success and achieving the desired end result.
An example to illustrate this point from Erik’s own experience involved an implementation project for a back-office system for an education institution with multiple locations. The prize at the end of this project were the organization-wide benefits. However, the school director at one of the locations was more concerned with being the first site to implement the system rather than working towards the company-wide benefits that were the true prize. This caused a problem as resources were diverted towards that individual site rather than being better utilized elsewhere and in a more evenly distributed fashion. The result was a tug-of-war to focus the resources and the client back on the true prize of the project, the company-wide benefits.
The issue was addressed and resolved during a Project Board meeting by the Project Manager with the backing of the chair.

Make Clear From the Start What a New System CANNOT Do

  • Print
Topics: System implementation | Lesson learned | Expectations management
When implementing a new system in a project it is as important to clarify for end users what the system CANNOT do as much as what it can do.
 
A few years back, Erik was involved in a project to implement an upgraded back-office and conference management system for a hotel. The legacy system that needed to be upgraded had been in place for several years and was used on a daily basis by staff (end users). The new system that was selected on the project not only had new functionality but also left behind a few things with the old system.
 
In other words, in the old system if you could do a certain amount of things, x of these were taken care of by the new system but the other n functions were no longer available in the new system. The new system also had m new things it could do as per the image below.

2012-11-03 11-42-01

The lesson learned here was that even though the five functions that were left behind were redundant and were actually a waste of time, it was not explained to the end users that this was going to happen. This ended up causing staff anxiety and angst and disrupted intial training sessions which cost both time and money as the project team was forced to go back to the drawing board with the approach to training.

 

This situation is a great example of how losing something can be a more powerful emotion than gaining something, how end users are affected most by project outcomes, and of course that people need to be made aware from the start what a new system CANNOT (or can no longer) do.

 

Manage expectations effectively!

Create Structures for Collaborative Problem-Solving

  • Print
Topics: Lesson learned | Problem solving | Team work

Effectively leveraging the creative and critical thinking capacity of your team requires structures. This is especially true for teams which are located in multiple locations and/or have a mixed cultural composition.

 

Deal with Causes, Not Symptoms

  • Print
Topics: Problem solving | Root cause
The health of any entity, whether it be a human body or a project, is both created and sustained through careful attention to root causes.  
 
When dealing with a fire, of course you first reaction will and should be to extinguish it. Once the fire, or critical situation in your project/work, has been dealt with try not to get back to business as usual but spend some time understanding what caused the fire/situation. In doing so you may very well be able to identify the reason(s) that caused the situation. 
 
In complex environments/systems this may not be easy at first. Do not play the blame-game.
 
In a project Erik worked on many years ago, he was confronted with a stuborn project manager who, after having attended a mandatory Prince2 course, was mindlessly filling in the templates. As a result the work this PM produced was sub-par. Initially the reaction of the executive was to reprimand the PM. Erik's initial reaction was also more geared towards the quality of the work then the reason for the stuborness. Afterall, the PM had over 25 years experience and it seemed out of character. Only when Erik started proding a bit more for the reasons behind the PM's behaviour did it become evident that the PM in question was never consulted about the contents of the templates. Remember that this PM had over 25 years of experience.
 
The root cause seemed to be not a lack of understanding but more a lack of buy-in. Once that was established Erik suggested a review of all the templates and subsequent modifications.  This completely got rid of the problems. Problems, because during the review it became clear that the PM in question was not the only who had not been consulted.
 
See also "TEMPLATE LESSON LEARNED"
  • Print
Topics: Tools | Lesson learned

Worse, a fool with a tool is a dangerous fool.

Use tools in moderation and only in the appropriate setting. If one does not know why and how something needs to be done the use of a tool is just masking the problem. Actually it is exacerbating the situation.

Tools, such as document templates, computer software, mobile apps to name a few, can cause harm in a variety of ways.

First of all using the wrong tool for a given circumstance can lead to both a waste of time and the wrong results. Using the right tool but without proper knowledge of how to use the tool or the actual purpose of the tool may also lead to a lot of wasted time and the wrong results.

For example there is now ample evidence of how errors in spreadsheets such as in MS-Excel have caused major problems. There is even a special interested group, The European Spreadsheet Risks Interest Group - EuSpRIG -

We have seen quite a few instances where the wrong or inappropriate tool was used and even more situations where the right tool was used in an incompetent way. Massive schedules in MS-Project where a simple task list in a document or simple spreadsheet would have sufficed. Project document templates being filled in without making any adjustments to the contents and layout and by doing so adding complexity that was not needed for that specific project. MS-Project schedules with mistakes such as wrong project start date, mishmash of resources, needless task constraints to name a few.

Therefore two most important questions to ask your self when reaching for a certain tool are:

  1. Is this the right tool given the situation or process I am dealing with?
  2. Am I competent enough to use the tool in an effective and efficient way?
Asnwering these questions honestly, and seeking help if needed - there is nothing wrong with admitting you do not know something - will prevent you from being a fool.
 

More Articles...

  1. Lessons Are Not Learned At the End of a Project
  2. Demand Semantic Discipline in describing Risks
  3. Project Management Office needs to allign with PM to faciliate learning
  4. The Project Plan is Your New Best Friend

Subcategories