12.4. Final Project Sign-Off
Before you get too antsy to move on, remember that you need to obtain final project sign-off and transfer any operational, support, or training issues to the responsible parties. Let's look at these briefly.
12.4.1. Formal Project Sign-Off
Formal sign-off is truly the end of the project. In a sense, the work's not done 'til the project sponsor says so. Typically, you should present the project sponsor with your project closure report, an updated copy of the project plan (if appropriate or required), and obtain formal agreement the project is complete.
What if the project sponsor does not agree with you that the project is complete? There are several steps you can take to address this scenario.
Clearly you want to avoid any of these scenarios because it means that somewhere along the line, something was misunderstood or miscommunicated. If you discovered open change requests or work orders (discussed earlier), you may have realized too late that there were portions of the deliverables missing. This means there is a gap in your project management process that you should find and repair. However, it doesn't have to mean the end of the world either. Work with your project sponsor (who is sometimes an external customer paying for the project) to define acceptable next steps, generate a plan for accomplishing those next steps, and move along. It might be a bit deflating to think you're finished only to have another "to do" list, but it happens. When you move into a brand new house, you often go through and find things that need to be finished. This is often called a punch list, not because it makes you want to punch the wall (though it might), but because each item is "punched" as it is completed. The same may be required in some IT projects though the goal is to have a clean finish with no additional "to do" items. If you discover additional items, it's very important to figure out where you went wrong, not to blame the guilty parties, but to discover how you can fix your process to prevent this type of error in the future.
12.4.2. Operational Transfer
The process of transferring responsibility to another party for project deliverables should be well planned. This improves the perception of quality of your project and helps make everyone's life easier. Think about the last time you bought a new car. If the dealer just pulled the new car out of the lot (dust, window smudges, windows stickers, and all) and tossed you the car keys, you probably would have wondered about the car, the dealer, and the quality. On the other hand, most dealers make a big deal out of delivering the car. It's washed, polished, the windows are clean, the tires inflated, the tank is full, and they sit you down and explain every last detail of how the car works (most of which you promptly forget because you really can't wait to get behind the wheel). This whole experience can add to or detract from your car buying experience just as the project handoff can. Remember, throughout this book we've discussed best practices to give you the knowledge to deliver the best IT project you can. It's not always this tidy in the real world, but it's what you should aim for.
In Chapter 11, we discussed preparing for operational transfer as part of your managing, tracking, and completing project work. Earlier in this chapter, we discussed some of the documentation you might need for a smooth transfer. Now, let's look at some of the steps you can take to successfully hand off the project. Some of these steps should have been completed during project work. This list is a checklist you can use to be sure you have all your bases covered:
12.4.3. Dispose of Project Assets
During the course of your project, you may have acquired various tangible assets. That might include chairs, tables, desks, computers, lab or test equipment, temporary office space, etc. At this point, you should determine the status of all project assets and the appropriate disposition of those assets. Here's a partial list to get you started: