PLANNING PERFORMANCE DOMAIN

Planning organizes, elaborates, and coordinates project work throughout the project.

Figure 2-13. Planning Performance Domain

The following definitions are relevant to the Planning Performance Domain:

Estimate. A quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or durations.

Accuracy. Within the quality management system, accuracy is an assessment of correctness.

Precision. Within the quality management system, precision is an assessment of exactness.

Crashing. A method used to shorten the schedule duration for the least incremental cost by adding resources.

Fast Tracking. A schedule compression method in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration.

Budget. The approved estimate for the project or any work breakdown structure (WBS) component or any schedule activity.

2.4.1 PLANNING OVERVIEW

The purpose of planning is to proactively develop an approach to create the project deliverables. The project deliverables drive the outcomes the project was undertaken to achieve. High-level planning may begin prior to project authorization. The project team progressively elaborates initial project documents, such as a vision statement, project charter, business case, or similar documents to identify or define a coordinated path to achieve the desired outcomes.

It is becoming more common for initial planning to consider social and environmental impacts in addition to the financial impacts (sometimes referred to as the triple bottom line). This may take the form of a product life cycle assessment which evaluates the potential environmental impacts of a product, process, or system. The product life cycle assessment informs the design of products and processes. It considers the impacts of materials and processes with regards to sustainability, toxicity, and the environment.

The amount of time spent planning, both up front and throughout the project, should be determined by the circumstances. It is inefficient to spend more time planning than is needed. Therefore, the information gained from planning should be sufficient to move forward in an appropriate manner but not more detailed than necessary. Project teams use planning artifacts to confirm stakeholder expectations and provide stakeholders with the information they need to make decisions, take action, and maintain alignment between the project and stakeholders.

2.4.2 PLANNING VARIABLES

Because each project is unique, the amount, timing, and frequency of planning varies. Variables that influence how project planning is conducted include, but are not limited to:

• Development approach. The development approach can influence how, how much, and when planning is conducted. Examples include:A specific phase for planning or organizing early in the life cycle. In these situations, much of the planning is performed up front. The initial plans are progressively elaborated with more detail throughout the project, but there is little change to the original scope.An approach with high-level planning up front, followed by a design phase where prototyping is used. After the project team and stakeholders agree to the design, the project team completes more detailed planning.Adaptive approaches where the project team conducts iterations. Some planning occurs up front to establish release plans and further planning occurs at the beginning of each iteration.
• Project deliverables. Often the project deliverables necessitate planning in a specific way. Construction projects require significant up-front planning to account for design, approvals, materials purchasing, logistics, and delivery. Product development or high-technology projects may use continuous and adaptive planning to allow for evolution and changes based on stakeholder feedback and technological advances.
• Organizational requirements. Organizational governance, policies, procedures, processes, and culture may require project managers to produce specific planning artifacts.
• Market conditions. Product development projects can take place in a highly competitive environment. In these situations, project teams can undertake a minimum amount of up-front planning as the emphasis is on speed to market. The cost of delay that extensive planning entails exceeds the risk of potential rework.
• Legal or regulatory restrictions. Regulatory agencies or statutes may require specific planning documents before granting an authorization to proceed or to secure approval to release the project deliverable into the market.

2.4.2.1 Delivery

Planning begins with understanding the business case, stakeholder requirements, and the project and product scope. Product scope is the features and functions that characterize a product, service, or result. Project scope is the work performed to deliver a product, service, or result with the specified features and functions.

Predictive planning approaches start with the high-level project deliverables up front and decompose them into more detail. This approach can employ a scope statement and/or a work breakdown structure (WBS) to decompose the scope into lower levels of detail.

Projects that use iterative or incremental approaches can have high-level themes or epics that are decomposed into features, which are then further decomposed into user stories and other backlog items. Work that is unique, significant, risky, or novel can be prioritized to reduce the uncertainty associated with project scope at the start of the project before significant investment has taken place. Project teams plan routine work based on the concept of last responsible moment. This approach defers a decision to allow the project team to consider multiple options until the cost of further delay would exceed the benefit. It reduces waste by not expending time in developing plans for work that may change or may not be needed.

