Project closing

Many practitioners overlook the project closing process group. To them, successful project delivery is defined by the completion of deliverables as per the objectives of time and cost. They consider project closing as overburden, work that is done to satisfy organizational requirements, and in many cases of little significance, if any.

Little do these practitioners know that the Project Closing Process Group is as impactful and significant as the Initiation, Planning, Executing, and Monitoring and Controlling Process Groups. As further explained in this paper, the impact of project closing can be extensive, both to the project and to the organization. Failure to conduct thorough project close out could potentially (a) put the organization at a considerable amount of risk, (b) prevent the organization from realizing the anticipated benefits from the deliverables of the project, (c) result in significant losses to the organization, and (d) undermine the project manager and project management team's credibility.

What is Project Closing?

According to A Guide To The Project Management Body of Knowledge (PMBOK^® Guide) – Fifth Edition, “The Project Closing Process Group consists of those processes performed to conclude all activities across all Project Management Process Groups to formally complete the project, phase, or contractual obligations. This process group, when completed, verifies that the defined processes are completed within all of the Process Groups to close the project of phase, as appropriate, and formally establishes that the project or project phase is complete” (2013, p. 57).

In other words, Project Closing is the combination of the following when applied to a project:

1. Assurance that all the work has been completed,
2. Assurance that all agreed upon project management processes have been executed, and
3. Formal recognition of the completion of a project—everyone agrees that it is completed.

At first, the three points above may seem like “de-facto” or natural by-products of the last phase of a project; however, Exhibit 1 demonstrates how the above may be overlooked on even the simplest of projects and Exhibit 2 outlines the impact of such oversight:

Exhibit 1. Examples of project closing oversight.

Exhibit 2. Impact of project closing oversight

Project closing is further explained in depth throughout this paper. A comprehensive project closing process would typically include all of the following processes, and may include others, depending on the size, magnitude, complexity, and impact of the project:

4.   Making sure all the work that needed to be has been done.

5.   Obtaining approval by the project's sponsor and customer (whether internal or external) for the work completed.

6.   Reviewing whether or not all organizational governance processes have been executed.

7.   Assessing whether or not the necessary project management processes have been applied.

8.   Administrative closing of any and all procurements, reviewing that all work on the contract has been completed and that both parties have completed their contractual obligations toward each other.

9.   Formally recognizing the completion of a project and its transition to operations.

10. Validating that the project achieved benefits identified in the business case.

11. Capturing of lessons learned: What was done well, and should be documented so it can be repeated in the future? What could have been done better? And if so, how can it have been done better?

12. Disbanding project resources, freeing them to perform other projects and undertake other tasks as required within the organization.

13. Transitioning project deliverables to the customer organization in a manner that warrants seamless operations and support.

Why Is Project Closing Important?

Just as any of the other project management processes (Initiation, Planning, Execution, Monitoring and Controlling), Project Closing serves an important purpose for the organization and helps it avoid unfavorable and adverse scenarios.

What damage can happen to the time, effort, and credibility of the project management team?

If a project is not closed properly, the project management team and the project team's efforts, time, and credibility may be negatively perceived for matters that are not their fault or responsibility. Below are some examples of when such incidents may occur, and how they can easily be avoided.

The Never Ending Project

Many organizations have undertaken projects that, despite fulfilling all of their scope and quality obligations, have continued to be perceived by the rest of the organization as projects. In this scenario, the organization does not distinguish between responsibility for maintaining and operating the deliverables of the project by other departments, but rather continues to hold the project management team accountable for such activities.

As a result, those who have the necessary skills, tools, means, and capability to “operate and maintain” a project deliverable are not tasked to do so, and instead, those who do not have such skill, tools, means, and capability (the project management team) are required to operate and maintain the deliverable. This is not an understatement or dilution of the skillset of a project management team. The project team typically has the skills, tools, means, and capability to “develop” the project deliverables, but not necessarily maintain and operated those deliverables. Therefore, the project team performs a great job in the former and fails to deliver on the latter.

To further clarify this scenario, consider that you have purchased a new computer; however, the staff at the store or at the manufacturer's call center is incapable of supporting your requests. They transfer your request to the team that developed the computer. Although they have the capability of designing and producing cutting-edge hardware, they do not have the capability of troubleshooting specific software drivers.

