Project Closure

Eventually the project is closed, either quickly or slowly, but the manner in which it is closed out will have a major impact on the quality of life in the organization. PMBOK refers to this as “project closure” which is covered in PMBOK’s Chapter 4 on Integration. Occasionally, the way project closure is managed can have an impact on the success of the project. Invariably, however, it has a major effect on the residual attitudes toward the project held by senior management, the client, the project team, and even others in the organization. It also has a major effect on the organization’s successful use of projects in the future.

In some project-organized industries (e.g., construction, consulting, or software development), project closure is a less serious problem because the teams often remain relatively intact, moving on to the next project. In other industries, however, the termi­nation of a project, particularly a long and difficult one, is akin to the breakup of a family and may well be stressful, even to the point of grieving. Therefore, the skill and manage­ment of the closure process—a project in itself—can have a major impact on the working environment of the larger organization.

1. When to Close a Project

If one adopts the position that sunk costs are irrelevant to current investment decisions, a primary criterion for project continuance or closure should be whether or not the organization is willing to invest the time and cost required to complete the project, given its current status and expected outcome. Although this criterion can be applied to any project, not everyone agrees that sunk costs are irrelevant, nor does everyone agree that this is a primary criterion. The criteria commonly applied for deciding whether to close a project fall into two general categories: (1) the degree to which the project has met its goals and objectives, and (2) the degree to which the project qualifies against a set of factors generally associated with success or failure. Table 8.4 identifies the most impor­tant factors in closing R&D projects at 36 different companies.

In terms of the first category, if a project has met its goals, the time has come to shut it down. The most important reason for the early closure of a project is the likelihood it will be a technical or commercial failure (Baker et al., 1983). The factors associated with project failure, however, vary for different industries, different project types (e.g., R&D versus construction), and different definitions of failure (Pinto and Mantel, 1990).

As we have already noted, there appear to be four generic factors associated with project success (Shenhar, Levy, and Dvir, 1997): efficiency of project execution, cus­tomer satisfaction and use, impact on the firm conducting the project, and contribu­tion to the project firm’s future. Success on these dimensions appears to be directly related to the effectiveness of the project’s management (Ingram, 1994). There also appear to be four fundamental reasons for project failure: (1) a project was not required for this task in the first place; (2) insufficient support from senior management (espe­cially for unanticipated resources); (3) naming the wrong project manager (often a person with excellent technical skills but weak managerial skills); and (4) poor up­front planning.

Wheatley (2009) takes a broader view of the closure problem. To decide which projects should be continued and which should be dropped, he suggests that the deci­sion makers answer five questions: (1) Which projects have a legal or strategic impera­tive? (2) Which projects are luxuries? (3) Which projects are likely to drive future revenues and growth? (4) Which projects best match our skill sets and strengths, allowing us to deliver successfully? and, (5) What are the potential risks to the busi­ness if we do not service the demands for the project’s deliverables? He also suggests taking any pressing current requirements into consideration. For example, if lowering costs to reduce cash flows has suddenly become more important than some longer- run strategic goals, other projects may now take priority over more strategically focused projects.

2. Types of Project Closure

There are three fundamentally different ways to close out a project: extinction, addition, and integration. Project extinction occurs when the project activity suddenly stops, although there is still property, equipment, materials, and personnel to disburse or reassign. The project was closed either because it was successfully completed, failed, or because the expectation
of failure was high. Successful projects are completed and delivered to the client. Expected failures occur when the project no longer meets cost/benefit criteria, or when its goals have been achieved by another project, often in another firm. An example of the former cause of failure is the cancellation of the superconducting super collider (SSC). The SSC project’s tremendous costs relative to the lack of clear benefits doomed the project, and it was can­celled during President Clinton’s term in office. Other examples of projects facing extinc­tion are when a project’s process yield may have been too low, or a drug failed its efficacy tests, or other firms have discovered better alternatives.

One special type of closure that should be noted is closure by “murder,” characterized by its unexpected suddenness, and initiated by events such as the forced retirement of the project’s champion or the merger of the firm conducting the project with another firm.

