Much has been written about collecting lessons learned in projects. On the one hand, project management standards provide guidelines and examples of such activities. On the other hand, even the Agile world has focused on collecting and implementing improvements (for example in the form of retrospectives in Scrum) from the very beginning of its “existence”. And while the Scrum teams often use the retrospective, on large projects it is a bit like a “square peg in a round hole” and is primarily done at the very end of the project (only because it is required by the project closure documentation).
Therefore, today I would like to propose a more interactive method of cooperation with readers. Namely, I am going to present you a case study from one of the projects and provide you with an opportunity to analyze and propose an approach to collecting lessons learned in this situation. I encourage you to prepare a short recommendation on how to apply the lessons learned in the project, and the most interesting solutions along with my “solution” will be published in the next issue of Strefa PMI. Please, send your recommendations to: mbodych@whitecom.com.pl.
Case Study
The business process optimization project has been going on for 1.5 years. Its goal is to increase revenues by acquiring new clients and increasing the margin on the company’s existing clients. The goals are to be achieved as a result of the improvement of business processes related to customer service and the implementation of a new IT system. The project is intended to impact over 1,000 users handling the company’s clients, and over 50 people are directly involved in its execution.
So far, there have been many changes in the project (submitted both to the Project Sponsor and to the company’s management board). They result from both technical issues and changes in business requirements. The project was divided into 7 areas:
- New customer service model (process optimization)
- Establishing a single point of contact with the company for customers
- Implementation of the customer request handling module (M1)
- Implementation of a new financial module for settlements with customers (M2)
- Implementation of the customer data management module (M3)
- Implementation of the customer request reporting module (M4)
- Integration with other systems
Each area is taken care of by a separate business line in the company, and in addition, the team for the new customer service model participates in the works of areas 2, 3, 5, and 6. Each area has its dedicated Area Coordinator, Director; and a business team. Some Directors also participate in the project steering committee, which also includes heads of individual Divisions.
Project works in areas 3–7 are conducted by three IT suppliers. Modules M1 and M4 are handled by an internal IT team that carries out work within one Scrum team. All requirements are recorded in a single repository of tasks (backlog) and every week a decision is made to implement new functionalities. Priorities are defined by the project manager on the IT side based on conversations with two separate business lines. Module M2 is delivered by the supplier that carries out work based on the fixed price arrangements and has a complete schedule for the entire implementation. Many project aspects are managed by this supplier based on its internal PMI-based methodology. However, so far no lessons learned were collected by this supplier. Finally, the supplier of the M3 module conducts the work on the basis of 2-week sprints and keeps a close eye on the work backlog. It happens that as part of improvements, product demo workshops and lessons learned workshops (retrospectives) are combined into a single meeting. In practice, insufficient time limits longer discussion about potential improvements (and if there are such discussions, they are not documented anywhere).
The customer service system will interface with seven other systems. The two most critical of them are the financial system and the production planning system. The first one is currently also in the implementation and there are many cross-related issues between these two projects. They are being resolved on an ongoing basis. The second system is used in its production environment. Its requirements have been clearly defined and so far there have been no issues in cooperation with the production planning system maintenance team.
The works on defining the customer service model were completed 6 months ago. Currently, the efforts are put to close the development work in areas 2–7. The next steps in the project are:
- Conducting acceptance tests of individual modules—by January 29, 2021
- Conducting acceptance tests of the entire solution—by February 26, 2021
- Preparation of materials and conducting training courses—by March 19, 2021
- Migration and implementation of the solution in production environment—by April 9, 2021
Knowing that so far there has been no implemented approach to managing lessons learned from project, decide:
- How to organize the lessons learned process on the project?
- When should such a process take place and who should be involved?
Final Note
For those who cannot wait until the next issue to learn from the case study wrap-up, I have prepared some of my lessons learned to be applied in projects. I hope this wisdom in a nutshell helps you rethink your approach to this topic. Things that you may pay attention to include:
- Lessons learned are only a step towards actual improvements. We do not collect lessons learned only to fill the register, but to implement them in a project or organization.
- The lessons learned must be “bought-in” by the project team. The process is not about the manager or the board making their comments just based on their observations and without any discussion for application and expecting they will be implemented in projects. Rather than that, it should be an outcome of the team understanding their mistakes and identifying things that can be improved or corrected.
- We should also consider good practices (and not only about the mistakes we made).
- As part of the workshop, we are not aiming at investigating who made the mistake. Instead, we want to identify the non-performing components of project organization, missing capabilities of the project team, and defective tools or processes.
- The lessons learned should be used throughout the project life cycle.
I am waiting for your solutions until December 31, 2020 and I encourage you to accept this challenge. See if you can find all the elements of the solution that I have designed.
Ekspert w zakresie zarządzania projektami, portfelem projektów i PMO. Specjalizuje się w obszarze usprawnień organizacji poprzez wdrożenie zarządzania portfelem projektów i PMO oraz w obszarze rozwoju kierowników projektów. Od 2003 roku związany z PMI®, gdzie pełnił m.in. funkcję Prezesa Oddziału Polskiego. Z centralą PMI® w USA związany od 2010 roku – obecnie pracuje w Komitecie do Spraw Certyfikacji (CIT). Od 2010 roku prezes firmy WHITECOM Project Experience specjalizującej się w szkoleniach, ustawianiu PMO oraz zarządzaniu projektami i portfelem projektów. Współautor książki PMO. Praktyka zarządzania projektami i portfelem projektów w organizacji.