A post-mortem process for a project “means a close examination of all parts of the project to determine its successes and failures” (Campbell). No matter what its called close-out or a post-mortem, what is done after the project is key to the success of future projects.
Earlier this year, N Pharmaceuticals announced its need for a new and innovative documentation system that would house over 1,000 standard operating procedures, 200 controlled forms, and over 30 corporate policies. After several need and feasibility assessment meetings, and software presentation by different vendor the project team was committed and agreed to the change from Documentum to MasterControl. The project included the installation of the new software while maintaining a parallel system with the older documentation system, validating the each process, establishing test scripts and testing the system to ensure all scenarios functioned as expected.
The “MasterControl” project affected every department in the organization, so the project team was established using a “Functionally Organized Structure to ensure more response is provided to the needs of the different organizational areas. Separate units were established based on their specialty” (Portny, p 63).
Although the project was closed successfully, it was not without its challenges and even a “scope creep”, which could impacted the timeline and budget. During Phase I: Determine Need and Feasibility, the team brought together all department heads to discuss their specific documentation needs. This process was well organized and provided an accurate needs and feasibility assessment. As Phase II: Create Project Plan began to unfold, it seemed that based on the selection of members from each area the team was well represented by expertise, management and other key roles. The Project Manager developed a timelines, budget and identified required resources. A project charter was developed and signed by all stakeholders. The Kickoff meeting was well staff, which set the stage for the approved project plan to be presented.
In Phase III: Create Specifications for Deliverables, the “blueprint” which was presented in Microsoft Project was well detailed as to the deliverables and member assignment. The timeline was refined, and the work processes were reviewed. Phase VI: Create Deliverable was a smooth process since all of the deliverable were developed by the vendor, MasterControl. All the team members had the opportunity to provide feedback as to the specification; and, work processes for creating the deliverables. And finally, Phase V: Test and Implement Deliverables was clearly where the team encountered the challenges. It was quickly noticed that the person reasonable for the creation and publishing of the training modules, one of the key deliverables of the project, 620 lectora courses, she was not consulted when the timeline was established. The training manager was given 3 days to complete the updating and republishing, There were 620 courses and it takes approximately 30 to 45 minutes to update the link, publish lectora file and test in the QA and PD environments. This challenge presented a budget issue sine one person, even two could not feasibly develop those courses in 3 days. As the project manager, I had to establish as plan to correct the oversight. I met with the training manager, we developed an estimate for the work, and the resources that would have to be assigned to this part of the projects.
In summary, the project was completed successfully and the “post-mortem” meeting helped to identify strengths and weaknesses, which will benefit the team as a group, and individuals as they continue to participate to carefully plan and include all necessary team members from Day 1.
References:
E-book: The Project Management Minimalist: Just Enough PM to Rock Your Projects!
Step 2: Get your team together and start the project (pp. 10–12)
Step 3: Figure out exactly what the finished work products will be (pp. 13–16)
Project "Post
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: PlanningMortem" Review Questions (pp. 42–43)
Hi Elia
ReplyDeleteDuring the define phase it is important to create a detailed description of what is to be produced, a list of all work that is to be performed, the roles all team members will play, and a detailed schedule of all work. How successful the plan is depends on how detailed and clear the plan is (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 79). It seems that a detailed schedule of all work was not created. This could have been avoided by creating a Work Breakdown Structure (WBS) and Linear Responsibility Chart. These documents would have identified the unrealistic expectations of the training manager (Portny et. al., 2008, p. 97).
Another mistake was not including all team members in the initial planning. Greer (2010) states that it is important to include all project stakeholders' "in an active and engaged fashion from the beginning, . . . " (p. 10). If the training manager had been included, s/he would have been sure to see that the assumption made about the time s/he needed to complete the work was wrong.
Thank you for providing us with an excellent example of a successful project that, after post mortem reflection, could have been even more successful.
Sue
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.
Elia,
ReplyDeleteWhile I can’t fault Sue’s prescription, in my experience the situation you described is not at all uncommon. The problem, as you identified, was that the training manager was not consulted about the time it would take to complete the update and republishing. As a result, too little time was scheduled, potentially impacting the budget and schedule. Sue commented that including all team members in the initial planning would have prevented the problem.
But as I’ve indicated, I’ve seen a variation of this scenario on many projects I’ve worked on. I think there are two issues that are the root cause. The first issue is the way project managers tend to identify stakeholders, especially for inter-organizational systems (IOS) such as the one you described in your project. In a 2008 report looking at IOS projects, Boonstra and de Vries wrote, “Clearly the implementation of IOS systems is a complicated endeavor, both from a technical point of view and from many other perspectives, including strategic, organizational, political, and cultural viewpoints” (p. 190). While project managers are juggling strategic, organizational, political and cultural issues, identifying stakeholders who would support or resist a project, figuring out how to manage and involve stakeholders, and ensuring that the primary project objectives are met, the ‘training’ perspective gets lost in the shuffle.
And that’s the second reason I believe that I’ve seen this issue crop up so frequently. ‘Training’ isn’t the primary project objective. ‘Training’ is an ancillary activity, a deliverable that a small, low status, low power department is responsible for. A department whose support is assumed; a department that requires almost zero stakeholder management. The training deliverable also isn’t anything that needs to be managed with other stakeholders. Whether the other stakeholders support or resist the primary project objective, there’s no reason to negotiate the ‘training’. Doing so would be a distraction.
The Training department is not going to be a squeaky wheel, and provides no competition for stakeholder management resources. As a result, it tends to be overlooked.
Yes, the training department does represent ‘team members’, and their participation should be confirmed (Portny, Mantel, Meredith, Shafter, Sutton and Kramer, 2008, p. 83). But in practice, especially for large projects where ‘training’ is not the primary drive of the project, I’ve seen this ‘confirmation’ assumed far more often than I’ve seen it discussed.
- Patrick
Resources
Boonstra, A., & de Vries, J. (2008). Managing stakeholders around inter-organizational systems: a diagnostic approach . The Journal of Strategic Information Systems, 17(3), 190-201.
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.
Response to Patrick and Sue:
ReplyDeleteI agree with Sue that a work breakdown structure (WBS) would have potentially broken down the project milestones into individual activities, and the training department may not have been passed over when identifying the required activities and their time allotment. But, Patrick has an excellent point, in my experience when training is not the lead stakeholder, it is often overlooked, and only brought in at the final stage of the project causing possible delays and "scope creeps" depending on the team member's role. (Portny)
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.
Good evening Elia.lora,
ReplyDeleteWhat a complex project, yet extremely planned and effectively implemented. It is essential for phase I to be done effectively and especially in a detailed project such as yours. It seems as though all the right personal and roles were included into this project of the “MasterControl”. This was pointed out in our learning video, concerns of Scope Creep. In addition, the plan sounds as though the PMs and IDs were on top of all aspects and concerns that could have come about. Also the initial scope was well established.
The MasterControl project is a project that can and should be used for teachable moments.
Courtney
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.