Closing a Project
In a rush to get projects done, one of the most often overlooked, but critical, tasks of a project manager (PM) is conducting the project close-out step. The project close-out, closing, closure, termination or finish phase is the fourth and last phase in the project life cycle. In this phase, we formally close our project, and evaluate and report its overall performance.
Once the project product(s) has been produced and accepted by our sponsor and customer, our PM responsibilities continue to ensure that the project is properly closed down. A stakeholder acceptance meeting, as the name implies, is when our project team meets with other key stakeholders to review the project product and ensure that it is acceptable.
But sometimes projects take on a never-ending characteristic. They go into limbo land and are never allowed to close often because stakeholders keep coming up with bolt-on extras and change requests, whereas properly closing our project has several benefits:
- Ensures we deliver what we promised.
- Provides us with the opportunity to consolidate what we learned.
- Allows us to recognise our team members for the work they have done.
- Releases team members for other work opportunities.
Project closure is sometimes poorly done and is best treated as a “project within the project” when we identify, schedule and complete everything needed to properly close the project, which might involve all or any of the following activities, but not necessarily in this order:
- Finalise any contractual commitments.
- Measure customer satisfaction.
- Prepare and distribute letters of thanks.
- Debrief project team members.
- Complete team member performance reviews.
- Make final payments once contracted work has been properly completed.
- Reconcile paid and outstanding invoices.
- Close account to prevent additional costs being attributed to the project.
- Ensure lessons learned are disseminated to interested parties.
- Reassign people to their functional areas or new projects.
- Release resources so these can be disposed of or used for other work.
- Complete the final financial accounting for the project.
- Document the results of the project and make recommendations for the future.
- Decide distribution of project documentation.
- Hold a closedown meeting and make closeout assignments.
- Agree post-project review requirements with the sponsor and business.
- Terminate reporting arrangements.
- Close risk and issues logs.
- Identify any issues for further study and follow-on work.
- Arrange customer/end-user training/user manuals.
- Finalise delivery instructions.
- Audit final changes.
- Complete our PM diary or journal.
- Obtain client acceptance of project work.
- Advise client of any risks that may affect the achievement of benefits.
- Tidy the worksite and return stores.
- Ensure all deliverables have been installed or properly implemented.
- Integrate deliverables into business-as-usual.
- Initiate retention, warranty and defect notification periods.
- Conduct project evaluation.
- Confirm transition and benefits realisation plan and reviews.
- Update lessons learned database.
- Update estimating methods and estimating data base.
- Collect all debts.
- Close all project sites and project office.
- Arrange photographs for records and publicity.
- Prepare maintenance manuals and as-built drawings.
- Update asset register.
- Photograph deliverables.
- Complete test certificates.
- Prepare spares lists.
- Arrange repair and maintenance contracts for product.
- Dispose of waste material.
- Close and audit project accounts.
- Index and archive records.
- Celebrate – gifts, certificates, party, dinner.
The essential order for project closure is obtain formal acceptance, close contracts, evaluate project performance, identify lessons learned, and then release the team. One important activity during closure is to evaluate project performance, as no learning takes place without feedback. Such reflection is something we don’t always allow ourselves to experience because we are often too busy getting on with the next task. And who wants to relive the mistakes of the past? We do, because taking a closer look at the problems we faced on our project might help our next one go better, although often we neglect to formalise the lessons learned identification and recording process. Lessons learned are best posted at the time of their occurrence, and common mistakes are:
- There is no lessons learned log or a perception that it’s optional.
- No one is assigned the responsibility to maintain the log.
- The log is used to chastise people.
- Lessons learned means admitting our less than perfect performance.
- We’re unwilling to expose project members to criticism.
- We assume that lessons learned have already been learned.
- We haven’t documented lessons as we progressed through the project lifecycle.
- We’ve already moved on to other more pressing endeavours.
- Lessons learned are personal and not relevant to others in our organisation.
The purpose of lessons learned is to bring together any insights gained during a project that can be usefully applied on future projects. However, without learning lessons, our next project may repeat the same mistakes. Problem areas worth capturing on projects, detailing what worked well and where improvement is needed may include:
- Requirements management.
- Scope management.
- Schedule development and management.
- Cost estimating and budget control.
- Quality planning and management.
- Resource procurement and allocation.
- Leadership and team performance.
- Problem solving and issue resolution.
- Stakeholder identification and engagement.
- Status reporting.
- Risk identification and management.
- PM processes.
- Variation management.
- Change management.
- Benefit realisation management.
A project Lesson Learned Log or Register is a document that aims to identify and record learnings from our project. To be useful the log needs to be readily available in electronic or printed format and entries should be completed at the time when memories are fresh.
Typical Lessons Learned Log Format
|Lesson Number||Registered||Lesson||Recommended Action|
The project evaluation and lessons learned session might take the following form:
- Evaluate the business case. Did the project create or is it creating the business benefits that were used to justify the project. This question is less about how well the project team did and is more focused on the project selection and approval process. The lessons learned at this point aim to improve the ability of the organisation to select projects and develop realistic business cases.
- Evaluate the project plan. This question addresses how well the PM and project team planned the project. It concerns topics like the identification of tasks, cost and schedule estimates, risk factors, and team integration and communication.
- Evaluate the PM methodology. Was our organisation’s PM methodology useful for the project or not. Were procedures effective and efficient? Were checklists and templates current and useful? Were the audits and reviews appropriate?
- Evaluate team and individual performances. The team then considers how well they executed the plan and followed the methodology. This is normally a self-assessment by the team and can be aided with techniques such as 360 reviews. The method for conducting individual performance appraisals would be accomplished in accordance with our organisation’s HR practices.
The PM and team should attend the close-out meeting. In some situations, it can be advantageous to have an outside facilitator lead the meeting to help ensure that the discussions are objective and that everyone’s input is captured. The facilitator of the meeting introduces the session and explains its purpose. A series of open-ended questions such as these ensure that the discussion is focused:
- What were the major project successes?
- What were the major challenges?
- What could have been done to have increased the successes and decreased the number of difficulties on the project?
- Can this information be passed to other projects? If so, what would they be?
- What were the actual project deliverables versus the original plan?
- How close to the schedule was the project actually completed?
- What was learned about scheduling that will help future projects?
- What was learned about the scheduling of activities and tasks?
- What unanticipated project benefits were derived?
- What was learned about the scheduling of resources that will help future projects?
- How close to budget was the final project cost?
- How useful and accurate were the estimating tools that were used?
- What did the project team learn about budgeting that will help them on future projects?
- Were the right people included in the project team?
- Were the team roles and responsibilities clear?
- To what extent did the stakeholder positively or negatively affect the project?
- Upon completion, did the project output meet the stakeholder’s requirements without additional work?
- If additional work was required, why was it necessary?
- How was change managed through the project?
- What risks occurred on the project that weren’t anticipated?
- What could have been done to anticipate these risks?
- What was learned about risk management that will help future projects?
- To what extent did you manage the project by following the established quality criteria.
Typically a report is prepared by the PM at the conclusion of the project, possibly based on PMBOK Knowledge Areas or the six Ps format. Not “Proper Preparation Prevents Piss Poor Performance”, which of course is true, but in this instance six Ps mean we assess project performance from the following six perspectives:
- Purpose. Did the project realise its purpose; its rationale for being undertaken? What business case benefits have been realised or are still to manifest?
- Parameters. How did the project perform in terms of its goal, scope, time, quality, cost, risk and whatever other parameters or objectives were relevant? Were time and cost estimates accurate? Was there scope creep or an excessive number of variations?
- Participants. Were stakeholders (including project team members) effectively engaged, how did they perform and were their needs satisfied? What level of satisfaction or dis-satisfaction (accomplishment, enjoyment, pleasure, anger, conflict, frustration) exists for each of the key project stakeholders?
- Processes. How effective and efficient were the processes used during the project? Such processes may include those for communication, estimating, project approval, outsourcing, scheduling, team building, conflict resolution, meetings, problem solving, decision-making, negotiation, reviews, risk and issues management, variations, monitoring and control, managing change and realising benefits.
- Products. Were the final products satisfactory in terms of design, performance, functionality and uptake? Is their use generating the anticipated benefits? How well are the products meeting the functional and business objectives that were used to establish the business case? How well do the products achieve their Key Performance Indicators (KPIs)?
- Politics. Project success is directly linked to the ability of PMs to understand the importance of organisational politics and how to make this work for the success of the project. Office politics are part of organisation life and PMs are political beings by virtue of their position. What impact did good and bad politics have on the project?
Project reports culminate in conclusions that may be followed by recommendations. If so, this section of our report is probably the most useful part where we make suggestions based on our report’s conclusions. Recommendations in project reports tend to be less tentative than those of academic reports. For example, a vague recommendation such as “Perhaps the procedure for recording variations should be updated in due course” will not be as effective as a more action-oriented and SMART recommendation that might read “The project sponsor is to update and publish the procedure for recording variations by 1 June.”
Recommendations must flow logically from our report’s conclusions and it’s usually helpful to involve others in their identification. Also, our recommendations should be capable of implementation, match any terms of reference, be prioritised since they require resources to implement, and be consistent with our organisation’s purpose, goals, core values and desired culture. Our recommendations may spawn further projects.
|Executive Summary||Provides a quickly read version of the report – purpose, main findings, main conclusions and key recommendations. One or two pages only. Call it an Executive Summary, Precis, Abstract, Synopsis or Epitome if you like. It’s sure to be read. It’s written last.
|Introduction||Secures the reader’s attention. Orientates the reader, describes context, project rationale, background, and/or origin.|
|Purpose||To assess project performance and recommend improvements to project management processes and practices.
|Evaluation Methodology||Explain briefly how you tackled the evaluation process, method of research, scope of the report, sources of information, assumptions, and limitations if appropriate.
|Explain briefly and clearly what the report aims to achieve – presumably to evaluate our project.
|Project Success in terms of Project Parameters
|Effectiveness and Efficiency of Management Processes
|Stakeholder Engagement and
· Project Team
|Sometimes there are issues about our current PM practices and processes to be resolved after project finish. Also, there may be outstanding issues concerning product training, use and maintenance.|
|Users always need support. We could have a bulletproof product, excellent training and documentation, but someone will find a way to break it or just not read the information provided.
|Conclusions and Lessons Learned
|These are the result of the evaluation and follow logically from the above analysis. Lessons learned should be unbiased and clearly stated. There is usually no discussion in this section nor is there new information.
|Recommended follow-up actions and suggested changes to methodology, policy, practices, processes and procedures. Recommendations follow logically from conclusions. They are capable of implementation, action-oriented, and look to the future. They may be goals. They may result in new projects.
We send the report to the sponsor and finally all project information is held for future reference. Sometimes the client, for reasons of intellectual property or security, might want records returned to them, including digital files. At project completion, project files may include items such as:
- Project business case and project charter.
- Product requirements, specifications and photographs.
- PM plans and procurement documents.
- Contracts with external organisations.
- Project audit reports, status reports, timesheets and project reports.
- Stakeholder registers.
- Logs for lessons learned, risk, issues, changes, and health and safety incidents.
- Photographs and key correspondence.
- Meeting agendas and action plans.
- Handover documentation.
Project closure can be a time of mixed feelings for our project team. Hopefully they will feel satisfied about the job, but we need to ensure they aren’t:
- Worried about what the future will hold for them.
- So eager to get on with the next project that things go unfinished.
- Elongating project life because they don’t want to leave.
The exit strategy for the project staff must be clear so that they feel adequately supported whether they are going on to new projects, returning to routine jobs or leaving the organisation.
A post-project team celebration recognises the contribution of project team members and those who have supported the team’s efforts, boosts morale and contributes to a motivated staff who will be keen to tackle future projects.
After product handover the productive life of the project product begins. This is when product owners and users realise the benefits of the investment, providing the business is prepared to accept and adapt to the changes involved. Thus, the extended project life also includes a benefits realisation phase that follows project closure when the project product is used.