2.4.2.2 Estimating

Planning entails developing estimates for work effort, duration, costs, people, and physical resources. Estimates are a quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or duration. As the project evolves, the estimates can change based on current information and circumstances. The project’s phase in the life cycle impacts four aspects associated with estimating:

• Range. Estimates tend to have a broad range at the start of the project when there is not much information about the project and product scope, stakeholders, requirements, risks, and other information. Figure 2-14 shows a range of -25 to +75% at the start of exploring a project opportunity. Projects that are well along in their life cycle may have an estimating range of -5 to +10%.
• Accuracy. Accuracy refers to the correctness of an estimate. Accuracy is linked to range in that the lower the accuracy, the larger the potential range of values. An estimate at the start of the project will have less accuracy than one that is developed halfway through the project.
• Precision. Precision is different from accuracy (see Figure 2-15). Precision refers to the degree of exactness associated with the estimate. For example, an estimate of 2 days is more precise than “sometime this week.” The precision of estimates should be compatible with the desired accuracy.
• Confidence. Confidence increases with experience. Experience working on a previous, similar project can help with the level of confidence required. For new and evolving technology components, the confidence in estimates is expected to be low.

Figure 2-14. Estimate Range Decreases over Time

Figure 2-15. Low Accuracy, High Precision

There are different ways of presenting and/or adjusting estimates:

• Deterministic and probabilistic estimating. Deterministic estimates, also known as point estimates, present a single number or amount, such as 36 months.Probabilistic estimates include a range of estimates along with the associated probabilities within the range. They can be developed manually by (a) developing a weighted average based on multiple likely outcomes, or (b) running a simulation to develop a probability analysis of a particular outcome, usually in terms of cost or schedule.

A probabilistic estimate derived from a computer simulation has three associated factors:

1.A point estimate with a range such as 36 months +3 months/-1 month.

2.A statement of confidence such as a 95% confidence level.

3.A probability distribution describing the dispersion of the data within and around the given range.

Together these three items form a complete metric describing a probabilistic estimate.

• Absolute and relative estimating. Absolute estimates are specific information and use actual numbers. An absolute estimate for effort might be shown as 120 hours of work. One person working full time could accomplish the work in 15 workdays, assuming 8 hours of productivity per workday.While absolute estimates are specific, relative estimates are shown in comparison to other estimates. Relative estimates only have meaning within a given context.

One form of relative estimating is planning poker. In planning poker, the project team performing the work comes to a consensus on the effort that is necessary to deliver value. Using story points to estimate work could result in 64 story points being assigned for that work. New work is estimated using the amount of estimated work compared to points assigned to previous work. Therefore, new work effort is compared to previously known work effort.

• Flow-based estimating. Flow-based estimates are developed by determining the cycle time and throughput. Cycle time is the total elapsed time it takes one unit to get through a process. Throughput is the number of items that can complete a process in a given amount of time. These two numbers can provide an estimate to complete a specified quantity of work.
• Adjusting estimates for uncertainty. Estimates are inherently uncertain. Uncertainty by definition is associated with risk. Key deliverable dates or budget estimates may be adjusted, or contingency time or funds may be added, based on the outcomes of a simulation conducted to establish the range of uncertainty for these parameters.

2.4.2.3 Schedules

A schedule is a model for executing the project’s activities, including durations, dependencies, and other planning information. Schedule planning can use predictive or adaptive approaches.

Predictive approaches follow a stepwise process as follows:

• Step 1. Decompose the project scope into specific activities.
• Step 2. Sequence related activities.
• Step 3. Estimate the effort, duration, people, and physical resources required to complete the activities.
• Step 4. Allocate people and resources to the activities based on availability.
• Step 5. Adjust the sequence, estimates, and resources until an agreed-upon schedule is achieved.

