Project Lessons Learned: “Post-Mortem”

Just Say No!


The re-engineering software project that will be analyzed in this article is a State Government three year project to restructure multi-legacy systems into a single web-based system for easier access, user-friendly computer system. The goal of the project is to reduce user input by sharing data intelligence from other state agencies and departments to build a smart computer system that would improve work productivity across applications to share vital information.

Almost everyone has worked on a project that has made mistakes, wishing the team had done it differently. It is extremely important at the end of a project to look back to share the lessons learned among the team members, so these mistakes do not get repeated in the next projects (Greer, 2010). To learn from what did we do right and where did we get off track?

It is recommended after project completion the project manager prepares open ended questions for team members to get their initial feedback; in addition allowing individuals to respond back with ideas and suggestions how they would have done it differently. Project managers should structure these post-mortem questions per the project phases to help team members focus and narrow down their answers instead of trying to recall all of the issues for the entire life cycle of the project (Greer, 2010).

Phase 1: Determine Need and Feasibility
The State Government project goals and reasons behind replacing their legacy systems was highly justified. Replacing old green screen terminals with a new GUI Web interface will give the application a new modern feel that users are familiar with requiring less software training time. Green screens use computer keyboard function keys which is something that most end-users are not familiar with compared to web-based features using graphical screen interfaces such as Web 2.0 click-thru elements for navigation, buttons and other features that gives the application a new, modern Internet site look and feel. In addition, moving towards a service-oriented architecture (SOA) will not lock system applications into an architecture that cannot be expanded and supported in the future.

Out of date technology is difficult to maintain and support with IT staffing because younger programmers today are taught in colleges current coding such as Java or ASP.net not legacy coding such as COBAL or FORTRAN. So as baby boomer coders retire there will be fewer programmers to support legacy systems in the future. The need and feasibility of the State Government project was valid. The project’s problem-solution strategy during the analyst phase was successful it was considered to be a cost-effective solution that would improve the overall quality and reduce the complexity of the state’s application systems.

Phase 2: Create Project Plan
To ensure the success of a project is absolutely dependent on the project plan details (Portny, 2008). Looking back and being it was my first time on a multi-million dollar project, the State Government project showed early signs of potential problems that occurred later on during the scope of the project. When stakes are high and the project is extremely difficult and complex, many times inexperienced project manager will spend time on something unnecessary, instead of spending adequate time on planning, monitoring and controlling the project. “It is precisely why high stake projects desperately need a mature project manager who realizes the importance of creating effective planning-monitoring-controlling processes” (Portny, 2008).

The first sign of problems in this project started in the beginning of phase 2 when the initial project manager was let go because of difficulties working with key management stakeholders. To immediately fill the void, the consulting company moved an IT manager with no prior project management skills background to fill the vacant PM position. It was a disaster waiting to happen, using an amateur person to fill the role of a knowledgeable project manager to gamble with the high stakes of corporate financial resources and investment with the high risk of losses.

Phase 3: Create Specifications for Deliverables
Sometimes the original project plan deliverables are not enough to jumpstart a project because they are too vague and unclear. This will cause a project currently in progress to lose focus on what should be and what should not be included in the deliverables, causing project teams working across multi-localities to get off track. To get back on track, project managers should consider revising the original project plan, announce to stakeholders of changes, inform team members of a new direction the project will take and track performance very closely (Portny, 2008). The failure in this State Government project was not taking the first step toward fixing the initial small problems of deliverables in the beginning phase before they escalated into larger out of control unmanageable obstacles.

Phase 4: Create Deliverables
Towards the beginning of phase 2 and 3 the project was already heading towards the edge of the road but in phase 4, the project literally ran off the mountain cliff. Scope creep was now out of control with business stakeholders demanding extra deliverables and there were no clear project plan constraints, limitations to control all of the vendors and stakeholders changes of project deliverables. Of course, clients want more enhancements without paying for extra resources. Statistics of post-mortem reports from more than 500 project managers regarding the single most important challenging problem a PM will face is coping with project changes making it the top issue (Portny, 2008, p.346). After discovering new technologies or missing business requirements that become apparent during the project discovery will cause change control. In fact, the later these changes are discovered during the scope of the project, the more difficult and costly they will become due to delays, missed timelines raising the cost of the project.

Unfortunately the biggest mistake in this project was an inexperienced project manager that avoided dealing with Government contract bureaucracy. Instead, he tried to handle the request for changes informally without a change control system in place. Which finally drove the project off the mountain cliff into the ditch, causing the consulting firm to get fired and cut from the Government project due to breach of contract. Not only did the project manager lose his job, so did the entire 40 team members. Failure of change control not only cost employees their jobs but left the consulting firm with huge financial losses and a bad repetition as a preferred Government contractor.

Phase 5: Test and Implement Deliverables
In the perfect world, all project deliverables would move seamlessly with no problems but in the real world this never happens. In this case, the mentioned State Government project’s consulting firm never made into phase 5, due to scope creep. According to Portny, project managers often learn by doing. Sometimes it may take several projects to fine tune their skillsets. It is advisable for new project managers to take on smaller projects to learn from their successes and failures before jumping into large-scale complex projects.

What did we learn today that can translate to tomorrow’s projects? Excellent analyst strategies to gather business requirements for forecasting client’s future needs are essential for the initial success of the project. On the other hand, the project can run out of control quickly and it takes an experienced skilled project manager to handle obstacles to avoid scope creep. Finally, project managers need a clear change control system in place and set limitations. A project manager needs to have effective communication skills to stand up and be able to “just say no” to the client by setting clear written limitations in the project plan what is and what is not deliverables.

-Mary Layne





Reference

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.