The Business Requirements Document (BRD) specifies the concrete, measurable business improvements that are needed in order to achieve the high-level vision, mission, and goals of the sponsoring organization. It clarifies why the project is necessary and becomes a key reference for developing and implementing project deliverables. It is typically prepared by a business analyst who is assigned to the project team and who works closely with the project manager to identify, record, and validate the business requirements. Figure 3.1 shows the outline of a comprehensive BRD. A full template and a sample completed version are found in Appendix 8 and Appendix 9.

For large, complex, or lengthy projects, the preparation of a BRD normally involves extensive information collection, synthesis, documentation, and validation. These activities therefore benefit from careful planning. The Requirements Work Plan (RWP) shown in Figure 3.2 is used for this purpose. A template of the RWP is included as Appendix 7.

The Statement of Work (SOW) specifies how the business requirements will be achieved and includes the overall project approach and tactics, a detailed timeframe with key milestones, funding details, success criteria, assumptions, constraints, and traceability to specific business requirements documented in the BRD. Essential to the SOW is a clear declaration of all activity that is in scope as well as out of scope. Figure 3.3 contains a standard format. A full SOW template and completed sample are found in Appendices 10 and 11.

Although the SOW serves as a principal reference document for all project efforts, changes are inevitable. Therefore, it is vital that a formal change management process becomes an integral part of managing the project. For this purpose a change request form template can be found in Appendix 20.

As early as possible a list of core team members, including any vendor staff, should be compiled. Contact information, area(s) of specialty and responsibility, and alternate representatives should be indicated for each person. This can be recorded in a stand-alone document or as part of the SOW. Figure 3.4 displays a standard project roster. Note that each member of the project team has an alternate identified, together with information on contacting those individuals as well as their administrative support staff. This is designed to ensure that no discipline goes unrepresented at key project meetings. If the primary is unable to attend, the alternate—who is totally aware of all relevant issues and actions—attends instead. A project roster template is located at the end of this handbook as Appendix 12.

The project plan document serves as the main control mechanism, both by specifying project phases and by decomposing these phases into specific tasks with associated timeframes, resources, dependencies, and deliverables. During project implementation, it also serves as a status tool by showing completion progress. It is typically included as Attachment C to the SOW and can be done in Microsoft Project or Excel, and possibly distributed as a document in Adobe pdf. Figure 3.5 is a segment of a project plan in Microsoft Project 2003. A standard template and samples of completed project plans can be found at the end of this book in Appendices 13.1, 13.2, 13.3 and 14.