Week 2 - Project Post-Mortem

Greer (2010) states that it important for Project Managers (PM) and project team members to examine a completed project at its end and develop a list of lessons learned so that they don't repeat any mistakes in the next project. Greer (2010) refers to this as a post-project review or "post mortem." (Greer, 2010).

This week we were tasked with recalling a project in our past where we were not happy with its results. For me, this was an easy call. I recently took a new job that includes, among other thing, project management. I started on Halloween of2011 and my first big project was the rebuild of a machine that was to be shipped to our Canadian manufacturing plant. I studied the machine design, supervised the machine shop that made the modifications and worked with the engineer that designed all of the changes. Based on feedback from these project team members, my immediate supervisor, upper management, the plant managers at both my location and the Canadian location, and the maintenance staff on site I developed a Project Charter, scope, and a timeline. The project began on December 7th, 2011 and was scheduled to complete on December, 29th, 2011. Boy! Was I in for a surprise.

Before getting into the details, Geer (2010) states that you should do a post mortem in two phases. In Phase I you create a specific set of questions to send to the project team members and have them answer. In Phase II you hold a meeting to discuss the answers to these questions. Those questions may look like what Greer (2010) came up with below:

1. Are you proud of our finished deliverables (project work products)? If yes, what's so good about them? If no, what's wrong with them?

2. What was the single most frustrating part of our project?

3. How would you do things differently next time to avoid this frustration?

4. What was the most gratifying or professionally satisfying part of the project?

5. Which of our methods or processes worked particularly well?

6. Which of our methods or processes were difficult or frustrating to use?

7. If you could wave a magic wand and change anything about the project, what would you change?

8. Did our stakeholders, senior managers, customers, and sponsor(s) participate effectively? If not, how could we improve their participation?

 

Now, onto my miserable project

First off, I made a rookie mistake. It was December, "Hello! The holidays..." I scheduled the project and got approval from management and the project team members. The project was scheduled to run sequentially for three weeks. Much to my surprise, a week into the schedule all of the project team members went on vacation. What! It was almost as if they wanted me to fail.

I had neglected to anticipate the vacations that everyone would be taking. It was the end of the year, people had to take their earned vacation for the year or lose it when the new year rolled around. Let me tell you, that fact was not lost on them. They left in a mass exodus. Not only that, the company had Christmas Eve and Christmas day off, as well as New Year’s eve and New Year’s day (so much for trying to catch up).

Onto the questions

I am proud of the deliverables. The machine turned out nice and the modifications work like a charm. However, the project ran three times as long (from 3 to 9 weeks). Along the way there was trouble after trouble after trouble. Parts were not ordered, parts did not fit, some parts had to be customer made. Other parts were not even planned for but came up as the project progressed. Much of the work had to be farmed out to other machine shops and costs skyrocketed.

The single most frustrating part of the project was the lack of team play. Everyone left me after a week and took vacation. Then management expected me to still deliver on time.
Next time I am definitely not forgetting vacations, the time of the year, sick days, and any other freak or labor shortage. I will have backups for everyone.

Stepping away from Greer (20102) now, the course assignment requested information on the processes, project artifacts, or activities I included in the project that contributed to its success. Portny et al. (2008) state that a Work Breakdown Structure WBS) is a organized, detailed and hierarchical representation of all work to be performed in a project (Portny et al. 2008). That is exactly what I created in the failed project based on input for the project team. I laid out the who, where, when, why and how of every aspect of the project that I knew about. I also used Microsoft Project to track the project and create a Gantt Chart. However, even with all of that planning it was the things that I did not know about that were the ones that got me and killed the project's deadline.

Additionally, the Blog assignment this week wanted a report on the processes, project artifacts, or activities that I did not include in the project that might have made the project more successful. That is a no-brainer; I should have looked at the calendar. The holidays are never good for projects. Beyond that, I needed to work on bringing the team together better, driving home the importance of keeping to a schedule, and more communication to all stakeholders as the project progressed.

In closing...

There are a lot of things I could have done better on that project. However, failure is not just failure, it is the discovery of yet another way that a project can go bad. That discovery in itself is experience. I learn from my mistakes and the more I fail, the better I get. As a result of the aformentioned failure I have learned how to communicate better, pull together a responsive team and communicate updates to all stakeholders. The current project I am working on closes out next week, and I am ahead of schedule, under budget and delivering more than required. This project is yet another machine rebuild/modification. This time I know all the of the required specifications and I have had full control of all of the resources. That was something I sorely needed in the failed project but did not have.


References

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

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.