Project Planning
A Project Management Process Area at Maturity Level 2
Purpose
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
Introductory Notes
In CMMI, the term “project” is given a broad definition so that the practices that use that term (e.g., in the Project Management process areas) have appropriately broad applicability. The term “project” refers to a group of people and resources committed to planning, monitoring, and executing defined processes in a shared endeavor to achieve a set of objectives. These objectives include (or may be derived from) the goals of the business but will also include goals associated with customers, though there may not yet be any customers identified (or service agreements in place) when the project is initiated.
The definition above of “project” includes those endeavors that have an intended termination (e.g., developing a product, delivering services under a service agreement with a specified end date) as well as those that an organization does not intend to terminate (e.g., providing health care, providing fire safety services in a community). Some people are unaccustomed to this broad interpretation of the term “project” and may habitually restrict its use to only those kinds of endeavors with a defined end point. However, the process areas, goals, and practices in CMMI for perpetual endeavors overlap completely with those needed for traditional projects. Therefore, CMMI models use the single term “project” to encompass both types of endeavors as a way of avoiding unnecessary distinctions and duplication among model components.
A project can be composed of multiple projects, in which case the CMMI project-related practices apply to the projects at these lower levels as well, though they may be implemented less formally as the level of their application moves to an individual team and as the risk of failure decreases.
The term “organization” refers to a higher level of management that provides policies, resources, standard processes, and other support to several projects. Obtaining business value from the practices in this and related process areas requires, in part, correctly identifying which endeavors are projects. (See the definitions of “project” and “organization” in the glossary.)
One of the keys to effectively managing a project is project planning. The Project Planning process area involves the following activities:
• Developing the project plan
• Interacting with stakeholders appropriately
• Getting commitment to the plan
• Maintaining the plan
Planning includes estimating the attributes of 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 project activities that address commitments with the project’s customer.
The project plan is usually 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 replanning are contained in this process area.
The term “project plan” is used throughout this process area to refer to the overall plan for controlling the project.
Projects that respond to service requests generated over time by end users may require an entire level of detailed and frequently revised plans for resource-to-task allocation and task queue management (e.g., the assignment of repair jobs in a maintenance shop). These low-level operating plans may be considered a detailed extension of the overall project plan.
Related Process Areas
Refer to the Capacity and Availability Management process area for more information about ensuring effective service system performance and ensuring that resources are provided and used effectively to support service requirements.
Refer to the Service Delivery process area for more information about preparing for service system operations.
Refer to the Strategic Service Management process area for more information about gathering and analyzing data about the strategic needs and capabilities of the organization.
Refer to the Measurement and Analysis process area for more information about specifying measures.
Refer to the Requirements Management process area for more information about managing changes to requirements as they evolve during the project.
Refer to the Risk Management process area for more information about identifying, analyzing, and mitigating risks.
Specific Practices by Goal
SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
Project planning parameters include all information needed by the project to perform necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.
Estimates of planning parameters should have a sound basis to instill confidence that plans based on these estimates are capable of supporting project objectives.
Factors to consider when estimating these parameters include the following:
• The project strategy
• Project requirements, including product requirements, requirements imposed by the organization, requirements imposed by the customer, and other requirements that impact the project
• The scope of the project
• Identified tasks and work products
• Identified services and service levels
• How incidents and requests are to be handled
• The selected project lifecycle model (e.g., waterfall, incremental, spiral)
• Attributes of work products and tasks (e.g., size, complexity)
• The schedule
• Models or historical data used for converting attributes of work products and tasks into labor hours and costs
• The methodology (e.g., models, data, algorithms) used to determine needed material, skills, labor hours, and cost
Documentation of the estimating rationale and supporting data is needed for stakeholder review and commitment to the plan and for maintenance of the plan as the project progresses.
SP 1.1 Establish the Project Strategy
Establish and maintain the project strategy.
The project strategy provides the business framework for planning and managing the project. The strategy includes consideration of the following factors at an appropriate level of abstraction:
• The objectives and constraints for the project
• Possible approaches to meeting those objectives and constraints
• The resources (e.g., skills, environment, tools, new technologies) that will be needed
• Risks associated with these factors and how they are addressed
The project strategy typically takes a long-term view of a project, reflects its entire scope, considers long-term risks, and addresses the roles to be played by multiple stakeholders, including suppliers, the customer, and other projects.
The project strategy may play various roles, but typically and initially, it serves as the basis for senior management approving a project and committing resources to it. As project planning proceeds, and the solution, processes, resources, and risks are explored and developed, the project strategy may need to be revised.
For a short-duration project, a project strategy may not be developed or only developed once, in which case it is replaced by the project plan as the project progresses and more detailed planning becomes possible.
For a long-duration project, the strategy plays a continuing role in helping to maintain a long-term view of the project and its rationale, touching on various elements of the project plan but at a higher level of abstraction; whereas the project plan will typically reflect a much lower level of detail over a shorter time horizon.
A project strategy may initially be created by the organization or by prospective project personnel perhaps in collaboration with potential customers and suppliers, or some other combination of parties with a strategic business view of the prospects for the project.
The project strategy may include a top-level description of the services to be provided, the approach to developing the service system, and the approach to service delivery as appropriate.
Typical Work Products
1. Project strategy
Subpractices
1. Identify the objectives of the project and the capabilities it intends to provide.
The organization may maintain an overall business strategy in which the project plays a role in establishing capabilities needed by the organization. The project-related objectives and capabilities described in this subpractice may be derived from such considerations for the overall business, but will tend to have a specific or near-term set of objectives and capabilities.
Refer to the Strategic Service Management process area for more information about establishing and maintaining standard services in concert with strategic needs and plans.
2. Identify the approach used to achieve the objectives or provide the capabilities.
There will often be both an approach to developing the infrastructure needed to deliver services (i.e., technical approach) and an approach to delivery that accounts for customer satisfaction, skill levels needed, skill levels available, costs, and risks.
Refer to the Service Delivery process area for more information about establishing the service delivery approach.
3. Document business considerations.
Business considerations include potential costs and benefits, intellectual property, competitive climate, aging of the industry and impact on long-term needs and profit margins, core competencies of the organization to be enhanced, core competencies needed from other parties, and future trends in society, trade, and technology.
4. Identify major resource needs.
A review of the project approach helps to identify categories of resources needed by the project and the suppliers of these resources (e.g., other business groups within the organization, specific functional groups, human resources, intellectual property experts, the legal department, the marketing department, business partners, external suppliers).
Refer to the Capacity and Availability Management process area for more information about ensuring effective service system performance and ensuring that resources are provided and used effectively to support service requirements.
5. Identify stakeholders that will play major roles in the project.
The Plan Stakeholder Involvement specific practice provides a more detailed, though perhaps shorter term, consideration of which stakeholders to involve in the project and in what way.
The project approach may be able to leverage external stakeholders (e.g., existing and potential customers and business partners) to provide some of the needed resources.
6. Identify the agreement types to be used.
To be successful, the project must establish agreements with its major stakeholders. The nature of those agreements is determined, in part, by considering each party’s needs, objectives, expectations, constraints, and risks. The types of agreements selected should be part of business considerations and thus help answer how various parties will share in the risks, costs, and benefits of the project.
7. Identify risks and how those risks may be allocated to various stakeholders.
The Identify Project Risks specific practice in this process area provides a more detailed, though perhaps shorter term, consideration of the risks that the project may encounter.
8. Identify the approach used to maintain safety and security in the project.
Attention to safety and security should be present in all major planning activities (e.g., those related to project objectives, resources, risks, and stakeholders) but this subpractice suggests taking a holistic view and focus on safety and security issues and risks, and the activities the project might take to address them.
9. Review the project strategy with senior management and obtain its agreement.
Review the project strategy from the following key business perspectives:
• Are these objectives the right ones?
• Is the approach feasible?
• Is this strategy an appropriate allocation of the organization’s resources for a prolonged period of time?
• What is the return on investment?
• What opportunities open up as a result of this strategy?
• Will the organization be subjected to excessive risk?
• What roles might some not-yet-identified major stakeholders play in project success?
• How might customers, suppliers, and competitors react?
10. Revise the project strategy as necessary.
Depending on the duration of the project, it may be necessary to refine the project strategy to reflect changes in the objectives, approach, availability of resources, market conditions, customer needs, process and product technologies, etc.
SP 1.2 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. Initially, 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 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.
The activities in a WBS may be organized in different ways but are typically scoped by time or duration and address both service system development and maintenance as well as service delivery as appropriate. Some of the services identified may be continuously delivered; others may be in response to ad hoc requests. Both are specified in a (possibly future) service agreement.
Activities may be further organized along one or more dimensions. For example, in the case of product maintenance, we could further distinguish activities according to those persisting through the end of the life of the product (from product delivery through product disposal), activities related to managing and executing the service agreement, and activities related to an individual incident or service request.
Typical Work Products
1. Task descriptions
2. Work package descriptions
3. WBS
Subpractices
1. Develop a WBS based on the project strategy.
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.3 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of work product and task attributes.
The estimate of 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 tasks for which size measures are made include the following:
• Service system development and delivery
• Service system monitoring
• Preventative maintenance or repair
• Training in operations
• Incident management and resolution
• Monitoring for and addressing obsolescence
• Updating equipment and supplies used by service teams
• Logistical support
• Facilities maintenance
• System disposal
Examples of size measures include the following:
• Number of requirements
• Number and complexity of interfaces
• Number of risk items
• Volume of data
• Number of service levels
• Availability of services, by service level (e.g., turnaround time, operational availability ratio, number of calls the help desk should be able to handle per hour)
• Number of stakeholders affected by a service level
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.
Typical Work Products
1. Size and complexity of tasks and work products
2. Estimating models
3. Attribute estimates
Subpractices
1. 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 service development and delivery characteristics to attributes increases.
2. Estimate the attributes of work products and tasks.
SP 1.4 Define Project Lifecycle Phases
Define project lifecycle phases on 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 selection of a lifecycle for development and delivery of services will depend on the characteristics of the services and their environment. Some service providers will define phases based on their standard service definitions.
Refer to the Strategic Service Management process area for more information about establishing standard services.
Often, individual services have implicit lifecycles associated with them that involve points of communication, evaluation, and decision and should be considered when estimating what is required to support delivery of such a service.
Typical Work Products
1. Project lifecycle phases
SP 1.5 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 may 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. An effort is unprecedented if the organization has no experience with such a product.
Typical 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 target environment, or any appropriate combination of these environments when estimating effort and cost.
Examples of infrastructure resources include the following:
• Critical computer resources
• Tools with which service teams will be equipped
• Facilities, machinery, and equipment
3. Estimate effort and cost using models and historical data.
Effort and cost inputs used for estimating typically include the following:
• 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
• Service and service system requirements
• Product and product component requirements
• Project strategy
• WBS
• Size estimates of work products, tasks, and anticipated changes
• Cost of externally acquired products
• Selected project lifecycle model and processes
• Lifecycle cost estimates
• Capability of tools provided
• Skill levels of managers and staff needed to perform the work
• Knowledge, skill, and training needs
• Facilities needed (e.g., for developing and maintaining the service system and for service delivery)
• Capability of manufacturing processes
• Travel
• Level of security required for tasks, work products, personnel, and the work environment
• Service 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.
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on project requirements and established estimates.
The project plan should consider all phases of the project lifecycle. Project planning should ensure that all plans affecting the project are consistent with the overall project plan.
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 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 an 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.
The subpractices and typical work products of this specific practice should be interpreted both at the overall project level and within each service type as appropriate. That is, individual service requests (e.g., to repair a piece of equipment in a remote facility, transport a package to a destination) may have individual milestones, task dependencies, resource allocations, and scheduling constraints that should be considered together and in coordination with the larger project’s budgeting and scheduling activities.
Typical Work Products
1. Project schedules
2. Schedule dependencies
3. Project budget
Subpractices
1. Identify major milestones.
Milestones are preplanned events or points in time at which a thorough review of status is conducted to understand how well stakeholder requirements are being met. (If the project includes a developmental milestone, then the review is conducted to ensure that the assumptions and requirements associated with that milestone are being met.) Milestones may be associated with the overall project or a particular service type or instance. Milestones can thus be event based or calendar based. If calendar based, once agreed, milestone dates are often difficult to change.
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 are available. Identifying these assumptions provides insight into the level of confidence (i.e., uncertainties) in the overall schedule.
3. Identify constraints.
Factors that limit the flexibility of management options should be identified as early as possible. The examination of the attributes of work products and tasks often brings these issues to the surface. Such attributes can include task duration, resources, inputs, and outputs.
4. Identify task dependencies.
Frequently, the tasks for a project or service can be accomplished in some ordered sequence that minimizes the duration. This sequencing involves the identification of predecessor and successor tasks to determine optimal ordering.
Examples of tools that can help determine optimal ordering of task activities include the following:
• Critical Path Method (CPM)
• Program Evaluation and Review Technique (PERT)
• Resource-limited scheduling
5. Define 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 the time phasing of activities
• Determining a breakout of subordinate schedules
• Defining dependencies among activities (predecessor or successor relationships)
• Defining schedule activities and milestones to support project monitoring and control
• Identifying milestones for the 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 may require replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan.
Criteria for corrective action are based on the project objectives identified in the project strategy and are typically stated in terms of process, product, and service level measures. The criteria trace back to specific stakeholder needs and threshold values for project success. 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
Typical 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 must be identified and described in an understandable way before they can be analyzed. 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
Examples of risks include the following:
• Change of mission
• Change of customer or end user
• Change of project strategy
• Change in the availability of a needed facility
• Equipment, tool, and part obsolescence
• Defects
• Lost skills
• Supplier failures
• Service interruptions
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 risks are identified
• When risks become problems
• When risks are retired
• When project circumstances change significantly
SP 2.3 Plan 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 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 project’s contract data requirements), or data may be nondeliverable (e.g., informal data, trade studies, analyses, internal meeting minutes, internal design review documentation, lessons learned, or 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.
Typical Work Products
1. Data management plan
2. Master list of managed data
3. Data content and format description
4. Lists of data requirements for acquirers and suppliers
5. Privacy requirements
6. Security requirements
7. Security procedures
8. Mechanisms for data retrieval, reproduction, and distribution
9. Schedule for the collection of project data
10. List 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 must be established to identify who has access to which data as well as when they have access to which data. Requirements and procedures may cover service staff who will have the responsibility for the security of data under the terms of a service agreement.
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 stakeholders.
A review of other elements of the project plan may 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 more stringent levels of configuration control and establish mechanisms to ensure project data are controlled.
SP 2.4 Plan the Project’s Resources
Plan for necessary 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.
Typical 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 reporting templates
Subpractices
1. Determine process requirements.
The processes used to manage a project must be identified, defined, and coordinated with all relevant stakeholders to ensure efficient operations during project execution.
2. Determine requirements for communication mechanisms.
These requirements address the kinds of mechanisms to be used for communicating with customers, end users, service provider personnel, and other stakeholders during service delivery. Such requirements are derived, in part, from process requirements, service agreements, and the project strategy.
Communication mechanisms may be created during service system development and must be regularly reviewed, tailored, and possibly supplemented to meet ongoing service delivery needs.
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 must consider the knowledge and skills required for each identified position as defined in the Plan Needed Knowledge and Skills specific practice.
Refer to the Capacity and Availability Management process area for more information about ensuring effective service system performance and ensuring that resources are provided and used effectively to support service requirements.
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 personnel 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 that they perform their roles effectively and efficiently.
Knowledge delivery to projects involves training project personnel and acquiring knowledge from outside sources.
Staffing requirements are dependent on the knowledge and skills available to support the execution of the project.
Planning for training addresses the knowledge and skills required by project members and support personnel to perform their tasks. Knowledge and skill needs can be derived from project risk.
For example, if the project is providing a service whose successful delivery requires detailed familiarity with a piece of complicated equipment, planning for training ensures that personnel assigned to the project have the appropriate expertise with such equipment or provides training for the project team in those areas.
Training can also include orientation in the project’s processes and the domain knowledge required to execute project tasks. The project may also identify and plan for the knowledge and skills needed by its suppliers. Planning includes ensuring that costs and funding sources to pay for training are available and lead times are sufficient to obtain funding and training.
For long-duration and continuous-operation projects, the knowledge and skills needed will evolve as the following occur:
• Project personnel rotate in and out of the project (or from one service type to another)
• The technology used in the service system or an individual service changes
• The processes and technology used in the development or customer environments change
For example, a change in project personnel creates the need to determine the knowledge and skills needed by new project members. New knowledge and skills are needed during different phases of the project (or as new services or service levels are added). Planning for needed knowledge and skills should address these sources of change.
Refer to the Service System Transition process area for more information about preparing for service system transition and preparing stakeholders for changes.
Typical 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 into 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.
Example relevant stakeholders may include project members, management, suppliers, customers, end users, the organization’s product line team, and other providers of related products and services with which the project must coordinate.
Refer to the Service Delivery process area for more information about establishing service agreements.
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
• Roles and responsibilities of relevant stakeholders with respect to the project by project lifecycle phase
• Relationships among stakeholders
• Relative importance of the stakeholder to the success of the project by project lifecycle phase
• Resources (e.g., training, materials, time, funding) needed to ensure stakeholder interaction
• Schedule for the phasing of stakeholder interaction
Implementing this specific practice relies on shared or exchanged information with the previous Plan Needed Knowledge and Skills specific practice.
Typical Work Products
1. Stakeholder involvement plan
SP 2.7 Establish the Project Plan
Establish and maintain the overall project 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 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 descriptions include responsibility and authority relationships for project staff, management, and support organizations.
Typical Work Products
1. Overall project plan
Subpractices
1. Document the project plan.
Projects may consist of other, lower level projects. A project may consist of a service system development project and a service delivery project. A service delivery project may consist of several services that may benefit from separate planning and the practices of this process area. See the introductory notes for additional comments about the applicability of the specific practices in this process area to projects. When projects consist of other projects, the overall project plan should include or reference the project plans of the lower level projects, and all related plans should be compatible and appropriately support one another.
2. Include, reference, and reconcile the results of planning activities as appropriate.
To gain the support of relevant stakeholders, the project plan should document a realistic and sensible approach to meeting their needs, expectations, and constraints. Such a plan requires various planning elements to be reasonably complete and consistent (at least until the next plan revision, which may be weeks or months away).
If implemented appropriately, the specific practices of this process area address the Plan the Process generic practice as applied to other project-related process areas within the scope of the process improvement effort, but otherwise the results of implementing that generic practice should also be considered in this subpractice.
3. Review the project plan with relevant stakeholders and get their agreement.
The specific practices of the next specific goal, Obtain Commitment to the Plan, describe activities to help ensure the project plan describes a realistic approach for meeting the needs, expectations, and constraints of relevant stakeholders and to help ensure that these relevant stakeholders will fulfill their roles as described in the project plan, including the provision of resources and other forms of support during project execution.
4. Revise the project plan as necessary.
In general, when revising the project plan, it may be necessary to repeat many of the planning activities described in this process area to help ensure that relevant stakeholder commitments to the plan are maintained.
SG 3 Obtain Commitment to the Plan
Commitments to the project plan are established and maintained.
To be effective, plans require commitment by those responsible for implementing and supporting the 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 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 that 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.
Typical 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.
Typical Work Products
1. Revised methods and corresponding estimating parameters (e.g., better tools, the 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.
Typical 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 the appropriate level of signatories.
Commitments must be documented to ensure a consistent mutual understanding and for project tracking and maintenance. Provisional commitments should be accompanied by a description of 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 regarding interfaces between project elements and other projects and organizational units so that these commitments can be monitored.
Well-defined interface specifications form the basis for commitments.