A by-product of this scenario is that resources that were required to manage the project would be consumed in post-launch activities, limiting their availability and capability to manage new projects, and hence limiting the capacity of the organization to meet its strategic objectives.

The Orphan Product

Another result of inadequate project closure is the lack of a proper hand over or transition of the project deliverables to business as usual (or operations). When a deliverable is produced, the parties involved with operating and maintaining that product need to receive the appropriate training, awareness, and tools to do their job effectively and efficiently. They also need to understand—and commit—to their new responsibility. The number of organizations that fail to conduct this process adequately, comprehensively, and in a timely manner, is alarming.

To further understand this example, consider how many companies in the past have produced outstanding products only to find themselves facing their demise due to their inability to provide adequate after-sales services and or support for their products? Imagine buying a new computer that works perfectly, only to not find anyone capable of fixing it when it breaks down?

How project closing can lead to exponential value through lessons learned

Because projects are progressively elaborated, project management teams are not exposed to the whole project until it is completed. The uniqueness of the experience presents the project team with plenty of knowledge, that, if not recorded may be lost by both the team and the organization. Recording lessons learned—a key component of project closing—allows the organization to record, maintain, and reuse lessons learned for future projects.

Some organizations have repetitive projects. For instance, projects that are undertaken once a year for maintenance or compliance purposes, or projects that are very similar to one another, as in the case of a company that builds websites or houses for sale. By having a recurrent lessons-learned process, these organizations will be able to capture and learn from their experience and create more effective and efficient project management processes, which ultimately reduces the time and cost to develop their products.

How project closing can support my project management career

Just as any professional, a project manager needs to (1) establish consensus that their work is effective and complete, (2) avoid unfavorable situations for the organization, and (3) learn from their experiences. All three can be achieved through comprehensive project closing. A project manager who fails to conduct thorough project closing can leave the organization liable for compliance, or liable to a third party for payment, or even portray an image of incompetence because the project seems never to end. One other important achievement for project managers through comprehensive project closing is the assurance of complete and adequate transition of the project's deliverables to business as usual (operations).

What liability can poor closing create to the organization?

As mentioned above, a project that is not properly closed can leave the organization liable to external parties for incomplete payments on contracts, liable to customers for incomplete scope, or liable to regulators for incompliant practices and/or products.

When is it time to draw the line?

Many practitioners conduct project closing at the end of a project, some many times during the life of a project, and others never at all. Before answering the question of when to draw the line, the practitioner must first understand the value that the process will create. This paper addresses such value in multiple sections.

Project closing must definitely occur at the end of the project, and, best practice has it that closing needs to occur at every phase in the project life cycle. Phase definition may be logical, preferential, or even hypothetical. When devising project phases, three factors need to be taken into consideration:

Inherent Industry Best Practice

For instance, a construction project may be undertaken following the industry best practice of engineering, procurement, and construction (EPC), or a software development project may follow the phases of requirements gathering, design, development, testing, implementation, and deployment. The use of industry best practice to define and dissect a project into phases may prove extremely useful; however, depending on the magnitude and complexity of the project, industry-based phases may be combined with other methods to maximize impact.

Organizational Governance and/or Policy

Most organizations that have developed and deployed mature organizational project management methodology (OPM) mandate that projects be divided into phases. Typically each organization will have its unique set of phases. For the sake of simplicity, one example of such phase breakdown could be as follows: business case development, planning, procurement, implementation, hand over to business as usual, and closing. When managing projects within the organization, practitioners are obliged to follow such phasing. Depending on the magnitude and complexity of the project, such phasing may be combined with any of the other two techniques as described later in this section.

Maximization of Control and/or Benefit

By building phases into a project, the project manager and project management team are automatically instilling a higher degree of control in comparison to a scenario where a project is managed without phases. Practitioners often define phases to a project based on the degree of control they would like to instil. For instance, after the completion of major deliverables or milestones, or after the work of a certain resource group or type has been completed. Similarly, phases may be drawn before the start of work on a certain deliverable, or work by a certain resource group, or work on certain deliverables that will or may have significant impact on the project and/or organization.

Combining Techniques in Phase Definition

