SP 1.1 Estimate the Scope of the Project
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

The WBS evolves with the project. A top-level WBS can serve to structure initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components.

Typically, the WBS is a product, work product, or task 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 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.

Some projects use the term “contract WBS” to refer to the portion of the WBS placed under contract (possibly the entire WBS). Not all projects have a contract WBS (e.g., internally funded development).

Example Work Products
1. Task descriptions
2. Work package descriptions
3. WBS

Subpractices
1. Develop a WBS.
The WBS provides a scheme for organizing the project’s work. The WBS should permit the identification of the following items: Risks and their mitigation tasks Tasks for deliverables and supporting activities Tasks for skill and knowledge acquisition Tasks for the development of needed support plans, such as configuration management, quality assurance, and verification plans Tasks for the integration and management of nondevelopmental items

2. Define the work packages in sufficient detail so that estimates of project tasks, responsibilities, and schedule can be specified.
The top-level WBS is intended to help gauge the project work effort for tasks and organizational roles and responsibilities. The amount of detail in the WBS at this level helps in developing realistic schedules, thereby minimizing the need for management reserve.

3. Identify products and product components to be externally acquired.
Refer to the Supplier Agreement Management process area for more information about managing the acquisition of products and services from suppliers.

4. Identify work products to be reused.


SP 1.2 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of the attributes of the work products and tasks.

Size is the primary input to many models used to estimate effort, cost, and schedule. Models can also be based on other attributes such as service level, connectivity, complexity, availability, and structure.

Examples of attributes to estimate include the following:
* Number and complexity of requirements
* Number and complexity of interfaces
* Volume of data Number of functions
* Function points
* Source lines of code
* Number of classes and objects
* Number of database tables
* Number of fields in data tables
* Architecture elements
* Experience of project participants
* Amount of code to be reused versus created
* Team velocity and complexity
* Number of pages
* Number of inputs and outputs
* Number of technical risk items
* Number of database tables
* Number of fields in data tables
* Architecture elements
* Experience of project participants
* Amount of code to be reused versus created
* Number of logic gates for integrated circuits
* Number of parts (e.g., printed circuit boards, components, mechanical parts)
* Physical constraints (e.g., weight, volume)
* Geographic dispersal of project members
* Proximity of customers, end users, and suppliers
* How agreeable or difficult the customer is
* Quality and ―cleanliness‖ of the existing code base

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.

Example Work Products
1. Size and complexity of tasks and work products
2. Estimating models
3. Attribute estimates
4. Technical approach

Subpractices
1. Determine the technical approach for the project.
The technical approach defines a top-level strategy for development of the product. 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 the functionality and quality attributes expected in the final products, such as safety, security, and ergonomics.

2. Use appropriate methods to determine the attributes of the work products and tasks to be used to estimate resource requirements.
Methods for determining size and complexity should be based on validated models or historical data.

The methods for determining attributes evolve as the understanding of the relationship of product characteristics to attributes increases.

3. Estimate the attributes of work products and tasks.
Examples of work products for which size estimates are made include the following:
* Deliverable and nondeliverable work products
* Documents and files
* Operational and support hardware, firmware, and software


SP 1.3 Define Project Lifecycle Phases
Define the project life-cycle phases upon which to scope the planning effort.

The determination of a project’s lifecycle phases provides for planned periods of evaluation and decision making. These periods are normally defined to support logical decision points at which the appropriateness of continued reliance on the project plan and strategy is determined and significant commitments are made concerning resources. Such points provide planned events at which project course corrections and determinations of future scope and cost can be made.

Understanding the project lifecycle is crucial in determining the scope of the planning effort and the timing of initial planning, as well as the timing and criteria (critical milestones) for replanning.

The project lifecycle phases need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. Larger projects can contain multiple phases, such as concept exploration, development, production, operations, and disposal. Within these phases, subphases may be needed. A development phase can include subphases such as requirements analysis, design, fabrication, integration, and verification. The determination of project phases typically includes selection and refinement of one or more development models to address interdependencies and appropriate sequencing of the activities in the phases.

Depending on the strategy for development, there can be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles. In addition, explicit phases for “project startup” and “project close-out” can be included.

Typical Work Products
1.  Project life-cycle phases



SP 1.4 Estimate Effort and Cost
Estimate the project’s effort and cost for work products and tasks based on estimation rationale

Estimates of effort and cost are generally based on results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on rationale for the selected model and the nature of the data. There can be occasions when available historical data do not apply, such as when efforts are unprecedented or when the type of task does not fit available models. For example, an effort can be considered unprecedented if the organization has no experience with such a product or task.

Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project should be documented when using these models to ensure a common understanding of any assumptions made in the initial planning phases.

