Software development project Postmortem

If you’ve been a part of any software development project, you know things don’t always go as planned. In theory, projects have two possible extreme outcomes: success or failure. In reality, all projects will have a blend of success and failure factors when a large number of factors are considered. And in Apiumhub we believe that the best way to work through what happened during an incident and capture any lessons learned is by conducting a software development project postmortem.

What is a software development project postmortem?

Software development project postmortem brings people together to discuss the details of an incident: why it happened, its impact, what actions were taken to mitigate it and resolve it, and what should be done to prevent it from happening again.
A project post-mortem is performed at the conclusion of a project to determine and analyze elements of the project that were successful or unsuccessful, the process as lessons learned.
Project post-mortems are intended to inform process improvements which mitigate future risks and to promote iterative best practices.

Bringing people together to engage in a structured, collaborative process allows everyone to reflect and contribute what they learned and can build trust and resiliency within your team. And documenting the incident and how the team remedied it can inform how future incidents are handled. It helps drive continuous improvement.

One important detail – postmortem is not about assigning blame. You should be finding process failures not personal failures.

Software development project postmortem can encompass quantitative data, qualitative data and subjective data

Quantitative data
Quantitative data include the variance between the hours estimated for a project and the actual hours incurred. These are your standard yes or no questions. Were deadlines met or missed? Did we provide all deliverables outlined in the project scope? Were pre-defined success metrics achieved? Were outline workflows and processes followed? Was there a budget overrun?

Qualitative data
Qualitative data will often include stakeholder satisfaction, end-user satisfaction, team satisfaction, potential reusability and perceived quality of end-deliverables.
These open-ended questions should evaluate the project beyond the hard data and planning. Did we deliver work at the high standards we and our client expect? Does the client agree? Did people feel like they had the resources, information, and support they needed to get their own tasks done? Were task expectations poorly defined or communicated?

Subjective data
Subjective questions help assess how your team members are feeling, and can help leadership identify troubling signs of burnout and fatigue. These questions also let leadership know what processes worked best with their team, helping them plan future projects. What did people enjoy most and least about this project? How was working with the client? What changes would they make to this type of project in the future? How could the work run more smoothly with this client or among certain departments in the future? Do you want to work on a similar type project again? If not, why not?

In order for software development project postmortem to be effective and allow you to build a culture of continuous improvement, you want to implement a simple, repeatable process that everyone can participate in:

• Set a limit
  Incidents in your organization should have clear and measurable severity levels. These severity levels can be used to trigger the postmortem process. For example, any incident Sev-1 or higher triggers the postmortem process, while the postmortem can be optional for less severe incidents. Consider allowing team leads or management the opportunity to request a postmortem for any incident that doesn’t meet the threshold.
• Do it on time
  It’s important to take a break and get some rest after an incident. But don’t delay writing the incident postmortem. Wait too long and important details might be lost or forgotten. Ideally, it’s drafted immediately after the incident and not more than five business days.
• Assign responsibility
  It’s good to delegate the postmortem to a person who has the required level of technical and organizational knowledge to understand the causes and mitigations.
• Follow the checklist
  A template can keep you from leaving out key details. And it’s a great way to build consistency throughout your postmortems.

Sample agenda for an effective software development project Postmortem

Send out a questionnaire to all the participants prior to the meeting. An agenda is extremely important, but it’ll be hard to stick to your timetable if the participants aren’t prepared themselves having thought about all the questions you plan to cover.

Along with an agenda, there must be one person responsible for moderating the meeting. This is generally the same person that set the agenda and scheduled the postmortem. Having a moderator not only creates bumper rails for the conversation, but allows all the other team members the freedom to speak their mind without worrying excessively about the structure or process.

1. Set Tone
It’s where you remind the participants about constructive analysis. It’s your chance to guide the mindset of the group and hopefully get them to relax and feel safe enough for a truly productive session.

2. Recap The Project 
You’ll give a synopsis of what the project was about and what the initial expectations were. This will let you focus on the measurable goals so you can objectively evaluate the failures.

3.Recap The Outcome 
Was the client happy? Did the cost exceed the budget? Was the product delivered on time? Etc.

4.Team Member Questions 
It’s where the conversation really gets going and your team members get an opportunity to speak up. It helps to jump-start by asking one person a question and allow people to riff off each other. The important thing is that everyone gets a chance to contribute.

Here are the questions that may be used:

• Are you proud of our finished deliverables? If yes, what made them great? If no, what was wrong or missing?
• Did we get the results we wanted and did it make impact?
• Which of our methods or processes worked particularly well?
• Which of our methods or processes were difficult or frustrating to use?
• How would you do things differently next time to avoid this frustration?
• What else could we do better next time?
• What was the most gratifying or professionally satisfying part of the project?
• Was anything too vague in the plan? Was the plan missing any key information?
• Were tools, budgets, and team members allocated correctly? Were the needed resources adequate for the project?
• Were the deadlines achievable and realistic?
• etc.

5. Wrap-Up
This is where you thank everyone for participating and let them know that notes will be coming soon.

Sharing the lessons from a postmortem with other teams working on similar projects helps everyone in an organization. Post-mortems allow people to call out problems and ensure they get addressed. The progress boosts morale because people know they can directly contribute to the quality of their workplace and work product.