Project Management at a Glance

Project Closing

by

After all the blood, sweat, and tears (figuratively speaking, we hope) expended in the previous project phases—Initiation, Planning, Execution, and Monitoring and Controlling—we finally arrive at the stage where we close the project. We look at what we’ve built, marvel at its glory, clock out, go home, put our feet up, and relax.

Oh, if only it were that easy.

The good news is, if the rest of the project has been well managed, the closing phase should not be difficult. In closing, the project manager basically ensures that all project tasks have been completed, including the documentation, and receives formal acceptance from the project customer that the project has met all requirements outlined in the final approved Scope Document. Let’s step through the details of the process.

Scope Verification

In the Project Planning phase we created a Statement of Scope. During the Project Execution phase we may have made changes to the original scope, but at this point in the project, we should be able to proudly present the final scope document,including all updates, and be able to check off each item in it as having been complete to the project customer’s satisfaction. In parallel with the Project Execution phase, we monitored and audited the project to ensure that all outputs met the requirements objectives. By diligently ensuring the customer was satisfied with the output as the project progressed, we should get to the completion having no questions about what was actually produced.

That’sone way of verifying that the project is complete and all requirements have been met. Most practicing project managers, however, will tell you there’s a more direct and easier test to ensure project completeness: The schedule has every item checked off.

This comes with a caveat, of course. In the planning phase, did you ensure your task list, which was used to create the schedule, included everything needed to fulfill the scope? If you did, you’re golden. This is where we go back to meticulously planning the project. That Scope Statement should have been treated like a sacred document. It wasn’t cobbled together just to check it off the list of required documentation; it was written as if the project manager’s professional life depended on it. That’s because it does. The Scope Statement is the contract between the project and the customer. If you’ve been reading this series of articles, this may sound like a broken record, but a project manager risks professional suicide if planning isn’t given the utmost importance. Yes, this article is about closing the project, but closing can be a bear if the project wasn’t planned and executed properly.

Let’s assume that the project manager did plan and execute carefully. With the Statement of Scope generating the list of activities that had to be accomplished to produce all deliverables within that scope, and with the activity list generating the schedule, we get to the end of the schedule and find, magically, that every item in it has been checked off. Because we have received customer acceptance as we completed each and every deliverable during project execution, the final acceptance should be no more than a matter of paperwork.

Yes, you want to verify that all deliverables within the Scope Statement are complete to the customer’s satisfaction. But, the practical reality is that the schedule, properly done, provides the project manager with a checklist that does exactly that.

Close Procurements

If our project included purchasing hardware or services, we probably have some purchase agreements to check up on. Of course, all organizations always pay their invoices as soon as humanly possible(we pause briefly for a smile), but just in case one might drop through the cracks, it’s the project manager’s responsibility to ensure that each and every purchase agreement is either paid or is in the process of being paid. It’s rare that a PM has any direct authority for making payment, but at a minimum, he or she has the obligation to ensure that all contracts are being managed according to the organization’s policy. In short, the PM ensures that nothing has fallen through the cracks.

In some cases, it may be necessary to close out general ledger accounts that were opened specifically for the project or manage other financial or cost accounting processes. As with so many other tasks in the project, the project manager probably will not do this, but will ensure that it is complete before calling the project closed.

If there were problems with a purchase it may be the case that final resolution won’t be complete for months or even years, but this doesn’t hold up the closing of the project. Rather, the situation is turned over to another process within the organization and is documented within the project records. Clearly, every contract dispute is not the project manager’s responsibility, but documenting the source and current status of the dispute must be part of the project closing documentation. During the Project Monitor and Control phase, the project manager made sure that all contractual obligations between the enterprise and vendors were well managed. He or she checked off obligations as they were fulfilled, or documented disputes and disagreements as they occurred. If there were contract problems, now, at the project closing phase is where documentation concerning the dispute is turned over to the proper organization to be handled. If any documentation remains to be approved or if any action items were created through the audits, they need to be closed or turned over to another process outside of the project so that the project no longer has responsibility for them. This other process might involve a negotiated settlement, arbitration, or litigation. In any case, the project documentation will include all specifics of the dispute. Even though the project is closed, documentation will remain to support the organization’s case.

Transfer New Service or Process

Whether the the final deliverable of the project was a building, new software, a process, or service, the transition of the end result from project to daily use should have been built into the project deliverables as part of the scope. So, a new building, at the end of the project should be in the hands of a property manager or building maintenance group. New software should be in the hands of IT production. A new process should be owned by the organization it serves.

Project closure, however, requires that all documentation is complete regarding the transference of the physical plant, hardware, or process. This is where all i’s are dotted and all t’s crossed. All stakeholders know beyond a shadow of a doubt that the project now has nothing to do with the output, the result of the project. Not only do they know it, but they sign their name to a document stating the fact. The absolute last thing a project manager wants is for his or her phone to ring three months after completing the project and have someone request further ostensible project-related activities. If this happens, and the project manager cannot produce documentation showing that the project has no more responsibility in that area, someone (read, project manager) has messed up. As we said in the last article, if it’s not it writing, it didn’t happen. The process of formal transfer of project deliverables, with physical sign-off, cannot be stressed enough.

Release Project Personnel

This process varies widely according to the organization, and it’s for that reason that Organization Process Assets are again so important. It may be the case that the project manager really has nothing to do in this area; a functional or weak matrix organizational structure may preclude the PM from having any responsibility for formally releasing personnel from the project. However, in cases where the organization is projectized or utilizes a strong matrix structure, the project manager will have some administrative duties to perform. This may be an informal process of verbally informing the team member’s line manager that the project is complete and the services of the person are no longer required. On the other hand, there may be paper or automated forms that the project manager is required to fill out to update a personnel assignment system, acknowledging that the person is now available to work on other projects or services. Projectized organizations may also require that the project manager provide performance reviews of the project personnel.

Lessons Learned

In life, things go well and sometimes, not so well. Authors and historians document life’s successes and failures. Intelligent people read those accounts—stories and histories—and learn from them. Likewise, during the course of the project things go well, and things don’t go so well. The problem is, there is rarely a novelist or historian to document the story. Without that, lessons we might use for future projects go to waste. Like a good history book, a document of lessons learned from a project helps to guide future projects. We don’t have to keep making the same mistakes over and over. All we have to do is ask whether a similar situation has ever existed and find out how those who preceded us handled it. This may be as simple as, “We used XYZ vendor for wiring and they were horrible! Never use them again.” Or the situation might have involved a very specific software setting that caused a problem for a development team. The lesson might just as well concern a very successful process or project innovation, such as, “We studied every article and followed all suggestions on project management in Public Sector Excellence Magazine and our project ran without a hitch.”

The point is, Lessons Learned can be positive or negative. Anything the project team learned that might possibly help another future project should be documented. Not only should they be documented, the information should be readily and easily available to future project personnel. It does no one any good for a paper list of lessons learned to be filed in a cardboard box in an offsite warehouse. With today’s technology, there is absolutely no reason every lesson learned from every project cannot be entered in an indexed database, easily searchable by keywords. People love to give advice and tell others of their experiences—IF—they believe that advice and experience is actually going to do someone some good. A project team will approach a lessons learned information gathering session with extreme cynicism if they believe their comments will be filed in a dark corner of an obscure warehouse. But if they know that their wisdom will live for future generations and be useful and actually used by others, they will put every effort into documenting successes and failures.

Yes, but…

Yes, but some projects do not complete successfully. There are as many possible reasons for this as there are failed projects and there always seems to be sufficient blame to pass around so that nobody needs to go back to their office without at least a little egg on their face when a project “has gone south.”

Scope creep, those seemingly insignificant changes and additions to the project, may have become an unbearable weight, causing the entire project to crash and burn. Unmanageable risks may have become issues that could not be overcome. Key personnel may have left the company. Costs, for whatever reason, may have spiraled out of control.

It may simply be the case that business conditions changed; the project became unnecessary or another project requiring the budget and personnel became more important or urgent.

Whatever the cause, most of the above closure activities still have to be carried out. The difference being, rather than have the project customer sign off on final deliverables, they may be asked to sign off on a statement of partially completed deliverables or other agreements or statements of understanding. The issue is that all parties have to know the status of the project so that they can make plans for limited, or no, project deliverables.

Part of the close process will be an evaluation of all costs that will be incurred if cancelation of procurement contracts incurs penalties.Procurement agreements, even if not complete, still need to be closed out and possible cancelation provisions invoked.

Unfortunately there is no “Canceled Project Process.” Each one is different so it’s important to consider all project deliverables, procurement contracts, personnel issues, and myriad other considerations and properly handle all the normal steps noted above as well as any issues that arise as a result of “dismounting in mid-stream,” as it were.

And One More Thing

What follows is not in the Project Management Body of Knowledge, that tome known only to professional project managers, normally sitting on a shelf somewhere near his or her desk (good for reference but not what one would call entertaining reading by any stretch of the imagination). No, what this author has to say about project closing is only gleaned from decades of experience, not only managing projects, but in life. And here it is: the last thing a good project manager does, the last thing a good project sponsor does, is to express gratitude to the project team. Yes, normally they have received a salary for their work and even outstanding work may be considered just and fair trade for the remuneration they’ve received.

But research has shown that in the workplace, money is not a motivator. When the employee feels they are not being sufficiently compensated the issue of money is a de-motivator. But once an employee feels they are being fairly compensated for their work, money loses its motivational flavor. It’s exactly the case with water or food—once you have enough of it, getting more is not a driving force.

What is a driving force for most humans, and employees normally count themselves among this group, is feeling appreciated, even needed. A project team is normally assembled for a one-time project; they are a team only for a short time. For that brief period, with good project management, they feel as if they are part of a group of talented individuals who have come together temporarily to produce something new and, hopefully, wonderful. Then at the close of the project they go their separate ways. People who may have enjoyed working with their team members may find that they never have the opportunity to work together again. By the end of a successful project, there is a spirit of camaraderie, of success, of winning.

This is the perfect time to capitalize on strong feelings of being part of a team, of being proud of having accomplished a goal. What a shame, when project teams are disbanded without taking advantage of these positive emotions to encourage team members by demonstrating the company’s gratitude. The size of the team and the resources of the company play a big part in what kind of demonstration of gratitude is given, but a special luncheon, possibly with a few awards for those who went above and beyond the call of duty should be considered a minimum effort on the part of the project sponsorship.

With a closing celebration, the team members will have a sense of closure that helps generate good morale in the rest of their work life. With a closure that helps to give meaning to a project, when they are requested on another project, employees will be more likely to look forward to the opportunity and will give it their best efforts.

And from a project manager’s perspective, that is as close to heaven on Earth as one can get.

by