The very definition of a projects mentions its temporary nature with a defined end. Thus the project close is a critical – if often overlooked – part of the project.
By the time of the project close, the project product should have already been turned over to a support organization and “operationalized”. There should be technical support documentation, assigned technical support and defined service management processes (including a service agreement). The project product should be included in any operational maintenance, backup, DR, and/or regulatory compliance plans. Any unresolved project issues need to be acknowledged and signed off by the new owner.
The project manager or IT managers involved in the project should solicit and/or produce some artifact of project acceptance. Many methodologies include a formal gateway artifact and a formal meeting, but even an email from the project customer/sponsor may suffice. There just needs to be some written indication that the project has met its scope.
The IT manager will likely want to commence with tidying up and closing any project accounts created by accounting/finance for classifying project expenditures. The IT manager may not want to actually close the account until after all the charges come trickling in; however, they might want to limit the number of expense approvers and scrutinize new charges to ensure that no one is subconsciously (or consciously) trying the milk the project budget before it goes away.
For formal project managers, probably the most important part of the project close is the “lessons learned”. Mentioned 55 times in the PMBOK Guide (4th Ed), PMI defines lessons learned as follows.
…the learning gained from the process of performing the project… such as the causes of variances, the reasoning behind the corrective action chosen, and the other types of lessons learned from quality control are documented so they become part of the historical database for both the project and the performing organization. Lessons learned are documented throughout the project life cycle, but at a minimum, during project closure.
Then there is the lessons learned knowledge base, which is “a store of historical information and lessons learned about the outcomes of previous project selection decisions and previous project performance”. Whether a formal knowledge base exists or not, the IT manager or PM tie up loose ends and archive the project documentation.
If the project has a formal PM, this is the best time for the IT manager to get performance input as to how their resources contributed to the project team.
PMI also infers there is an actual lessons learned meeting where the lessons are discussed and acknowledged. Manager Tools refers to this as a “Hot Wash“. This is an occasion for the PM, team and sponsor to consider the individual successes and failures; i.e., what worked well and what should be modified to make it work better in the future. In more formal project organizations, here is where the PM can document potential changes to the methodology they can take back to the PMO.
The concept of a lessons learned meeting is indeed valuable. Unfortunately most project teams have disbanded and moved on to the next number one priority well before such a review is even scheduled. If there is any project budget left, bribing meeting attendees with pizza or beer can stimulate interest… although the event can easily degenerate into a project celebration, especially in the latter case.