After one particularly difficult midterm in college, my professor said, "This is just a wakeup call; there's still time to improve before the final." I think that wakeup call was particularly painful, but my professor's words stick with me today, especially when thinking about data collection (or lack thereof) when a project is over.
As someone who is not a project manager, it was difficult for me to understand why project managers would not collect their own historical data. I understand now that after a project is finished, people move on to the next project and there's no time to update project stats. Recently, I read a post on Gantthead.com by Kenneth Darter called, Project Closure: Party or Post-Mortem?. Darter says if the project was a success, then it's important to record why it was successful; if the project was not successful, it's important to capture why it was not successful.
The word "data" in Latin literally means "things having been given." At the end of a project, you have been given a lot of things that only you and your team know: size, effort, duration, staffing, PI, cost, etc. If you are able to take a moment to fully document your project information, you not only build a historical database, but you're able to reflect back on that project to improve future endeavors (whether you would like to remember it or forget it completely). Darter recommends creating a checklist which, "should be defined early on in the project and communicated to everyone who will have input into the checklist at the end of the project." In addition to project specific information, he specifically recommends these three items:
- Scope: both the original planned scope and the scope that was met by the final result of the project.
- Issues and risks faced by the project and how they were dealt with during the execution of the project.
- Actual vs. Plan Data: The actual data from the project plan versus the baseline data
The idea here is to focus the project manager and provide a baseline for what kinds of information should be included in your "party" or "post-mortem." If you’re importing your project closeout information from SLIM-Control, items 1 and 3 (planned vs. actual scope and baseline vs. actual data) will come in automatically. Project issues and risks can be documented in the Significant factors area of the Review tab:
Every completed project is a midterm; the final is the future of your team's software development. Although your wakeup call might be painful, you can use everything you have been given to make the next wakeup call less painful until it's time to take the final.