4.1.1 Inputs to Project Plan Development

.1 Other planning outputs. All of the outputs of the planning processes in the other knowledge areas (Section 3.3 provides a summary of these project planning processes) are inputs to developing the project plan. Other planning outputs include both base documents such as the work breakdown structure as well as the supporting detail. Many projects will also require application area-specific inputs (e.g., most construction projects will require a cash flow forecast).

.2 Historical information. The available historical information (e.g., estimating data-bases, records of past project performance) should have been consulted during the other project planning processes. This information should also be available during project plan development to assist with verifying assumptions and assessing alternatives that are identified as part of this process.

.3 Organizational policies. Any and all of the organizations involved in the project may have formal and informal policies whose effects must be considered. Organizational policies which typically must be considered include, but are not limited to:

   Quality management—process audits, continuous improvement targets.

   Personnel administration—hiring and firing guidelines, employee performance reviews.

   Financial controls—time reporting, required expenditure and disbursement reviews, accounting codes, standard contract provisions.

.4 Constraints. A constraint is an applicable restriction that will affect the performance of the project. For example, a predefined budget is a constraint that is highly likely to limit the team’s options regarding scope, staffing, and schedule. When a project is performed under contract, contractual provisions will generally be constraints.

.5 Assumptions. Assumptions are factors that, for planning purposes, aree considered to be true, real, or certain. Assumptions affect all aspects of project planning, and are part of the progressive elaboration of the project. Project teams frequently identify, document, and validate assumptions as part of their planning process. For example, if the date that a key person will become available is uncertain, the team may assume a specific start date. Assumptions generally involve a degree of risk.

4.1.2 Tools and Techniques for Project Plan Development

.1 Project planning methodology. A project planning methodology is any structured approach used to guide the project team during development of the project plan. It may be as simple as standard forms and templates (whether paper or electronic, formal or informal) or as complex as a series of required simulations (e.g., Monte Carlo analysis of schedule risk). Most project planning methodologies make use of a combination of "hard" tools such as project management software and "soft" tools such as facilitated startup meetings.

.2 Stakeholder skills and knowledge. Every stakeholder has skills and knowledge that may be useful in developing the project plan. The project management team must create an environment in which the stakeholders can contribute appropriately (see also Section 9.3, Team Development).
Who contributes, what they contribute, and when they contribute will vary. For example:

   On a construction project being done under a lump sum contract, the professional cost engineer will make a major contribution to the profitability objective during proposal preparation when the contract amount is being determined.

   On a project where staffing is defined in advance, the individual contributors may contribute significantly to meeting cost and schedule objectives by reviewing duration and effort estimates for reasonableness.

.3 Project management information system (PMIS). A PMIS consists of the tools and techniques used to gather, integrate, and disseminate the outputs of the other project management processes. It is used to support all aspects of the project from initiating through closing and generally includes both manual and automated systems.

.4 Earned value management (EVM). A technique used to integrate the project's scope, schedule, and resources and to measure and report project performance from initiation to closeout. Further discussions on EVM can be found in Section 7.4.2.3.

4.1.3 Outputs from Project Plan Development

.1 Project plan. The project plan is a formal, approved document used to manage project execution. The project schedule lists planned dates for performing activities and meeting milestones identified in the project plan (see Section 6.4.3.1). The project plan and schedule should be distributed as defined in the communications management plan (e.g., management of the performing organization may require broad coverage with little detail, while a contractor may require complete details on a single subject). In some application areas, the term integrated project plan is used to refer to this document.
  A clear distinction should be made between the project plan and the project performance measurement baselines. The project plan is a document or collection of documents that should be expected to change over time as more information becomes available about the project. The performance measurement baselines will usually change only intermittently, and then generally only in response to an approved scope of work or deliverable change.
  There are many ways to organize and present the project plan, but it commonly includes all of the following (these items are described in more detail elsewhere):

   Project charter.

   A description of the project management approach or strategy (a summary of the individual management plans from the other knowledge areas).

   Scope statement, which includes the project objectives and the project deliverables.

   Work breakdown structure (WBS) to the level at which control will be exercised.

   Cost estimates, scheduled startand finish dates (schedule), and responsibility assignments for each deliverable within the WBS to the level at which control will be exercised.

   Performance measurement baselines for technical scope, schedule, and cost—i.e., the scheduled baseline (project schedule) and the cost baseline (time-phased project budget).

   Major milestones and target dates for each.

   Key or required staff and their expected cost and/ or effort.

   Risk management plan, including: key risks, including constraints and assumptions, and planned responses and contigencies (where appropriate) for each.

   Subsidiary management plans, namely:

     Scope management plan ( Section 5.2.3.3).
     Schedule management plan ( Section 6.4.3.3).
     Cost management plan ( Section 7.2.3.3).
     Quality management plan ( Section 8.1.3.1).
     Staffing management plan ( Section 9.1.3.2).
     Communications management plan ( Section 10.1.3.1).
     Risk response plan ( Section 11.5.3.1).

      Each of these plans could be included if needed and with detail to the extent required for each specific project.

   Open issues and pending decisions.
   Other project planning outputs should be included in the formal plan based upon the needs of the individual project. For example, the project plan for a large project will generally include a project organization chart.

.2 Supporting detail. Supporting detail for the project plan includes:

   Outputs from other planning processes that are not included in the project plan.

   Additional information or documentation generated during development of the project plan (e.g., constraints and assumptions that were not previously known).

   Technical documentation such as, a history of all requirements, specifications, and conceptual designs.

   Documentation of relevant standards.

   Specifications from early project development planning.

   This material should be organized as needed to facilitate its use during project plan execution.