Closing Projects

Overview

"History repeats itself. That's one of the things wrong with history.''

—CLARENCE DARROW

Reviewing the records of technical projects, it is striking how many consecutive projects fall victim to the same problems. Common issues such as inadequate staffing, top-down imposed deadlines that have nothing to do with the work, fixed commitments made with little or no analysis, and many of the other issues listed in the PERIL database, discussed in the first several chapters of this book, plague project after project. One definition of insanity is repeating the same actions over and over, hoping for a different result. More than a little risk in most projects is a direct result of using the same methods for projects that have caused problems in the past.

Getting better results requires process improvement. Using a continuous cycle of measurement, small modifications, new measurement, and comparative analysis, you can discover ways to improve any process. By treating each project as a separate experiment, you can, as part of project closure, examine the results you obtained from the project processes that were used. Achieving consistently better results and minimizing risks down the line requires you to identify what worked well, ensuring that these processes are repeated on future projects, and it also requires you to isolate the processes that did not work and investigate ways to change them. Any process change you come up with is probably a better bet than repeating something that does not work. After the changes, if the performance of your next project is still not good enough, you can always change it again. Postproject analysis is a powerful and effective tool for longer-term project risk management improvement.

Most of the content of this chapter falls into the "Administrative Closure'' portion of the Closing Processes in the PMBOK Guide, as well as other Project Processes. The principal content of this chapter focuses on:

• Project closure
• Project retrospective analysis

Project Closure

There are a number of closure activities common to most technical projects, but the specifics vary a great deal with the type of project. Project close-out generally involves:

• Formal acceptance of the project deliverables (for successful projects)
• The final written report
• Close-out of all contracts, documents, and agreements for the project
• Acknowledgement of contributions
• A postproject retrospective analysis to capture the lessons learned
• A celebration or other event to commemorate the project

The most relevant of these to risk management is the retrospective analysis, which is covered in detail later in this chapter.

Formal Acceptance

One of the greatest potential risks any project leader faces is, after finishing the work, to be asked, on delivery, "What's this?'' Scope risk management seeks to avoid this situation through validation of the initial specifications and scrupulous management of changes. Definition of all final acceptance testing, aligned with the initial specifications, should be one of the first activities undertaken in technical projects, as part of scope definition and planning. Testing and acceptance requirements must also be modified as needed throughout the project in response to authorized changes. If final tests and acceptance criteria are defined late in the project, it is only through happenstance that the project deliverables will meet the requirements.

Managing this risk involves thorough specification of the deliverable and frequent communication throughout the project with the people who will evaluate and accept it. You can also minimize the risk greatly by engaging them in discussions and evaluations of any prototypes, models, incremental results, or other interim project deliverables. Detailed, validated scope definition is the best way to minimize late project surprises.

When your project is successful, get formal acknowledgment of this from the project sponsor and, as appropriate, from the customer or other stakeholders. For technical projects undertaken on a fee-for-service basis, generate the final billing information and ensure that the customer is properly and promptly billed. Even for projects that end in cancellation or fail to deliver on all of their objectives, you should obtain written acknowledgement whenever possible of the partial results or other accomplishments that you did successfully complete.

Final Project Report

The main purpose of a final report is to acknowledge what has been done and to communicate to everyone involved that the project is over. Some years ago, two contributors on a distributed team called their project leader to report their status, because txhey had not heard from him in about a month. The telephone conversation started awkwardly. Following a long, embarrassed pause, the project leader finally asked, "Didn't I call you last month to let you know the project had been canceled?'' Every project needs a final project report summarizing results and thanking contributors, whatever its final disposition.

A final project report is usually very similar in format to a regular status report, but it puts more emphasis on the overall project and the accomplishments of the contributors. The report is an excellent place to document and formally recognize significant contributions made by individuals (and groups) on the project team. While the final project report may be longer than the periodic project status reports, it should also begin with a high-level summary, and it often includes much of the same content that you reported throughout the project.

Contract and Document Close Out

For all internal agreements and external contracts that are specific to your project, complete any final paperwork required. Following final payments of all invoices, summarize the financial information, and terminate the agreements. If there are issues or problems relating to any contracts, escalate and resolve them as soon as practical.

