Project Closing PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

Certifications Membership Learning & Events 


PMBOK® Guide & Standards Business Solutions Store About More 
 Register Log In
 

Project closing
the small process group with big impact
Search


CONFERENCE PAPER ǀ Project Integration Management, Using PMI Standards ǀ 10 October 2015 What are yo
Aziz, Emad E.

How to cite this article:


Aziz, E. E. (2015). Project closing: the small process group with big impact. Paper
presented at PMI® Global Congress 2015—EMEA, London, England.
Newtown Square, PA: Project Management Institute.

Emad E. Aziz, PgMP, PMP

BRISK Business Inc.

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

Certifications Membership
completed.
Learning & Events PMBOK® Guide & Standards  Business Solutions Store About More 
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

Certifications Membership Learning & Events PMBOK® Guide & Standards
work on the contract has been completed and that both parties have
 Business Solutions Store About More 
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

Certifications Membership Learning & Events 
PMBOK® Guide & Standards
of designing and producing cutting-edge hardware, they do not have the
Business Solutions Store About More 
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

Certifications Membership Learning & Events PMBOK® Guide & Standards
comprehensive project closing is the assurance of complete and adequate
 Business Solutions Store About More 
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

Certifications Membership Learning & Events PMBOK® Guide & Standards
of work on a certain deliverable, or work by a certain resource group, or
 Business Solutions Store About More 
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

Certifications Membership
analysis or not? While vertical verification 
Learning & Events
tests whether the said processes 
PMBOK® Guide & Standards Business Solutions Store About More 
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

Certifications Membership
requirements and will deliver those 
Learning & Events
requirements as opposed to any 
PMBOK® Guide & Standards Business Solutions Store About More 
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.

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

Certifications Membership
project, and that
Learning & Events PMBOK® Guide & Standards
the organization has completed 
all of its obligations to the
Business Solutions Store About More 
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.

Project Management Institute. (2013). A Guide to the Project Management


Body of Knowledge (PMBOKྞ ྠ Guide) – Fifth edition. Newtown Square,

PA: Author.
This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI or any listed author.
© 2015, Emad E. Aziz, PgMP, PMP
Originally published as a part of the 2015 PMI Global Congress
Proceedings – Orlando, Florida, USA

© 2020 Project Management Institute, Inc. USA

You might also like