Complex IT Project Management: 16 Steps to Success

8.2 What You Should Document

Here is a listing of documentation your project will benefit from managing on a formal basis. Many of these document types are discussed in more detail elsewhere.

• Scope. This is your project's Ten Commandments. It should be limited to a few concise declarative sentences.

• Issues log. This lists each issue by name, owner/resolver, due date, and current status.

• Assumptions, requirements, and specifications. These are clearly worded descriptions of the project deliverables or "solutions."

• Implementation strategy. This tells the story of how each requirement will be fulfilled.

• Plan Bs. A description of any risks that require an alternate implementation strategy and the detail of that strategy.

• Project schedule. The project schedule outlining the critical path and key tasks contributing to project milestones.

• Roles and responsibilities. For groups with significant deliverables, including internal and external vendors, the "who, what, when, where, and how" should be committed to writing and published. For internal teams, including them in implementation strategies is generally adequate; but with vendors, a contractual, statement of work (SOW) format is far more desirable.

• Purchasing documents. Presumably, your company has systems and forms for this process. Keep copies of any submitted for tracking, validating shipments, and budget management.

• Budgets. Your firm may have an online budget tracking system. You should track expenditures from your own point of view, because internal tracking systems are often inaccurate and not user-friendly. They also lag weeks behind so can be frustratingly dated. Use a spreadsheet to track planned, committed, and project-to-date expenses, and a running tab of dollars remaining.

• Status reports. This should leverage schedules and issues logs. Status reports are best used to advertise success, indicate completion of tasks against the overall plan, and briefly describe the impact of any open issues or delays. You should also recognize upcoming events, and update them with subsequent releases of this document. Stick to the verbs on this one. Be honest and brief. Do not make this a puff piece, nor is it desirable to appear defensive or accusatory.

• Meeting agendas and minutes. I like to publish an agenda in advance of a meeting, and then use it as the basis for the minutes. Of course, I add items to the minutes if they come up in the meeting and are important enough to capture.

• Inventory and other asset management. You may be purchasing millions of dollars worth of hardware, software licenses, and services. You should account for everything on paper, even if your company has systems in place for this purpose. The mindset you should have is that in the event that there is a perceived or actual discrepancy, you want to be able to produce your own records, be they copies of packing slips or signed time sheets. Legibility and completeness count for more than fancy online forms as long as serial numbers, addresses, costs centers, and other tangible data are collected and can be presented as truthful and accurate.

• Move schedules. For projects where relocation of equipment or users is involved, establish target move dates early with as much detail as possible, and republish them as quickly as the information changes.

• Transport logs. Be sure and record equipment being moved between locations, including make, model, serial number, network names, etc. These moves can impact maintenance contracts, fault management system management information bases (MIBs), asset management systems, disaster recovery, etc.

• User census and other detail. Many hardware or software rollouts or upgrades, as well as other project types, require detailed surveys and analyses of end-user information such as home server, e-mail or network IDs, application access rights, and so on. Proper surveying and documentation has become a professional specialty. Automated tools are available for some components of this process.

• Schedules. These are used for circuit installs, power cutovers, and other service events.

• Loaners. You may elect to authorize the short-term deployment of equipment to accommodate workarounds, to be used as swing servers, or to curry favor. It is confoundingly easy to lose track of them. Put the terms of the loan in writing, particularly the length, as well as the optional purchase by the user if returning the item becomes unlikely or undesirable.

• Job aids or user guides. Some project output requires the production of cheat sheets, navigational aids, or training documentation to assist users trying to acclimate themselves to the new system, hardware, service, location, or phone system your project has put into their work experiences.