CHAPTER 5

Planning

Planning follows expectations (see Figure 5.1). It is often part of contractual agreements in case of predictive delivery. Planning is a very traditional concept that needs to be adjusted with the delivery model, either predictive or agile. HybridP3M’s approach to planning is characterized by very explicit planning objectives, the commonly used work breakdown structure (WBS), and planning iterations with or without baselines, depending on the delivery model. The planning iterations focus on the planning of Work Packages aligned with Agile product delivery. HybridP3M also introduces the concept of “project history plan,” a plan that emerges based on actual progress and hindsight information. The project history plan is more dominant in Agile delivery, which is less predictable and thus more difficult to plan. The project history plan is very useful for evaluation purposes and learning across projects.

Defining and Analyzing Product

The first step in the planning process is always to define and analyze the product. The outcome is a product definition, and thus, this activity also relates to project/ program definition. The product definition defines the end product, and likely subcomponents or features. The delivery of an end product is usually organized around key deliverables for control and handover purposes. Analysis of the product helps to define these key deliverables. In practice, make-or-buy decisions determine whether specific components are external, third-party products. Such external products, adopted from PRINCE2, should be designated as such in the planning process, and require special attention given the additional uncertainty factor (e.g., regarding the delivery process or quality). Finally, the product definition is added to the “overall project plan.”

image

Figure 5.1 Planning PDD

Adopting Delivery Model

The second step in the planning process is to choose a delivery model. HybridP3M is compatible with both Agile and waterfall delivery. The HybridP3M process of Agile product delivery is essentially an agile approach. However, the stage-gate paradigm applies as well. So a waterfall approach based on linear stages is possible as well. It should be noted that selecting a particular delivery model is binary: it is either waterfall or agile. Something in between does not exist. So a hybrid methodology like HybridP3M is not something in between either. HybridP3M simply combines Agile product delivery, being compatible with waterfall as well, with traditional management control as overhead for more predictive behavior.

Defining Planning Objectives

The third step is to define planning objectives. A distinction can be made between at least three types of planning objectives: (1) acceleration tactics, (2) rework cycle strategy, and (3) levels of plan. Acceleration tactics refer to tactical decisions, like for example,parallel planning of activities, that aim to reduce project duration. Acceleration can be desirable from the outset but also when projects fall behind schedule due to various reasons. With acceleration comes greater risk. One perverse outcome of acceleration could be the increase of rework. Rework cycles, which often lay at the root of disruption and delay, should be considered at a strategic level in combination with acceleration tactics, especially in case of Agile delivery due to changing requirements. There are potentially three levels of plan: at the project level, stage level, and team level (adopted from PRINCE2). The delivery model has great impact on the levels of plan. In case of Agile delivery, the project level plan is less detailed and no stage or team plans are guiding material. In case of waterfall delivery, the project plan is detailed and controlled based on lower-level stage plans. In case of large waterfall projects with multiple teams, team plans add value thanks to even greater detail.

Creating Work Breakdown Structure

The next step is to create a WBS, a hierarchical structure of elements that comprise the end product. PRINCE2 uses a product breakdown structure focused on products and subproducts. HybridP3M uses the more widely known WBS. The difference is that the WBS focuses on activity, related to deliverables or project outcomes, a nuance as such. A WBS is the preferred notion, especially when dealing with less tangible products, like services or change. The creation of a WBS is a skill and rather self-explanatory. Knowledge such as examples of similar past projects is very useful to this end.

Setting Planning Tolerances

Based on the overall business case, planning tolerances are needed as a control mechanism. Exceeding such tolerances—anticipated or actually—triggers management-by-exception, the situation in which decision makers decide on the viability of the project while handling the exception, based on intervention such as corrective actions or adjusted tolerances. Since HybridP3M is based on Agile product delivery, stage tolerances cannot be applied, only tolerances at the project level, associated with the fundamental business case. Planning tolerances cover not only time, in order to deliver just-in-time, but also resources like human resources as well as budget required for the investment (on-budget). Scope is another possible tolerance as to limit or exclude certain functionality based on early premises. Tolerances are usually set in percentages based on ball park estimates in combination with required or desired outcomes, such as in terms of duration.

