Abstract
In this paper, we will try to propose and demonstrate operationally an alternative process for closing projects. The aim is not to define the reasons for closing or not closing a project; rather, we will do an overview of some generic closure triggers and establish a framework for coping with these triggers, in order to increase project closing efficiency, secure resource spending, and ensure acceptance.
As such, our journey will take us through Project Risk Management, Project Planning, and Resource Management. The Modular Risk-Based Closure (MRBC) resides on foundations put in place by the Project Driven Strategic Chain® (Lazar, 2007) and The MAP Method (CIMAP, 2002) initiated by the work of RP Declercke at Lille Graduate School of Management’s Research Center on Project Management. This method is used for the Systemic Approach part, which allows us to integrate the different components of our MRBC into a smooth and “agile” (to borrow this very trendy word) set of processes.
The Modular Risk-Based Closure process lies in the full integration of project closing activities into the project’s Risk Management processes and defines the closure as being a regular and simple risk response work-package, activated in the case of a risk or opportunity occurrence; in this paper we will consider risk involving the termination of the project, and as an opportunity occurrence, we will consider the successful completion of the project’s objectives. In both cases, we’ll use the same set of activities and resources planned and budgeted at an early project definition stage, ensuring closure acceptance by the different stakeholders, including the project team, and the efficiency of the project closing activities by a formal prepared plan. This allows also that project closure be disconnected from the “failure syndrome” in case of termination and facilitates the lessons learned performance appraisal processes.
Introduction
In this paper, we propose and demonstrate operationally an alternative process for closing projects. Our aim is not to define the reasons for closing or not closing a project; rather, we will provide an overview of some generic closure triggers and establish a framework for coping with these triggers in order to increase project closing efficiency, secure resource spending, and ensure acceptance.
As such, our journey will take us through Project Risk Management, Project Planning, and Resource Management. The Modular Risk-Based Closure (MRBC) resides on foundations put in place by the Project Driven Strategic Chain® (Lazar, 2007) and The MAP Method (CIMAP, 2002) initiated by the work of RP Declercke at Lille Graduate School of Management’s Research Center on Project Management (CIMAP). This is for the Systemic Approach part, which allows us to integrate the different components of our MRBC into a smooth and “agile” (to borrow this very trendy word) set of processes.
The Modular Risk-Based Closure process lies in the full integration of project closing activities into the project’s Risk Management processes and defines the closure as being a regular and simple risk response work-package, activated in the case of a risk or opportunity occurrence. Risk involving the termination of the project, or opportunity meaning the successful completion of the project’s objectives. In both cases, we’ll use the same set of activities and resources planned and budgeted at an early project definition stage, ensuring closure acceptance by the different stakeholders, including the project team, and the efficiency of the project closing activities by a formal prepared plan. This allows also that project closure be disconnected from the “failure syndrome” in case of termination and facilitates the lessons learned performance appraisal processes.
The Project Regular Closing Processes
Project closing is described in various references and guides, and the related processes, as described for example in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition (Project Management Institute [PMI], 2008), or in PRINCE2, are quiet clear and straightforward. They are presented as a set of actions and deliverables to be undertaken or to produce in order to achieve an administrative closure of the concerned project, as described in the Figures 1 and 2, extracted from the PMBOK® Guide and from PRINCE2.
Exhibit 1: Close Project or Phase Process – inputs and outputs. (PMI, 2008, p 65)
Exhibit 2: « Closing a Project » diagram from PRINCE2, OGC 2002.
As we can see above, the actions are globally very similar, consisting in reviewing the project’s outcomes and deliverables, collecting Lessons Learned, archiving documentation, and, finally, confirming the formal closure to the various governance bodies.
Stating that, we can say that we know how to operationally close a project when it has to occur, but the real question at stake here remains: How do we integrate an unexpected closure into the Project Plan? How can we ensure the efficiency of such a process? And finally, how do we deal with “soft” issues related to such an event, including the team’s acceptance and HR-related outcomes?
The “Closing Package”
To answer to the above-mentioned questions, let’s take a step back and reconsider the perspective of the Project. According to the work of Declercke at CIMAP, which led to the definition of the MAP model, the project can be seen as a set of systems, interacting one with each other through their various outcomes, in order to produce the final project’s objective and deliverable, being the outcome of a global system, the Project itself (Exhibit 3).
Exhibit 3: The System representation.
Note. From CIMAP. (2002–2009). Strategic project management. Lille Graduate School of Management. Paris‥
Exhibit 4: Systems’ interactions model‥
Note. From CIMAP. (2002–2009). Strategic project management. Lille Graduate School of Management. Paris.
In this model, each set of activities, or work package, is using resources (human or material), in the context of some initial conditions to produce an output, which can become an input for the following system. Then, managing a project lies more in dealing with the various interactions among the systems it includes, rather than managing the transformational process acting inside each system to generate the expected output (CIMAP, 2002) (Exhibit 4).
Having stated that, we can see the activities to perform to close a project as being one of the project’s systems, a work package by itself, included into the project plan.
This work package can then be defined with a set of activities, related timelines and resources, estimated budget, and can be included in the project’s WBS.
Usually, this “closing package,” is placed at the end of the life cycle of the project or of the phase. This is fine if the project is fully completed and reaches all of its objectives. But what happens if we have to close a project before its successful completion? (It is beyond the scope of this paper to enter into the debate of defining the success of a project). Very often, in some industries it is the “standard case,” a project has to be closed before completion. Let’s see what can trigger the closure of a project.
The Triggers of Project Closure
A project can be closed for different reasons, all depending on the nature of the project, the industry, the technology, etc. But if we get a closer look at the nature of these closure triggers, we’ll see that there’s a great deal of common points among all kinds of projects.
First, consider the regular closing of a project. It is mainly motivated by the achievement of the project’s objectives and the successful delivery of its outcomes. This is definitively a positive event leading the team to close a project.
Then, let’s consider the closure before successful completion. This can occur when an unexpected event arises, driving the project team to terminate the project, or when the project fails in delivering the expected benefit or reaching its objectives. This kind of closure can also occur when a strategic change is decided by the organization or for budget restriction impacting the project portfolio. In any event, this kind of closure is always the result of an unexpected negative event.
To summarize, project closure is triggered by the occurrence of a negative or positive event in the project life cycle, regardless of whether this event is expected or not.
Does this remind you of anything?
Let us now consider a definition from the PMBOK® Guide: “An uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective…” (PMI, 2008, p 275) Yes! This looks like the definition of Risk! Some would argue that successful completion is always expected, yes—but also always uncertain. It is the purpose of project management to reach successful completion, by reducing the uncertainty existing around the completion point of a project.
As a Risk/Opportunity Response
Once this statement is made, that Closure is triggered by a risk occurrence, we can then define the closing activities as being the response, or mitigation of that risk.
If we consider that in addition to the first statement made through the systemic approach to project management, we can define a new approach to project closure.
With this approach, we consider project closure activities as a Risk Mitigation work package, this being then included in the Risk Management plan, and then being ready to be initiated at any stage of the project, when a risk driving to close the project occurs (whether this is negative or positive). This risk mitigation package being defined, scheduled, resourced and budgeted, it can be even integrated in a Risk Mitigation Structure, defined in parallel to the WBS and ready to be transferred in the operational project plan, and it can be updated with the new activities (Exhibit 5).
Exhibit 5: Risk Mitigation Structure in // with the Operational WBS.
Benefits of the Process
Considering Project Closure in this way delivers an interesting set of benefits in terms of Project Management process and Change Management.
First, in terms of process, this approach allows one to have a planned response in case of unexpected termination. As with any Planning process, if it is prepared in advance, due to its nature as a Risk Mitigation plan, it allows one to save precious time and resources at risk occurrence (Hillson, 2008). This approach also provides visibility in terms of budget and timelines and allows an accurate performance tracking of the closing phase, which is always critical in terms of resources. It is usually at a time when the organization can’t afford to waste any asset.
From a Change Management perspective, it allows fostering of the acceptance of the termination event from the project team and stakeholders. On some projects that have been running for several years, the incomplete realization of a project is a difficult event, raising many questions and concerns. Many times, people involved in a project have a tendency to forget that closing a project is the right thing to do, and saying that, the closure is not necessarily a failure. It’s just part of the project’s life.
By an early identification of the possible closure triggers through the Risk Management process, it has become more acceptable by the team, as people know in advance what may happen and why.
An important aspect to be integrated into the Closing Package is related to the team decommissioning; when planned in advance, this process is generally smoother and less detrimental to the concerned team members.
Conclusion
The process presented in this paper is very simple and is founded on simple statements. We have been able to implement it operationally in several organizations with some success.
It also states that everything is connected in project management in general. To achieve an efficient and not only effective outcome, project management needs to be considered not only from a systematic perspective, but also from a systemic perspective.
The very purpose of this kind of process or approach is to simplify matters, make them smoother and to allow the project team to truly own the project and its management processes.
