Project Closeout Critical Elements
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. On 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.