Creating Baseline Project Plan

A baseline project plan is an optional element, depending on the delivery model. In case of predictive delivery such as waterfall, a baseline project plan is used for evaluation and control purposes. A baseline project plan is a plan at the project level. This means that the level of detail is limited. The contents usually would reflect the ball park estimates, given a high-level WBS. The plan is further characterized by distinct stages, which are project phases ending with decision moments to continue with the next stage, in other words, go-no-go decisions. The additional schedule is handy for monitoring progress. For example, predictive projects and programs can benefit from the earned value management technique. In the context of evaluation, project deviations are closely examined by comparing actual plans against the baseline project plan. This type of analysis helps to answer project performance. Since HybridP3M is a generic method, also applicable to an Agile context, stage plan baselines are omitted. The Agile context is too dynamic for predictive stages, but not to the extent that stages cannot be identified at all, provided that project outcomes are not unknown. Extreme projects where requirements are uncertain or unknown not only lack baseline project plans, but lack a project planning process as we know it. The following activities focus on smaller chunks of the project plan organized around Work Packages. In a generic context, Work Packages define stages and should be planned for Agile product delivery.

Analyzing Risks

The activity to analyze risks initially follows the development of a baseline project plan. Based on the latter, risks can be identified related to planning. Many planning risks are related to productivity losses and the rework cycle (Eden et al. 2000), which contribute to the cost of disruption and delay. For example, a subcontractor might fail to deliver a needed product on time, or a resource may not perform at the required level. On occasion, external events may create a crisis, disrupting timely delivery of several products. Analyze risks is a recurring activity as part of new iterations triggered by the need for planning new Work Packages. As new information on new Work Packages becomes available, the planner, supported by the risk manager (or vice versa), may identify new risks or update existing risks. Analyze risks always follows the incentive to plan a Work Package, preceding Work Package definition and planning (as depicted in the diagram) or, alternatively, should at least run in parallel. Given a record of risks, planning the Work Package can be adjusted so that risks are mitigated.

Planning Work Package

The activity to plan Work Packages is typical for hybrid project management, having roots in traditional project management. The concept of Work Package is compatible with Agile because delivery always needs to be defined and planned, and Work Packages are suitable for this purpose. Agile sprints, an Agile notion for fast delivery of manageable chunks, would imply at least one Work Package, but more are possible. Also many organizations have IT systems that record Work Packages for supplier purposes, which link work with costs, and thus, the invoicing process in a commercial customer/supplier environment. A Work Package is essentially a summary of the work that needs to be carried out. It covers a set of requirements and, in case of product-based planning, a specific product description (referring to deliverables), and associates with a specific stage and possibly multiple user stories (in software development).

Identifying Activities and Dependencies

The activity of identifying activities and dependencies consists of two steps: (1) identify all activities required to deliver the products (including project management products) and (2) determine interdependencies between activities. During the second step, one should take into account both internal and external dependencies (e.g., delivery of an external product or decision from corporate/program management). In case of other project outcomes, alternative to products, such as change or capability, activities are identified that support those outcomes. The WBS is used as input and further elaborated with additional detail. PRINCE2 also uses a project flow diagram that can be used in the context of this activity.

Estimating

Once all activities have been identified, the next step is to make estimates. Estimates relate to work, usually in man hours; duration, based on available resources assigned to activities; and cost, which follows work. Estimating is essential for control of cost and duration, and the notion of progress. It is of utmost importance that estimates are accurate for realistic scheduling, the following step. In many industries there exist specific techniques for estimating. The most common and generic technique is expert judgment. A subtechnique in this respect is capacity planning, which states that x available resources result in y duration. Another common technique is analogy, which presumes that similar projects account for similar estimates. This requires systematic registration of projects, according to specific attributes and project types, classification in general. Furthermore, in the software industry parametric models have been applied, in which parameters determine estimates. Parametric techniques use an algorithm and also take into account historic data. In case of software development, one example is to calculate estimates based on the number of functions required in code. Functions relate to specific requirements. This is called function-point analysis, and there exist a number of variations. Another example of a parametric technique is COCOMO.

