project post mortem blog post title

Creating a Project Post Mortem | The Why’s and How’s of Finishing Projects

A project post mortem is a lethal-sounding term that seeks to answer the question: did this project work? Was it worth the investment and the time, and if it wasn’t can you learn from it? As the term implies, the project must be “no more” or “ceased to be” or “bereft of life.”

Creating this document requires a time investment, and it’s tempting to just move onto the next project. Overcome this urge by packaging your post mortem into a short meeting to expedite the process. We believe learning from your work is the most important part; whether that takes the form of a public blog post, a private email, or an internal chat is your call.

Startups especially benefit from post mortems, as their teams are often agile enough to make adaptations to the development process. Larger companies sometimes struggle with bureaucracy, an important roadblock worth documenting.

A project post mortem is ultimately a learning exercise. If you’ve gotten this far, you’ve invested in yourself and recognize opportunities to optimize and improve. The essentials of the process are an honest and holistic look at the project’s successes and failures.

Results and Expectations

Let’s begin with a simple yes or no: did we get the results we wanted for the effort we put in? This should be an easy answer based strictly on expectations versus results. Identify the goals you didn’t hit and dive deeper into the project.

Examine Your Resources

An important part of staying on task is ensuring that your team hits its milestones within deadline. Project management frequently forecasts hours (a team I worked with once called them “chili peppers”), and a post mortem investigates those initial forecasts and their outcomes.

If the project experienced crunch at any point, or required more development than initially forecast, then you’ve uncovered a gap.

Document What Went Right

Don’t forget to allot some time to celebrate your victories. Ideally, projects have multiple steps needed to attain certain goals. A post mortem is a chance to improve morale as you critically examine these steps.

Establish what works and optimize your process for better performance next time. Don’t forget to recognize efforts that went above and beyond, or unexpected results that can spur additional discussion.

Examining Milestones

Looking at your returns, you can examine unexpected events or roadblocks that may have prevented teams from meeting their steps. This part of the post mortem is enhanced by any technical data you have available for productivity or output.

Monitoring and Run-Time metrics

Website downtime is a good example, where technical data on what went wrong can inform future decisions. Deploying a new feature or migrating a database are multi-step processes that teams have to tackle as part of improving an application. They require additional infrastructure investment and lots of development effort behind them.

When downtime occurs, it correlates to either resource use, development effort, or overall usability among other aspects of development. Knowing why something went down helps you figure out which of these you should focus on.

We recommend at minimum that teams utilize the following to assess downtime:

  • HTTP(S) checks
  • SSH expiry
  • DNS
  • SMTP/POP/IMAP as relevant
  • Domain Blacklist and Malware
  • WHOIS expiry

More complex applications should be utilizing API checks to ensure availability of databases and test for uptime and response after major changes. The GET and POST requests help verify a server’s status based on response codes, or expected strings, from multiple locations. If your development team is remote or spread out, this kind of request is useful for determining who has access to what or identifying roadblocks that occurred during development.

Transaction checks are useful for eCommerce, but provide flexibility in other areas. For example, a transaction check can test a particular form from a specific landing page. The technical data generated from that check can help optimize this funnel, or provide first-response to an outage and a historic record of events.

Development Effort

There’s more to a project than whether or not a team met expectations. Were decision makers on board? Did the project parameters shift during development, and were those shifts part of the forecasted outcomes?

Parsing out these roadblocks will help teams prepare for future forecasts. If parameters shifted multiple times, then it might be useful to allocate more time and effort to the planning phase. If decision makers are feeling non-committal, can you prioritize objectives that contribute positively to the project outcome?

You may also uncover opportunities based on how priority was allocated. The benefit of hindsight allows the wise project manager an opportunity to examine “panic moments” and learn from what went wrong.

Team Check In

Google Docs is useful for anonymous surveys. Creating a thoughtful list of questions about someone’s experiences with the project, and anonymizing that data, can lead to some useful insights. Project managers and decision makers can review this data ahead of time to get a sense of how teams handled the expectations and requirements.

Open-ended questions with text responses offer opportunities to discuss ideas that might not come up in a meeting. Addressing these responses also provides team members the reassurance that their feedback matters.

Some good items to ask about include:

  • Did you experience crunch?
  • Were the deadlines reasonable?
  • Did you require help from other members or teams?
  • What roadblocks gave you the most difficulty?
  • Do you think this project could have been more successful?

Allow team members to address some of the items your post mortem examination will likely uncover. You may find their feedback valuable.

Closing Your Project Responsibly with a Post Mortem

A post mortem meeting is where everything comes together. You can put all of this feedback and data into succinct slides (don’t forget the rule of six, but maybe don’t take it so literally), and hold a meeting not to exceed 30-45 minutes. You want a quick discussion with time for questions, then it’s back to the next project.

A post mortem is part of the investment you make when you decide to undertake any project that furthers your business goals. It’s an important learning step in a long line of failures that lead to your success. Understanding every hindrance, whether technical or self made, helps your team be better.

Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.

Get Started

Don't forget to share this post!

Avatar

Richard Bashara is Uptime.com's lead content marketer, working on technical documentation, blog management, content editing and writing. His focus is on building engagement and community among Uptime.com users. Richard brings almost a decade of experience in technology, blogging, and project management to help Uptime.com remain the industry leading monitoring solution for both SMBs and enterprise brands. He resides in California, enjoys collecting and restoring arcade machines, and photography.

Catch up on the rest of your uptime monitoring news