Project managers may choose to combine one or more of the above phases; for example, creating an overall business case for the project with a subset business case for engineering, another one for procurement, and another one for construction on an EPC project. The number of possibilities is endless, and no one document or paper can capture all such possibilities.

Exhibit 3 is an example of how a university's website project may be structured, dividing it into phases and sub-phases in order to maximize control over and benefit from the project. The phases can be clearly attributed to industry best practices as well as what may be the preference of the organization and/or the project management team:

Exhibit 3. Multi-Phase projects.

Phase-gate reviews

The purpose of dividing a project into phases is to be able to have phase-gate reviews. They are also widely known as stage-gates, kill-points, phase-reviews, hand offs, and transition-points to name just a few of multiple widely used conventions. Regardless of the choice of name, phase-gate reviews occur at the end of each phase and their main purpose is simply to review how the elapsed phase was performed, and take an informed decision whether or not to proceed to the next phase, and if so, why and how.

Project closing needs to be conducted at each and every phase-gate of a project. The closing process at a specific phase would help the project management team do the following:

1. Ensure all the required work in the elapsed phase has been done, and address deficiencies as applicable.
2. Obtain approval by the project's sponsor and customer (whether internal or external) for the work completed; therefore, eliminating any debate or scepticism, and addressing any future changes to the work performed. As such any changes would be managed as change requests or new projects, depending on their nature. This seemingly insignificant process is of great importance in the avoidance of scope creep.
3. Review whether or not all organizational governance processes have been executed: Have we obtained all the necessary approvals? Are all the appropriate policies implemented? Have we complied with all organizational procedures? The team can take corrective action as necessary should deficiencies be identified, as well as use findings to guide future phases of the project.
4. Help the project team address, in retrospect, whether or not the necessary project management processes have been applied. This applies in the horizontal as well as vertical contexts. The difference between the two is the following: a typical horizontal verification includes checking that all the necessary processes were included, for instance, has the team conducted risk analysis or not? While vertical verification tests whether the said processes were implemented to sufficient extent, for instance, has our risk analysis been thorough enough? Do we need to do more? Or maybe less? The results of this exercise guide the future phases of the project.
5. Conduct administrative closure of any and all procurements in that specific phase. Assuming an external party was contracted to develop or contribute to the design of a specific product, the phase-gate review is an opportunity for the project team to work with that contractor on closing out the contract by:
   1. Reviewing that all work on the contract has been completed—and taking corrective actions as applicable.
   2. Reviewing that both parties have completed their contractual obligations toward each other, and if not, fulfilling all such obligations.
   3. Obtaining approval that the work of the contractor has been accepted, and like point 1 above, eliminating any future objections that can leave the contractor or the project team liable.
   4. Ensure that all payments have been made, and all products/services received, and avoid unnecessary delays or missing requirements.
6. Conduct formal recognition of the completion of a phase. As a result of all the activities above, all stakeholders will recognize, formally, that a phase has been completed. The project team is able to establish such consensus and hold the deliverables of the elapsed phase as part of the scope baseline. For better clarity, and using the example of a “design phase,” the project team will be in a position to formally recognize the completion of the design, and base all future phases on that formally recognized completed design.
7. Many projects continue to progress for months if not years expending organizational resources and efforts only to end up with a result that is different from what was projected in the initial business case. The project management team can avoid such failure by ensuring that the project is still in alignment with the organization's strategic objectives. This can be achieved through the periodic validation of the project and its business case, during a phase-gate review. Project teams conduct this validation exercise on two levels:
   1. Validate that the benefits identified in the business case are still valid—in other words, is the project justification, as identified in the business case, still valid? For instance, if a project is expected to put the organization ahead of its competition, it will still do that and market forces or customer aspirations haven't changed. Or, if a project will allow the organization to launch a new product that is expected to yield certain revenues, the product is still in demand and expected revenues are still sound. This is done at the business case level and should include the same stakeholders who were involved in the formulation and approval of the business case. The findings of this exercise may lead to any of the following three outcomes:
      1. Termination of the project: the business case is no longer relevant
      2. Proceeding with the project as is: the business case is still valid as it was originally planned.
      3. Modifying the business case to better align with market conditions or external factors, and hence modifying the project
   2. If the business case is still valid, the next priority for the project team should be the validation that the project will still meet the business case. Projects are progressively elaborated, meaning that very little is known about the project at its onset and that stakeholders (including the project team) become more aware of the project as it progresses. Given this important characteristic of projects, the completion of a certain phase will only render all stakeholders better informed of the project, and whether it will indeed meet the objectives outlined in the business case. The results of this validation exercise will lead to one of the following decisions:
      1. Proceeding with the project as is—it is in-line with the business case's requirements and will deliver those requirements as opposed to any other project that could be undertaken for the same purpose
      2. Modifying the project scope, duration, or other attributes to better meet the requirements of the business case
      3. Terminating the project as it does not meet the business case's requirements and is not expected to yield the required results.
