Section 12.3. Preparing Final Documentation

12.3. Preparing Final Documentation

At the end of each project, there are numerous project documents that should be prepared including a finalized project plan, variance reports, support or training documents, and more. Here's a list of some of the types of documentation you may need to prepare:

• Project reports and documentation

• Project closure report

• System and configuration documentation

• Program code

• Instruction manuals

• Training manuals

• User documentation

• Test criteria and results

• Regulatory information (test and results documents proving conformity to legal specifications, etc.)

• Acceptance or product certification

This list is not exhaustive but should clue you in to the types of documentation you should prepare as you close out your report. As we've discussed previously, it's always easier to document these things as quickly as possible so you don't have to expend tremendous effort later trying to remember project detail and fill in the gaps. In some cases, there may be legal requirements for the timing of these documents, so keep those in mind as you move forward.

In addition, there are probably different formats you'll need to use to distribute these documents. Here's a starter list to get you thinking about the possibilities:

• Printed hard copy

• Soft copy (network location with link, e-mail attachment)

• DVD or CD

• PowerPoint or multimedia presentations

• Online documentation (Adobe's PDF is a popular format for this) for downloading, viewing, and printing

• Help files and FAQs (within the product or online)

• FTP sites (for downloads)

• Video, audio, Web conferencing

• Intranets and extranets

Take a look at your communication plan and determine who needs which documents and what type of project close-out communication is appropriate for the various stakeholders. You might need to create a formal report for your project sponsor or develop a presentation for corporate executives. Think about all the people you need to communicate with and which method of communication will be most convenient for them. Remember that project success is determined, in part, by the perception of success so use this communication opportunity to create a positive impression of your project outcomes.

12.3.1. Technical Documentation

For IT projects, system and configuration documentation is critical. The internal deployment/support team or an external vendor (to whom operations are transferred) will need this information. To develop appropriate documentation, first determine who the intended audience is for each type of documentation. Look at the user environment to determine the best format and method of distribution. If in doubt, ask. For instance, it wouldn't make sense for you to create Help files and FAQ on a website if none of the users have Internet access. Assign owners for these tasks (if this falls within your project area) and make sure these documents are generated. If preparation of these documents is outside your area, be sure to keep your IT project team in the loop so they can provide information to the folks preparing the documentation. There are three primary types of IT projects and each has slightly different documentation needs: software development, desktop applications, and network infrastructure.

12.3.1.1. Software Development Projects

The program code itself must be thoroughly documented along with the versions of any plug-ins or external applications used. The configuration of the operating system the code has been tested on and the version and configuration information about any other software used in the development, testing, or support of the product should be documented. Relevant backup and recovery procedures should also be documented where needed. If bug fixes were included, the bug numbers and descriptions should be listed. If any temporary workarounds were included, those should also be documented along with notes about how to unwind those changes.

12.3.1.2. Desktop Applications

Documentation about the applications licensing, versions, configurations, and images (disk images, often referred to as ghost images), as well as configuration and images of the operating system should be prepared. If any workarounds are required, these should be noted along with how to back out of the workarounds once a fix is installed.

12.3.1.3. Network Infrastructure

Documentation should include version and configuration information for all relevant network infrastructure components such as network servers, application servers, Web servers, print servers, routers, gateways, firewalls, proxy servers, wireless access points, etc. Include any unique information regarding these components such as order of start up or shut down or special steps needed to properly install, configure, troubleshoot, or maintain this equipment. Backup and recovery procedures should also be well documented (and tested). Record currently installed firmware versions and workarounds, if used. Where applicable, also provide diagrams and/or updated blueprints showing network configuration such as subnets, cabling, router configuration, etc.

12.3.2. Final, Updated Project Plan

The project plan that you've used throughout this project to help you stay on course should be fairly up to date with the latest versions of schedule, budget, variances, issues logs, and whatever else you included in your project plan. Take time to gather the final data for the project and update the project plan one last time. This will enable you to finalize numbers in terms of plan versus actual. This data will be needed both for the project closure report (see next section) and for your communications with your project sponsor, stakeholders, or corporate executives. Have the team look at the project schedule and budget reserves to determine how close (or far) your estimates were from actual. This is a great opportunity to improve your estimating skills through examining planned estimates versus actual, looking at how you calculated reserves, understanding how reserves were used, and learning what you can do better next time.

12.3.3. Project Closure Report

You should prepare a project closure report. This report should be distributed to the project sponsor, appropriate stakeholders, and key corporate executives (if appropriate). This report should adhere to the following guidelines:

1. Include a brief statement of project background and objectives.

2. List members of the project team and contributors including name, department, title, project role, and next project assignment (where applicable).

3. State reason for project closure (completion, postponement, cancellation).

4. List planned and actual project deliverables. Discuss the gaps, if any.

5. List planned and actual project schedule. Briefly discuss changes that impacted final delivery date.

6. List planned and actual project budget. Briefly discuss any variances.

7. Identify project ROI (return on investment), if possible.

8. List any outstanding risks as well as related contingency plans, if applicable.

9. Include a summary of lessons learned (discussed later in this chapter).

10. Discuss methods or processes developed during the project that could (should) be reused and why.

11. Discuss external (organizational, departmental, procedural) limitations or problems that impacted the project and provide suggestions for improvement.

12. Identify ongoing support or maintenance needs, plans for or status of operational transfer.

13. If needed, identify next steps. This might include moving onto the next phase of a multi-phased project, filing required legal documentation (copyrights, patents, conformance to regulatory requirements, etc.), or moving any open tasks to a post-deployment plan.

14. Obtain formal project closure approval from the project sponsor.

A project closure report is a summary of the entire project at a high level. Avoid delving into detail in this report. The updated project plan should include all the project detail and this data should not be simply copied and pasted into the project closure report. Think of this report as a summary that you could look back over in a few years. It will tell you all the salient information about the project without delving into detail that in two or three years will be completely irrelevant to you.

One important note hereif a project is cancelled, it's especially important to formalize the close-out so that you and all those involved are aware the project was cancelled and not just forgotten. Projects are cancelled for many reasons, some of which we've discussed throughout this book. If your project is cancelled, go through the project closure report process to document the project and to obtain formal approval to cancel the project. This avoids the type of miscommunication where perhaps you thought you were told to cancel the project but were, in fact, told to put it on hold temporarily. It also should capture the reason for canceling the project and on whose authority. If someone comes back to second-guess this decision, it should be well documented and defensible.