Project Planning (PP) Category: Project Management
Notes:
·
The contents of this web page were extracted from
the following document: Capability Maturity Model® Integration
(CMMISM), Version 1.1, Continuous Representation,
CMU/SEI-2002-TR-011, March 2002 (CMMI-SE/SW/IPPD/SS). Copyright 2002 by
Carnegie Mellon University. NO WARRANTY.
·
Ignore the identifiers
in square brackets that appear at the end of paragraphs.
·
The formatting may not
be the same as in the printed CMMI document. The web page is best viewed in
Internet Explorer.
·
In the CMMI, a subset is known as a "Process
Area (PA)" and a requirement is known as a "Practice". The
specific practices are referred to as SPs and the generic practices are
referred to as GPs.
·
This web page contains the text for SPs and GPs as
it appears in Chapter 7 of the CMMI document, in the section corresponding to
the process area named in the heading of this page. This web page does not
include the detailed description of the GPs that appears in a separate chapter
of the CMMI document; the detailed
description of the GPs is available in a separate web
page. (Note: Using the hyperlink provided here will open that web page in a
separate window.)
Purpose The purpose of Project Planning is to establish and
maintain plans that define project activities.
[PA163]
Introductory
Notes The Project Planning process area involves the following: [PA163.N101]
· Developing the project plan
· Interacting with stakeholders appropriately
· Getting commitment to the plan
· Maintaining the plan
Planning begins with requirements that define the product and project. [PA163.N102]
Planning includes estimating the attributes of the work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing project risks. Iterating through these activities may be necessary to establish the project plan. The project plan provides the basis for performing and controlling the project’s activities that address the commitments with the project’s customer. [PA163.N103]
The project plan will usually need to be revised as the project progresses to address changes in requirements and commitments, inaccurate estimates, corrective actions, and process changes. Specific practices describing both planning and re-planning are contained in this process area. [PA163.N104]
The term “project plan” is used throughout the generic
and specific practices in this process area to refer to the overall plan for
controlling the project. [PA163.N105]
Refer to the Requirements Development process area for more information
about developing requirements that define the product and product components.
Product and product-component requirements and changes to those requirements
serve as a basis for planning and re-planning. [PA163.R101]
Refer to the Requirements Management process area for more information
about managing requirements needed for planning and re-planning.
[PA163.R102]
Refer to the Risk Management process area for more information about
identifying and managing risks. [PA163.R103]
Refer to the Technical Solution process area for more information about transforming
requirements into product and product-component solutions.
[PA163.R104]
Specific Goals
SG 1 Establish
Estimates [PA163.IG101]
Estimates of project planning parameters are established and maintained.
SG 2 Develop
a Project Plan [PA163.IG102]
A project plan is established and maintained as the basis for managing the project.
SG 3 Obtain
Commitment to the Plan [PA163.IG103]
Commitments to the project plan are established and maintained.
Generic Goals
GG 1 Achieve
Specific Goals [CL102.GL101]
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GG 2 Institutionalize
a Managed Process [CL103.GL101]
The process is institutionalized as a managed process.
GG 3 Institutionalize
a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GG 4 Institutionalize
a Quantitatively Managed Process
[CL105.GL101]
The process is institutionalized as a quantitatively managed process.
GG 5 Institutionalize
an Optimizing Process [CL106.GL101]
The process is institutionalized as an optimizing process.
Practice-to-Goal Relationship Table
SG 1 Establish Estimates
[PA163.IG101]
SP 1.1-1 Estimate the Scope of the Project
SP 1.2-1 Establish Estimates of Work Product and Task Attributes
SP 1.3-1 Define Project Life Cycle
SP 1.4-1 Determine Estimates of Effort and Cost
SG 2 Develop a Project Plan
[PA163.IG102]
SP 2.1-1 Establish the Budget and Schedule
SP 2.2-1 Identify Project Risks
SP 2.3-1 Plan for Data Management
SP 2.4-1 Plan for Project Resources
SP 2.5-1 Plan for Needed Knowledge and Skills
SP 2.6-1 Plan Stakeholder Involvement
SP 2.7-1 Establish the Project Plan
SG 3 Obtain Commitment to the Plan
[PA163.IG103]
SP 3.1-1 Review Plans that Affect the Project
SP 3.2-1 Reconcile Work and Resource Levels
SP 3.3-1 Obtain Plan Commitment
GG 1 Achieve Specific Goals [CL102.GL101]
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process [CL103.GL101]
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process [CL104.GL101]
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]
GP 4.1 Establish Quantitative Objectives for the Process
GP 4.2 Stabilize Subprocess Performance
GG 5 Institutionalize an Optimizing Process [CL106.GL101]
GP 5.1 Ensure Continuous Process Improvement
GP 5.2 Correct Root Causes of Problems
Specific Practices by Goal
SG 1 Establish Estimates
Estimates of project planning parameters are
established and maintained.
[PA163.IG101]
Project planning parameters include all information
needed by the project to perform the necessary planning, organizing, staffing,
directing, coordinating, reporting, and budgeting. [PA163.IG101.N101]
Estimates of planning parameters should have a sound
basis to provide confidence that any plans based on these estimates are capable
of supporting project objectives.
[PA163.IG101.N102]
Factors that are typically considered when estimating
these parameters include the following:
[PA163.IG101.N103]
· Project requirements, including the product requirements, the requirements imposed by the organization, the requirements imposed by the customer, and other requirements that impact the project
· Scope of the project
· Identified tasks and work products
· Technical approach
· Selected project life-cycle model (e.g., waterfall, incremental, spiral, etc.)
· Attributes of the work products and tasks (e.g., size or complexity)
· Schedule
· Models or historical data for converting the attributes of the work products and tasks into labor hours and cost
· Methodology (models, data, algorithms) used to determine needed material, skills, labor hours, and cost
Documenting the estimating rationale and supporting data
is needed for stakeholders’ review and commitment to the plan and for
maintenance of the plan as the project progresses. [PA163.IG101.N104]
SP 1.1-1 Estimate the Scope of the Project
Establish
a top-level work breakdown structure (WBS) to estimate the scope of the
project. [PA163.IG101.SP101]
The WBS evolves with the project. Initially a top-level
WBS can serve to structure the initial estimating. The development of a WBS
divides the overall project into an interconnected set of manageable
components. The WBS is typically a product-oriented structure that provides a
scheme for identifying and organizing the logical units of work to be managed,
which are called “work packages.” The WBS provides a reference and
organizational mechanism for assigning effort, schedule, and responsibility and
is used as the underlying framework to plan, organize, and control the work
done on the project.
[PA163.IG101.SP101.N101]
Typical Work Products
1. Task descriptions [PA163.IG101.SP101.W101]
2. Work package descriptions [PA163.IG101.SP101.W102]
3. WBS
[PA163.IG101.SP101.W103]
Subpractices
1. Develop a WBS based on the product
architecture. [PA163.IG101.SP101.SubP101]
The WBS provides a scheme for
organizing the project’s work around the products that the work supports. The
WBS should permit the identification of the following items: [PA163.IG101.SP101.SubP101.N101]
· Identified risks and their mitigation tasks
· Tasks for deliverables and supporting activities
· Tasks for skill and knowledge acquisition
· Tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans
· Tasks for integration and management of non-developmental items
2. Identify the work packages in sufficient detail
to specify estimates of project tasks, responsibilities, and schedule. [PA163.IG101.SP101.SubP102]
The top-level WBS is intended to
help in gauging the project work effort in terms of tasks and organizational
roles and responsibilities. The amount of detail in the WBS at this more
detailed level helps in developing realistic schedules, thereby minimizing the
need for management reserve.
[PA163.IG101.SP101.SubP102.N101]
3. Identify work products (or components of
work products) that will be externally acquired.
[PA163.IG101.SP101.SubP103]
Refer
to the Supplier Agreement Management process area for more information about
acquiring work products from sources external to the project. [PA163.IG101.SP101.SubP103.R101]
4. Identify work products that will be reused. [PA163.IG101.SP101.SubP104]
SP 1.2-1 Establish Estimates of Work Product and Task Attributes
Establish
and maintain estimates of the attributes of the work products and tasks. [PA163.IG101.SP102]
Size is the primary input to many models used to estimate
effort, cost, and schedule. The models may also be based on inputs such as
connectivity, complexity, and structure.
[PA163.IG101.SP102.N102]
Examples of
types of work products for which size estimates are made include the following: [PA163.IG101.SP102.N103]
· Deliverable and nondeliverable work products
· Documents
· Operational and support software
Examples of
size measures include the following: [PA163.IG101.SP102.N104]
· Number of functions
· Function points
· Source lines of code
· Number of classes and objects
· Number of requirements
· Number of interfaces
· Number of pages
· Number of inputs and outputs
· Number of technical risk items
· Volume of data
The estimates should be consistent with project
requirements to determine the project’s effort, cost, and schedule. A relative
level of difficulty or complexity should be assigned for each size attribute. [PA163.IG101.SP102.N101]
Typical Work Products
1. Technical approach [PA163.IG101.SP102.W101]
2. Size and complexity of tasks
and work products [PA163.IG101.SP102.W102]
3. Estimating models [PA163.IG101.SP102.W103]
4. Attribute estimates [PA163.IG101.SP102.W104]
Subpractices
1. Determine the technical approach for the
project. [PA163.IG101.SP102.SubP101]
The technical approach defines a
top-level strategy for development of the products. It includes decisions on
architectural features, such as distributed or client server; state-of-the-art
or established technologies to be applied, such as robotics, composite
materials, or artificial intelligence; and breadth of the functionality
expected in the final products, such as safety, security, and ergonomics. [PA163.IG101.SP102.SubP101.N101]
2. Use appropriate methods to determine the
attributes of the work products and tasks that will be used to estimate the
resource requirements. [PA163.IG101.SP102.SubP102]
Methods for determining size and
complexity should be based on validated models or historical data. [PA163.IG101.SP102.SubP102.N101]
The methods for determining
attributes evolve as our understanding of the relationship of product
characteristics to attributes increases. [PA163.IG101.SP102.SubP102.N102]
Examples
of current methods include the following:
[PA163.IG101.SP102.SubP102.N103]
· Number of logic gates for integrated circuit design
· Lines of code or function points for software
· Number/complexity of requirements for systems engineering
· Number of square feet for standard-specified residential homes
3. Estimate the attributes of the work products
and tasks. [PA163.IG101.SP102.SubP103]
4. Estimate, as appropriate, the labor,
machinery, materials, and methods that will be required by the project. [PA163.IG101.SP102.SubP104]
SP 1.3-1 Define Project Life Cycle
Define
the project life-cycle phases upon which to scope the planning effort. [PA163.IG101.SP103]
The determination of a project’s life-cycle phases
provides for planned periods of evaluation and decision making. These are
normally defined to support logical decision points at which significant
commitments are made concerning resources and technical approach. Such points
provide planned events at which project course corrections and determinations
of future scope and cost can be made.
[PA163.IG101.SP103.N101]
For Software Engineering
The determination of project phases for software typically includes selection and refinement of a software development model to address interdependencies and appropriate sequencing of software project activities. [PA163.IG101.SP103.N101.AMP101]
For Systems Engineering
Identify the major product phase (e.g., concept exploration, development, etc.) for the current state of the product, expected future phases, and the relationships and effects among phases. Adjust planning parameters to account for relationships and effects among phases. [PA163.IG101.SP103.N101.AMP102]
The project life cycle consists of phases that need to be
defined depending on the scope of requirements, the estimates for project
resources, and the nature of the project. Larger projects may contain multiple
phases, such as concept exploration, development, production, operations, and
disposal. Within these phases, subphases may be needed. A development phase may
include subphases such as requirements analysis, design, fabrication, integration,
and verification. Depending on the strategy for development, there may be
intermediate phases for the creation of prototypes, increments of capability,
or spiral model cycles.
[PA163.IG101.SP103.N102]
Understanding the project life cycle is crucial in
determining the scope of the planning effort and the timing of the initial
planning, as well as the timing and criteria (critical milestones) for
re-planning.
[PA163.IG101.SP103.N103]
Typical Work Products
1. Project life-cycle phases [PA163.IG101.SP103.W101]
SP 1.4-1 Determine Estimates of Effort and Cost
Estimate
the project effort and cost for the work products and tasks based on estimation
rationale. [PA163.IG101.SP104]
Estimates of effort and cost are generally based on the results
of analysis using models or historical data applied to size, activities, and
other planning parameters. Confidence in these estimates is based on the
rationale for the selected model and the nature of the data. There may be
occasions where the available historical data does not apply, such as where
efforts are unprecedented or where the type of task does not fit available
models. An effort is unprecedented (to some degree) if a similar product or
component has never been built. An effort may also be unprecedented if the
development group has never built such a product or component. [PA163.IG101.SP104.N101]
Unprecedented efforts are more risky, require more
research to develop reasonable bases of estimate, and require more management
reserve. The uniqueness of the project must be documented when using these
models to ensure a common understanding of any assumptions made in the initial
planning stages.
[PA163.IG101.SP104.N102]
Typical Work Products
1. Estimation rationale [PA163.IG101.SP104.W101]
2. Project effort estimates [PA163.IG101.SP104.W102]
3. Project cost estimates [PA163.IG101.SP104.W104]
Subpractices
1. Collect the models or historical data that
will be used to transform the attributes of the work products and tasks into
estimates of the labor hours and cost. [PA163.IG101.SP104.SubP101]
For Software Engineering
Within the software-engineering area, many parametric models have been developed to aid in estimating cost and schedule. The use of these models as the sole source of estimation is not recommended as these models are based on historical project data that may or may not be pertinent to your project. Multiple models and/or methods may be used to ensure a high level of confidence in the estimate. [PA163.IG101.SP104.SubP101.AMP101]
Historical data include the cost,
effort, and schedule data from previously executed projects, plus appropriate
scaling data to account for differing sizes and complexity. [PA163.IG101.SP104.SubP101.N101]
2. Include supporting infrastructure needs when
estimating effort and cost. [PA163.IG101.SP104.SubP102]
The support infrastructure
includes items needed from a development and sustainment perspective for the
product.
[PA163.IG101.SP104.SubP102.N101]
For Software Engineering
Consider critical computer resources in the host environment, in the test environment, in the target environment, or in any combination of these. Computer resource estimation typically includes the following: [PA163.IG101.SP104.SubP102.N101.AMP101]
· identifying the critical computer resources for the software project and
· basing estimates of critical computer resources on allocated requirements
For Software Engineering
Examples of critical computer resources include the following: [PA163.IG101.SP104.SubP102.N101.AMP102]
· Memory, disk, and network capacity
· Processor power
· Communications channel capacity
· Workstation power
· Peripheral capacity
For Software Engineering
Examples of software-engineering facilities include the following: [PA163.IG101.SP104.SubP102.N101.AMP103]
· Host computers, peripherals, and networks
· Software test computers and peripherals
· Target computer environment software
· Software-engineering environment (i.e., software tools)
3. Estimate effort and cost using models and/or
historical data. [PA163.IG101.SP104.SubP103]
Effort and cost inputs used for
estimating typically include the following: [PA163.IG101.SP104.SubP103.N101]
· Judgmental estimates provided by an expert or group of experts (e.g., Delphi Method)
· Risks, including the extent to which the effort is unprecedented
· Critical competencies and roles needed to perform the work
· Product and product-component requirements
· Technical approach
· WBS
· Size estimates of work products and anticipated changes
· Cost of externally acquired work products
· Selected project life-cycle model and processes
· Life-cycle cost estimates
· Capability of tools provided in engineering environment
· Skill levels of managers and staff needed to perform the work
· Knowledge, skill, and training needs
· Facilities needed (e.g., office and meeting space and workstations)
· Engineering facilities needed
· Capability of manufacturing process(es)
· Travel
· Level of security required for tasks, work products, hardware, software, personnel, and work environment
· Service-level agreements for call centers and warranty work
· Direct labor and overhead
SG 2 Develop a Project Plan
A project plan is established and maintained as
the basis for managing the project.
[PA163.IG102]
A project plan is a formal, approved document used to
manage and control the execution of the project. It is based on the project
requirements and the established estimates.
[PA163.IG102.N101]
The project plan should consider all phases of the
project life cycle. Project planning should ensure that all plans affecting the
project are consistent with the overall project plan. [PA163.IG102.N102]
SP 2.1-1 Establish the Budget and Schedule
Establish
and maintain the project’s budget and schedule.
[PA163.IG102.SP101]
The project’s budget and schedule are based on the developed
estimates and ensure that budget allocation, task complexity, and task
dependencies are appropriately addressed.
[PA163.IG102.SP101.N101]
Event-driven, resource-limited schedules have proven to
be effective in dealing with project risk. Identifying accomplishments to be
demonstrated before initiation of the event provides some flexibility in the
timing of the event, a common understanding of what is expected, a better
vision of the state of the project, and a more accurate status of the project’s
tasks. [PA163.IG102.SP101.N102]
Typical Work Products
1. Project schedules [PA163.IG102.SP101.W101]
2. Schedule dependencies [PA163.IG102.SP101.W102]
3. Project budget [PA163.IG102.SP101.W103]
Subpractices
1. Identify major milestones. [PA163.IG102.SP101.SubP101]
Milestones are often imposed to
ensure completion of certain deliverables by the milestone. Milestones can be
event based or calendar based. If calendar based, once milestone dates have
been agreed upon, it is often very difficult to change them. [PA163.IG102.SP101.SubP101.N101]
2. Identify schedule assumptions. [PA163.IG102.SP101.SubP102]
When schedules are initially
developed, it is common to make assumptions about the duration of certain
activities. These assumptions are frequently made on items for which little if
any estimation data is available. Identifying these assumptions provides
insight into the level of confidence (uncertainties) in the overall schedule. [PA163.IG102.SP101.SubP102.N101]
3. Identify constraints. [PA163.IG102.SP101.SubP103]
Factors that limit the
flexibility of management options need to be identified as early as possible.
The examination of the attributes of the work products and tasks will often
surface these issues. Such attributes can include task duration, resources,
inputs, and outputs.
[PA163.IG102.SP101.SubP103.N101]
4. Identify task dependencies. [PA163.IG102.SP101.SubP104]
Typically, the tasks for a
project can be accomplished in some ordered sequence that will minimize the
duration of the project. This involves the identification of predecessor and
successor tasks to determine the optimal ordering. [PA163.IG102.SP101.SubP104.N101]
Examples
of tools that can help determine an optimal ordering of task activities include
the following: [PA163.IG102.SP101.SubP104.N102]
· Critical Path Method (CPM)
· Program Evaluation and Review Technique (PERT)
· Resource-limited scheduling
5. Define the budget and schedule. [PA163.IG102.SP101.SubP105]
Establishing and maintaining the project's
budget and schedule typically includes the following: [PA163.IG102.SP101.SubP105.N101]
· Defining the committed or expected availability of resources and facilities
· Determining time phasing of activities
· Determining a breakout of subordinate schedules
· Defining the dependencies between the activities (predecessor or successor relationships)
· Defining the schedule activities and milestones to support accuracy in progress measurement
· Identifying milestones for delivery of products to the customer
· Defining activities of appropriate duration
· Defining milestones of appropriate time separation
· Defining a management reserve based on the confidence level in meeting the schedule and budget
· Using appropriate historical data to verify the schedule
· Defining incremental funding requirements
· Documenting project assumptions and rationale
6. Establish corrective action criteria. [PA163.IG102.SP101.SubP106]
Criteria are established for
determining what constitutes a significant deviation from the project plan. A
basis for gauging issues and problems is necessary to determine when a
corrective action should be taken. The corrective actions may require
re-planning, which may include revising the original plan, establishing new
agreements, or including mitigation activities within the current plan. [PA163.IG102.SP101.SubP106.N101]
SP 2.2-1 Identify Project Risks
Identify
and analyze project risks.
[PA163.IG102.SP103]
Refer to the Risk Management process area for more information about risk
management activities. [PA163.IG102.SP103.R101]
Refer to the Monitor Project Risks specific practice in the Project
Monitoring and Control process area for more information about risk monitoring
activities. [PA163.IG102.SP103.R102]
Risks are identified or discovered and analyzed to support
project planning. This specific practice should be extended to all the plans
that affect the project to ensure that the appropriate interfacing is taking
place between all relevant stakeholders on identified risks. Project planning
risk identification and analysis typically include the following: [PA163.IG102.SP103.N101]
· Identifying risks
· Analyzing the risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
· Prioritizing risks
Typical Work Products
1. Identified risks [PA163.IG102.SP103.W101]
2. Risk impacts and
probability of occurrence [PA163.IG102.SP103.W102]
3. Risk priorities [PA163.IG102.SP103.W103]
Subpractices
1. Identify risks.
[PA163.IG102.SP103.SubP101]
The identification of risks involves
the identification of potential issues, hazards, threats, vulnerabilities, etc.
that could negatively affect work efforts and plans. Risks must be identified
and described in an understandable way before they can be analyzed. When
identifying risks, it is good to use a standard method for defining risks. Risk
identification and analysis tools may be used to help identify possible
problems.
[PA163.IG102.SP103.SubP101.N101]
Examples
of risk identification and analysis tools include the following: [PA163.IG102.SP103.SubP101.N102]
· Risk taxonomies
· Risk assessments
· Checklists
· Structured interviews
· Brainstorming
· Performance models
· Cost models
· Network analysis
· Quality factor analysis
2. Document the risks.
[PA163.IG102.SP103.SubP102]
3. Review and obtain agreement with relevant
stakeholders on the completeness and correctness of the documented risks. [PA163.IG102.SP103.SubP103]
4. Revise the risks as appropriate. [PA163.IG102.SP103.SubP104]
Examples
of when identified risks may need to be revised include the following: [PA163.IG102.SP103.SubP104.N101]
· When new risk is identified
· When risks become problems
· When risks are retired
· When project circumstances change significantly
SP 2.3-1 Plan for Data Management
Plan
for the management of project data.
[PA163.IG102.SP102]
For Integrated Product and Process Development
When integrated teams are formed, project data includes data developed and used solely within a particular team as well as data applicable across integrated team boundaries if there are multiple integrated teams. [PA163.IG102.SP102.AMP101]
Data are the various forms of documentation required to
support a program in all of its areas (e.g., administration, engineering,
configuration management, financial, logistics, quality, safety, manufacturing,
and procurement). The data may take any form (e.g., reports, manuals,
notebooks, charts, drawings, specifications, files, or correspondence). The
data may exist in any medium (e.g., printed or drawn on various materials,
photographs, electronic, or multimedia). Data may be deliverable (e.g., items
identified by a program’s contract data requirements) or data may be
nondeliverable (e.g., informal data, trade studies and analyses, internal
meeting minutes, internal design review documentation, lessons learned, and
action items). Distribution may take many forms, including electronic
transmission.
[PA163.IG102.SP102.N101]
The data requirements for the project should be
established for both the data items to be created and their content and form,
based on a common or standard set of data requirements. Uniform content and
format requirements for data items facilitate understanding of data content and
help with consistent management of the data resources. [PA163.IG102.SP102.N102]
The reason for collecting each document should be clear.
This task includes the analysis and verification of project deliverables and
nondeliverables, contract and noncontract data requirements, and
customer-supplied data. Often, data is collected with no clear understanding of
how it will be used. Data is costly and should be collected only when needed. [PA163.IG102.SP102.N103]
Typical Work Products
1. Data management plan [PA163.IG102.SP102.W101]
2. Master list of managed data [PA163.IG102.SP102.W102]
3. Data content and format
description [PA163.IG102.SP102.W103]
4. Data requirements lists for
acquirers and for suppliers [PA163.IG102.SP102.W104]
5. Privacy requirements [PA163.IG102.SP102.W105]
6. Security requirements [PA163.IG102.SP102.W106]
7. Security procedures [PA163.IG102.SP102.W107]
8. Mechanism for data
retrieval, reproduction, and distribution
[PA163.IG102.SP102.W108]
9. Schedule for collection of
project data [PA163.IG102.SP102.W109]
10. Listing of project data to
be collected [PA163.IG102.SP102.W110]
Subpractices
1. Establish requirements and procedures to
ensure privacy and security of the data.
[PA163.IG102.SP102.SubP101]
Not everyone will have the need
or clearance necessary to access the project data. Procedures must be established
to identify who has access to what data as well as when they have access to the
data.
[PA163.IG102.SP102.SubP101.N101]
2. Establish a mechanism to archive data and to
access archived data. [PA163.IG102.SP102.SubP102]
Accessed information should be in
an understandable form (e.g., electronic or computer output from a database) or
represented as originally generated. [PA163.IG102.SP102.SubP102.N101]
3. Determine the project data to be identified,
collected, and distributed. [PA163.IG102.SP102.SubP103]
SP 2.4-1 Plan for Project Resources
Plan
for necessary resources to perform the project.
[PA163.IG102.SP104]
For Integrated Product and Process Development
When integrated teams are formed, planning for project resources has to consider staffing of the integrated teams. [PA163.IG102.SP104.AMP101]
Defining project resources (labor, machinery/equipment,
materials, and methods) and quantities needed to perform project activities builds
on the initial estimates and provides additional information that can be
applied to expand the WBS used to manage the project. [PA163.IG102.SP104.N101]
The top-level WBS developed earlier as an estimation
mechanism is typically expanded by decomposing these top levels into work
packages that represent singular work units that can be separately assigned,
performed, and tracked. This subdivision is done to distribute management
responsibility and provide better management control. Each work package or work
product in the WBS should be assigned a unique identifier (e.g., number) to
permit tracking. A WBS may be based on requirements, activities, work products,
or a combination of these items. A dictionary that describes the work for each
work package in the WBS should accompany the work breakdown structure. [PA163.IG102.SP104.N102]
Typical Work Products
1. WBS work packages [PA163.IG102.SP104.W101]
2. WBS task dictionary [PA163.IG102.SP104.W102]
3. Staffing requirements based
on project size and scope [PA163.IG102.SP104.W103]
4. Critical
facilities/equipment list [PA163.IG102.SP104.W104]
5. Process/workflow
definitions and diagrams [PA163.IG102.SP104.W105]
6. Program administration
requirements list [PA163.IG102.SP104.W106]
Subpractices
1. Determine process requirements. [PA163.IG102.SP104.SubP101]
The processes used to manage a
project must be identified, defined, and coordinated with all the relevant
stakeholders to ensure efficient operations during project execution. [PA163.IG102.SP104.SubP101.N101]
2. Determine staffing requirements. [PA163.IG102.SP104.SubP102]
The staffing of a project depends
on the decomposition of the project requirements into tasks, roles, and
responsibilities for accomplishing the project requirements as laid out within
the work packages of the WBS.
[PA163.IG102.SP104.SubP102.N101]
Staffing requirements must
consider the knowledge and skills required for each of the identified
positions, as defined in the Plan for Needed Knowledge and Skills specific
practice.
[PA163.IG102.SP104.SubP102.N102]
3. Determine facilities, equipment, and
component requirements. [PA163.IG102.SP104.SubP103]
Most projects are unique in some
sense and require some set of unique assets to accomplish the objectives of the
project. The determination and acquisition of these assets in a timely manner
are crucial to project success.
[PA163.IG102.SP104.SubP103.N101]
Lead-time items need to be
identified early to determine how they will be addressed. Even when the required
assets are not unique, compiling a list of all of the facilities, equipment,
and parts (e.g., number of computers for the personnel working on the project,
software applications, office space, etc.) provides insight into aspects of the
scope of an effort that are often overlooked. [PA163.IG102.SP104.SubP103.N102]
SP 2.5-1 Plan for Needed Knowledge and Skills
Plan
for knowledge and skills needed to perform the project. [PA163.IG102.SP105]
Refer to the Organizational Training process area for more information
about knowledge and skills information to be incorporated into the project
plan. [PA163.IG102.SP105.R101]
Knowledge delivery to projects involves both training of
project personnel and acquisition of knowledge from outside sources. [PA163.IG102.SP105.N101]
Staffing requirements are dependent on the knowledge and
skills available to support the execution of the project. [PA163.IG102.SP105.N102]
Typical Work Products
1. Inventory of skill needs [PA163.IG102.SP105.W101]
2. Staffing and new hire plans [PA163.IG102.SP105.W103]
3. Databases (e.g., skills and
training) [PA163.IG102.SP105.W104]
Subpractices
1. Identify the knowledge and skills needed to
perform the project. [PA163.IG102.SP105.SubP101]
2. Assess the knowledge and skills available. [PA163.IG102.SP105.SubP102]
3. Select mechanisms for providing needed
knowledge and skills. [PA163.IG102.SP105.SubP103]
Example
mechanisms include the following:
[PA163.IG102.SP105.SubP103.N101]
· In-house training (both organizational and project)
· External training
· Staffing and new hires
· External skill acquisition
The choice of in-house training
or external outsourcing for the needed knowledge and skills is determined by
the availability of training expertise, the project's schedule, and business
objectives.
[PA163.IG102.SP105.SubP103.N102]
4. Incorporate selected mechanisms in the
project plan. [PA163.IG102.SP105.SubP104]
SP 2.6-1 Plan Stakeholder Involvement
Plan
the involvement of identified stakeholders.
[PA163.IG102.SP106]
For Integrated Product and Process Development
When integrated teams are formed, stakeholder involvement needs to be planned down to the integrated team level. [PA163.IG102.SP106.AMP101]
Stakeholders are identified from all phases of the
project life cycle by identifying the type of people and functions needing
representation in the project and describing their relevance and the degree of
interaction for specific project activities. A two-dimensional matrix with
stakeholders along one axis and project activities along the other axis is a
convenient format for accomplishing this identification. Relevance of the
stakeholder to the activity in a particular project phase and the amount of
interaction expected would be shown at the intersection of the project phase
activity axis and the stakeholder axis.
[PA163.IG102.SP106.N101]
For the inputs of stakeholders to be useful, careful selection
of relevant stakeholders is necessary. For each major activity, identify the
stakeholders that are affected by the activity and those who have expertise
that is needed to conduct the activity. This list of relevant stakeholders will
probably change as the project moves through the phases of the project life
cycle. It is important, however, to ensure that relevant stakeholders in the
later phases of the life cycle have early input to requirements and design
decisions that affect them. [PA163.IG102.SP106.N102]
Examples of
the type of material that should be included in a plan for stakeholder
interaction include the following: [PA163.IG102.SP106.N103]
· List of all relevant stakeholders
· Rationale for stakeholder involvement
· Roles and responsibilities of the relevant stakeholders with respect to the project, by project life-cycle phase
· Relationships between stakeholders
· Relative importance of the stakeholder to success of the project, by project life-cycle phase
· Resources (e.g., training, materials, time, funding) needed to ensure stakeholder interaction
· Schedule for phasing of stakeholder interaction
Conduct of this specific practice relies on shared or
exchanged information with the previous Plan for Needed Knowledge and Skills
specific practice. [PA163.IG102.SP106.N104]
Typical Work Products
1. Stakeholder involvement
plan [PA163.IG102.SP106.W101]
SP 2.7-1 Establish the Project Plan
Establish
and maintain the overall project plan content.
[PA163.IG102.SP107]
For Systems Engineering
Systems-engineering planning details the work activities and work products of the integrated technical effort across the project. [PA163.IG102.SP107.AMP101]
For Systems Engineering
Examples of plans that have been used in the U.S. Department of Defense community include the following: [PA163.IG102.SP107.AMP103]
· Integrated Master Plan – an event-driven plan that documents significant accomplishments with pass/fail criteria for both business and technical elements of the project and ties each accomplishment to a key program event.
· Integrated Master Schedule – an integrated and networked multi-layered schedule of program tasks required to complete the work effort documented in a related Integrated Master Plan.
· Systems-Engineering Management Plan – a plan that details the integrated technical effort across the project.
· Systems-Engineering Master Schedule – an event-based schedule that contains a compilation of key technical accomplishments, each with measurable criteria, requiring successful completion to pass identified events.
· Systems-Engineering Detailed Schedule – a detailed, time-dependent, task-oriented schedule that associates specific dates and milestones with the Systems-Engineering Master Schedule.
For Software Engineering
For software, the planning document is often referred to as one of the following: [PA163.IG102.SP107.AMP102]
· Software development plan
· Software project plan
· Software plan
A documented plan that addresses all relevant planning items
is necessary to achieve the mutual understanding, commitment, and performance
of individuals, groups, and organizations that must execute or support the
plans. The plan generated for the project defines all aspects of the effort,
tying together in a logical manner: project life-cycle considerations;
technical and management tasks; budgets and schedules; milestones; data
management, risk identification, resource and skill requirements; and
stakeholder identification and interaction. Infrastructure descriptions include
responsibility and authority relationships for project staff, management, and
support organizations.
[PA163.IG102.SP107.N101]
Typical Work Products
1. Overall project plan [PA163.IG102.SP107.W101]
SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established
and maintained. [PA163.IG103]
To be effective, plans require commitment by those
responsible for implementing and supporting the plan. [PA163.IG103.N101]
SP 3.1-1 Review Plans that Affect the Project
Review
all plans that affect the project to understand project commitments. [PA163.IG103.SP103]
For Integrated Product and Process Development
When integrated teams are formed, their integrated work plans are among the plans to review. [PA163.IG103.SP103.AMP101]
Plans developed within other process areas will typically
contain information similar to that called for in the overall project plan.
These plans may provide additional detailed guidance and should be compatible
with and support the overall project plan to indicate who has the authority,
responsibility, accountability, and control. All plans that affect the project
should be reviewed to ensure a common understanding of the scope, objectives,
roles, and relationships that are required for the project to be successful.
Many of these plans are described by the Plan the Process generic practice in
each of the process areas.
[PA163.IG103.SP103.N101]
Typical Work Products
1. Record of the reviews of
plans that affect the project [PA163.IG103.SP103.W101]
SP 3.2-1 Reconcile Work and Resource Levels
Reconcile
the project plan to reflect available and estimated resources. [PA163.IG103.SP101]
For Integrated Product and Process Development
When integrated teams are formed, special attention needs to be paid to resource commitments in circumstances of distributed integrated teams and when people are on multiple integrated teams in one or many projects. [PA163.IG103.SP101.AMP101]
To obtain commitment from relevant stakeholders, it is
important to reconcile any differences between the estimates and the available
resources. Reconciliation is typically accomplished by lowering or deferring
technical performance requirements, negotiating more resources, finding ways to
increase productivity, outsourcing, adjusting the staff skill mix, or revising
all plans that affect the project or schedules.
[PA163.IG103.SP101.N101]
Typical Work Products
1. Revised methods and
corresponding estimating parameters (e.g., better tools, use of off-the-shelf
components) [PA163.IG103.SP101.W101]
2. Renegotiated budgets [PA163.IG103.SP101.W102]
3. Revised schedules [PA163.IG103.SP101.W103]
4. Revised requirements list [PA163.IG103.SP101.W104]
5. Renegotiated stakeholder
agreements [PA163.IG103.SP101.W105]
SP 3.3-1 Obtain Plan Commitment
Obtain
commitment from relevant stakeholders responsible for performing and supporting
plan execution.
[PA163.IG103.SP102]
For Integrated Product and Process Development
When integrated teams are formed, the integrated team plans will need buy-in from the team members, the interfacing teams, the project, and the process owners of the standard processes that team has selected for tailored application. [PA163.IG103.SP102.AMP101]
Obtaining commitment involves interaction among all
relevant stakeholders both internal and external to the project. The individual
or group making a commitment should have confidence that the work can be
performed within cost, schedule, and performance constraints. Often, a
provisional commitment is adequate to allow the effort to begin and to permit
research to be performed to increase confidence to the appropriate level needed
to obtain a full commitment.
[PA163.IG103.SP102.N101]
Typical Work Products
1. Documented requests for
commitments [PA163.IG103.SP102.W101]
2. Documented commitments [PA163.IG103.SP102.W102]
Subpractices
1. Identify needed support and negotiate
commitments with relevant stakeholders. [PA163.IG103.SP102.SubP101]
The WBS can be used as a
checklist for ensuring that commitments are obtained for all tasks. [PA163.IG103.SP102.SubP101.N101]
The plan for stakeholder
interaction should identify all parties from whom commitment should be
obtained.
[PA163.IG103.SP102.SubP101.N102]
2. Document all organizational commitments,
both full and provisional, ensuring appropriate level of signatories. [PA163.IG103.SP102.SubP102]
Commitments must be documented to
ensure a consistent mutual understanding as well as for tracking and
maintenance. Provisional commitments should be accompanied by a description of
the risks associated with the relationship. [PA163.IG103.SP102.SubP102.N101]
3. Review internal commitments with senior
management as appropriate. [PA163.IG103.SP102.SubP103]
4. Review external commitments with senior
management as appropriate. [PA163.IG103.SP102.SubP104]
Management may have the necessary
insight and authority to reduce risks associated with external commitments. [PA163.IG103.SP102.SubP104.N101]
5. Identify commitments on interfaces between
elements in the project, and with other projects and organizational units, so
they can be monitored. [PA163.IG103.SP102.SubP105]
Well-defined interface
specifications form the basis for commitments. [PA163.IG103.SP102.SubP105.N101]
Generic Practices by Goal
(Note: The detailed description of the GPs is available in a separate web page. Using the hyperlink provided here will open that web page in a separate window. However, the GP elaborations pertinent to the process area of this web page are available below.)
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
Perform
the base practices of the project planning process to develop work products and
provide services to achieve the specific goals of the process area. [GP102]
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish
and maintain an organizational policy for planning and performing the project
planning process. [GP103]
Elaboration:
This policy establishes organizational expectations for
estimating the planning parameters, making internal and external commitments,
and developing the plan for managing the project.
[PA163.EL101]
Establish
and maintain the plan for performing the project planning process. [GP104]
Elaboration:
This plan for performing the project planning process
differs from the project plan described in specific practices in this process
area. The plan called for in this generic practice would address the
comprehensive planning for all of the specific practices in this process area,
from estimating the scope of the project all the way to obtaining commitment
for the project plan. In other words, this generic practice calls for one to
“plan the plan.” In contrast, the project plan called for in the specific
practices would address planning for the project effort itself in a
comprehensive manner. [PA163.EL103]
Provide
adequate resources for performing the project planning process, developing the
work products, and providing the services of the process. [GP105]
Elaboration:
Special expertise, equipment, and facilities in project
planning may be required. Special expertise in project planning may include the
following: [PA163.EL104]
· Experienced estimators
· Schedulers
· Technical experts in applicable areas (e.g., product domain and technology)
Examples of
other resources provided include the following tools: [PA163.EL106]
· Spreadsheet programs
· Estimating models
· Project planning and scheduling packages
Assign
responsibility and authority for performing the process, developing the work
products, and providing the services of the project planning process. [GP106]
Train
the people performing or supporting the project planning process as needed. [GP107]
Elaboration:
Examples of
training topics include the following: [PA163.EL108]
· Estimating
· Budgeting
· Negotiating
· Risk identification and analysis
· Data management
· Planning
· Scheduling
Place
designated work products of the project planning process under appropriate
levels of configuration management. [GP109]
Elaboration:
Examples of
work products placed under configuration management include the following: [PA163.EL110]
· Work breakdown structure
· Project plan
· Data management plan
· Stakeholder involvement plan
GP 2.7 Identify and Involve Relevant Stakeholders
Identify
and involve the relevant stakeholders of the project planning process as
planned. [GP124]
Elaboration:
This generic practice is different from developing the
plan for stakeholder involvement for the project itself, which is covered in a
specific practice of this process area.
[PA163.EL111]
Select relevant stakeholders from senior managers,
project managers, project functional managers (e.g., systems engineering,
software engineering, other disciplines), software engineers, systems
engineers, manufacturing engineers, logisticians, suppliers, customers, and
others who may be affected by, or may affect, the project. [PA163.EL118]
Examples of
activities for stakeholder involvement include the following: [PA163.EL119]
· Establishing estimates
· Reviewing and resolving issues on the completeness and correctness of the project risks
· Reviewing data management plans
· Establishing project plans
· Reviewing project plans and resolving issues on work and resource issues
GP 2.8 Monitor and Control the Process
Monitor
and control the project planning process against the plan for performing the
process and take appropriate corrective action.
[GP110]
Elaboration:
Examples of
measures used in monitoring and controlling include the following: [PA163.EL113]
· Number of revisions to the plan
· Cost, schedule, and effort variance per plan revision
GP 2.9 Objectively Evaluate Adherence
Objectively
evaluate adherence of the project planning process against its process
description, standards, and procedures, and address noncompliance. [GP113]
Elaboration:
Examples of
activities reviewed include the following: [PA163.EL115]
· Establishing estimates
· Developing a project plan
· Obtaining commitments to the project plan
Examples of
work products reviewed include the following: [PA163.EL117]
· WBS
· Project plan
· Data management plan
· Stakeholder involvement plan
GP 2.10 Review Status with Higher Level Management
Review
the activities, status, and results of the project planning process with higher
level management and resolve issues. [GP112]
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish
and maintain the description of a defined project planning process. [GP114]
GP 3.2 Collect Improvement Information
Collect
work products, measures, measurement results, and improvement information
derived from planning and performing the project planning process to support
the future use and improvement of the organization’s processes and process
assets. [GP117]
GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish
and maintain quantitative objectives for the project planning process that
address quality and process performance based on customer needs and business
objectives. [GP118]
GP 4.2 Stabilize Subprocess Performance
Stabilize
the performance of one or more subprocesses to determine the ability of the
project planning process to achieve the established quantitative quality and
process-performance objectives. [GP119]
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure
continuous improvement of the project planning process in fulfilling the
relevant business objectives of the organization.
[GP125]
GP 5.2 Correct Root Causes of Problems
Identify
and correct the root causes of defects and other problems in the project
planning process. [GP121]