top

Project Closeout

Project closeout is a best practice in project management because it pays so many dividends for a relatively small time investment.  It’s tough when you’ve just finished a project and no one feels like having another meeting to talk about what went right and what went wrong. We can ease the burden on our project team members and stakeholders by gathering project closeout data, and particularly lessons learned information, during the life of the project.  Lessons Learned Main Page

Project Closeout Critical Elements

Proper project closeout has a couple of very critical elements. One is the lessons learned documentation. That write-up will help future project managers with similar types of projects. It saves their project from being surprised by the risks or problems that the project you just finished encountered. The other critical element is to archive the project data. What’s included in that is all of the management plans, the hours worked on every task and the costs spent on every task. This second step is the difference between organizations who can accurately estimate the cost of projects and those organizations who are limited to guessing. When there is archive data on your project’s duration and cost, you  can do analogous estimating on future projects, major deliverables or individual tasks which are similar. Successful project organizations require that the archive data be carefully indexed so future project managers can easily find it.

More often than not, project managers are so occupied with getting the project started and then getting things done, that they totally forget about project closeout. Let’s take a standard IT implementation as an example: you initiate the project,  get all the coding done and even let the users test the application. project closeoutOn the Go-Live date, the code gets promoted into production and this is when the problems start. Someone forgot to set a flag, enter a variable, or forgot that one important step. As result, you spent days, if not weeks after go-live to fix problems that should not have occurred to begin with. What I want to suggest today, is a way of planning for the end. The end of your project that is.

Project Closeout Example

I’ll use one of my last projects as an example of project closeout. Our task was to migrate a specific product group from an older system into a newer system. The project included test cycles that featured full migration cycles, including all downstream systems, accounting, and payments. When we started with the test cycles, I began developing a check-list. You heard right, a good old check-list. At first it was just a loose collection of tasks, but as we progressed, the list of tasks became a structured document. At one point, I asked the participants to use this check-list for our test migrations and note down how much time it actually took them to complete their tasks. Doing so converted the check-list into a pre-project plan, because now I knew how much time to plan for each task. From that point on, I used the check-list not only as a check of completion, but also as a base line for task duration. At one point, I even added the parameters used for each executable and report that we had to run on migration weekend. From that we derived quality metrics that allowed us to measure success free of emotional distractions. Over time, that check-list evolved into a Go-Live script. Even more, because the script was rather detailed, it was possible for a third party to take over a task if the main person was sick or otherwise occupied.

The beauty of this exercise became clear to me when we started the actual Go-Live planning with our users. During our tests, we had developed the Go-Live script already so we knew how much time we needed, we knew what to do, and we knew what to expect. The planning session, therefore, was not so much about who had to do what, but it was about staff scheduling and making sure that we didn’t forget anything. Originally, we didn’t know if it was possible for us to perform the full migration in one day because our Head Office in Germany had to perform some tasks too. But with our script already tested multiple times, everyone was very confident that we could do it.

Then came the Go-Live weekend, and we simply executed our script, and everything went as planned. Except one thing: We did our tests against test systems, which performed significantly slower than the actual live system that was used for the migration. As a result, we finished way earlier than expected. When was the last time that finishing earlier was the only problem that occurred on Go-Live?

Project Closeout Summary

So what did I learn? A lot. First of all, there is nothing wrong with check-lists. Second, as the project manager, you must you have the big picture in mind. You should start planning for the project closeout earlier than anybody else. I want to challenge you to do so. Start planning for the finish line when everybody else is still running.

Until next time.

Powered by WordPress. Designed by WooThemes

Bitnami