Scheduling

According to PRINCE2, a plan is a comprehensive management product describing what is required, how and when this will be achieved, and by whom. Visually, this information can be captured by a schedule such as a Gantt chart. Essentially, a schedule is a list of activities and their allocated resources, plus dates over which the activities take place. As most people think of plans as charts with time scales (according to official guidance), such visual representations play a central role in plans. With every new Work Package planned, the overall schedule is modified. This overall schedule is the main element of the project history plan, a new management product introduced in HybridP3M. In other words, the live schedule provides the source for this product. The project history plan depicts progress based on actual statistics. In an Agile context, this product is very valuable because it provides essential input for project evaluation as baselines cannot be used for this purpose.

Executing Plan

Supported by schedules, plans are executed. Executing a plan is the actual work managed according to a delivery process. HybridP3M’s delivery process is introduced in Chapter 16.

Process Aspects

Figure 5.2 captures the knowledge nature of planning.

image

Figure 5.2 Tacit–explicit continuum of planning

Planning mainly relies on explicit planning information. Only explicit knowledge can facilitate agreement on planning. The only tacit dimension of planning (arguably) is the activity to estimate, provided this involves expert judgment.

Figure 5.3 captures the manageability of planning.

image

Figure 5.3 Step-by-step process versus skilled activity continuum of planning

Planning is essentially a step-by-step process that can be rationalized and standardized. To a certain extent it does build on skilled activity, but this is limited to the right use of supporting tools (i.e., it depends on system knowledge). So corporate standards are ideal for promoting and managing the planning process.

Figure 5.4 captures the specialization level of planning.

image

Figure 5.4 Management–specialist continuum of planning

Planning is rather a specialization. While most project managers can create planning schedules, which is key planning data, mature organizations use specialist planners. For example, it takes experience to understand interdependencies integrated in plans or the impact of risk on project planning. Also, planning is closely tied with monitoring and control. This may imply some basic understanding of techniques such as earned value management, complementing planning with progress control.

Figure 5.5 captures IT support in relation to planning.

image

Figure 5.5 Available IT support for planning

Of all project subfunctions, planning is the most popular area for IT support. There is an abundance of project planning software on the international market. MS Project is one of the most popular tools, but there are plenty of alternatives. The list would go on, with large players and smaller ones.

Figure 5.6 captures the complexity of panning.

image

Figure 5.6 Task complexity scale of planning

Planning is rather a complex process. Even more so in Agile projects with a smaller planning horizon. Ultimately, the effectiveness of planning and the usefulness of schedules (a key point of planning) depend on accurate estimates. The complex WBSs are also invaluable. Aspects such as acceleration and risk awareness make planning more complicated or complex.

MAIDEO Requirements

Table 5.1 presents MAIDEO requirements related to “planning.”

Table 5.1 MAIDEO requirements related to planning

Requirement

Level

Dimension

The product is defined and analyzed.

1

Organization and process

The selected delivery model aligned with planning is treated as a binary choice.

1

Organization and process

External products are considered in the planning process.

2

Organization and process

The project uses schedules for the coordination of planned activity.

2

Monitoring and control

The project uses a basic work breakdown structure or equivalent product breakdown structure.

2

Organization and process

Planning objectives include a reference to acceleration tactics, the rework cycle, and address levels of plan.

3

Organization and process

Planning tolerances are applied.

3

Monitoring and control

In predictive delivery baselines plans are used for evaluation and control.

3

Monitoring and control

Risks are integrated with planning and considered on a continuous basis.

4

Organization and process

Planning involves Work Packages.

4

Organization and process

Advanced specialist estimation techniques are applied.

5

Organization and process

Both internal and external interdependencies are addressed in the planning process.

5

Organization and Process

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.223.31.148