It is my belief from my years of project management that performing a lessons learned activity is one of the most critical processes for future project success and yet also one of the most overlooked and underutilized. We tend to get to the end of a project and breathe a sigh of relief and move on. Rather, we should hold one or more formal sessions with our team and our customer to identify what worked and what didn’t.
The customer always has a lot to say about any implementation and their opinion and input matters greatly. It’s best for you to hear it in a formal lessons learned process rather than have your customer follow-up with your CEO and give him an earful.
I’ve published some of my thoughts on Lessons Learned previously including an article from February 2009 titled simply “Lessons Learned.” Here, I present some further thoughts on lessons during the project implementation process from Jason Charvat’s book “Project Management Nation.”
Lesson Learned During Project Implementation
“What could be simpler than buying some computers, throwing them on a desktop, plugging them in and turning them on?”
The question is simple: The answer is much more complex. Complexity is almost always underestimated until well after the start of the planning process. Many of the elements of deployment require special coordination and handling due to the lack of direct control over the processes or compounding dependencies. Complexity can come from the technical nature of a project that attempts to take advantage of a new technology not yet tested by the corporation and requires full integration into the existing systems. These factors don’t surface until the project manager demands action or some form of change. Implementing a solution without testing it properly is not acceptable.
I Wish I Had Known That
Look for early warning signs that planned business benefits will not be delivered.
-
- It is not clear that achieving the business benefits is the top priority of those managing the project.
-
- Time scales and resources for training, testing, and implementation support have been eroded by project slippage, and there are proposals to cut corners.
-
- Acceptance testing is being carried out by IS specialists and there is no involvement from the business.
-
- Other parties, who were not previously identified as part of the project, are now being identified as needing to be involved in acceptance testing and implementation.
-
- Staff involved in developing and agreeing to the original business objectives have moved on.
-
- The supplier has not demonstrated that the new system is compatible with existing systems and peripherals.
-
- The solution needs to be tested and demonstrated within the proposed environment (including links to existing systems). Have the tests for accepting the system from the supplier been planned and agreed upon? Has the process for data conversion been planned and has sufficient time been allowed for it?
-
- All necessary on-site preparations were not included in the planning (e.g., accommodation, cabling, safety, and security).
-
- All dependencies, such as slippage on other related projects, have not been taken into account.
-
- Too little attention is paid to testing the final solution.
-