There was no internal weekly sharing this week. So, no presentation slides are available as well. Sorry ~
Instead, we had a Post-Mortem meeting of a recently completed insurance client project. "What is Post-Mortem meeting ?" you might ask. From wikipedia:
A project post-mortem is a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that were successful or unsuccessful
In F5 Works, our client projects usually take 3 to 5 months to complete (projects bigger than that are split into smaller phases). Every project team has to host a Post Mortem sharing meeting in front of everyone, after they complete the project.
In software consultancy business, people are separated into different project teams (in F5 Works, usually size of 3 to 5) and dedicated to different client projects. Being participated in a project, one can gain lots of unique hands-on experience and at the same time gain lots of insights on overall process efficiency.
If we model this knowledge equipment progress like git branches, it would be like this:
If we leave the knowledge staying in individual's head, then it is like keep forking branches without merging back to master branch. Next project team will start from old master state again and learn from scratch.
Conducting Post Mortem is like merging all the isolated commits (member knowledge) back to forked branch (team knowledge) and then back to master (company knowledge).
By sharing knowledge after every project, company level knowledge will be aligned and next project team can start from the latest knowledge. It ensures we are always improving and not few steps forward few steps back. It also helps individuals to grow and helps company to scale at the same time.
Here are the high level steps that we do:
- Initial Document Draft
- PM consolidates issues raised into a Memo (we are using Basecamp Doc)
- Team members appends items to the Memo
- Project Team Meeting
- Go through the Memo together, and discuss items in detail
- Company-wise Sharing Session
- Highlight valuable points and suggestions (details in next section)
- Further discuss on particular critical items
- Implement changes to other projects and company process
Topics Covered in Sharing Session
It is obvious that sharing every tiny details is wasting everyone's time. So, we just focus on the following major topics:
- Project Summary
- Background, Timeline, Team Formation, Tech Stack, Client Satisfaction
- Major differences from other projects we did
- For each process unit (e.g. Sales, PM, Design, Dev, QA, DevOps, Client Communication)
- Things that we should keep doing
- Things that we should NOT do at all
- Things that we should improve
1. Review while still remember
Almost in every consultancy project, everyone is so concentrated in "Get Things Done" during the project schedule. There might be lots of "Not Urgent" && "Not Important" (in Eisenhower Matrix) problems people noticed and decided to deal with it later.
Instead of joining a new project immediately, it is better to review while your memory is still fresh and your focus/mood is still binding to the project.
2. Voice out and Look into Future
Instead of keeping to oneself, bring it up and talk to your teammates. Whether or not it is some terrible topics that you don't want to talk about again, let it out.
If it is bad things that you faced, let's figure out better solutions together. Don't let it bother you or your teammate again. If it is good things that you saw, appreciate it and encourage everyone to follow / reproduce.
3. Grow as a company
Give & Take. Share & Learn.
Work and grow as a company together, not an individual person nor just within a project team. Everyone can grow faster and further.
4. Loyalty & Reward
One of the biggest reasons people would join a company is because of learning and potential to grow. Especially in software development scene, one has to be good at many areas in order to build a good quality software (T-Spectrum skillset). Provides your team members as much learning and growing opportunity as possible. They will appreciate.
Do not blame. The spirit of Post Mortem is looking into the future, not a finger-pointing-blaming meeting. Be respectful, as always, to your team mates and your clients.
Take actions. Depending on your team's process design, schedule follow up meetings and implement changes ASAP.
Keep it Short. Q & A should be included at the end of the meeting. However, it is not for brainstorming. Keep a list of TBDs (To be determined) into the Post-Mortem document, start a separate discussion thread for those topics.
F5 Works is hiring ~ Check out opening positions on our website Jobs page.