8. Validate all the assumptions and constraints that planning was based on. It is of great importance to the project team to understand whether their assumptions (elements of uncertainty that were considered to be true for the purpose of planning) are still valid or not, as well as to understand whether certain constraints (elements of uncertainty that were considered to be true in limiting the project management team's options for the purpose of planning) are still applicable. Assumptions and constraints are essential to every plan, and because they define the boundaries of the plan, it is important to periodically validate them. Project teams are often intertwined and mired in the details of their projects, and hence, stopping to validate assumptions and constraints can easily be overlooked, though unintentionally. The phase-gate review presents an opportunity for such validation. Consideration needs to be given to the importance of validating assumptions, as a project team proceeding on the basis of an assumption that is invalid may easily derail the project should that assumption become erroneous, exposing the project to undesirable—if not detrimental—risk. Similarly, a project management team's options may be incorrectly limited should the team assume certain constraints are true, and hence not be able to plan the project to its fullest extent unnecessarily.
9. Capture lessons learned is another activity of great value to an organization that is conducted as part of project closing, and the benefit of which is maximized if also conducted during project phase-gate reviews. Capturing lessons learned is a very simple exercise, and requires the project team to answer two questions:
   1. What was done well, and should be documented so it can be repeated in the future?
   2. What could have been done better? And if so, how could it have been done better?

   Lessons-learned capturing is often excluded on the premise that it is an administrative burden of little value. The truth is that through capturing lessons learned, knowledge is documented and is an addition to the organization's wealth and assets, as it helps the organization achieve all of the following:

   1. Avoid repetition of mistakes.
   2. Reduce learning curves on future and/or new work or projects.
   3. Provide a wealth of best practices that can save time, cost, and effort on future projects and/or work, and thereby allow the organization to deliver projects in shorter durations, and in a more cost-effective manner.
10. Influence the management of the next phase. Once all the processes above are completed, the project management team will be in a position to comprehensively review its plans for the next phase, or phases of the project. This is equivalent to getting a second chance at planning the remaining portions of the project. In effect, the project team will be able to conduct all of the following in the coming phase(s):
    1. Better align the project to its business case.
    2. Baseline the deliverables of the previous phase and plan future work accordingly.
    3. Obtain acceptance of work done in the previous phase, and eliminate scope creep and reduce future dissatisfaction and requests.
    4. Comply with organizational procedures and requirements.
    5. Verify that all contractors have completed all of their obligations to the project, and that the organization has completed all of its obligations to the contractor.
    6. Refine the plan for the coming phase knowing what worked and enhancing/avoiding what did not.

All of the above addressed the necessity of conducting project closing at the end of each project phase. The next section explains why formal project closing is important at the end of a project.

How can I close the project in the best manner possible?

The section above describes a thorough project closing process. Below is a guideline that project managers could use to close their projects comprehensively:

1. Ensure those operations and any and all other departments/units/parties who will use the product(s) of the project have the necessary training, tools, documentation, and capability to perform their role.
2. Ensure that the project has satisfied the strategic goal(s) for which it was undertaken.
3. Ensure that the whole scope of work has been completed, and make sure to receive formal documented acceptance from the client and sponsor.
4. Review all contracts with the project team and suppliers. Make sure that all parties have satisfied their contractual obligations—that the suppliers have delivered all of the products or services required of them and that the organization has made all pertinent payments. Release bonds if necessary, and make sure the supplier provides all supplementary deliverables, which may include, but may not be limited to product documentation, drawings, warranties, service contracts, lien waivers, and so forth.
5. Review project management practices.
6. Document lessons learned for future reference.
7. Disband the project team and officially return resources to their functional locations.