Add the final project report to the project information archive, along with any other project documents and reports that are updated or created as part of your project close-out.

Acknowledging Contributions

It is a small world. When you work with people once, the chances are fairly good that you will work with them again. Managing risk in a continuing stream of projects depends on developing and maintaining trust, relationships, and teamwork. Recognizing the accomplishments and contributions that people have made is fundamental to this.

On technical projects, expertise and hard work are frequently taken for granted. When technical people finish difficult activities, often the only feedback they get is an assignment to another, even more difficult activity. Especially at the end of a project, you need to thank people, both in person and in writing. For people who work for other managers, acknowledge their contributions to their management, also. Keep your remarks truthful, but focus on positive contributions. If it is culturally appropriate, praise people and teams publicly, as well. If there are programs in place for specific rewards, such as stock options or other tangible compensation for extra effort, submit recommendations for deserving project contributors to reward them for their work.

Celebration

Whatever the atmosphere has been in the closing days of your project, bring the project to a positive conclusion. Celebrate the success of the project with some sort of event. Even if the project was not a success, it is good to get people together and acknowledge what was accomplished. Celebrations need not be lavish to be effective; even in businesses that may not currently be doing well financially, project teams can get together and share food and beverages that they provide for themselves. Moving on to the next project or another assignment is much easier when people have a chance to bring the past project to a good conclusion. If your project has a global or distributed team, arrange a similar event for each location at roughly the same time.

Project Retrospective Analysis

Managing project risk on an ongoing basis requires continuing process improvement. Whether you call this effort a retrospective meeting, lessons learned, a postmortem, a postproject analysis, or something else, the objective is always the same: improving future projects and minimizing their risks. If the people who led the projects before yours had done this more effectively, your project would have had fewer risks. Help the next project leader out—it could be you.

The overall process for a project retrospective analysis is similar to the project review process discussed in Chapter 11, but the focus is broader. Project reviews are concerned primarily with the remainder of the current project, using the experiences of the project so far to do "course corrections.'' A retrospective analysis is backward-looking and more comprehensive, mining the history of your whole project for ideas to keep and processes to change in projects generally.

Before you schedule and conduct a project retrospective, get organizational commitment to act on at least one of the resulting change recommendations. Performing postproject analyses time after time that always discover the same process defects is worse than useless. It wastes the time of the meeting participants and is demotivating. Decide how you will use the resulting information before you commit resources to the analysis.

Prepare for and Schedule the Project Retrospective

Thorough postproject analysis requires you to have accurate, completed project data. As the final project documents are added to the archive, determine what information is necessary, and ensure that it will be available for review during your project retrospective meeting. Some of the information you will need is the actual and planned schedule and resource data, the project change history, logs of issues and escalations, project metrics collected, and your status reports. If some team members left during the project and are no longer available, assemble any information that may have been archived when they left so that their perspectives on the project will also be considered.

Schedule the retrospective analysis soon after the project, but not immediately after it. If it is too soon, final documents will be incomplete, and events from the last, chaotic days of work will dominate the analysis. Don't wait more than about two to three weeks after the project, though, or important memories, particularly the less pleasant ones, will begin to fade, and key contributors may no longer be around. Schedule the meeting when the people who need to participate are available, and get their commitment to attend, face-to-face if possible. Strive to have all contributors participate; absent project team members often end up as scape-goats for more than their fair share of the project's difficulties.

You may benefit from having more than one retrospective meeting. If allowing managers or customers to attend will stifle discussion, consider having separate meetings—one for just the project team and another for everyone. Large programs may require retrospectives at several levels to collect appropriate information, generally beginning at the individual project level and then building on the findings and observations in additional meetings up through the program hierarchy.

Allocate sufficient time. Even shorter projects can generate enough data to justify a half-day retrospective. Longer projects require longer retrospectives. The process is most effective when all the project contributors, including the project leader, can focus on the project, so consider using a facilitator to run the meeting and have someone from outside the project take notes.

Set an agenda, and publish it in advance to gather comments for additional topics and requirements. At a minimum, include:

• A general statement by each project team member about the project
• Positive results: things that went well and practices to repeat
• Desirable changes: processes that caused problems that need improvement, new practices needed, and ideas for avoiding disappointments
• Prioritization of recommendations
• Final thoughts

