Section 12.4. Final Project Sign-Off

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.

1. Accept project with variance noted.

2. Accept project with compensation to user/customer/sponsor for omissions or variances.

3. Continue project work until variances are addressed.

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:

• Begin with a final operational test to make sure everything actually is complete and in working order.

• Identify your contact point for operational transfer so you can coordinate the transfer of information and processes.

• Develop warranty information (express, implied) and how warranty issues will be handled.

• Develop documentation detailing ownership of copyrights or other intellectual property. You may need your corporate attorney to draw up these documents on behalf of your company.

• Contact the Training department to determine training needs. This might include train-the-trainer sessions, support documentation, or other assistance in defining and developing training materials.

• Clearly document who is responsible for operations, support, fixes, warranty issues, etc. Using the is/is not framework we used to define scope earlier in the book can be helpful to avoid making incorrect assumptions about roles and responsibilities.

• Formally transfer code, configuration, and other relevant documentation to your contact.

• Set a transfer date and develop specific transfer procedures with your contact, if needed.

• Communicate the transfer date to all relevant parties including project sponsor, stakeholders, and the project team.

• Perform any other activities that may have been contractually listed as handoff items (usually this is with external, paying customers).

• Manage user/customer/client perception. The perception of success has been built throughout your project, so be sure to end on a high note. Make the handoff a more visible affair by having a walkthrough, a demonstration, or a ribbon cutting ceremony. Making the handoff a more formal, visible affair helps build a positive perception of the project and the competence of your project team. If possible and appropriate, think of an innovative, interesting way to formalize the handoff so your user/customer/client remembers it in a positive light.

Cheat Sheet…
Project Audit

Whether or not your company requires a project audit, it's a good habit to get into following the completion of a project. An audit is an examination of the project's goals, achievements, deliverables, and metrics. It examines compliance with scope, time, cost, and quality requirements. It measures variance from functional and technical specifications. It documents final variance in terms of schedule, cost, and scope. It's a good habit to get into, but it should not turn into a major flog-fest. Problems will always crop up in a project, which is why every project has a project manager. Your job is to do your best to guide the project to successful completion through often treacherous terrain. Taking the opportunity to audit your project will build strong IT PM muscles. No pain, no gain.

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:

• Pack up and vacate temporary office space.

• Pack up and vacate temporary conference rooms.

• Pack up and vacate labs or other temporary project space.

• Clean up after yourselves in all of the temporary locations you occupied (no sense in ruining your reputation at this late date).

• Properly dispose of unneeded project documentation through shredding or other appropriate disposal mechanisms (if documents are part of legal or regulatory requirements, file and store them appropriately).

• Dispose of (transfer, sell, reassign) hard assets including servers, desktops, laptops, cell phones, PDAs, test equipment, or any other equipment acquired specifically for the project.