Post-mortem to Lessons Learned

A project post-mortem also known as a post-project review is an opportunity for a project team to take stock at the end of a project and develop a list of lessons learned so that they don’t repeat their mistakes in the next project according to Michael Greer in the Project Management Minimalist. (p. 42, 2010). Those of who are or were in the military might be familiar to a similar tool to the project post-mortem known as an after action review (AAR). The purpose of the AAR is to also identify mistakes and develop lessons learned to improve future activities, but of course the subject being review is normally a tactical military mission, not a project. (Combined Arms Center, U.S. Army).

It was not too difficult to select a project from my past to use as vehicle to discuss project post-mortems. Ten or so years ago I was thrust into the position of a becoming an ad hoc or what the Project Management Institute (2010) calls an  “accidental project manager” for an instructional delivery to one of the branches of the military. Some of the details of the project are not be disclosed, but I can say that it involved providing entry level training for an automated information system and our firm was contracted to provide 40-hours of training to meet the client’s learning objectives. The original, and trained, project manager (PM) left the project but had completed most of the planning requirements so I was told during my transition in briefing. The other thing told to me was not to worry and just follow my predecessor’s plan. You probably already know where this tale is going.

After the in brief, one of the first things I did was to review the Statement of Work (SOW) and compare that with the existing project planning documents. Some aspects of the plan were very complete and detailed. For example, the work breakdown structure (WBS) showing the interim deliverables was quite intricate segmenting the 40-hour project down to a fine level of granularity. It also had a comprehensive task and requirement list; however, the original PM did not such a great job in estimating the resources needed for the project in particular the time required to complete the project with the existing team members.

Thus, the submitted and stakeholder approved project schedule was grossly optimistic. At the project close the final delivery was late by seven-months, which cost the firm and damaged its reputation with the client. In retrospect, I should have requested a change in the project scope early on in the development phase when I could see that we were going to miss our initial delivery. Greer describes a method for handling scope changes such as needing to add more time to the schedule. This includes making “adjustments to the project plan to deal with additions, reductions, or modification to the deliverables or work process; formal documentation of each scope change, and formal approval of each scope change.” (p. 45, 2010).

If I had made the attempt to manage the scope change through a formal process early on, we would have probably ended up in a better plan financially and in terms of our firm’s reputation. My principal “lesson learned” from being an accidental project manager is one summed up in the old saying, “bad news doesn’t get better with age” and that sometimes decisive, yet measured actions are required to keep a bad project situation from becoming a catastrophe.

In Grimes (2010) Project “Post-mortem” review questions, several of those dealing with Creating a Project Plan reminded me of this experience. These include:

  1. How accurate were our original estimates of the size and effort of our project? What did we over or under estimate? (Consider deliverables, work effort, materials required, etc.)
  2. How could we have improved our estimate of size and effort so that it was more accurate?
  3. Did we have the right people assigned to all project roles? (Consider subject matter expertise, technical contributions, management, review and approval, and other key roles) If no, how can we make sure that we get the right people next time?
  4. Describe any early warning signs of problems that occurred later in the project? How should we have reacted to these signs? How can we be sure to notice these early warning signs next time? (p. 44, 2010).

Having an awareness of what underlies these four questions, especially the last one would have benefitted both me and my firm. The bottom line is when the plan has fundamental flaws, then act quickly to obtain key stakeholder buy-in to effect a change that gets the project back on schedule, under budget and within scope of the obligated delivery requirements.

References:

Greer, M. (2010). Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Combined Arms Center, U.S. Army (n.d.). Establishing a lessons learned program. Retrieved from: https://rdl.train.army.mil/catalog-ws/view/100.ATSC/2F5E29AA-DABF-4BE4-9F6F-2C804BE46EE7-1274436620178/25-10/CH5.htm

Project Management Institute (2010). The accidental project manager. Retrieved from: http://www.pmi.org/en/Professional-Development/Career-Central/The-Accidental-Project-Manager.aspx