If the schedule model does not meet the initial desired end date, schedule compression methods are applied. Crashing is a schedule compression method that seeks to shorten the duration for the least incremental cost. Crashing can include adding people to activities, working overtime, or paying to expedite deliveries.

Fast tracking is a schedule compression method in which activities or tasks that are normally done in sequence are performed in parallel, at least for a portion of their duration. Fast tracking often entails applying leads and lags along a network path. A lead is where the work of a successor activity is accelerated, such as starting a successor activity before the predecessor has finished. In Figure 2-16, there is a lead between the finish of Task 2 and the start of Task 4.

A lag is a delay of a successor activity. An example of using a lag would be changing the type of relationship between activities, and then applying a lag. For example, rather than waiting for an activity to finish before the next one starts (a finish-to-start relationship), change the relationship to have the end of the successor activity finish a determined amount of time after the end of the predecessor (a finish-to-finish relationship). The network logic would show a lag between the finish of the predecessor and the finish of the successor activities. There is an example of a finish-to-finish relationship with a lag in Figure 2-16 between Task 8 and Task 7. A lag can also be applied between the start of one activity and the start of another activity (a start-to-start relationship).

Figure 2-16. Fast Tracking Examples

When compressing the schedule, it is important to determine the nature of the dependencies between activities. Some activities cannot be fast tracked due to the nature of the work—others can. The four types of dependencies are:

• Mandatory dependency. A relationship that is contractually required or inherent in the nature of the work. This type of dependency usually cannot be modified.
• Discretionary dependency. A relationship that is based on best practices or project preferences. This type of dependency may be modifiable.
• External dependency. A relationship between project activities and non-project activities. This type of dependency usually cannot be modified.
• Internal dependency. A relationship between one or more project activities. This type of dependency may be modifiable.

Adaptive schedule planning uses incremental planning. One such scheduling approach is based on iterations and releases (see Figure 2-17). A high-level release plan is developed that indicates the basic features and functionality to be included in each release. Within each release, there will be two or more iterations. Each iteration adds business and/or stakeholder value. Value may include features, risk reduction, experimentation, or other ways of delivering or protecting value. The planning for the work in future releases is kept at a high level so the project team does not engage in planning that could change based on feedback from earlier releases.

Figure 2-17. Release and Iteration Plan

Adaptive approaches often use timeboxes. The work in each timebox is based on a prioritized backlog. The project team determines the amount of work they can do in each timebox, estimates the work, and self-manages to accomplish the work. At the end of the timebox, the project team demonstrates the work completed. At that point, the backlog and estimates of work available to be done may be updated or reprioritized for the next timebox.

Determining the schedule involves using the information in the estimating section to determine overall duration and effort estimates. Regardless of the scheduling approach used, the relationship between effort and duration needs to be addressed. Some activities are effort driven, which means that the duration can be reduced by adding people. This approach can work up to a point, after which adding people might actually extend duration. Framing a building is effort driven. If more people are added, the duration can be reduced. Some activities are fixed duration, such as running a test or conducting employee training.

The nature of the work determines if and how much the duration can be reduced by adding people before increasing the time due to coordination, communication, conflict, and potential rework. There is no fixed formula to determine the reduction in duration due to the addition of people.

2.4.2.4 Budget

The project budget evolves from the agreed estimates for the project. The information in Section 2.4.2.2 on Estimating is applied to project costs to develop cost estimates. Cost estimates are then aggregated to develop the cost baseline. The cost baseline is often allocated across the project schedule to reflect when the costs will be incurred. This practice allows project managers to balance the funds approved in a specific budget period with the scheduled work. If there are funding limitations for a budget period, the work may need to be rescheduled to meet those limitations.

The project budget should include contingency reserve funds to allow for uncertainty. Contingency reserves are set aside to implement a risk response or to respond to risk events should they occur.

Management reserves are set aside for unexpected activities related to in-scope work. Depending on the organization’s policies and organizational structure, management reserves may be managed by the project, the sponsor, product owner, or the PMO at the program and portfolio level. Figure 2-18 shows the budget build up.

Figure 2-18. Budget Build Up