Friday, January 17, 2014

Learning from a Project “Post-mortem”

My classmates and I have begun the eighth of ten courses to achieve a Masters in Instructional Design and Technology.  In this leg of the journey, we learn about project management.  For this blog posting, we were requested to describe a project that may not have ended so well, and briefly discuss the contributions to the success or failure especially in consideration of the project management process provided in our course text.
This project was to create a mail merge type of system that created orientation schedules for new employees via information from the HRIS system.  The PM was an IT specialist, and the team consisted of him and a HRIS analyst from the IT department.  After a lengthy period of time (I’m guessing over a year), the PM suddenly left the organization, and the project was turned over to me.  There was no clear direction or formal written out plan to achieve this project’s completion.  I worked with the HRIS analyst for approximately six months, and determined that the project should not move forward.
The project that I have chosen departs a bit from the actual assignment, in that I was the closing PM, but not the PM who began the project.  The project did not seem to follow any of the formal phases suggested by Greer (2010, pp. 42-43), or include any kind of written Statement of Work (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 53).  After trying to move the project forward, and examining the scope, and benefits versus costs, it was decided that the costs and time resource were not worth creating the system.
If I had more formal PM experience, I probably would have started at the very beginning with the conceive phase (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 77).  This would have decided the outcome much earlier.  The project was technically feasible, but the benefits were not worth the expected costs (people and time resources).  The bottom line lesson for me is that a good project manager follows a process and writes it down in case something happens.
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.

4 comments:

  1. Jenni,

    It is interesting what we know and do not know until we experience it or learn about it first hand. As I process the information I read each week, discussions posted and bogs shared, I learn there is much I do not know. I like what the military does after a major event or training exercise, they document lessons learned. allowing management to see what worked well and what did not for future operations. Looking back at your experience, I can see creating a Statement of Work, establishing a schedule and developing a work breakdown structure as illustrated in "Project Management: Planning, Scheduling, and Controlling Projects" by Portny, Mantel, Meredith, Shafer, Sutton, and Kramer (2008).

    Consider it a case study enabling you to practice what you are learning. The often comment we say to ourselves, "I would do it different".

    Marnie

    ReplyDelete
  2. Hi Jenni,
    Your story makes a great point: just because a project is possible doesn’t mean it’s feasible. The original PM should have performed a feasibility analysis at the beginning. This analysis would have answered questions about whether the project met a customer (or internal) need, offered a competitive advantage, met financial goals, and so forth (Zaval & Wagner, 2011). At least you had the courage to end the project rather than continue wasting money and resources on it.

    --Deanna

    Reference

    Zaval, L.K., and Wagner, T. (2011). Project manager street smarts: A real world guide to PMP skills (2nd ed). Indianapolis, IN: John Wiley & Sons, Inc.

    ReplyDelete
  3. Jenni,

    I can only imagine how frustrating that must have been. It's really challenging to try to step into a project someone has already begun and to try to figure out where they were going with it, especially when there is no documentation for the goals, sequence, etc. of what they were trying to do. We recently had a teacher out for a medical emergency and they had no calendar, sub plans, or anything, and the poor long-term sub had to recreate his curriculum from the ground up. I am glad you had the flexibility to determine that the project should not continue, but your story does make me wonder: who signed off on the project to begin with? In our SOW discussions last week, we talked about one of the most important phases of project planning in the very beginning to be gaining the authority or buy-in of someone high enough in the company to be able to lend some weight to the project (Portny, Mantel, Meredit, Shafer, Sutton, & Kramer, 2008). If the task were truly important to someone within your organization or the client's (which, it seems, it was not, based on your description and your ability to terminate it), I would have imagined that there would have been some pushback when you tried to end it.

    Anna

    Reference

    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.

    Anna

    ReplyDelete
  4. Hi Jenni,

    In a way, you made a courageous decision. In its current state the project did seem unfeasible. While you could second-guess your decision to “pull the plug,” without those initial phases (Needs and Feasibility; Project Plan), bringing the project to fruition under the circumstances does seem extremely difficult. However, it does appear that you did ask the pertinent questions when you determined, “After trying to move the project forward, and examining the scope, and benefits versus costs, it was decided that the costs and time resource were not worth creating the system.” You essentially asked these very questions:

    1. “Did our needs/market analysis or feasibility study identify all the project deliverables that we eventually had to build? If not, what did we miss and how can we be sure our future analyses don’t miss such items?

    2. Did our needs/market analysis or feasibility study identify unnecessary deliverables? If so, how can we be sure our future analyses don’t make this mistake?

    3. How can we have improved our need-feasibility or analysis phase” (Greer, 2010)?

    Your decision prevented additional expense for a deliverable that would not make sense for the company from a cost standpoint. Clearly, the answer to question #3 would be do be sure that a need-feasibility study was conducted prior to initiating a project! Also, a SOW would have enabled a much smoother turnover after the original PM left the position.

    Susan

    References

    Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects. Laureate International Universities.

    ReplyDelete