Deal with Causes, Not Symptoms
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"
A Fool with a Tool is Still a Fool
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:
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.
Lessons Are Not Learned At the End of a Project
Lessons Are Not Learned At the End of a Project
Lessons are not learned at the end of a project but throughout the project and even beyond. A lesson is truly learned when the same, or similar, mistake is not made the next time the same, or similar, situation arrises.
Lessons learned need to be acted upon and actively applied during, after and before each project.
The collection (verb AND noun!) of lessons learned is only the begining. There is ample evidence1 that active learning is only fully realized when organizations apply both passive (online repositories, surveys) and active (workshops, brainstorming sessions, mentoring & coaching) forms.
Initial lessons learned are the antecendent for further learning throughout the life cycle of your project and are critical to its success.
See also "Lessons are learned throughout the project" and "Project Management Office needs to allign with PM to faciliate learning"
1 Sofia Pemsel, Anna Wiewiora, Project management office a knowledge broker in project-based organisations, International Journal of Project Management, Volume 31, Issue 1, January 2013, Pages 31-42, ISSN 0263-7863
Demand Semantic Discipline in describing Risks
The word semantic comes from the Greek word sēmantikós which means "having meaning".
The word discipline comes from the Latin word disciplina meaning "instruction".
Risk Management is an important part of managing projects. Most of us are aware of that and will act accordingly.
The problem however is that when we ask team members and others to come up with a list of risks as part of the risk identification process early on in the project the risk descriptions are all over the place. Some are just impact statements, others are merely a list of mitigation actions and then there are always motherhood statements such "not enough resources"
We have used a very simple remedy for this by adding a few descriptive (active) sentences in our risk registers. 
By just adding these three sentences as highlighted above in the risk indentification section we were able to dramaticallly reduce the number of meaningless and incomplete risks.
Try it!
Credit where credit is due, we borrowed the term "Semantic Discipline" from a paper titled "Implementation of Opportunity & Risk Management in BAE SYSTEMS Astute Class Limited – A Case Study", presented at the Fourth European Project Management Conference, PMI Europe 2001, London UK, 6-7 June 2001 by Andrew Moore, Astute Risk Manager & Alec Fearon and Mark Alcock, Astute Risk Team.
Project Management Office needs to allign with PM to faciliate learning
Project Management Office needs to allign with PM to faciliate learning
Project Management offices come in a lot of forms and sizes. One of the functions a lot of these Project Management Offices pride themselves of providing is facilitating the so called lessons learned process. There is also definitely a desire and wish among project managers to learn. This section on lessons learned is testament to that.
Recent research1 published in the International Journal of Project Management however sheds an interesting light on this. Not all is well in the lessons learned world of PMO's. There seems to be a tendency for PMO's to focus primarily on the creation and management of explicit knowledge, especially related to technical and procedural knowledge. There was however limited attention for the management of tacit knowledge. In addition the extraction of knowledge/lessons learned is mainly done with the use of boundary objects such as forms, questionnaires and repositories. Boundary encounters, such as workshops, are rarely used!
Add to that a strong desire within project managers to actively share information and it becomes clear the PMO is less effective in supporting the lessons learned process than maybe expected/perceived. The takeaway for this is that the PMO needs to improve its knowledge sharing capabilities, improve its facilitation process and improve its relationship promotion.
See als:
1
Sofia Pemsel, Anna Wiewiora, Project management office a knowledge broker in project-based organisations, International Journal of Project Management, Volume 31, Issue 1, January 2013, Pages 31-42, ISSN 0263-7863