Académique Documents
Professionnel Documents
Culture Documents
Talking Points
Standards
Definition
The OMB Process and Project Management
Project Management
CPIC
Architecture
Authorization
Project Scope
Integrated Management Control Plan
Project Resource Estimates
Supporting Documentation
The project plan is a consistent and coherent document that guides both project
execution and project control. The plan is used to:
Guide the projects through execution and control.
Document the planning assumptions.
Document planning decisions regarding alternatives choices.
Communicate with stakeholders.
Define management reviews (as to content, extent, and timing).
Establish project baselines for progress measurements and control.
PMBOK Glossary Definition: a project plan is a formal, approved document that defines how the project is
executed, monitored and controlled. It may be summary or detailed and may be composed of one or more
subsidiary management plans and other planning documents.
The project plan is a consistent and coherent document that guides both project
execution and project control. The plan is a product of the iterative planning
process. The plan addresses the following questions in the following sections:
What is to be done?
Whos authority?
How it is to done?
What time and dollars are needed?
Project Scope
Authorization/Chartering
Integrated Management Plan
Resource Estimates (Baseline)
Authorization
Project Scope
A Collection of Artifacts
Project Authorization
Project Scope
Project Scope
Project Scope
Defined (authorized), risk adjusted, scheduled and planned work of the project.
Project plan is founded on a mature project scope statement.
Project scope statement is founded on detailed solution architecture (SA).
Solutions architecture is found on mature enterprise architecture (EA).
Project scope is the product of the iterative scope management processes that is
generally done by the project team, using a WBS.
Using the WBS, the team to capture and then decompose all of the work of the project,
project scope.
Project Scope
What makes up the Solution Architecture?
Using IBM architecture nomenclature, for the project plan should summarize and reference the major
artifacts, including:
Architecture Overview
Architecture Decisions
Architecture Templates
Business Context Diagrams
Use Case Model
Data & Information Models (and Specifications)
(Technical) Performance Model
Systems Context
Operational Model
Deployment Units
Project Scope
Where does the Solution Architecture come from?
Project Scope
Where does the Solution Architecture come from?
Mature Project Plan Based on Detailed Solution Architecture Based on Good Enterprise Architecture
Integrated Management Control Plan or what is often referred to as Control Account Plan (CAP) is
all of the defined (authorized), risk adjusted, scheduled and planned work. The sum of all the
integrated management control plans constitutes and defines the management of the total project
scope. The scope management section details the verification and control processes, including formal
acceptance process, configuration and change controls. The management control plans include:
Scope Management Plan
Schedule (Time) Management Plan
Cost (Budget) Management Plan
Quality Management Plan
Human Resource Management Plan
Communication Management Plan
Risk Management Plan
Procurement (and Contract) Management Plan
Time (Schedule) Management Plan: Time management addresses the schedule issues and schedule
needed complete project objectives.
Includes: Descriptions of how the project schedule will be/was determined, including its planning
methodology, assumptions and decisions.
Major Artifacts: produced in this section are the:
Schedule Management (and control) Plan
Project Schedule (including project network diagram, Gantt chart, milestone chart, updated WBS)
Management Processes, include the 1) activity definition, 2) activity sequencing, 3) activity resource
estimating, 4) activity duration estimating, 5) schedule development, and 6) schedule control.
Cost Management Plan: Cost management addresses the cost of the resources needed to complete
project activities. Additionally, project cost management should also consider the effect of project
decisions on the cost of using the product, often referred to as the life-cycle costing.
Includes: Descriptions of how the project cost estimates and baseline will be/was determined,
including its planning methodology, assumptions and decisions.
Major Artifacts: produced in this section are:
Resource Requirements
Cost Estimates (and cost baseline)
Updated WBS
Cost Management (and control) Plan.
Management Processes, includes 1) cost estimating, 2) cost budgeting, and 3) cost control.
Schedule Estimate: The schedule estimate is primarily the product of the Time (Schedule)
Management processes. This section summarizes the risk-adjusted schedule estimate, estimate
assumptions and methodologies.
Cost (Budget) Estimate: The cost (budget) estimates are primarily the products of the Cost
(Budget) Management processes. This section summarizes the risk-adjusted cost estimate, estimate
assumptions and methodologies.
This section should summarize how these performance baselines (estimates) are used within the
integrated control process and by its primary control tool, earned value management (EVM). The
work breakdown structure (WBS) is used to develop (planning) cost & scheduled work baseline
estimates, guide the scheduled-work (executing), and monitor (controlling) the cost & scheduledwork baseline estimates. Estimating involves primarily scope, time, cost and risk management
processes.
Supporting Documentation
The supporting documentation section quotes, summarizes and/or references documentation that
gives more meaning, understanding, context, authority to the project plan. Supporting
documentation may include:
Mission or Strategic Plans
Organizational Policies
Legal Mandates and Legislation
Technical and Management Standards
Lessons Learned
Business Issues Details (resulting in a formal project)
Project Managers and Team Credentials
Prior Business and Technical Studies
Issues Paper on Business or Project Assumptions and Limitations
Formatting: If possible and appropriate, the supporting documentation should be a verbatim. All
documentation should be accurately concisely summarized and authoritatively referenced. If
available, all documentation should include authoritative internet addresses. If applicable, all
supporting documentation should reference the applicable project plan section.
Thanks You!
Will Brimberry, Program Manager
Project Management Office
Office of the Chief Information Officer
202-208-6052
will_Brimberry@ios.doi.gov