Project Post-Mortem Reflection

Project Post-Mortem

     The project I was working on involved a new product being made by a company I was working for.  Most of our product team (including the Project Manager (PM)) was new to project management so there was a steep learning curve.  I supported the project by providing technical advice to ensure it could be serviced by a technician with the least time and cost to service, repair or replace components.  When reviewing the Generic Project Life Cycle Phases (Greer, 2010),(pp 42-43).  Phase 1 passed the first question because it was determined that there was a need and the project was feasible.  It failed the second question.  In the beginning of the project there were no unnecessary deliverables, but that changed after launch.  Phase 2 was to Create a Project Plan.  This company wanted estimates to be realistically close to what the team thought actual costs would be.  Since most of the team was new, we complied. 

     This is where Phase 2 started to fall apart.  The product manager wanted to add items after launch that should have been stopped.  If they had been part of the original plan, money could have been incorporated in the estimate to cover them.  I learned from this that there is almost no way to stay on budget if the PM doesn’t stop scope creep.  Scope creep is very common (Laureate Education (Producer), n.d.).  There were several times the group let scope creep in because each idea sounded good and would have benefitted the project.  Add to this, people from senior management wanted some of the scope creep items added to the project.  We were new to this and thought the ideas would benefit the project and the company.  Some of them made the project more successful but added a few months to the project and about $20,000 dollars in extra cost.  Fortunately, senior management approved this because they had asked for the extra items to be added to the project. 

     Phase 3 also started well in that product specifications were detailed in the beginning of the project.  The different departments involved in the project were represented and the different players provided valuable input into the project.  We could have improved the work process by meeting with senior management and the product director at the same time and asking about any added features they wanted.  We could have then discussed the ramifications of adding features and how they should be documented and approved by the team and by senior management using a document called a Change of Scope document (Laureate Education (Producer), n.d.).  This would have kept us on track because the time and cost would have been changed and approved by all involved in the project.

     Phases 4 (Create Deliverables) and 5 (Test and Implement Deliverables) followed the path of scope creep.  As parts of the project were completed, additional features were added due to scope creep.  These features needed to be speced, added and tested.  This is where time and money were added to the project.  The outcome was a project that worked well and fit a market niche.  It has sold well, so the company was able to recuperate the money spent on the extra features, which is fortunate.  The project taught all involved a valuable lesson about adding features after a project has been scoped.  They started using the Change of Scope document more and more.

References

Greer, M. (2010). The Project Management Minimalist:Just Enough PM to Rock Your Projects! Retrieved from michaelgreer.biz: http://michaelgreer.biz/?page_id=636

Laureate Education (Producer) (Director). (n.d.). PM Concerns: Scope Creep [Motion Picture].