Chapter 12

Closing Projects

“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 based on little or no analysis, and many other issues listed in the PERIL database 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. You can, as part of project closure, examine the results you obtained from the processes that were used for each project. Achieving consistently better results and minimizing future risks requires you to identify what worked well, ensuring that these processes are repeated on subsequent projects, and it also requires you to isolate the processes that do not work and investigate changing 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.

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

• Acknowledgment 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 finishing the work only 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. Defining 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 proto-types, 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 acknowledgment 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. Every final project report should also thank the contributors.

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. If you have had difficulties with any outside service providers, document them and make the information available to other project leaders to avoid similar risks in the future.

As part of project closure, add all final project documentation to your project information archive.

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 last project to a friendly 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 primarily concerned 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.

Preparing for and Scheduling 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. 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.

Allocate sufficient time. Even shorter projects can generate enough data to justify an hour or so to look backward. Set an agenda providing time for all contributors to comment and to collect both positive results and proposals for process change. 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, managing 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, the following survey form may be useful.

Postproject Risk Survey

Please evaluate each of the following statements using the scale:

Plan to use the survey in addition to the discussion of processes during the meeting. You can also use it to collect inputs from any project contributors who are unable to participate.

Conducting the Meeting

Start a retrospective meeting with a statement of objectives, and review the meeting agenda and ground rules for the meeting. At a minimum, establish a rule to maintain a focus on the processes and to avoid attacking individuals and “blamestorming.”

Capture ideas generated in the meeting, starting with “Positives” before moving to “Needed changes” (not “Negatives”). Collecting positives about the project first reminds people of all the aspects that went well. 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.

Throughout the meeting, work to hear from everyone, not just a vocal minority. As the allotted time winds down, summarize the recommendations, and 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.

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.

Documenting the Results and Taking Action

Document the meeting results in a concise format with the top recommendation (or recommendations) and key findings in a clear, short summary at the beginning. Distribute the project retrospective report to the participants for review and comment. When completed, put a copy of the results in the project archive, and share the findings with others who could benefit from the information, including 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 rejected, 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 your next project to address the problem. Effective risk management requires your firm commitment to continuous process improvement.

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.

Panama Canal: Completion (1914)

On August 15, 1914, the first sea-going 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, with most of the loss of life due to handling 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 US$23 million less than the budget (US$352 million had been approved). The total cost for construction was over US$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 deal with any problems. His thoughts on completion of the work at Panama, delivered in March of 1915, were:

If you were asked to name a famous engineer, Goethals would be an excellent choice. Although 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.