Closure-by-starvation often occurs when it is impolitic to terminate a project but its budget can be squeezed, as budgets always are, until it is a project in name only. The project may have been suggested by a special client, or a senior executive (e.g., a sacred cow), or perhaps closing the project would be an embarrassing acknowledgment of managerial failure. Occasionally a few project personnel members remain assigned to such a project along with a clerk whose duty it is to issue a “no-progress” report once each quarter. It is considered bad manners for anyone to inquire about such projects.

Closure-by-addition occurs when an “in-house” project is successfully completed, and institutionalized as a new, formal part of the organization. This may take the form of an added department, division, subsidiary, or other such organizational entity, depending on the magnitude and importance of the project. 3M Corporation often uses this technique to reward successful innovation projects, such as the invention of Post-It Notes®, and Nucor uses its own construction management teams to staff new steel minimills.

Sometimes, project team members become the managers of the new entity, though some team members may request a transfer to new projects within the organization— project life is exciting. Although the new entity will often have a “protected species” status for the first year or so of its life, it eventually has to learn to live with the same burden of overhead charges, policies, procedures, and bureaucracy that the rest of the organization enjoys. Exceptional project status does not carry over to permanent entities. This shift may be a difficult one for the project team to make.

Closure-by-integration With closure-by-addition, the project property often is simply transferred to an existing or newly created organizational entity. With closure-by- integration, the output of the project becomes a standard part of the operating systems of the sponsoring firm, or the client. The new software becomes the standard, and the new machine becomes a normal part of the production line. Project property, equipment, material, personnel, and even functions are distributed among the existing elements of the parent or client organization. Whether the personnel return to their functional homes in the organization or become a part of the integrated system, all the following functions of the project need consideration in the transition from project to integrated operations: human resources, manufacturing, accounting/finance, engineering, informa­tion systems/software, marketing, purchasing, distribution, legal, and so on.

3. The Closure Process

As usual, the following process and advice may be ignored in the case of small, routine projects. For all major and nonroutine projects, however, it is best for a broadly based committee of reasonably senior executives to make the closure decision in order to dif­fuse and withstand the political pressures that often accompany such decisions. In general, projects do not take kindly to being shut down. To the extent possible, it is best to detail the criteria used and explain the rationale for the committee’s decision, but do not expect sweet reason to quell opposition or to stifle the cries of pain. Again, the PM will need the power of persuasion. In any case, shutting down an ongoing project is not a mechanistic process and should not be treated as such. There are times when hunches and beliefs about the project’s ultimate outcomes should be followed. The closure committee that treats the decision as mechanistic is sure to make some costly errors.

The activities required to ensure a smooth and successful project closure will have, we hope, been included in the initial project plan. The closure process will have much better results for all concerned if it is planned and managed with care—even treating it as a project in itself, as illustrated in Figure 8.3. Usually, the project manager is asked to close out the project but this can raise a variety of problems because the PM is not a disinterested bystander in the project. We believe it is better to appoint a specialist in the process, a closure manager (project undertaker), to complete the long and involved pro­cess of shutting down (interring) a project, preferably someone with some experience in closing projects. The primary duties of the closure manager are given in Table 8.5.

Many of these tasks will be handled, or at least initiated, by the project manager. Some will have been provided for in the project proposal or contract. One of the more difficult jobs is the reassignment of project personnel. In a functional organization, it usually entails a simple transfer back to duty in the individual’s parent department; but at those times when a large project is shut down, many team members may be laid off. In a pure project organization there may be more projects to which project personnel can be transferred but no “holding area” such as a home functional department. The matrix organization, having both aspects, may be the least problematic in terms of personnel reassignments.

The prevalence of corporate mergers in recent years has exacerbated personnel dis­placement problems. It is expected that the closure manager and the organization’s Human Resources department will aid loyal project workers in finding new employment. This is not merely an act of charity. It may prevent the tendency of some team members to seek employment on their own and leave a project early, which can compromise the successful completion of the project. If such people are unsuccessful in finding new jobs, they may drag out the final tasks to give themselves more time—also detrimental to the project. The PM needs to make it clear that midproject resignations as well as tenure-for-life are both unacceptable. Facing the closure decision in a timely and straightforward manner will pay dividends to the PM, as well as the closure manager, in a smooth project transition.

