Much has been written regarding how to conduct post-project assessments with the goal of gathering best practices and lessons learned. In future blogs I will add my own ideas and experiences regarding this critical process as well. But before we get there, I don’t think near enough has been written (or has stuck with us) regarding how to make sure an organization doesn’t learn the same lesson multiple times. Unfortunately I have seen this happen on too many occasions in the past, so here are some of my tips to prevent an organization from getting fooled twice.
Many of the writing on this topic that I have reviewed discuss how to disseminate best practices and lessons learned (BP/LL) to project managers within the organization. These processes typically include making all of the BP/LLs available to the project managers who will then, supposedly, review these during planning and execution. To more efficiently disseminate these nuggets you could build a database to house them along with capturing characteristics of the BP/LLs in order to facilitate searches. For example you could characterize each BP/LL by a project management phase, project type, or a host of other characteristics. I have used this method in the past but the result was a low level of adoption by the project managers within the organization.
Other dissemination strategies include reviewing the BP/LLs from a project in a meeting with all the project managers within the organization. The results of this process can be somewhat effective if some of the project managers can apply the lessons immediately on their projects. The limitation of this process is that, even if retained by the individual project managers, these nuggets will ultimately drift away from the organization as staff turn-over occurs.
Given these less than successful approaches, here is another method to consider. The key is that the organization, not individual project managers, needs to retain this information. This shift in thinking means that the Project Management Office (PMO), or whatever unit oversees the project managers, must be responsible for insuring BP/LLs are not only retained but applied to the next project. To accomplish this, the PMO needs to make the BP/LLs actionable, install them in their PM processes, and oversee their usage on current and future projects.
The critical concept of applying BP/LLs is actually simple – project managers manage from task lists not from repositories of information. The key is to create an actionable task that can be included in future project plans. But of course these actionable tasks will not apply to every project. To determine if an item should be applied to a project; either (1) the project manager could make their own determination or (2) the PMO can identify the condition under which the actionable items should be included. Obviously option 2 will help promote consistency across projects.
Unfortunately the identification of a condition and actionable task may not be enough. This valuable information needs to be documented where a project manager can find the information. From past experiences I can confirm that simply documenting the information in a Project Closeout Report is not enough. This is where the PMO needs to install what is learned into their PM processes, which may include checklists, templates or procedures. Let’s look at a simple example first.
Best Practice: A key component in proactively managing project issues is the creation of an issues log. (Okay, I know that we should assume every project manager is already doing this, but you’d be surprised…)
Condition: All projects
Actionable Task: Create an Issues Log
PM Process Change: In the first phase of their PM Methodology, the PMO should document the need for the project manager to create an issue log. Alternatively, if the PMO has a standard project framework (such as a MS-Project template), then a task to ‘Create an Issues Log’ should be added.
Here is another example.
Lesson Learned: A project Steering Committee is a useful forum for allowing various stakeholder units to collaborate on project design, review status and deliverables and resolve issues.
Condition: To be applied to projects which will impact business areas that are not within the Project Sponsor’s organization.
Actionable Task: Form a Steering Committee
PM Process Change: The initial phase of the PM Methodology should say “If the Project Sponsor does not have authority over all the impacted business units a Project Steering Committee is to be established.” This type of procedure could also be included in a phase checklist. What, you don’t have one? Well start one!
As we see, adding a PM process change puts the BP/LLs right in front of the project managers so they do not need to dig through past Closeout Reports.
The final step is for the PMO to verify that the PM processes are being followed. This can be done by employing simple checklists or formal project review.
I understand that some of you may be working in an organization that does not have a formal PMO to develop and maintain PM procedures for the organization. My response to this would be to start creating these procedures that you can share with the other project managers! Share your knowledge – be a Linchpin. The procedures do not have to be elaborate or look pretty – they just need to present information to project managers that is easy to find and easy to digest.
Many smart people (such as Franklin and Einstein) have been quoted to say that insanity is doing the same thing over and over again and expecting a different result. If you apply these simple concepts, your organization can avoid learning the same lessons over and over again.
No comments:
Post a Comment