Chapter 11: Principles of Project Closeout

Project closeout is often the most difficult phase of a project, not because the project is coming to an end and the customer and your senior management expect the project to have been completed on time, on budget, and in accordance with the customer's requirements, although that is certainly important. The difficulty is mostly created because of the draw upon your resources to other projects. Functional managers have enormous pressures to support every project in the organization. Generally, an organization never has as many resources on staff as it needs to support the projects it pursues, and that is as it should be—it is a function of efficient resource utilization. That fact notwithstanding, there are never enough resources to go around, so functional managers are constantly seeking ways to siphon off resources from one project to apply against another project's needs. Consequently, project managers feel that they are losing their resources before the project work is completed—and that is usually an accurate assessment. So what can a project manager do to successfully close out her project? That is what we are going to explore in this chapter.

Activities of the Closeout Phase

The project manager's function is largely administrative during this phase of the project. It is the time to ensure that all the requirements have been met, the product is delivered and working, all bills are paid, all invoices are sent, the project office is properly closed, and all team members are assigned to new jobs. But "administrative" does not mean that the task is easy.

Ideally, the project team starts planning for the project closeout no later than the beginning of the development phase of the project life cycle. The planning should be done even earlier if there is enough information available, but it often is not practical to develop a closeout plan until there is a clear understanding of all the project and product requirements. In any event, a closeout plan should be in place before the product development begins. Exhibit 11-1 is a sample of a WBS of closing activities. The following checklist, Exhibit 11-2, and the subsequent discussion take a closer look at the closeout activities.

Exhibit 11-1: A WBS for the closeout phase.

start example

click to expand

end example

Exhibit 11-2: Activities for closing out a project.

start example
  1. Scope verification

  2. Financial audit

  3. Product completion and delivery

  4. Customer sign-off

  5. Contract closeout

  6. Project office closeout

  7. Lessons learned

  8. Personnel reassignment

  9. Close and archive files

  10. Prepare for product maintenance

end example

If all the closeout activities are completed, the project manager and his team will have completed a major task.

Scope Verification

A favorite question on PMI's Project Management Professional (PMP) certification examination is: When does one conduct scope verification? The natural (but incorrect) answer is during scope development. Of course, you verify the scope is correct and complete during the scope definition and development process, but scope verification comes at the end of events—tasks, phases, and the project. The objective is to ensure all the scope requirements for that event, whether a task, phase, or the project, are accomplished.

Scope verification constitutes one of the two audits, the technical audit, which is conducted during this phase. The second audit is to determine the project's financial status.

The Financial Audit

The purpose of the financial audit is obvious—you want to know if all the bills are paid and all the invoices have been sent out. But you also need to know another important piece of information. Namely, how well did the actual expenditures match the planned budget?

An often overlooked benefit of a financial audit is the opportunity to collect metrics that can be used to improve the cost estimates. Estimating techniques can be improved every time a project is accomplished by using the variances between the planned budget and actual costs to refine estimating methodology. At the minimum, these variances can be used as weighting factors to adjust new project estimates.

Product Completion and Delivery

Naturally, the primary objective of the project is to complete the customer's product. Basically, the product is completed at the end of the implementation phase, but there still are some final tests and clean-up chores required before the product can be delivered. Most often, acceptance is contingent upon a successful acceptance test, or simply stated, a demonstration that the system works as advertised. If so, the final step is delivery and installation of the system, which, incidentally, may come before the acceptance demonstration. In other words, it is not uncommon to install the system and then conduct the final tests in front of the customer.

Customer Sign-Off

One of the crucial elements of any contract, external or internal to the organization, is a clear explanation of the acceptance criteria. All of us probably have experienced projects that seem to have no end. Usually, this phenomenon occurs because there are no stated acceptance criteria that the customer can use to determine whether the product or system is completed. If there are no criteria, then the customer can always aver that the product does not meet the requirements.

The customer's sign-off literally means she agrees that you have indeed developed the system to specification, i.e., requirements, and that it is accepted. If the project resulted from an external contract, sign-off may be a part of the contract closeout procedure, but whether it is or not, the project can't be formally closed until the system is accepted.

The Contract Closeout

Contracts require a lot of administrative effort to execute, and closing one usually means that some specific forms, letters, and/ or reports have to be generated. Often, particularly with federal sector contracts, the formal acceptance of a system is a part of the contract closeout procedure. This procedure is done with a letter or with a standard form that gives the contract name and number, date of acceptance, and the signature of the designated contracting officer.

The contract closeout also might involve the return of equipment owned by the customer. In very large, expensive, or highly developmental projects, it is not unusual for the customer to supply specialized equipment such as tools, test equipment, computers, or special software to aid in developing the system. If this is the case, this equipment either must be returned to the customer or disposed of in accordance with the contract provisions. Often, it is cheaper for the customer to allow the contractor to keep the equipment than to ship it back, but however it is disposed of, you must formally account for this equipment.

Administratively, disposing of the customer-furnished equipment is part of the contract closeout; physically it is a part of the office closeout.

The Office Closeout

Many projects are executed on-site, which means that the contractor works on the project at the customer's location. Often the customer provides an office or workspace for the project, but usually on-site means that the contractor has to lease office and workspace within a specified radius of the customer's location. If the project is actually accomplished on the customer's premises, there may not be much site-closing activity required beyond the removal of personal belongings and company equipment. Otherwise, the project manager will have to close out the lease, stop all utilities, disconnect telephone service, and notify all suppliers. In either case, the project manager is responsible for packing and shipping the company-owned and customer-owned supplies and equipment back to the parent company or to the designated customer ship point.

Lessons Learned

Most companies do a poor job of capturing the lessons learned from their projects. There is a natural tendency to rush team members, and even the project manager, off to new projects. Once a project is completed, it is difficult to regroup the team for the two or three hours it takes to complete a lessons-learned analysis. The irony is that most of the data already exists in the form of status reports and other project documents. It only requires tapping into the collective memory and project experiences of the team to complete the analysis. If the status and other reports are thorough and capture information that actually describes what happened within the project during the reporting period, then summarizing the information in a final lessons-learned document is relatively easy and painless.

Personnel Reassignment

Although the project manager has no functional authority over project personnel, he should make every reasonable effort to facilitate reassignment to other projects as each individual's work is finished. There are two reasons why getting team members reassigned should be a priority with the project manager: First, it is the right thing to do. Second, it will pay enormous dividends for both the project manager and the organization in the future.

One of the reports that the project manager will submit during closeout is a personnel report. Since the project manager has no functional authority over team personnel, he is not the person to write performance reviews. However, the project manager is often asked to make comments for an individual's performance review. This is because he will have observed the individual's work and team behavior at close hand. In the same vein, the project manager should submit a personnel report to all the appropriate functional managers, detailing each individual's work ethic, team skills, technical expertise, and whether the person should be assigned to future projects. Obviously, this report should have limited and confidential distribution.

Closing and Archiving Files

Good project managers will maintain two types of files—the project book, which is the collection of all the project-related plans, reports, and any other pertinent documentation, and the contract files, which contain all the legal documentation relative to the project. Like the lessons-learned report, the project book and contract files contain vital historical data that should be maintained in a useable and accessible format for future reference. Most organizations now maintain these documents in an electronic format, which greatly facilitates accessibility. Being user-friendly also encourages other teams to refer to and use this historical record as well.

Closing the books on the project requires one final report, which is referred to as the final project audit. This is essentially a compilation of the other reports we mentioned above and, in fact, can be thought of as the cover page that forwards these other reports. A sample format for the final project audit is shown in Exhibit 11-3. Notice that this format can serve the dual purpose of being a checklist for the project manager of closeout activities, as well as being a report format.

Exhibit 11-3: Sample final project audit format.

start example

Final Project Audit Report

  1. Executive Summary

  2. Introduction

  3. Project Review

  4. Planning Effectiveness

  5. Project Management Effectiveness

  6. Effectiveness of Technical Solutions

  7. Project Deliverables

  8. Quality

  9. Schedule

  10. Finances

  11. Resources Utilization

  12. Individual Team Member Assessment and Recommendations

    (Submit as separate, confidential report)

  13. Lessons Learned

  14. Recommendations

end example

Once this final project audit report is compiled, it is sent to all the project stakeholders and is included in the project archives.

Preparing for Product Maintenance

Information technology is one of those industries where the project is finished and delivered but still has a connection to the providing organization. In other words, the customer expects, and pays for, a continuing maintenance of the system after it is delivered.

Organizationally, the best way to set up and plan for continuing product maintenance is to have the specialist groups that do the initial project management activities design and develop the product and specialist groups that will maintain the product once it is shipped. This is a statement of the obvious, so what is the big deal? The big deal is that too often organizations fail to adequately plan for and execute a smooth hand-off between these two groups. The project team that develops the product has to close the project with the approach that its documentation is essentially the statement of requirements and statement of scope for the maintenance team. That is why I believe project life cycles should actually have a final cycle phase that is devoted to continuing product and service maintenance. If we view all our projects from this perspective, then the final phase will require some overlap of activities between the development project team and the maintenance project teams. This results in a better IT system for the customer.

Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor © 2008-2017.
If you may any questions please contact us: