Yesterday a major project ended for me. This project, as most, consumed my life. I gave up sleeping, found myself wearing the same clothes days in a row because I didn’t know the day had changed, skipped meals, and pretty much neglected anything that wasn’t related to getting the job done. Today I examine the aftermath. Yes, I thought I’d take the day away from the computer but if you stop the momentum, the project never really closes.
When I was a quality assurance engineer so many eons ago, I pushed hard for postmortems. In the software world, a postmortem is an examination after the project to review the development process while fresh in mind with the goal of improving the process on upcoming projects. A postmortem doesn’t just discuss where things went wrong but where things went right. A postmortem can include the ever important cleanup that happens afterward such as backing up the development environment, closing out your notes, jotting down notes about assumptions that were made and things aside for the future, and anything else to bring full closure to a project. In the real world, not many people like postmortems. They represent overheard to management and extra work to the developer. And it may or may not be billable to the client. People want to simply celebrate the product delivery, shove everything on the desk to the floor, and move onto the next project.
My postmortem is not billable to the client. Examining the aftermath, I recognize the importance of wrapping up to be able to move on. I can’t even find the surface of my desk right now for the scattered notes and neglected pile of mail. Instead of taking a break today, I’m going to bring closure to my project. (and find my desk).
