Study Phase—Planning Activities

Abstract

Planning (also called forethought) is the process of thinking about and organizing the activities required to achieve a desired goal. The planning activities define the value proposition delivery strategy, which aims to develop the scoped product in the most efficient way, with no/minimum waste, unevenness, or over burden. This chapter uses the stall recovery system project example to present a stepwise execution of this phase’s activities, where special emphasis is given to defining the pull events that shape the future development execution.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Planning (also called forethought) is the process of thinking about and organizing the activities required to achieve a desired goal. The planning activities (Fig. 12.1) define the value proposition delivery strategy, which aims to develop the scoped product in the most efficient way, with no/minimum waste, unevenness, or overburden. This chapter uses the stall recovery system project example to present a stepwise execution of this phase’s activities, where special emphasis is given to defining the pull events that shape the future development execution.

Fig. 12.1

Value delivery planning activities position in the PDP

1 Introduction

In order to support a JIT-like execution phase, the development plan is indeed composed by a sequence of “pull events” that guide the development team through the development activities.

Instead of pushing scheduled activities, which themselves push information and materials through the development process, pull events guarantee the value flow, make quality problems visible and create knowledge. They are typically tied to physical evidence of progress, such as: (1) integration events that create “boundary objects” as built engineering projects, mockups, prototypes, etc.; (2) successful endings of checks and validations, which are moments of reducing uncertainty and risk in the program. The pull events set creates a “ladder” where in each step up we get closer to the development success.

According to the Project Management Institute [1], planning consists of those processes which establish the total scope of the project effort, define and refine the objectives, and develop the course of action required to attain those objectives.

Indeed, the PD planning takes place during the whole study phase, where the PDVMB and the VFD create a backbone to support and align the planning activities. By finishing the study phase, we can observe that all the project management process groups [1] have been somehow considered (Table 12.1).

Table 12.1 Project management process and the book’s method

2 Using the Board to Guide the Value Delivery Planning Activities

Once having defined the value proposition, your next step is creating a strategy on how to deliver it in the most efficient way. On the PDVMB and VFD filling sequence described below (Fig. 12.2), you are going to focus on defining both the complete PD team and the pull events that will be used during the execution phase of the PDP. In fact, the defined pull events will become the milestones during the execution phase. Note that at this moment the focus is on completing the VFD, by filling its Concurrent Engineering and Flow Definition Sub-matrices.

Fig. 12.2

PD visual management board filling sequence

2.1 Milestone Chart and Progress Board

Both the milestone chart and the progress board must be updated and reviewed at each team meeting. Activities will progress from Not Checked Out ≫ Checked Out ≫ Done through the progress board, and the team shall control the work pace according to this progress, also considering any risk mitigation and issue-solving activities added to the backlog.

2.2 Risks and Issues

Advancing through the PDP is like climbing a ladder, after each step seeing further ahead. As a consequence, more knowledge about the development challenge is built and better understanding of the related risks is obtained.

During the planning activities, you might find new risks and redefine previous ones, particularly when related to the team structure and capacity and aspects that might impact on the activity timely execution (i.e., aspects related to suppliers). Whenever a risk or issue is identified, mitigated, or solved, this filed is revisited and updated.

2.3 Fill the VFD’s Concurrent Engineering and Flow Definition Sub-Matrices

At this moment, you have already created the value proposition (PD program scope), and now you must determine what functional divisions will need to participate during the development execution, what they will do (which value delivery function they will work on), and when they will do it (the pull events’ scope).

The following VFD filling occurs according to the steps presented in Chap. 9.

2.3.1 Identify the Value Delivery Teams

The lean PD flow is achieved by product teams with all necessary skills to drive the general design, detailed engineering, prototyping, testing, procurement, equipment and production planning activities with no/minimum waste.

Integrated product teams, when effectively implemented (as seen in Chap. 2), greatly improve the use of human capital during PD and help provide a better understanding and communication among the various stakeholders.

The full development team encompasses all and only the necessary people to develop the alternatives chosen to be carried out during the development project, and to deliver the complete value items set through the designed functional architecture.

You shall consider “value delivered teams” subsets of people from the company’s functional areas related to the PD program’s product/service. These functional areas are not limited to engineering and production, but also might include the complete value chain areas (acquisitions, marketing, services, etc.) This is particularly true when the results from the development projects include not only (if any) product, but also services or even new value stream.

Note that the set of teams is bounded by the LPDO’s organizational structure and by the results from the make or buy analysis which defines what is going to be acquired/supplied and what is going to be developed internally. Therefore, different LPDO might develop the same product/service using diverse value delivered team sets.

The stall recovering system example, for instance, included both value delivered teams related to the product and to the company’s value chain which includes the suppliers:

• MEC—Mechanical Engineering

• ELE—Electronic Engineering

• SYS—Systems Engineering

• CHE—Chemical Engineering

• AER—Aeronautical Engineering

• QUA—Quality Engineering

• IND—Industrial Engineering

• PRO—Production Department

• CLI—The Client himself

• CE—Chief Engineer

• HOM—Homologation Department

• LOG—Logistics Department

• ADM—Administrative Department

• SPP—Suppliers of Pieces and Parts

• SLT—Suppliers of Labs and Test Facilities

2.3.2 Define the Contributing Roles of Each Value Delivery Team

Each team’s role in contributing to deliver a particular function shall be mapped in the VFD’s Concurrent Engineering Sub-matrix. During this mapping we recommend using the Role and Responsibility Charting (RACI) notation, as presented in Table 12.2.

