As we were going through a pm brown bag, one of my colleagues was explaining her frustrations, "We just quit project here, and then leave it up to others to support it." After a little investigation, I found that this was simply true. A chaotic intake process often leads to a chaotic close process. Closing the project down had been relegated to quitting and jumping to another screaming priority. For the IT department, just to keep the operations running took about 80% of the staff time. Technical Debt was overwhelming, continuous process improvement did not exist, and the department was sliding downhill. Quitting Projects helps to incur astronomical portions of technical debt, but given poor prioritization it is a nasty habit to break. So let's walk through how to stop quitting projects and start closing projects.
Explain the need for a time to close - Quite simply take a moment of time and don't switch priorities. For the executive who is requiring the priority change, manage the expectations. Find out the need for the urgency change, assure they are aware of the impacts and how long it will take to shift gears. Include in the shifting of gears the need to close the project with knowledge capture.
Plan for the operational support transition - As individuals start adopting a project management mentality, they have the live event as the end of the project. This is simply not true, one should plan for an operational support transition. There will need to be planned activities throughout the project including documentation, training operational support and oncall staff, creation of help desk scripts, etc. It is wise to include these activities in the project schedule.
Continuously take lessons learned throughout the project - Lessons Learned should not start at the end of the project. A lessons learned log through out a project can be invaluable. Make a point to at least monthly capture lessons learned and incorporate the improvements. When you are in a fast close, having this information available is priceless.
Have an established process to decommission equipment - Re-inventing the wheel each time, is just not really productive. The same is true with your decommission of equipment. The equipment needs to be shutdown, wait a bit, have a final archive, destroy pertinent data, moved to a secured location, the lease closed, and then removed from campus. This cross collaboration includes several departments, and should be a known policy and procedure.
Have a resource release process - The release of resources should be established when the resources are brought onto the project. This process should have the operational manager and project manager aware and in agreement for releasing a resource. In other words, the process need to have a little pain to be worth the squeeze.
Establish Project Cancellation Criteria and Process in the charter - if you are about to quit a project, there is a good chance this is a cancellation. Have clearly defined cancellation criteria in the project charter, and assure the sponsor is aware and understands this process. If the project needs to undergo cancellation, walk the established process according to what was agreed in the charter.
Running from priority to priority has you mimicing a chicken without its head. Using your head and figuring out a way to close project will not only help portray your leadership skills, but also reduce the amount of technical debt your organization incurs. As always, we welcome your suggestions and comments based upon your experiences.
If you enjoed this post you may what to check out these further readings on Taming Chaotic Project Management: