STEP NINE
Know When You're Done
OVERVIEW
Documents That Substantiate Completion
Process for Ending Well
Transfer of the Project
Celebration!
Ending a project—sometimes called “closing”—occurs when the project sponsors accept the project deliverables. Sometimes this can be quite formal, with a signoff, but often it's less dramatic.
The time to talk about finishing well is not at the end. If you've skipped earlier steps, it's unlikely that you'll finish well. Even if you've done everything well, it's still more difficult than you'd think to end a project. During the project, you're under tremendous pressure from sponsors to hit your due dates, but when the final due date has arrived, some sponsors don't want the project to end. Suddenly they want to add every requirement they can imagine.
Projects today are increasingly complex, time constrained, and unclear. Change is the norm, not the exception. People who don't take the time to create the deliverables of the Define and Plan phases are doomed to do free overtime work.
We recently had the opportunity to develop a sales training initiative. This project involved training, coaching, mentoring, assessment, process design, and compliance. It was a wonderful chance to practice performance consulting, influencing every aspect of a company's approach to sales. The program, to be rolled out to 100 sales managers across the country, would take 18 months to deliver.
Each little, pig was ready.
Goldy and Demmy took the sides and Speedy held the wagon firm at the back corner. It wasn't long before wolf breath stirred the trees. Not one little pig eye blinked. Even the jingle of Speedy's cell phone didn't break their concentration. Each pig held his part of the wagon as tight as he could.
“Little pigs, little pigs, let me in!” BB bellowed. But the only movement was six firmer grips.
A small wolf-scented wind became a mighty huff and a mightier puff. It blew in between the bricks but the walls stood firm. A pause, and the pigs felt the weight of the wolf on the wagon-roof. Now his huffs and his puffs pushed the wagon more firmly into place. The pigs and the walls held firm.
Finally the wind stopped, and the pigs heard the wolf's tired voice. “OK, you win. I can't blow this house down. Anybody want to get breakfast?”
Demmy thought a moment and then called through the door, “BB, we're tired of running from you, and we're tired of building things for you to knock down. Can we all agree to stop?”
“That would be great,” said the wolf, blowing out a big sigh. “I really don't enjoy this anymore. I'd like to retire, maybe do some volunteer work. Something that doesn't wear me out so much. It's time for us all to move on to other things. You have my word.”
Demmy looked at his brothers, and all nodded their heads. He opened the door and the three little pigs walked out into the quiet dawn. Each pig shook BB's paw and a deal was struck to end this chapter of their lives.
The client's chief financial officer was a shrewd negotiator. As we worked out the final pricing and requirements for our contract, he asked that we share the risk of successfully completing the project. His offer was that I risk 25 percent of the total contract amount on their reaching a specific increase in sales, although it was clear at the start what the timeframe would be for that metric. The target increase was moderate, but if their sales team didn't achieve it, I'd have to return to them one quarter of a large dollar amount in services. Normally, a training class is not enough to guarantee increases in sales, but this time we weren't just creating and delivering a class. We were going to work on the entire sales function with them. I thought about the offer and agreed, with the following constraints in the contract:
the subject-matter experts would be available to us at least 10 hours a week.
low-performing sales representatives would be let go if they couldn't adapt to the new sales processes.
sales growth would be measured after 18 months (that is, 36 months after the start of the project). I negotiated for 36 months because I believed that if the training was successful and the constraints of the project were honored, sales would go down during the transition to the new processes. With any change, there are people who are just unable or unwilling to make the move.
As the project progressed, the scope fluctuated, sales regulations changed, and corporate executives were shuffled. Through it all, the project went well. There were many advantages to this shared-risk approach to projects, including executive buy-in to do everything necessary to support the change. The project constraints I requested were honored, which drove the success of the project. The sales went up after the first class and continued to go up as the processes evolved and new training was done throughout the 18 months. The sales numbers exceeded the “deal” by the 36-month point. In retrospect, I wish I'd put some bonus money in the contract for achieving the high results in addition to sharing the risk.
As I think about that project now, I believe that negotiating this unique contract in the beginning, especially the shared risk component, ensured that all parties involved knew exactly how we were going to measure the end of the project. There were deliverables at certain milestones—process redesign, three rounds of instructor-led training, e-learning components, and redesigned job responsibilities—but the most critical goal was that sales increased by a specific amount within 36 months. In the absence of such a concrete understanding reached with the sponsor before the project starts, a project manager has to find some way to describe a final deliverable—an outcome, a product, a process, something tangible or measurable that means “our work is over here” when it's transferred from the project manager to the sponsor. As a project nears the end of its schedule, emotions are high, needs have changed, and it's a bad time to make agreements you should have reached at the beginning.
Stakeholders
The stakeholders of the project are again the key players in determining what the “end” will look like. The most important stakeholders are your project sponsors. Because the project is being funded by them, they'll decide how to measure the successful completion.
Your stakeholders are just like everyone else. They aren't completely clear about what they want at the beginning of a project, but they'll know it when they see it. The communication patterns that you've established from the beginning pay off at the end. Clearly described project deliverables and timeframes all along make it less likely that a stakeholder will change the deliverables and timeframes at the end.
Still, business change does occur, and often at a less-than-ideal time. Even as the project ends, sponsors retain the right to ask for changes, more requirements, and anything else they want because it is their project. Your response as project manager is, “Yes, we can do that, and it will cost $X and take X more weeks to deliver.” The scope diagram you constructed in an earlier step will serve as proof to everyone concerned that those requests are new and that they aren't covered by the budget, time, and human resources previously granted to the project. If you skipped creating a diagram earlier, create one now.
There may be stakeholders who've agreed with (or, at least, ignored) the objectives, scope, and progress to this final point, but now find major problems. Remember what you've learned about communication, conflict, and collaboration. It may be that their last-minute dissatisfaction arises more from a need to be heard and acknowledged than from a serious need for project changes. Listen to their concerns, work toward a collaborative outcome, and find a safe bridge over which these people can retreat. Compromises and consensus are always possible if you're willing to be patient and wait it out.
As the implementation of the project deliverables approaches, specifically spell out the following for your stakeholders:
what will be delivered
when it will be delivered
to whom it will be delivered
what stakeholders' role(s) will be.
Even if these same tasks have been part of the project schedule all along, it's critical that you spend time managing the expectations of the stakeholders as you move into the final lap.
Your executive sponsor and other participants who exhibit the dominance behavioral mode will lose interest in the project as it nears completion. These people like to start things; they get bored with the endings. It will be difficult to keep them involved until the end. If your project is going well, they'll lose interest. If your project is going poorly, they'll try to take it over and fix it. Vary your communication to keep their interest, sharing successes and challenges and explaining what you'll do about those challenges. This effort will keep their interest in the project and their trust in you.
Influencers also will be on to other things. They lose interest because they feel the project is a done deal long before the end is official. Keeping them tuned in will be difficult, but you'll need their evangelist approach to get everyone through the transition. Put the influencer in charge of creating the celebration.
Most of the members of your project team and most stakeholders will be steady types. These people prefer the status quo. They're comfortable working on the project, and they grow nervous about what will happen to everyone when the project ends. Keep up communication with them and be certain they always have a clear list of tasks. Staying focused on the daily work of the project will help them move through the uncertainty.
The perfectionist compliant person doesn't want the project to end because it's never quite right. This person usually is one of your technical or subject-matter experts. Although perfection is a nice ideal, it's not cost feasible. You'll have to push your perfectionists to finish the tasks they've been assigned—especially at the end.
Questions to Ask
Ask the stakeholders the following questions as you prepare to end the project:
When would you like to set up the acceptance meeting?
Who will need to be present at the acceptance meeting?
Who will track the features that were not included in this project? How will these features/aspects be handled (for example, maintenance releases)?
Who will be the person responsible for the project deliverables after delivery? What will the hand-off period be?
When will the project team resources be released to other project work?
Project Manager's Toolkit: Documents to Define, Declare, and Substantiate Completion
Tool 9.1 lists and describes the documentation you need to have in place to complete the project. Those documents describe the objectives and scope of the work to be completed. If you haven't created and updated these documents as you've moved through the project steps, you can't substantiate the close—you can't prove that you've delivered to the sponsor all that was required of you and you can't get the sponsor's final sign-off. As a starting point in this step, open your project file and make sure you have all the documents listed in tool 9.1 and that all of them are current. Late in the project, when you can see the light at the end of the tunnel, it's tempting to let the documentation get a little obsolete. Use this tool to refresh your own memory of these deliverables, and invest the time to bring them up to date.
Depending on the conflict that occurred during the project, it may be difficult to end the project with a sponsor, and difficult to get her or him to sign off on the final output. This is another reason that your documentation needs to be in good shape. Make sure there have been updates to your project schedule to show the output delivered to the stakeholders, the date(s) it was delivered, and the person or department that received it.
In addition, future project managers may use your project documentation to help them create and maintain their project deliverables. Libraries of project documentation provide a tremendous benefit to newer project managers, and a great way for project knowledge management to be extended within an organization.
Notice that the entire project schedule is not one of these substantiating documents. Although it's useful while the project is in progress, it's only post-project value is as a historical record of the project and as a tool in the post-project review. Occasionally, the actual times for some tasks on the project schedule may be useful to defend project decisions that you made—for example, noting that requirements from a stakeholder were not delivered on time and that delayed the implementation. Most stakeholders don't want to review this level of detailed history; and, for the project manager, this level of debate is usually better avoided because of the conflict it creates.
TOOL 9.1
Your Project's Substantiating Documentation
As your project draws to a close, make certain you have all your project documentation on file. There are two purposes for ensuring that the documentation is complete and that you know where it is:
| 1. | If there is a disagreement about a deliverable that was not part of the implementation, the documentation can provide explanation. |
| 2. | These documents describe the project in a way that defines the end, and therefore will help you secure your sponsor's final sign-off. |
Here are the documents you should have:
Business Objectives: This is a statement of the ways in which this project will increase revenue, avoid or decrease costs, improve service, satisfy regulatory requirements, and/or keep up with changes in the industry and with strides made by the competition.
Project Objectives: This document describes the specific output that the project will produce and explains how you and your sponsor will measure that output so that the project endpoint is apparent to all parties.
Scope Diagram: The diagram is a graphic enumeration of the project stakeholders and a depiction of the flow of input and output to and from the project. It illustrates the outer edges of the project, clearly depicting the end product(s) to be delivered. It establishes lines of responsibility and shows what ancillary actions/interactions are not within the scope of the project.
Risk Assessment: This document, based on each stakeholder's individual assessment of the project's inherent risk (in terms of size, requirement stability, resources, and technology), establishes the likely level and source(s) of risk the project will encounter.
Constraints Statement: This statement defines the forces that will restrict or compel various aspects of the project—forces that generally focus on time, budget, and quality.
Assumptions: This document is a list of underlying assumptions about resources, expert knowledge, processes, and technology you and the project team will need to perform the work of the project.
TOOL 9.2
Criteria Describing the Project's End
Scope: The project inputs and where they will come from, and the project outputs (deliverables) and who will receive them
Business case and objectives: The financial goals the successful project will meet, generally focused on improving service, avoiding cost, increasing revenue, or reacting to government regulations
User acceptance testing: The results of the stakeholders' testing of the system prior to full implementation, including test cases and logs of results
User sign-off: The sign-off of the project sponsors based on the results of the user acceptance testing
Letter of completion: A formal communication to all stakeholders explaining the end of the project and the timing of the transition to maintenance
Project documentation archive: The location of the project documentation for future use
A Process for Ending Well
How do you know when you're done? On what criteria will you and your sponsor base your agreement that you've reached the end? Your organization may have standard steps for ending a project if it has a formal project management or development method. If not, take a look at tool 9.2, which lists criteria on which you can make your agreement.
Just as there is a stepwise process for doing the work of a project, there's a process for ending it—and ending it well. Tool 9.3 describes the four steps of that process. The steps are fairly formal, but they ensure that everyone knows that the project is completed and all acceptance is documented. Because delivering input to a project team member's performance review, formally closing contracts with external suppliers, and getting official closure from the sponsors may involve difficult conversations, some project managers avoid that work or do it casually. Taking that path doesn't serve you, your sponsors, or your team members well.
TOOL 9.3
Step-by-Step Process for Ending a Project
| Step and Activity | Description | Stakeholder(s) Responsible |
| 1–Determine if the project is done | Measure project performance and deliverables:
|
All |
| 2–Evaluate team performance | Evaluate the performance of the project team members:
|
Project manager |
| 3–Close the contract(s) | When third parties have been contracted to provide products or services to the project team:
|
External vendors, project manager |
| 4–Obtain project acceptance | Obtain formal project acceptance:
|
Executive sponsor, project manager |
Evaluate the deliverables' quality and the extent to which it satisfies the project's requirements
To complete the steps of the ending process, make certain you have all the documentation listed and described in tool 9.4. The requisite documents will substantiate decisions and changes made during the project, and will be very useful supporting data for compiling workers' performance reviews and for conducting the eventual post-project review.
TOOL 9.4
Documents Archived as You End the Project
| Material | Details and Remarks |
| Approved business case | The approved business case, including business objectives, is required to assess the project and determine whether the identified benefits were realized. This material was created in the Define phase and was modified as needed, with the approval of the project sponsors during the Plan and Manage phases. |
| Approved project management schedule | Specific tasks and due dates set forth in the project schedule are used to evaluate each team member's performance and to substantiate feedback provided by the project manager for the individual's performance review. |
| Product/service documentation | Whatever thorough documentation is expected to accompany the delivery of the final product or service, including
|
| Performance and status reports | These are the reports the project manager has compiled and sent to sponsors and stakeholders throughout the course of the project. These reports will also contribute to performance reviews. |
| Contract documents | Any external contract documentation, including
|
| Updated project tracking spread-sheet(s) and risk log | This is the final set of project tracking spreadsheets (including issues, decisions, and deliverables for review/approval), and the risk log. These materials will help the manager track changes that occurred in project deliverables and, thus, will contribute to performance reviews. |
Finally, secure the sponsor's signed acknowledgment of receipt and formal approval of the project's promised output. See tool 9.5 for the list of materials to be gathered and archived as a record of project completion. All of your stakeholders should know that these materials have been compiled and where and how they can view or get copies of them if necessary.
Turning Over the Project
When a project is completed, the work of maintaining it is shifted to the business area of the organization. The transition involves a lot of effort. Don't assume that the project will be taken over easily by the business area. If the business area hasn't really considered who'll take up whatever the project produced and delivered, you'll probably get some pushback from the recipient department.
TOOL 9.5
Documents That Declare a Project Complete
| Material | Details and Remarks |
| Project definition | This includes the project objectives and/or contracts that defined early in the project what project approval would be based on. |
| Closure report | This report documents the results of user acceptance testing. |
| Project sign-off | This is a document signed by the project sponsors that states that the project is complete. |
| Project archives | The project archive includes
|
As project manager, you're stuck at this point between two worlds. You're still getting calls requesting tweaks to the project, even though it's complete, but you've moved on to other work. Weeks before the transition, use the tools in this step to start managing the hand-off expectations of the business area. Explain how it will be done—and when. Involve the sponsor in all the communications about ending.
It may be necessary to escalate to the sponsor if the transition activities don't occur. Handle this carefully by sharing with the sponsor the date you'll no longer be involved. Also offer ideas for who might pick up the slack on the business side. Leverage the negotiation tips covered in Step 8.
Celebrate!
At the end of the project, acknowledge and celebrate the team's accomplishments. Doing so gives everyone a sense of satisfaction, recognition, and closure. When you decide how to celebrate, make sure that all stakeholders have the opportunity to participate in the festivities. Don't leave out anyone, no matter how small his or her role was in the overall scheme.
Communication
It's tempting to cut back the communication a bit when the end is in sight. Don't make that mistake. Continue sending out your project status spreadsheets, showing progress, and keeping the end visible to everyone. Be very clear about end dates, including those for testing and implementation plans when those are part of the project. If possible, set the dates and build the stakeholders' anticipation of their involvement in the post-project review, which we'll address in Step 10.
Communication must be very explicit at the hand-off point. There are three possible transition scenarios:
1. Individual stakeholders will be responsible going forward for the new processes, the technology, and the other deliverables of the project.
2. Multiple stakeholders will be responsible for everything, but the ownership is unclear.
3. No one has been assigned to take care of the deliverables from your project.
Having a single person responsible for a project deliverable is the best option. For example, one IT person takes responsibility for maintaining the software, and one functional manager maintains the process. In such a case, what you need to do is share the specifics that pertain to their parts of the project with each of those individuals.
Oftentimes, the whole project gets thrown into the work of a functional area in the business without much thought about who really will be responsible for it. In that case, you'll have to take more time to communicate all the specifics about the deliverables to everyone who's involved in that functional area.
Finally, in the worst case, there are no resources dedicated to maintaining the project deliverables. As project manager, you can complain about this, but there's a chance that no one will listen. In that case, you have to make the difficult decision to walk away. Be certain that your documentation is archived completely and that the stakeholders have been notified formally about the project ending and the location of the final deliverable. Then, move on.
What If I Skip This Step?
Projects are hard work and it's so tempting to let your guard down as the end approaches. People begin to relax a little and generally feel pretty good about themselves and each other. And it's tempting to gloss over formal ending procedures. But not ending a project well costs the business in several ways:
Multiple people doing similar work: If the hand-off to the business is not clear, chances are good that people on the project team will continue working on the project, as will the stakeholders. Redundant work is very expensive and unnecessary. Unclear roles also create conflict very quickly.
The cost to you is that you're working on too many things: If you've done a good job on the project and you've built a lot of trust with the stakeholders, it will be natural for them to call you for help even after the project ends. At first, it might feel good to be so valuable, but eventually you'll be embroiled in the copious responsibilities of a new assignment and you'll find that the recurring calls and questions are preventing you from getting your current work done.
Lurking Landmines
The project's final product or service has been delivered and the transition completed, but your client hasn't paid your earlier invoices. This is a tricky situation. Let's say your client is a little behind on payment for work you've delivered and invoiced. Do you hold off the project transition and implementation until all earlier invoices have been paid? This is a situation that demands you speak frankly with your sponsor to find out what's holding up payments. In worst-case scenarios, you may have to state clearly that you will deliver the final pieces only when the outstanding invoices have been paid. That's a very bad situation to be in and taking that tack can create conflict, but sometimes it's your only recourse.
Sponsorship changes at the last minute. If there is a reorganization late in the project, it can be devastating to your plans for project completion because new sponsors almost always have new requirements. If possible, get sign-off on the project product or service deliverables from the original sponsor before he or she leaves. Meet as soon as you can with the new sponsor to review the project status. Make it clear that his or her support and sponsorship are critical to a successful completion.
Step 9 Checklist
Be sure that you have built and shared all the documentation recommended in Steps 2, 3, and 4—business and project objectives, scope diagram, risk assessments, statement of constraints, and role definitions.
Proceed more formally than you feel you should. Keep the project plan tight all the way through the transition to the business area.
Involve the sponsors constantly as your project moves into the business area.
The Next Step
The final step in managing your project is learning from it. Having the discipline to do a post-project review will strengthen your project management skills and prepare you for even more success in future projects.