Encourage participants to come prepared with specific examples of what went well and what changes they would recommend.

Retrospective Surveys

If your business has a standard retrospective survey form, plan to use it. A retrospective survey typically includes questions about project definition, planning, defect and issue management, decision making, teamwork, leadership, process management, management of dependencies and deliverables, testing, logistics, and general recommendations. Standard formats usually have lists of statements to be rated on a scale from "strongly agree'' on one extreme to "strongly disagree'' on the other, and spaces for written comments.

If there is no survey form or the one you have does not include much in the way of risk information, consider using or adding the following:

Postproject Risk Survey

Please evaluate each of the following statements using the scale:

1—Strong disagree 2—Disagree 3—No opinion 4—Agree 5—Strongly agree

1	2	3	4	5	The project developed and used a risk plan.
1	2	3	4	5	Project problems were dealt with quickly and were escalated promptly when necessary.
1	2	3	4	5	Schedule problems were dealt with effectively.
1	2	3	4	5	Resource problems were dealt with effectively.
1	2	3	4	5	Project specifications were modified only through an effective change control process.
1	2	3	4	5	Detailed project reviews were done on an appropriate basis.
1	2	3	4	5	Project communication was frequent enough.
1	2	3	4	5	Project communication was thorough and complete.
1	2	3	4	5	Project documentation was self-consistent and available when needed.
1	2	3	4	5	Project status was reported honestly throughout the project.
1	2	3	4	5	Reporting of project difficulties resulted primarily in problem solving.
1	2	3	4	5	The project had adequate sponsorship and support throughout.

In addition to discussing processes during the meeting, it is also useful to have all project contributors list at least one practice that they recommend keeping and one practice that they recommend changing, with their suggestion on what to change.

Send the survey to team members, and ask each person to think about and return the survey with his or her thoughts before the project retrospective meeting. In some situations, it may be necessary to use a survey in place of a meeting, but, before deciding whether a survey will be sufficient, consider the loss of feedback involved.

Conduct the Meeting

Start a retrospective meeting with a statement of objectives, and review the meeting agenda. Invite each participant to make a general statement about the project, allowing people to say, briefly, what is on their minds.

Before getting into deeper detail, review the ground rules for the meeting. Rules might include a goal to hear from everyone, roughly equally. Do not allow just one person or a small group to dominate the discussion. Explain that the purpose of the meeting is to identify opportunities and issues, not to solve problems on the spot. The goal is recommendations, not solutions. As the retrospective continues, maintain a focus on the processes; avoid attacking individuals and "blamestorming.'' Resolve factual disputes using project documents.

To capture ideas generated in the meeting, have several flipcharts, or enter notes directly into a computer connected to a projector. (Computer entry saves time after the meeting, but posted large sheets of paper serve to keep the data visible where everyone can see them as the meeting progresses.) Maintain one list for "Positives'' and another for "Needed changes'' (not "Negatives''). Use additional lists for issues that need attention but are beyond the meeting scope, for action items, and for other data that may emerge. Designate a scribe to be responsible for creating the lists and documenting the meeting. If you cannot arrange for a scribe who was not involved in the project, rotate the responsibility for capturing data so that everyone can focus on the content of the meeting, at least most of the time.

Probe for positive aspects of the project first, using the data from the project retrospective surveys and other feedback or through general discussion. Collecting positives about the project first reminds people of all the aspects that went well. (If you allow people to begin by discussing problems and project aspects that went poorly, it starts the session on a depressing note, and the gloom can sometimes expand to take all the time you have.) You should probe for specific opinions on project aspects that led to success. Capture what went particularly well on your project; identify new practices that you should repeat or extensions to existing processes that were valuable.

When most of the positives have been cataloged, focus on desirable changes. Identify process areas that need improvement and practices that should be simplified or eliminated. Consider project issues and problems that you had to deal with, and develop process recommendations to avoid them on future projects. Seek the root causes of disappointments or failures on your project, and brainstorm possible ideas for mitigating them.

As your discussions progress, continue to collect positives that emerge, along with any important off-agenda information. Across the whole project team, perceptions may differ about what worked well and what did not. If there are differences, note them, and rely on project data wherever possible instead of opinions. Attack the issues, not the people; generating a list of people to blame things on will not improve future projects.

Throughout the meeting, specifically draw out people who are not saying very much, capturing their thoughts, and include observations provided in writing by former project team members and any others who are unable to participate.

As the allotted time winds down, summarize the recommendations. Ask each participant to nominate one recommendation that he or she believes would make the most significant difference on future projects. Work as a group to develop consensus, if possible, on the most important change, or at least generate support from the group for one or two that top the list. If further analysis will be necessary, capture the activities with owners and due dates.

Close the meeting with reflections on the process, and encourage people to share what they learned from the project personally and how they plan to work differently in the future.

Document the Results and Take Action

Document the meeting in a concise format, with the top recommendation (or recommendations) and key findings in a clear, short summary at the beginning. Include the lists of information developed in the meeting after the summary. Distribute the project retrospective report to the participants for review and comment. When this is completed, put a copy of the results in the project archive, and share the findings with others who could benefit from the information, such as the leaders of similar projects.

Take the principal recommendations to your management, and request support for making necessary changes. Small changes can be fairly trivial to implement, but more significant ones may trigger new projects and require significant data, planning, and resources to initiate. If your recommendation is denied, discuss alternatives with the project team, and investigate whether there might be other ways to mitigate the problem that, although less effective, would be under your control.

In any case, take at least one issue emerging from every project and resolve to do something different in the next project you undertake to address the problem. Effective risk management requires your firm commitment to continuous process improvement. Resolve to spread new practices found to be effective, and periodically review the standards and processes that are in place to detect the need for change and evolution. Monitor all changes you make to see whether they are effective. Whenever a change fails to achieve its desired result or causes serious unintended consequences, try something different.

Process improvement rests on the "Plan-Do-Check-Act'' cycle and requires persistence. Managing project risk means reusing what has worked before on your projects and fixing or replacing what has failed. Every project offers beneficial lessons learned.

Key Ideas for Project Closure

• Thoroughly and accurately document the project results.
• Recognize accomplishments and thank contributors.
• Conduct a project retrospective and use the recommendations.

Panama Canal Completion (1914)

On August 15, 1914, the first seagoing vessel crossed Panama, and the Panama Canal opened all the way through. This huge accomplishment was reported far and wide as the biggest news of the day. The attention lasted only a short time, though, as soon World War I broke out in Europe and quickly overshadowed the canal story.

In retrospect: The eighty-kilometer (fifty-mile) lock-and-dam canal was completed, slightly more than ten years after the congressional act that initiated the work. About 5,000 additional lives were lost finishing the U.S. project. Some died from disease, but most of the loss of life was from explosives (making the total death toll as high as 30,000, including those who died in the 1800s). The canal opened six months ahead of the schedule set earlier by John Stevens, despite all the difficulties and changes. Even more remarkable, it finished at a cost $23 million less than the budget ($352 million had been approved). The total cost for construction was more than $600 million, including the cost of the French project. If this is not the only U.S. government project ever to finish both early and under budget, it is certainly the largest one to do so.

Most of the credit goes to George Washington Goethals. Although he acknowledged his debt to John Stevens, nearly all the work was accomplished while Goethals was chief engineer. After the opening of the canal, Goethals remained in Panama as governor of the Canal Zone to oversee its early operation and to deal with any problems. His thoughts on completion of the work at Panama, delivered in March 1915, were:

We are gathered here tonight, not in the hope of something to be accomplished, but of actual accomplishment: the two oceans have been united. The [mud] slides hinder and prevent navigation for a few days, but in time they will be removed. The construction of the Canal means but little in comparison with its coming usefulness to the world and what it will bring about. Its completion is due to the brain and brawn of the men who are gathered here—men who have served loyally and well; and no commander in the world ever had a more faithful force than that which worked with me in building the Panama Canal.

If you were asked to name a famous engineer, Goethals would be an excellent choice. While there are other engineers who have become famous as astronauts, politicians, and multimillionaires, Goethals is famous for engineering. His accomplishments in addition to the canal are substantial, and he remains a significant influence in civil engineering to this day. The lessons learned from this project are thoroughly documented (as with all projects undertaken by the U.S. Army Corps of Engineers). They serve as the foundation not only for the subsequent civil engineering projects of the twentieth century but also for much of what is now recognized as modern project management.