Archive for February, 2014

Learning from a Project “ Post-mortem”

February 25, 2014 1 comment

First, I agree with the notion a project “post-mortem” analysis should ideally allow project team members to review the success and failures of a project in a way that improves future methods and practices, rather than point fingers. This sort of analysis is valuable because it can refine practices. (Collier, DeMarco, & Fearey, 1996)

Many organizations are averse to discussing and documenting their failures and areas of improvement. Hence experts recommend team members agree to a defined “post-mortem” process before the project starts. This defined process helps participants interact with and/or develop documented, well-understood procedures, establish communications that expose findings without compromising team members, assure teammates the process is blame free, and connect the “post-mortem” experience to returns on investment of future projects. Finally, “post-mortems” can be therapeutic or cathartic by allowing team members to vent. (Collier et al., 1996)

I’ve never been part of a formal “post-mortem” but I have been in recent meetings where we discussed a project’s shortcomings or challenges. These meetings were face-to-face and did not include a survey element to elicit sensitive comments or feedback from less-vocal team members. (Greer, 2010)

Again, this meeting was not formal but every phase-specific post-mortem review category was addressed. These phases included:

  • Determine Need and Feasibility
  • Create Project Plan
  • Create Specifications for Deliverables
  • Create Deliverables
  • Test and Implement Deliverables (Greer, 2010)

My most recent meeting was about a project deemed unsuccessful because it was not delivered on time. Unfortunately, we realized part of its failure was linked to pressure to adhere to standards not outlined in the original statement of work.

We’d contracted with a vendor to build an eight-module course related to leadership competencies. Not only was the January 16 deadline missed – we are still waiting on the deliverable.

We had conference call to review the status and a few interesting aspects surfaced from both client and vendor regarding project artifacts and activities that might have made the project more successful. Unfortunately, there were several constraints.

First, we experienced delays with the approval of the statement of work (SOW). This delayed our start date.

Second, our project plan or blueprint was broad and we never had a kickoff meeting of all key team members.

Third, we (the client) and the vendor, both succumbed to the pitfall of backing in to the schedule. We were both given a due date from our operational manager/project champion and were expected to identify activities and estimate their durations. We focused more on the time constraint than the required work. (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008)

Fourth, we never did any “Phase 1” research or polling as recommended by Greer (2010) to determine how our constituents would benefit from the course.

As we progressed, we received early-warning signs our product would not be delivered on time when our vendor did not send an e-mail or call on an expected “milestone” date. Additionally, the vendor e-mailed a link to the course draft to our operational manager. Our operational manager was on the road and tied to use their iPad to view the course was not able to. While we’d discussed creating an adaptive tablet version, this was scheduled for “phase 2.” Our operational manager, after that experience, demanded we design for tablets including iOS. This was not in our original scope of work. Our vendor is now updating the course specifications to be amenable to tablets and Macintosh operating systems. This requires more time. We gave our operations manager a copy of the SOW that listed tablet adaptation for “Phase 2,” however in the future, we will require her written signature of acknowledgement.

(Martin, 2012)

Another issue that hampered this project and contributed to our delay was our learning management software cannot accommodate Flash or FLV files. This was not specified in our requirements but is necessary for broad content delivery. Our vendor now is converting all FLV files to MPEG 4 video to accommodate a broad range of access.

Finally, this project fell victim to a lack of administrative considerations. We needed to film several individuals for the course. We allotted two days for filming, yet we did not consider the time it would take to schedule each person. They had to clear their schedules, check personal and professional commitments, and then fly into our location. Our project schedule also landed across the Thanksgiving holiday weekend when many project team members were unavailable.

Concluding, I’d say a lack of management understanding of the SOW that yielded last-minute changes in requirements and our underestimation of the value and time required by administrative tasks resulted in the failure of this project.

Works cited:

Collier, B., DeMarco, T., & Fearey, P., (1996). Defined Process for Project Postmortem Review. IEEE Software. Retrieved from

Greer, M. (2010). The Project Management Minimalist: Just enough PM to rock your projects! Laureate Custom ed. Baltimore: Laureate Education, Inc.

Martin, M. (2012). Responsive Design Alone Is Not Mobile SEO. Search Engine Land. [Illustration] Retrieved from

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.

Categories: Walden 6145