Table 12.2 RACI mapping

By setting this relationship among functions and teams, the need of concurrent engineering becomes evident; the VFD creates a visual for which teams need to communicate and cooperate in order to guarantee that a certain function will deliver all the related pulled value.

Considering the [Receive Pilot Command] function in Table 12.3, all the linked teams contribute somehow to developing it. Therefore, the PD success is only achieved if all the participant teams perform real concurrent engineering.

Table 12.3 Concurrent engineering sub-matrix

2.3.3 Define Preliminary Pull Events

The challenge to schedule within a complex (and even multi-project) environment is to schedule in only the details that accomplish the objectives—avoiding the waste of excessive information and false sense of control. Intermediate dates are crucial to manage limited resources across multiple programs and these dates have to be approached with rigor and precision.

The pull events are the backbone of the value flow and are important moments to knowledge capture; by pulling the value delivery, they allow the planning to reach execution. Every pull event is associated with physical progress evidences (e.g., models, prototypes, start of production, etc.).

As a result, the company aligns and tiers engineering cadence with lower-level events designed to support higher level program events. Engineers and suppliers come to these reviews with prototypes, test results, open issues, and so forth, so that the CE can determine (at the source) whether the program is where it is supposed to be. Later in the process, the CE schedule physical prototype builds and part coordination events to the same effect. Engineering leaders meet periodically with the CE to review the program status, open issues, and performance metrics, which are posted on the PDVMB.

In this context, “boundary objects” (models, prototypes, tools, and activities that allow the sharing of knowledge and information across the organization and/or areas of knowledge) facilitate integration, providing a common reference for the team [2, 3].

To define a sequence of preliminary pull events, the development team can use the enterprise’s standard process (if there is one), reuse historical information from previous projects, or consider best practices from the industry. For the stall recovery system example, twelve pull events were preliminarily defined, as adapted from the company’s standard development process (Fig. 12.3). Once two or more events have activities occurring in parallel, they cannot be characterized as phase gates.

Fig. 12.3

Pull events

Defining pull events is a tricky job. We recommend that you have what we call a “stairway building mindset,” where you design the steps leading you to the PD vision. At each step you should have gained more knowledge and become more confident with the PD success. We also do not expect that you set a pull event that gives you low confidence results and that requires you to reconfirm aspects that were on its scope: you should keep walking, but not in circles.

2.3.4 Relate the Pull Events to the Value Items and Risks

A pull event must be related to at least one value item and/or risk, and each value item must be checked by at least one pull event. A pull event’s scope is defined by the set of related value items and risks, according to the MoE verifications that would be executed on these exact value items [2, 3]:

• Inspection: An action of observation, visual examination, or investigation against relevant documentation to confirm the compliance of the material or system with the technical requirements.

• Analysis: A check action through evaluation equations, graphs, data reduction, extrapolation of results, or reasoned technical argument, that specified requirements for a material or service have been met.

• Calculus: Performing mathematical or computer simulations.

• Demonstration: The display of features, performance, and operational capacity of an item, equipment, or system where success is found only through behavioral observation and/or results. Tests that require a simple quantitative verification measure, such as weight, size, time to perform tasks, are included in this category.

• Test: Verification of action, through the full exercise of the item, equipment, or system under appropriate controlled conditions, in accordance with approved test procedures. The test can be subsystem (T1) and the integrated product (T2).

Table 12.4 shows how the [realign the aircraft] value items and the risks were related to the defined pull events (Fig.  12.3).

Table 12.4 Example of pull event’s scope

2.3.5 Refine the Pull Event Set

Be checking the completely filled Flow Definition Sub-matrix, you can visually check if the scope of the pull events set that you planned makes sense. Having highly valued items less verified than low value items, and failing to check risk mitigation are some examples of common mistakes. Therefore, the preliminary pull event set shall be refined until it meets the following criteria:

• (1) Is the set capable of verifying the progress of the effective value incorporation and the delivery of the project execution?

• (2) Is the set balanced according to the value item’s importance, where it is rare to expect less relevant value items being tested more thoroughly than the more relevant ones?

• (3) Does the set represent the value flow in order to guarantee the information is pulled, not pushed?

• (4) Does the set show the elimination of the risks that led to the development of multiple alternatives, allowing the combination and the reduction of the number of alternatives during the SBCE?

3 A Practical View

At this moment, after having identified the value items set, and defined the SBCE strategy, the value delivery team, and the pull events set, the complete VFD shall be checked and balanced against the development project cost restrictions. It must be done before starting the execution phase.

Even though they reduce risk, there is a cost impact for both the SBCE, which includes more people to work on the multiple alternatives, and the pull events. Since they are waste mitigation strategies, they might increase the planned costs while reducing the likelihood of waste occurrence. Remember that if the wastes did occur, the expenditures would be even higher, but there is always the chance they will not happen. This is the dilemma of acquiring or not acquiring insurance.

Looking at the complete VFD (Fig. 12.4), the pull events are used to check that the actual implementation of the value delivery functions, which are made/built by the value delivery teams applying concurrent engineering, are indeed delivering all the value related to them (functions), while mitigating the associated risks.

Fig. 12.4

The relation among the VFD’s core elements

While doing the final and complete VFD check, you should confirm that the pull event set give you confidence in delivering the value items (particularly the most important ones) while mitigating the risks.