In every environment and every project there are ups and downs which are teaching you how to act and what to avoid. Retrospectives, lessons learned and post-mortem analysis may sound as buzzwords once you are still on the crest of a wave in your project. What will happen if you fail? In the midst of failure it is even harder to think about them but projects that are not going so well as they suppose to offer the gift of opportunity to re-validate and learn from mistakes.
Experience of failure
If you are still on your success path as a project manager and you have managed, possibly with superhuman effort, not to fail any project yet, you may think this is irrelevant. Maybe, you assume that when a failure happens you will just swallow it and make sure it will never happen again. Possibly it is not as simple as that but also not so complicated. Certainly, you need to use it in the best possible way. Think about the failures, these are usually the most painful but most memorable lessons learned that we have. What’s the most crucial in such situations is ability to do backwards analysis to assure that issues, which led to failure, will not be recurred and you with your future team do not repeat the same wrong patterns. You would possibly say now: “each situation is different, there are various organizational and environmental factors impacting certain projects – patterns are not repeatable”, which is a misleading way of thinking. Let me point out what is most precious in learning on mistakes in the projects and then ask you for reflection on it.
Take your lesson
Failure might not relate only to a full project which was unsuccessful, it may be a phase, a group of tasks or some part of the project. What is essential to reconsider? These are lessons learned – they cannot be neglected. Obviously you should not only reflect on them when something is going wrong, neither only at the end of the project. The clue is that lessons learned capturing should be iterative process during the duration of the project. You may incorporate some milestones for lessons learned in your project or make sure retrospective mechanism is embedded in project processes – these are the best practices. It’s recommended to keep track of what went wrong and what went well in a lessons learned log. It can be a tracker or a Confluence page with minutes of the meetings including action items – whatever works the best and let you capture as well as share what you experienced.
Start with “Why?”
Let me relate here to example of the project which delivered most of the scope but with the slippage of time and budget. 10% of the functionalities were not delivered at all – de-scoped during the project with the acceptance of the Client but still did not satisfied them. Slippage in timeline was 10 working days (in the scale of 4 months). This was obviously not a fully positive delivery of the project. In such situation, first of all identify what happened – most important is to start with “Why?” – as Simon Sinek says. Typically lessons learned are considered from 2 sides – do not focus only on negative elements of the project – think also about positive practices, processes, behaviors that let you and the team deliver mentioned 90% of the scope.
“Why?” for problems that appeared is vital to understand. Identify first what were the issues to get into identification of root causes as a next step. In mentioned example problems were: incomplete scope delivery, slippage in timeline, dissatisfaction of the customer.
Brainstorm, gather feedbacks, summarize
To make sure you do your homework after the failure, identification of the problem as well as root causes is significant (see Diagram 1). The best format is to prepare lessons learned session, brainstorm on what was good, what was bad and what shall be improved. Multi-levels analysis together with the team is possibly the most effective way of gathering comprehensive view. Other formats may be soliciting feedback through surveys or interviews and having a meeting to go back and reassess what was collected. There can be used as well focus meetings or dedicated lessons learned meetings that can give you opportunity to brainstorm and summarize the feedback. What might be a good practice is to try to capture feedback from team members anonymously. This grants people freedom to give true real response. In mentioned case of project, post-mortem analysis was conducted through survey summarizing holistically what was happening during the project. From experience perspective I would recommend to ask the Team and stakeholders about such areas as:
- Communication,
- Scope and objectives,
- Changes,
- Issue management,
- Roles and responsibilities,
- Cooperation,
- Processes,
- Improvements,
- Things that each person took for themselves form that project.
Questions might be formed in different way – try dissimilar types of questions – closed, opened with various approaches to the topic. Main aim is to collect as much information as possible, which can give you valuable picture of “do’s” and “don’ts” within your project.
Example of the questions you can see on Diagram 2.
Document, analyze
After the collection it’s time to verify, synthesize and document. Documentation might be a key to solid understanding of what was gathered. During that process we document “why?” problems appeared. Discenza, R. & Forman, J. B. in their article are mentioning that categorizing, classifying or grouping of the failure factors / root causes “helps to focus the assessment and recovery planning task around few broad categories, for which there are numerous assessment tools, recovery planning techniques, and a reasonable amount of assistive literature.”1 You can actually use different methods, one which I selected to present collected information, is one of most popular quality tools used in Lean Six Sigma “Analyze Phase” – Ishikawa diagram (Diagram 3), showing cause-effect relations between the factors. Failure factors gathered have been categorized and categories put on the main bones of the fish to which failure factors from each group point out. Next step is identification of major root causes and prioritization of them. I recommend to create a ranking during lessons learned meeting to understand the list of those factors that were most adverse.
Once having failure factors gathered and visualized you can easily consider within focus group how to do it better next time, not to allow failure factor to appear. This is how you get into the point, when most significant improvements/recommendations that would have mitigate the risk of failure are identified. This list of the recommendations should be the one that other teams and PMs will be mostly interested in. With that don’t forget to figure out what was outstanding, what went really well, which practices helped you to deliver 90% of scope, what team and you learned thanks to that. In my view especially the last one is most precious one.
Communicate and let others take from your lesson
Once you reviewed summary of lessons learned with the Team and main stakeholders this is not the last point that PM should cover. It is vital to make sure your peers, PMs can learn from the failures. Some companies are gathering such lessons learned centrally, others tend to have less structured processes for that. All in all you can help others and share it in any form which may be suitable for your organization. This can support others in retrieving useful lessons learned for projects. Lessons learned base can also help you in your future endeavours. Do not miss that step – it is creating value!
Reflect on failure factors
There exist multiple areas, where you can look for reasons of failures. They might be very specific to certain projects but may be very common as well. I would like to mention most crucial which were identified in the example of the project mentioned:
- Communication issues – with the client and inside of the team (remote work, lack of experience in big remote teams, customer aggressive style of communication lowering the morale of the team etc.)
- Delays in the decisions to kick off the project (client delaying the decision, shortening time of buffer for project delivery),
- Lack of trust from customer side, which was not changing over time no matter of showing expertise, progress and trying to build good relationship,
- Loss of knowledge – hand over from discovery phase to delivery phase form key persons in the project no matter of transitions executed,
- Lack of stakeholder investment – not all stakeholders involved themselves from very beginning – it may result in gaps in the expectations and understanding,
- Troubles with perspective and high level comprehension of scope complexity leading to underestimation and not pertinent leveling of work in planning phase as well as during sprints,
- Legacy systems included in development – black boxes which we agree to work on assessing only risk. Lack of detailed analysis during discovery or time to perform this assessment is an approach that will lead you to troubles,
- Next steps after closure of the main implementation phase not negotiated with the client on time – negotiating next steps is always vital to make sure it’s clear and transparent what is happening next,
- Lack of understanding of project management processes on customer side no matter of explanations, presentations e.g. project boundaries baselines, CRs and change management, risks, mitigations and their realization, time required for ramp up and communications.
I would even risk a conclusion that few points from the list may be indicators of not going with the certain project or killing it very fast not to fall into big troubles. If not then making very sure you can cover them with proper mitigation actions and act very carefully and attentively within mentioned areas. Nevertheless, not always this is project manager who can fully decide about project start, however, always this is the project manager who needs to identify risks, assumptions, lessons learned, mark them, communicate and assure this is heard and taken into consideration with the proper level of management in the organization.
Believe or not
If you still do not believe in power of lessons learned reflect on it during your project and do not wait for the failure, learn your lessons on the go, which in not so painful but still is a good learning experience. Check out lessons learned documented and available in your organization, especially if there are some similar projects. In case you fail, remember – “failure is often simply a necessary experience that ultimately paves the way to success.”2 as Garry Jackson aptly summed up in his article.
- https://www.pmi.org/learning/library/seven-causes-project-failure-initiate-recovery-7195
- http://learnthat.com/8-lessons-to-learn-from-a-failed-project/
Delivery Director in an IT company leading a business unit delivering different types of projects for the success of the Clients. Certified Project Manager who is considering Project Management as a science and an art. Project Manager working in complex cross functional and international environments realizing projects such as innovation and transformation, HR with focus on improvements, system implementations, transitions, integrations/ splits (M&A), go-to-market etc. After work – traveler who is looking for undiscovered and surprising places in Europe as well as all over the world. Amateur of macro photography, who likes listening to good music and interesting audiobooks. Usually, looking for perfection in the world around.