Example Work Products
1. Estimation rationale
2. Project effort estimates
3. Project cost estimates

Subpractices
1. Collect models or historical data to be used to transform the attributes of work products and tasks into estimates of labor hours and costs.
Many parametric models have been developed to help estimate cost and schedule. The use of these models as the sole source of estimation is not recommended because these models are based on historical project data that may or may not be pertinent to the project. Multiple models and methods can be used to ensure a high level of confidence in the estimate.

Historical data should include the cost, effort, and schedule data from previously executed projects and appropriate scaling data to account for differing sizes and complexity.

2. Include supporting infrastructure needs when estimating effort and cost.
The supporting infrastructure includes resources needed from a development and sustainment perspective for the product.

Consider the infrastructure resource needs in the development environment, the test environment, the production environment, the operational environment, or any appropriate combination of these environments when estimating effort and cost.

Examples of infrastructure resources include the following:
* Critical computer resources (e.g., memory, disk and network capacity, peripherals, communication channels, the capacities of these resources)
* Engineering environments and tools (e.g., tools for prototyping, testing, integration, assembly, computer-aided design [CAD], simulation)
* Facilities, machinery, and equipment (e.g., test benches, recording devices)

3. Estimate effort and cost using models, historical data, or a combination of both.
Examples of effort and cost inputs used for estimating typically include the following:
* Estimates provided by an expert or group of experts (e.g., Delphi method, Extreme Programming’s Planning Game)
* Risks, including the extent to which the effort is unprecedented
* Critical competencies and roles needed to perform the work
* Travel
* WBS
* Selected project lifecycle model and processes
* Lifecycle cost estimates
* Skill levels of managers and staff needed to perform the work
* Knowledge, skill, and training needs
* Direct labor and overhead
* Service agreements for call centers and warranty work
* Level of security required for tasks, work products, hardware, software, staff, and work environment
* Facilities needed (e.g., office and meeting space and workstations)
* Product and product component requirements
* Size estimates of work products, tasks, and anticipated changes
* Cost of externally acquired products
* Capability of manufacturing processes
* Engineering facilities needed
* Capability of tools provided in engineering environment
* Technical approach


SP 2.1 Establish the Budget and Schedule
Establish and maintain the project's budget and schedule.

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.

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.

Typical Work Products
1.  Project schedules
2.  Schedule dependencies
3.  Project budget

Subpractices
1.  Identify major milestones.
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.

2.  Identify schedule assumptions.
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.

3.  Identify constraints.
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.

4.  Identify task dependencies.
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.

Examples of tools that can help determine an optimal ordering of task activities include the following:
·  Critical Path Method (CPM)
·  Program Evaluation and Review Technique (PERT)
·  Resource-limited scheduling
·  Customer priorities
·  Marketable features
·  End-user value

5.  Establish and maintain the budget and schedule.
Establishing and maintaining the project's budget and schedule typically includes the following:
·  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.
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 corrective action should be taken. Corrective actions can lead to replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan. The project plan defines when (e.g., under what circumstances, with what frequency) the criteria will be applied and by whom.


SP 2.2 Identify Project Risks
Identify and analyze project risks.

Refer to the Monitor Project Risks specific practice in the Project Monitoring and Control process area for more information about risk monitoring activities.

Refer to the Risk Management process area for more information about identifying potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Risks are identified or discovered and analyzed to support project planning. This specific practice should be extended to all plans that affect the project to ensure that appropriate interfacing is taking place among all relevant stakeholders on identified risks.

Project planning risk identification and analysis typically include the following:
* Identifying risks
* Analyzing risks to determine the impact, probability of occurrence, and time frame in which problems are likely to occur
* Prioritizing risks

Example Work Products
1. Identified risks
2. Risk impacts and probability of occurrence
3. Risk priorities

Subpractices
1. Identify risks.
The identification of risks involves the identification of potential issues, hazards, threats, vulnerabilities, and so on that could negatively affect work efforts and plans. Risks should be identified and described understandably before they can be analyzed and managed properly. When identifying risks, it is a good idea to use a standard method for defining risks. Risk identification and analysis tools can be used to help identify possible problems.

Examples of risk identification and analysis tools include the following:
·  Risk taxonomies
·  Risk assessments
·  Checklists
·  Structured interviews
·  Brainstorming
·  Performance models
·  Cost models
·  Network analysis
·  Quality factor analysis

2. Document risks.

3. Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks.

4. Revise risks as appropriate.
Examples of when identified risks may need to be revised include the following:
·  When new risk is identified
·  When risks become problems
·  When risks are retired
·  When project circumstances change significantly




SP 2.3 Plan for Data Management
Plan for the management of project data.

