It is speculated that Einstein once said, “The definition of insanity is doing the same thing over and over and expecting different results.” I can relate. Especially when it comes to managing a project.

For a project management professional, there is nothing better than completing a quality project on time and within budget. How often does that happen for you? In your experience, do you find yourself repeating the same mistakes over and over on the projects you manage? Can you honestly say that you build time into your project plan to take a step back and reflect after you have delivered? Probably not.

I humbly admit that I have repeated a mistake or two in an attempt to salvage budget or keep tasks moving along, but I have learned that the first step to conquering the “project management” type of insanity is admitting you have a problem. The next step is seeking guidance and tools to fix the problem. In this case, the problem I am referring to is a lack of proper Project Closure.

The reality is that far too many projects come to an end without proper closeout activities – most notably, Lessons Learned, which the Project Management Body of Knowledge (PMBOK) defines as the learning gained from the process of performing the project. The project ends, a celebration is planned, resources are released, the budget is closed, and it’s on to the next project.

A key component in Kenway’s approach to the Project Lifecycle is to include a formal Project Closure phase, which includes conducting a Lessons Learned activity prior to transitioning the solution or work product to the supporting team.

As part of a continuous improvement process, how you choose to solicit Lessons Learned can be as formal as distributing a survey to all key stakeholders and project resources, or as simple as a post-mortem discussion with team members. Documenting Lessons Learned helps the project team discover the root causes of problems that occurred, and helps them avoid those problems on future projects. It is important to recognize not only project shortcomings and opportunities for improvement, but also project successes and factors that support those successes.

Questions to Consider When Gathering Lessons Learned and Soliciting Feedback

For larger projects, these questions can be posed for each project phase:

• Did the project successfully meet the original goals and objectives? If not, what changes need to be made to meet goals in the future?
• What worked well and why?
• What did not work well and why?
• What could have gone better or what needs to be done differently?
• What challenges did the team encounter and what actions were taken to resolve those challenges?

In addition to open-ended questions, you can also survey team members using a standard rating scale. Some examples of areas to probe include:

• Overall Project Rating: On a scale of one to five, how would you rate the success of the project?
• Scope: Was the scope clear to all team members from the start of the project?
• Budget: Was the budget managed effectively throughout the project?
• Schedule: Were key project milestones clearly articulated?
• Resources: Were sufficient resources available throughout the project? Did the skills of the project team members match the project requirements?
• Teaming: Was the team structure effective?
• Roles and Responsibilities: Were roles and responsibilities clearly communicated?
• Issue and Risk Management: Was the management and escalation of risks and issues effective?
• Communication: Were project-related communications structured, timely, and effective?
• Deliverables: Was the quality of deliverables produced acceptable?
• Testing: Did testing activities effectively validate business requirements?
• Implementation: Was handover to the stakeholder efficient?

At one of Kenway’s financial services clients, we had the opportunity to prove the value of a sound project closure methodology by facilitating a Lessons Learned session at the completion of a point release for an online banking portal program. At the conclusion of Release 1.1, the Lessons Learned session unearthed the fact that User Acceptance Testing (UAT) ran over schedule not only due to the volume of defects logged by business users, but also due to the fact that after researching the defects, many of them were not actually defects, nor were they critical enough to warrant developer research in the first place. Instead, many of the items could have been added to the docket for future enhancements. By not having adequate UAT oversight, the churn around the root cause analysis process was too unorganized leading developers to lose focus on the truly critical defects. This key insight was enough to justify dedicated UAT management in Release 1.2, which increased the defect closure rate allowing UAT to pass according to the planned schedule. Without executing a Lessons Learned session, this same mistake would have been repeated in subsequent releases

So, if you would like to set your future projects up for success, be sure that you include a Lesson Learned task within the Project Closure phase of your standard work breakdown structure. It’s time well spent.

And if you’d like to learn more about Kenway’s approach to Project Lifestyle and the Project Closure phase, reach out to us at [email protected].