Sunday, September 18, 2011

Project Management 6145 Week 2-Learning from a Project Post-Mortem


Greetings All,

Well I am definitely a person deeply rooted in pattern and routine…as a result of assuming my blog had our “typical” due date of Sunday I am totally late with this posting.  Alas, it’s a lesson learned and one that I will not repeat next week…moving on J

This week, as the blog title eludes too, is learning from a project post mortem.  It’s nowhere near as dreadful as it sounds, it’s simply a “way to learn best practices and avoid mistakes on a future project [by] review[ing] the results and activities from a project that you have completed”. Outlined below is the assignment as provided by our professor:

To prepare for this assignment, recall a project that you worked on in the past, either personal or professional, that was not successful or did not result in the desired outcomes. You may be creative and use an example from your personal life that may not relate to your job. Using the Project “Post Mortem” Review Questions found on pages 42–43 of The Project Management Minimalist, recall your experience with the project and jot down answers to as many of the questions as you can (you do not need to submit these responses). Then, reflect on the following:
  • What processes, project artifacts, or activities did you include in the project that contributed to its success?
  • What processes, project artifacts, or activities did you not include in the project that might have made the project more successful?

Hopefully everyone is familiar with this document, if not I have hyperlinked a copy using Google docs for your reference.

The project that I commonly refer to is one with my previous employer, and I was the project lead.  Sadly and incidentally, it is a perfect example of almost everything NOT to do on a project. As I’ve mentioned in several class discussions, the project was the conversion of an in-person training course to an online format to be deployed overseas.

Contributions to Project Success:
The one activity that I feel I did a good job on (and I had control of) was my communication with my team.  As the lead, I stayed in constant communication with my manager regarding the status of the project, as well as my team regarding the status of their tasks. I utilized emails, in-person meetings, as well as conference calls to make sure we were all on the same page.  I also effectively communicated with the client regarding our status on the project and our timeline for completion of specific tasks.

Room for Improvement:
Aside from the client and their differing visions for the project, there were several things that we as a team could have done differently.  A key factor is in training and familiarizing the team with the ADDIE model. Due to the client, and our lack of formal training, the project was never rooted in grounded principles.  For example learner analysis was not performed, objectives were not specified in the manner in which they should have been, there was little time given to truly analyze, design, develop, implement, or evaluate the project.

An important factor that Dr. Stolovitch provided for successful id projects, is the let the instructional design process guide the work.  I feel this factor was missing from the beginning that caused a already volatile project to be more stressful than need be.


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. 

2 comments:

  1. When comparing your project to some of the other projects discussed in our learning resources and views from professionals, your project was going to be complicated largely due to geographical boundaries. Most projects contain a degree of difficulty, but when projects encompass distance culture, time boundaries, and language emerge as huge factors. As a project manager it is your responsibility to plan for difficult situations.

    The fact that you kept everyone informed is definitely a Post-mortem plus for you to re-use in any projects going forward. My advice for you would be to, "Reconfirm the work expected, including when the team members are to do it and the amount of time they are expected to spend" (Portny, pg.83, 2008).


    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.

    ReplyDelete
  2. Jamel,

    Thank you for your comment! Yes, typically when projects involve countries/territories outside of the host country this would cause many geographical problems. It's hard to provide ALL of the facts in these types of scenarios, of course; but geography was not as much of an issue as one may think...

    The largest issues we faced in dealing with another country were the logistics of facilitating the training due to the difference in time zone and if the material should be different for the overseas users versus the U.S. user (these were both decisions the client needed to make). In both cases the client/government agency were the same and all users are expected to speak English as their primary language. Also, as this is a government agency certain assumptions such as standard working hours, government holidays, etc were in place.

    I agree, it is a project manager's responsibility to plan for difficult situations, but when dealing with the government and the contracting world, textbook scenarios don't always work. This is not intended as a negative comment towards the government in anyway, as all agencies work differently, I can only speak from my experience. In normal situations the government contracts work to "experts" and allows and trusts the contracting company to utilize its expertise in a specific area. Unfortunately there are times when the client assumes "they" know best and as a contractor there is a very fine line in dictating orders to the government client.

    On this particular project I decided to ensure that I communicated and documented everything that was going on, in order to protect ourselves. As requests were changing on such a frequent basis I felt it was the best method to justify the time needed to make major changes when pending timelines were approaching.

    ReplyDelete