Data are forms of documentation required to support a project in all of its areas (e.g., administration, engineering, configuration management, finance, logistics, quality, safety, manufacturing, procurement). The data can take any form (e.g., reports, manuals, notebooks, charts, drawings, specifications, files, correspondence). The data can exist in any medium (e.g., printed or drawn on various materials, photographs, electronic, multimedia).

Data can be deliverable (e.g., items identified by a project’s contract data requirements) or data can be nondeliverable (e.g., informal data, trade studies, analyses, internal meeting minutes, internal design review documentation, lessons learned, action items). Distribution can take many forms, including electronic transmission.

Data requirements for the project should be established for both 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 data resources.

The reason for collecting each document should be clear. This task includes the analysis and verification of project deliverables and nondeliverables, data requirements, and customer supplied data. Often, data are collected with no clear understanding of how they will be used. Data are costly and should be collected only when needed.

Example Work Products
1.  Data management plan

2.  Master list of managed data

3.  Data content and format description

4.  Data requirements lists for acquirers and for suppliers

5.  Privacy requirements

6.  Security requirements

7.  Security procedures

8.  Mechanism for data retrieval, reproduction, and distribution

9.  Schedule for collection of project data .

10.  Listing of project data to be collected

Subpractices
1. Establish requirements and procedures to ensure privacy and the security of data.
Not everyone will have the need or clearance necessary to access project data. Procedures should be established to identify who has access to which data as well as when they have access to which data.

2. Establish a mechanism to archive data and to access archived data.
Accessed information should be in an understandable form (e.g., electronic or computer output from a database) or represented as originally generated.

3. Determine the project data to be identified, collected, and distributed.

4. Determine the requirements for providing access to and distribution of data to relevant stakeholders.
A review of other elements of the project plan can help to determine who requires access to or receipt of project data as well as which data are involved.

5. Decide which project data and plans require version control or other levels of configuration control and establish mechanisms to ensure project data are controlled.


SP 2.4 Plan the Project’s Resources
Plan for resources to perform the project.

Defining project resources (e.g., labor, equipment, materials, methods) and quantities needed to perform project activities builds on initial estimates and provides additional information that can be applied to expand the WBS used to manage the project.

The top-level WBS developed earlier as an estimation mechanism is typically expanded by decomposing these top levels into work packages that represent single 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 in the WBS should be assigned a unique identifier (e.g., number) to permit tracking. A WBS can be based on requirements, activities, work products, services, 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.

Example Work Products
1. Work packages
2. WBS task dictionary
3. Staffing requirements based on project size and scope
4. Critical facilities and equipment list
5. Process and workflow definitions and diagrams
6. Project administration requirements list
7. Status reports

Subpractices
1. Determine process requirements.
The processes used to manage a project are identified, defined, and coordinated with all relevant stakeholders to ensure efficient operations during project execution.

2. Determine communication requirements.
These requirements address the kinds of mechanisms to be used for communicating with customers, end users, project staff, and other relevant stakeholders.

3. Determine staffing requirements.
The staffing of a project depends on the decomposition of project requirements into tasks, roles, and responsibilities for accomplishing project requirements as laid out in the work packages of the WBS.

Staffing requirements should consider the knowledge and skills required for each identified position as defined in the Plan Needed Knowledge and Skills specific practice.

4. Determine facility, equipment, and component requirements.
Most projects are unique in some way and require a set of unique assets to accomplish project objectives. The determination and acquisition of these assets in a timely manner are crucial to project success.
It is best to identify lead-time items early to determine how they will be addressed. Even when required assets are not unique, compiling a list of all facilities, equipment, and parts (e.g., number of computers for the staff working on the project, software applications, office space) provides insight into aspects of the scope of an effort that are often overlooked.

5. Determine other continuing resource requirements.
Beyond determining processes, reporting templates, staffing, facilities, and equipment, there may be a continuing need for other types of resources to effectively carry out project activities, including the following:
* Consumables (e.g., electricity, office supplies) Access to intellectual property
* Access to transportation (for people and equipment)

The requirements for such resources are derived from the requirements found in (existing and future) agreements (e.g., customer agreements, service agreements, supplier agreements), the project’s strategic approach, and the need to manage and maintain the project’s operations for a period of time.

SP 2.5 Plan Needed Knowledge and Skills
Plan for knowledge and skills needed to perform the project.

Refer to the Organizational Training process area for more information about developing skills and knowledge of people so they can perform their roles effectively and efficiently.

Knowledge delivery to projects involves both training of project personnel and acquisition of knowledge from outside sources.

Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.  Knowledge delivery to projects involves training project staff and acquiring knowledge from outside sources.

Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.

Example Work Products
1. Inventory of skill needs
2. Staffing and new hire plans
3. Databases (e.g., skills, training)
4. Training plans