Clearly, the closure process can be handled well or poorly. An example of the former is Nucor’s closure-by-addition strategy where the closure of its Crawfordsville, Indiana, steel plant construction project was planned in detail months ahead of time (Kimball, 1988). An example of poor closure is that which resulted when Atlantic States Chemical Laboratories suddenly saw its contract with Ortec canceled, throwing the pro­ject, and its close-out, into disarray (Mantel, undated).

4. The Project Final Report

As the Beagle 2 Mars probe designed jointly by the European Space Agency and British National Space Center headed to the surface of Mars in December 2003, contact was lost and the probe never heard from again (PMI, October 2004). In retrospect, it appears that excessive pressure on time, cost, and weight compromised the mission right from the start. With insufficient public funding, the design team had to spend much of their time raising private funds instead of addressing difficult technical issues. Further, late changes forced the team to reduce the Beagle’s weight from 238 pounds to 132 pounds. The three airbags developed to soften the probe’s landing impact failed during tests, and a para­chute design was installed, but lack of time prevented sufficient testing of it. A review commission’s Final Report recommended that in the future:

• Requisite financing be available at the outset of a project.
• Formal project reviews be conducted on a regular basis.
• Milestones be established where all stakeholders reconsider the project.
• Expectations of potential failure be included in the funding consideration.
• Robust safety margins be included and funded for uncertainties.

The project final report is not another evaluation, though the audits and evaluations have a role in it. With the exception of routine projects where a simple “We did it. No problems” is sufficient, the project final report is a history of the project. It is a chronicle, typically written by the PM, of what went right and what went wrong, who served the project in what capacity, what was done, how it was managed, and the lessons learned. The report should also indicate where the source materials can be found—the project plan and all of its many parts; charter, budget, schedule, earned value charts, audit reports, scope-change documents, resource allocations, all updates of any of the above documents, and so on. It is all too easy to ignore these left-overs from yesterday’s project, but it is most important not to do so. The PMI refers to these as the organization’s assets, and the Project Report is a critical part of them. We think of them as the experiences all managers should learn by—but so often do not.

How the report is written, and in what style, is a matter of taste and preference. In any case, the following items should be addressed.

• Project performance— perhaps the most important information is what the project attempted to achieve, what it did achieve, and the reasons for the resulting per­formance. Since this is not a formal evaluation of the project, these items can be the PM’s personal opinion on the matter. The lessons learned in the project should also be included here.
• Administrative performance— administrative practices that worked particularly well, or poorly, should be identified and the reasons given. If some modification to administrative practices would help future projects, this should be noted and explained.
• Organizational structure— projects may have different structures, and the way the project is organized may either aid or hinder the project. Modifications that would help future projects should be identified.
• Project teamwork— a confidential section of the final report should identify team members who worked particularly well, and possiblythose who worked poorly with others. The PM may also recommend that individuals or groups who were particularly effective when operating as a team be kept together on future assignments.
• Project management techniques— project success is so dependent on the skill and techniques for forecasting, planning, budgeting, scheduling, resource allocation, control, risk management, and so on that procedures that worked well or badly should be noted and commented upon. Recommendations for improvements in future projects should be made and explained.

The fundamental purpose of the final report is to improve future projects. Thus, rec­ommendations for improvements are especially appropriate and valued by the organization. Of course, none of the recommendations for improvement of future projects will be of any help whatsoever if the recommendations are not circulated among other project managers as well as the appropriate senior managers. The PM should follow up on any recommenda­tions made to make sure that they are accepted and installed, or rejected for cause.

Since most of the information and recollections come from the PM, it is suggested that the PM keep a project “diary.” This is not an official project document but an infor­mal collection of thoughts, reflections, and commentaries on project happenings. Not only will the diary help the PM construct the final report, but also it can be a superior source of wisdom for new, aspiring project managers. Above all, it keeps good ideas from getting lost amid the welter of project activities and crises.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.