Project Management Pulse Check: Post-Mortem

There are many times when a project flies off the rails or doesn’t succeed as the project team anticipated. There are sever factor that can impact the success of a project implementation. Project Management best practice involves a post-mortem or project retrospective, to to evaluate the project’s success or failure at meeting its intended objectives, find what went well, and what could be improved on for future projects (McLaughlin, 2013).

As I reflect on my experience working on large-scale projects in my career, one example that comes to mind is the implementation of a new software system within a previous organization that I worked for. This software was going to be primarily used by Health Unit Coordinators and bedside staff (Physicians, Nurses, Case Workers, Social Workers, etc.).

Looking back, the project was not successful due to several factors. First and foremost, the project team did not have a clear understanding of the company’s requirements and needs. The project was launched and based on incomplete information and assumptions about what was needed. All of the necessary stakeholders were not involved from the beginning, which arose later on as a “we didn’t know what we didn’t know” situation. Many of the aspects of the launch were driven from an IT scope, but the consideration of its impact on the end-user (primarily bedside staff with no IT background) was not addressed throughout the project planning. As a result, the system did not meet the company’s needs as they intended to, and many of its features were either not used or not used effectively. Because the end-user was not included as a primary stakeholder, there was a lack of buy-in and commitment to the roll out and many team members were resistant to change.

Another contributing factor was the lack of a proper project management process. The project lacked a clear plan, timeline, and budget, and there was a lack of coordination and communication between team members. There were no established project management practices such as regular status updates, risk management, and issue resolution. Usually whoever had an issue arise during the planning project would throw on a meeting, which would sometimes lead to multiple meetings weekly addressing one-off issues or multiple weeks in a row without any status updates or check-ins. The lack of regular status updates led to big misses during implementation.

To make the project more successful, several parts of the project management process should have been included. First and foremost, the project should have begun with a comprehensive analysis of the company’s needs and requirements, involving key stakeholders in the process (Walden University, n.d.). While the project originated from the IT department, no one on the project planning team considered involving the end-user in the planning process. Secondly, a thorough project management plan should have been established, outlining the project’s scope, timeline, budget, and communication plan. This would have ensured that everyone involved was on the same page and working towards the same goals. Thirdly, regular status updates, risk management, and issue resolution should have been implemented throughout the project to identify and address any issues or problems promptly.

The lack of clear understanding of requirements, stakeholder involvement, and a proper project management process contributed to the failure of the software implementation project. Incorporating proper project management practices could have made the project more successful.

References

McLaughlin, E. (2013). Project post-mortem. Retrieved from https://www.techtarget.com/searchcio/definition/project-post-mortem

Walden University, LLC. (Executive Producer). (n.d.). Project management concerns: ‘Scope creep’ [Video file]. Retrieved from https://waldenu.instructure.com

3 thoughts on “Project Management Pulse Check: Post-Mortem

  1. Hi Jill,

    Great project scenario to share about project management gone wrong, or lack thereof.

    As I read your project example, all I could see were big red Xs on everything unfolding before everyone’s eyes, yet the IT group developing the new software turned a def ear to it all and leadership. Then right away, I was asking myself, “where is the needs analysis, and why was this not done before development?” The needs analysis is critical to get the raw data from those that will be using this program so that IT knows how to structure the software. Another thought I had was that there seemed to be no training or quick guide for the staff on how to use the new software, especially for those that are not as tech-savvy. I agree 100% with your final comments on how the project would have been more successful if there had been a straightforward project management process included from the start and the right stakeholders included from start to finish. Did anyone in your leadership or staff try to voice concerns about putting a stop to the project in its early stages? How long did it take to get new software implemented after this scenario?

    Like

  2. Hi Jill,
    Knowing what you know now, I am sure the project would have succeeded. Benjamin Franklin once said, “If you fail to plan, you plan to fail” It just shows how important planning is in any instructional design project. Two tools that would have proven beneficial had they been implemented and also help mitigate some of your challenges are a Statement of Work (SOW) or The Work Breakdown Structure (WBS). (SOW) is one of the first documents you’ll create to lay out the entire landscape of the project before you plan and execute. It defines the scope of work being provided, project deliverables, timelines, work location, and payment terms and conditions (Landau, 2021). In comparison, the project manager and project team can also use WBS to develop the project schedule, resource requirements, and costs. Having an outline will keep your team organized and constantly up-to-date as they follow the project’s progress during each phase. The team will be able to work collaboratively and more productively.

    Like

  3. Just like idmcneal, I saw red flags. Oftentimes when there is a problem, everyone says “there’s a problem; what we need is…” Then someone becomes the doctor and prescribes and answer to a symptom. No one examine the entire situation to see what the real problem is and possible solutions. Just because one solution is presented doesn’t mean it will fit the situation.
    I was really surprised that the end user was not considered when the software was decided upon and implemented. After all, who is the one who will use the software. If the end user is the one using a software, there definitely should have been training. However, training is not necessary if the software didn’t actually fit the problem.
    Needs or task analysis should have been conducted once the problem became apparent. Stakeholders analysis should have also been conducted to verify which stakeholders are affected by the problem. I definitely agree with you that project management is key and making sure that there is a proper fix to a problem and everyone that should be involved is involved.

    Like

Leave a comment