Subpractices
1. Identify the knowledge and skills needed to perform the project.

2. Assess the knowledge and skills available.

3. Select mechanisms for providing needed knowledge and skills.
Example mechanisms include the following:
·  In-house training (both organizational and project)
·  External training
·  Staffing and new hires
·  External skill acquisition

The choice of in-house training or outsourced training for needed knowledge and skills is determined by the availability of training expertise, the project’s schedule, and business objectives.

4.  Incorporate selected mechanisms in the project plan.


SP 2.6 Plan Stakeholder Involvement
Plan the involvement of identified stakeholders.

Stakeholders are identified from all phases of the project lifecycle by identifying the people and functions that should be represented in the project and describing their relevance and the degree of interaction for 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.

For inputs of stakeholders to be useful, careful selection of relevant stakeholders is necessary. For each major activity, identify stakeholders who 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 phases of the project lifecycle. It is important, however, to ensure that relevant stakeholders in the latter phases of the lifecycle have early input to requirements and design decisions that affect them.

Examples of the type of material that should be included in a plan for stakeholder interaction include the following:
·  List of all relevant stakeholders
·  Rationale for stakeholder involvement
·  Relationships among stakeholders
·  Resources (e.g., training, materials, time, funding) needed to ensure stakeholder interaction
·  Schedule for the phasing of stakeholder interaction
·  Roles and responsibilities of relevant stakeholders with respect to the project, by project lifecycle phase
·  Relative importance of the stakeholder to the success of the project, by project lifecycle phase

Implementing this specific practice relies on shared or exchanged information with the previous Plan Needed Knowledge and Skills specific practice.

Example Work Products
1.  Stakeholder involvement plan



SP 2.7 Establish the Project Plan
Establish and maintain the overall project plan content.

A documented plan that addresses all relevant planning items is necessary to achieve the mutual understanding and commitment of individuals, groups, and organizations that execute or support the plans.
The plan generated for the project defines all aspects of the effort, tying together the following in a logical manner:
* Project lifecycle considerations
* Project tasks
* Budgets and schedules
* Milestones
* Data management
* Risk identification
* Resource and skill requirements
* Stakeholder identification and interaction Infrastructure considerations

Infrastructure considerations include responsibility and authority relationships for project staff, management, and support organizations.

Lifecycle considerations can include coverage of later phases of the product or service life (that might be beyond the life of the project), especiallyTypical Work Products transition to another phase or party (e.g., transition to manufacturing, training, operations, a service provider).

For software, the planning document is often referred to as one of the following:
* Software development plan
* Software project plan
* Software plan

For hardware, the planning document is often referred to as a hardware development plan. Development activities in preparation for production can be included in the hardware development plan or defined in a separate production plan.

Examples of plans that have been used in the U.S. Department of Defense community include the following:
* 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 that ties each accomplishment to a key project event. Integrated Master Schedule—an integrated and networked multi-layered schedule of project 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 dates and milestones with the Systems Engineering Master Schedule.

Example Work Products
1. Overall project plan



SP 3.1 Review Plans That Affect the Project
Review all plans that affect the project to understand project commitments.

Plans developed in other process areas typically contain information similar to that called for in the overall project plan. These plans can 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 they contain 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.

Example Work Products
1. Record of the reviews of plans that affect the project


SP 3.2 Reconcile Work and Resource Levels
Adjust the project plan to reconcile available and estimated resources.

To establish a project that is feasible, obtain commitment from relevant stakeholders and reconcile differences between estimates and available resources. Reconciliation is typically accomplished by modifying or deferring requirements, negotiating more resources, finding ways to increase productivity, outsourcing, adjusting the staff skill mix, or revising all plans that affect the project or its schedules.

Example Work Products
1.  Revised methods and corresponding estimating parameters (e.g., better tools, use of off-the-shelf components)
2.  Renegotiated budgets
3.  Revised schedules
4.  Revised requirements list
5.  Renegotiated stakeholder agreements




SP 3.3 Obtain Plan Commitment
Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

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.

Example Work Products
1.  Documented requests for commitments
2.  Documented commitments

Subpractices
1.  Identify needed support and negotiate commitments with relevant stakeholders.
The WBS can be used as a checklist for ensuring that commitments are obtained for all tasks.

The plan for stakeholder interaction should identify all parties from whom commitment should be obtained.

2.  Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories.
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.

3.  Review internal commitments with senior management as appropriate.

4.  Review external commitments with senior management as appropriate.
Management may have the necessary insight and authority to reduce risks associated with external commitments.

5.  Identify commitments on interfaces between elements in the project, and with other projects and organizational units, so they can be monitored.
Well-defined interface specifications form the basis for commitments.