Week 2 - My Project Post-Mortem Story

The project I am writing about this week based on my experience on a government contractor team from 2006-2008.  I started on the project as an IT instructor/instructional designer where my role was to write the training material for the IT staff that would be taking over that role upon system delivery.  After spending about a year developing the material (in cooperation with our IT SMEs), I was promoted to be our team’s lead (ILS or logistics lead).  As the lead, the trainers and technical documentation writers fell under me and I became the interface between our team and the PM.  It was in this role that I quickly realized how disjointed our project team really was and how many factors contributed to both the internal and external impression of our team.

From the time I was hired, it only took about six months to realize that our team of approximately 50-60 contractors was woefully behind schedule.  This was solidified when our PM delivered the news of our first project “slip” to the customer.  Unfortunately this is where things started to unravel, and our team quickly realized that we were much farther behind schedule than we had initially estimated (or had been told, depending on your perspective).  What ensued was a confusing, confrontational, and frustrating period within our project, not to mention with our customer, where many people questioned their contribution to the team and, more importantly, our team’s leadership and ability to even complete the project (regardless of the time frame).  When I left the team in 2008 we were three years behind schedule and the system we were supposed to install in 2007 is just now in the initial phases of install and turnover to the customer.  There are many reasons for the delays, and I will attempt to go over as many as possible while keeping this as brief as possible.

            The majority of the issues our project team encountered are captured in section 4.7 of our book, “Examining Why Plans and Project Fail” (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, (2008). pg 104).  Since I joined the team about two or three years into the project, I cannot speak intelligently on how it was actually started and whether the phases were accomplished according to our reading.  What I can say is that, through many conversations with coworkers, it was obvious to me the project did not get off to a very efficient start.  The system requirements specifically were something our team kept going back to, even years into the project, and we found ourselves (us and our customer) disagreeing with the verbiage and questioning whether all of the actual system requirements were documented or mapped properly.  It is quite possible this is the number one reason why the project was so far behind schedule.  But again, that was the prevailing opinion of many team members (system engineers, software developers, etc.). 

           

            On page 107 of our text there is a section on “Detecting Potential Pitfalls Early” (Portny, et. al. (2008). pg 106).  I am not exaggerating when I say that virtually every one of these causes affected our team:  “not involving all key project stakeholders”, “vague objectives” (read requirements), “vague or nonexistent role and responsibility definitions”, “not identifying and sharing key project assumptions”, “not writing down key information”, “not holding people accountable for performance”, and the biggest one of all “poor team communication” (Portny, et. al. (2008). pg 107).  I blame most of this on our PM, as it was his primary reasonability to ensure we stayed on schedule and to avoid these circumstances when they arose.  However, the entire team seemed to have this dysfunctional dynamic that we just couldn’t shake.  It was in the ways we talked to each other in meetings, how teams didn’t share information, milestones weren’t given the proper amount of importance.  Again, I was hired years into the team being formed so I walked into this situation.  It didn’t take long to figure out that, while there were some very smart and talented people on the team, there were some that were obviously part of the problem yet no one seemed to be doing anything about it.  It was as if everyone knew this was good way to earn a paycheck and there wasn’t really a compelling reason to turn it around. 

            Well, after reading back over this post I don’t particularly care for how negative it sounds, but that is how the project “flowed” and some of the issues that I believe contributed to the setbacks.  As for me, after about two years I just didn’t have the patience so I moved on to a better opportunity.  But I have always remembered the lessons I learned on that team and have tried to put that knowledge to use since. 

References:

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.