Table of Contents | Appendix C-10 | Appendix C-12
The Project Management Plan is prepared for all projects. It is one of several key project-planning documents that use a building-block approach to planning. It is a vehicle for documenting project scope, tasks, schedule, allocated resources, and interrelationships with other projects. It also provides details on the involved functional units, required job tasks, cost and schedule performance measurement, and milestone and review scheduling.
Revisions to the Project Management Plan occur at the end of each phase and as information becomes available. Software tools designed for work breakdown structures (WBSs), Gantt charts, network diagrams, and activity detail reports are available and should be used to complete the project management plan. The size of the project management plan should be commensurate with the size and complexity of the systems development effort and should generally follow the outline attached.
1.0 INTRODUCTIONThis section is a description of the project management plan purpose and scope.
1.1 Project Description
This section provides a description of the project in as much detail as is required to understand the nature of the project. Identify the project name and code, state the project's objective(s), and give the date the plan was finalized in the Planning Phase.
1.2 Project Background
This section describes why the project is important to the organization, its mission, and the capabilities the project will provide to the organization. Include any background or history that is important to understanding the project.
1.2.1 Project Development Strategy
This section provides an overview of the development strategy selected for the project. For example, this strategy might include prototyping the system, use of commercial off-the-shelf software, or conversion of an existing system from one hardware and software family to another.
1.2.2 Organization of the Project Plan
This section briefly describes the organization of the Project Management Plan.
1.3 Points of Contact
This section identifies the key points of contact for the project management plan, including the System Proponent, IRM Manager, and Project Manager. Identify any additional points of contact.
1.4 Project References
This section is a bibliography of key project references and deliverables produced before this point. For example, these references might include cost-benefit analyses, existing documentation describing internal processes, or existing documentation of the system if the project is a conversion.
1.5 Glossary
This section provides a glossary of all terms and abbreviations used in the plan. If the glossary is several pages in length, include it as an appendix.
2.0 ORGANIZATION AND RESPONSIBILITIES
This section should include the various organizations and staff titles, roles, and responsibilities involved in the development project. Describe team structures, reporting responsibilities and relationships, and guidelines for status reporting internally within the Information Resources Management Office and externally for any contractor support. Also provide a roles and responsibilities matrix. Identify the following key organization components:
• Organization sponsor
for the project
• Manager responsible
for the day-to-day administration of the project (if different from the
sponsor)
• Quality Assurance
(QA) organization
• Configuration Management
(CM) organization
3.0 PROJECT DESCRIPTION, SCHEDULE, AND RESOURCES
This section lists all tasks/activities to be completed within each phase of the project. If possible, use diagrams and tables (automated tools) to list the tasks and show any possible relationships among them. Repeat any subsection for each known task within the project. This section should provide a detailed description of each task and its schedule, budget, and management. Also include an estimate of each software development phase-related work effort and deliverables.
Note: The actual structure of this subsection may be organized as best suits the project. For example, suppose the project has activities in the Requirements Definition and Design Phases. Sections 3.1, Project Work Breakdown Structure, through 3.7, Risk Management, could be repeated for each of these phases; or Sections 3.1 through 3.7 could be listed once, and subsections within those sections could address the two phases separately.
3.1 Project Work Breakdown Structure
This section describes the WBSs required for the project. The WBS is a family-tree structure that relates to products produced and tasks performed at the various phases of the project life cycle. A WBS displays and defines the product(s) to be developed or produced and relates the elementsof work (tasks) to be accomplished to each other and to the end product(s).
Typically, three levels of WBSs are developed during the system development process : Summary, Project, and Contract. A WBS Dictionary is also helpful for creating and recording the WBS elements.
3.1.1 Summary Work Breakdown Structure
This section describes the Summary WBS, a high-level WBS that covers the first three levels of the Project WBS. The Summary WBS is used for management presentations but is not used for detailed day-to-day project management. The structure of the Summary WBS may vary depending on the nature of the project.
3.1.2 Project Work Breakdown Structure
This section describes the Project WBS, the detailed WBS that is used for the day-to-day management of a project. The Project WBS includes all important products and work elements, or tasks, of the project, regardless of whether these tasks are performed by DOJ personnel or by a contractor. The Project WBS may be modified, if necessary, during the life cycle. Work elements requiring more than 2 person weeks of calendar time should be subdivided until the largest bottom-level work element represents work that can be accomplished in an interval of at least 1 person week, but not more than 2 person weeks. This subdivision may appear to be arbitrary; however, the bottom-level work elements should focus on finite tasks performed by a single individual. When that is done, the application of standard productivity rates can generally predict the expected duration of the work element and eliminate wide variation in work element duration. For a software system development project, the structure of the Project WBS should also reflect the project life-cycle approach. The structure of the Project WBS may vary depending on the nature of the project and should be customized by the Project Manager to reflect the particular project and the particular path through the life cycle. For example, a full-scale initial information system development project and a software conversion process would be expected to have somewhat different WBSs.
3.1.3 Contract Work Breakdown Structure
This section describes the Contract WBS (CWBS), a further breakdown of the contract-specific WBS that covers the products and work elements, or tasks, from the Project WBS that will be performed by a contractor. In addition to items derived from the Project WBS, the CWBS includes contractor-specific items that may not be reflected in the Project WBS. Depending on the nature of the project, the contractor may be responsible for a given part of the project development activities (such as QA), for a specific part of the development life cycle (such as the Requirements Definition phase), or for the entire development process. A preliminary CWBS may be specified in the acquisition plan. The contract line items, configuration items, contract work statement tasks, contract specification, and contractor responses will typically be expressed in terms of the preliminary CWBS.
3.1.4 Work Breakdown Structure Dictionary
A WBS Dictionary provides detailed descriptions of each WBS element. Each WBS Dictionary entry should contain a title that is the same as the WBS element it amplifies; a narrative describing the work represented by the element; the effort required (in person hours); the most likely duration (in calendar days); and references to any special skills or resources required to accomplish the work. WBS Dictionary entries should be completed only for the lowest-level WBS elements. Create one or more WBS and a WBS dictionary and generate the output in the form of graphic charts.
3.2 Resource Estimates
This section should estimate, for each WBS element, the total amount of human resource effort required, by resource category. Use available tools to estimate, store, and output resource requirements per WBS element to use in the next component of the project plan.
3.3 Schedule
This section presents the project schedule.
Assumptions made about task duration, resource availability, milestones, constraints, and optimization criteria should be carefully documented.
Provide the schedule in the forms of Gantt charts, milestone tables, and deliverables and dates lists.
3.4 Acquisition Plan
This section describes the addition (and eventual departure) of project resources via the Acquisition Plan (See Appendix C-6). Each type of resource should be considered in this Acquisition Plan. The plan should specify the source of the resources, the numbers of each, the start date for each, and the duration needed. It also should consider additional, associated resource requirements, such as space, hardware and software, office equipment, other facilities, and tools.
3.5 Communication Plan
This section should discuss frequencies, target audiences, media, sources, formats, locations, forms, and types of information delivered in each form of communication. Careful thought should be given to satisfying existing standards and following existing conventions, and consideration should also be given to improving the communication process in general and to ensuring that communication is enabled and simplified for all project team members and external entities. Periodic status reports, newsletters, bulletins, problem reports, issues lists, status and review meetings, team meetings, and other forms of communication should all be carefully considered and documented when creating the communication plan. Output the communication plan in the form of a communication item/audience matrix.
3.6 Project Standards and Procedures
While the estimating and scheduling activities are going on, assign members of the planning team to identify and document standards and procedures for the project team. These standards and procedures may already be in place Agency-wide, but, if not, they should be discovered and/or determined now. These include technical standards, business-related standards, and QA standards. Technical standards and procedures include such things as naming conventions, walk-through requirements, CM rules, security standards, documentation requirements, tools, modeling techniques, and technical contractual obligations. Business-related standards and procedures include such things as procedures for scope changes, requirements changes, costing, earned value implementation, and sign-off standards. QA standards and procedures include such things as review processes, testing procedures, and defect tracking requirements. QA may also provide standards on the use of metrics.
3.7 Risk Management
For this section, refer to Appendix C-5, Risk Management Plan, created during the System Concept Development Phase. Address approaches for mitigating the effects of these factors. Add subsections as necessary to separate different categories of risk or different risk-inducing factors.
4.0 SECURITY AND PRIVACY
This section should review security and privacy requirements for the project and should ensure that the Project Management Plan reflects these requirements.
4.1 Privacy Issues
This section identifies privacy issues that should be addressed during the phases of the information system development effort and define the process to be established for addressing the privacy issues throughout the life cycle. It is important that there be a preliminary analysis of the potential privacy effects of the proposed information system. The purpose will be to establish for the project team and the review process an awareness of the privacy-related issues that will have to be addressed as the system is planned, developed, and implemented.
4.2 Computer Security Activities
This section reviews and evaluates requirements for security risk assessment and computer security planning to determine that all system vulnerabilities, threats, risks, and privacy issues will be identified and that an accurate determination will be made of the sensitivity of the system and information. Refer to Chapter 4, System Concept Development Phase; Chapter 5, Requirements Definition Phase; and Chapter 6, Design Phase, for more information on security considerations.
PROJECT MANAGEMENT PLAN OUTLINE
Cover Page
Table of Contents
1.0 INTRODUCTION
1.1 Project
Description
1.2 Project
Background
1.2.1 Project
Description Strategy
1.2.2 Organization
of the Project Plan
1.3 Points
of Contact
1.4 Project
References
1.5 Glossary
2.0 ORGANIZATION AND RESPONSIBILITIES
3.0 PROJECT DESCRIPTION, SCHEDULE
AND RESOURCES
3.1 Project
Work Breakdown Structure
3.1.1 Summary
Work Breakdown Structure
3.1.2 Project
Work Breakdown Structure
3.1.3 Contract
Work Breakdown Structure
3.1.4 Work
Breakdown Structure Dictionary
3.2 Resource
Estimates
3.3 Schedule
3.4 Acquisition
Plan
3.5 Communication
Plan
3.6 Project
Standards and Procedures
3.7 Risk
Management
4.0 SECURITY AND PRIVACY
4.1 Privacy
Issues
4.2 Computer
Security Activities