12.3. Preparing Final DocumentationAt 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:
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:
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 DocumentationFor 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 ProjectsThe 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 ApplicationsDocumentation 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 InfrastructureDocumentation 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 PlanThe 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 ReportYou 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:
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. |