Keywords

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.

A product development project normally has its genesis after a PD project is included in the company’s development portfolio, and the product vision is given to the chief engineer . This pulled vision puts the PD wheel in motion, triggering the identification activities (Fig. 10.1), which aim to deliver a comprehensive description of the development project scope, by gathering the value pulled by all the involved stakeholders, both external and internal to the development. 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 eliciting and prioritizing the value pulled by the external and internal stakeholders.

Fig. 10.1
figure 1

Value identification activities position in the PDP

Full size image

1 Introduction

In many traditional companies, once given the product vision, the development team will (1) assume it like law; (2) try to produce the concept internally, mixing the experience and expertise from the team members; or (3) use some market and business data to support their decisions. The lean way assumes the vision as a hypothesis to be confirmed or refuted. The team must go and see ( Genchi Genbutsu ).

Even though we use the PDVMB and the VFD to support the value identification activities, you can use other tools and techniques, provided you keep the lean philosophy . But we strongly recommend you to do it as we suggest here, at least on some of your PD projects, thus gaining confidence to try other approaches and keeping the lean philosophy.

By following the PDVMB filling steps, the development team is guided through the lean journey. It acts as a direction giver, providing process discipline, fostering communication, and facilitating management.

2 The Board Guides the Team Through the Lean Journey

The PDVMB and VFD filling sequence described below (Fig. 10.2) will guide you during the value identification activities. Note that at this moment only the Value Identification Matrix from the VFD is filled, and the new product/process design is not filled.

Fig. 10.2
figure 2

PDVMB filling sequence

Full size image

2.1 The Background Is the Basis for Everything

The contents of this field are normally given to the chief engineer when he/she receives the request to lead the project. It can arrive in different formats: a direct request, one objective from the company strategy, a customer’s request, a project charter, a signed contract, etc. Regardless of the case, it can be always summarized into a couple of unambiguous statements describing:

  • What is the product vision?

  • What versions/models are available to customer?

  • What options/groups of options would be made available to the customer as add-on modules or services?

  • Is this product the first of a future product line where we need to create a platform upon which to build other offerings in future projects?

  • What components/subsystems of the product must remain fixed from the prior product? (i.e. must be reused or not changed due to part commonality with other models, safety, cost, packing, etc.)

  • What are the current product and its history in the marketplace? If there is no current product, what is the related previous experience that the company have?

  • Why are we doing a new product/product line? What demand/value do we perceive as pulling the new product development ?

In good systems and requirements engineering, the product vision corresponds to the Business Requirements Level [1, 2]. Therefore, it should describe the sponsor’s point-of-view, and define the objective of the product development project (goal) and the measurable business benefits for doing the project:

The purpose of the [project name] is to [project goal—that is, what is the team should implement or deliver] so that [measurable business benefit(s)—the sponsor’s goal].

For instance, this book’s background was described as:

The purpose of the development project entitled “THE LEAN PRODUCT DESIGN AND DEVELOPMENT JOURNEY: A PRACTICAL VIEW” is to develop a book, which is going to be available both in printed online versions, and which aims to fill the literature gap of addressing a method to support PD practitioners while changing their current PDP into Lean PDP.

In order to be really practical, we will base our arguments on our experience both on practicing and teaching PD, and will take advantage of our previously published academic work, which was already peer reviewed

In the case of a process development project, this field must include details about the process AS-IS, and why it needs improvement.

2.2 Analyzing the Current Condition

The contents of this field (Table 10.1) are normally available at the chief engineer’s request. It basically contains market intelligence data which supported the new development project attractiveness analysis during the portfolio phase. If this data is not available, special care must be taken while identifying the value, since the development vision may not be supported by relevant and reliable market data, and might not sustain a business case.

Table 10.1 Current condition field contents
Full size table

In the case of a process development project, this field must include the mapping of the process AS-IS, including the identified wastes, its impact (particularly on the cycle time), the bottlenecks and the process restriction.

2.3 I, Myself, and the Others

On the comparative board, the company’s actual product (if any), the competitors, the substitutes, and the planned new product are compared according to the customers’ and the final users’ pulled value .

This board will be updated whenever there is an identified market change and according to the development progress of the company’s new product. Considering innovation success and the outcome from verification and validation activities, the value actually incorporated into the product might vary from the initial plan.

We recommend using either a graph, chart, or table to make the comparison visual. Radar charts, even though bringing graphical and easy to understand information, lose resolution if the number of value items to compare or products to consider increases, thus becoming difficult to read. When comparing lots of data, tables are a better choice.

In the case of a process development project, this field must include details comparing the process AS-IS and the designed process TO-BE against the identified value items.

2.4 Planning for What Is Relevant

The team (even if it is a one-man team) should create an initial version of the milestone chart . This will help them to keep the focus, give priority, and reduce the waste in this phase of the PDP.

Milestone charts are similar to bar charts but only identify the scheduled start or completion of major deliverables and key external interfaces (Fig. 10.3) [3]. This approach helps the team to keep focus and prioritize deliverables. We would rather use this kind of chart since it gives a broader view of what dates cannot be missed and reduces the wastes of wishful thinking, unnecessary processes, scheduled wait, and all the consequences from detailing the whole set of activities for the whole development team.

Fig. 10.3
figure 3

Milestone chart

Full size image

Note that the milestone chart gives a program-level view of the complete development project, thus facilitating the team meetings. Each individual team shall have a more detailed planning, even using bar charts, to help the planning, execution, and control of their specific work. But at the team level they have much more knowledge of how to detail their exact activities and with minimum wishful thinking.

The minimum set of milestones should include the dates the team expects to have the PD Visual Management Board and the VFD fields filled. The milestone chart is reviewed and updated at each team meeting. If you want more control, you can adopt the EVA (Earned Value Analysis —see Chap. 4) to keep track of the development progression. We strongly suggest, though, using instead a kanban system as presented in sequence.

2.5 Kanban and Product Development

The progress board use was borrowed from Agile Methods, and it implements the Kanban system into our product development project. After creating the milestone chart, the team has all the key dates set, but no activities defined to reach any of these dates and with the expected results.

Before you start the real work, you should decide the periodicity of the team’s meetings (we recommend daily or weekly), define the set of activities to be performed in order to achieve the next milestone, and define who is responsible to do what until the next meeting.

Figure 10.4 shows that the set of activities to be performed between milestones shall be put in the “not checked out” space. Whenever a team member starts an activity it is moved to the “checked out” area, and, after completion, to the “done” space. The burn down chart keeps track of the team’s progress, by graphically decreasing the amount of work not initiated, which ideally will reach 0 (zero) until the next milestone, when this process will start again.

Fig. 10.4
figure 4

Progress board example

Full size image

In each meeting, the Progress Board is updated considering the work accomplished and the tasks still to be performed. It is important to keep track of the team productivity in order to have a good sense of how likely they will finish all the work required until the next milestone. This track of productivity is a good measure of the team’s capacity to deliver the development results on time and according to the budget. This field is reviewed and updated in each team meeting.

2.6 The Road Ahead Is Always Bumpy

This field is a repository of all identified risks and issues, and the corresponding planned mitigation or corrective measures. Whenever a risk or issue is identified, mitigated, or solved, this field is revisited and updated.

Identifying risks is a tricky job. People often mistake consequences as risks, while the risks are the very causes of these consequences. You can make a parallel to when you go find the root causes by asking why. For instance, having the project go into overtime and/or over budget is a consequence; but why do you believe this might happen? Maybe you believe there will be changes in the exchange rates and you have important product parts which are imported. Maybe you believe you might suffer delays from a supplier. Maybe you are not sure how easily you are going to master a particular technology. One cannot plan mitigation actions to “go into overtime and/or over budget,” but you can think of actions that face the particular situations that might cause them. These particular situations are the risks.

After identified, qualitative and quantitative impact analysis must be carried out for each risk. A likelihood vs consequence chart (Fig. 10.5) supports this analysis, by either assigning qualitative or quantitative weights to each of the following attributes and respective weights:

Fig. 10.5
figure 5

Likelihood versus impact chart

Full size image

2.6.1 Likelihood

Remote (weight 1)—These are things that have a near 0 % chance of happening to you: “You do not live anywhere close to the Pacific Ring of Fire and your area has never experienced an earthquake, then it would come as a complete and total anomaly for you to experience an earthquake.”

Unlikely (weight 2)—These are things that happen on a regular basis but are less than 33 % likely to happen to you directly: “Each year 1 in every 34 in 100 homes will be burglarized. While this is not statistically likely to happen to you it is something that happens on a regular basis.”

Likely (weight 3)—These are things that are statistically between 33 and 66 % likely to happen to you: “About once every three years you face some electric shortage; it is statistically likely that in any given year you have a 33 % chance of facing electric shortage.”

Highly Likely (weight 4)—These are things that are probably going to happen. The statistics are 67 % or better that you will experience it at some point in your life: “Statistics say you will change a burnt light bulb once every year of your life. At least one burnt light bulb in five years is highly likely.”

Near Certain (weight 5)—These are things that have happened to you before and are almost certainly going to happen again: “You live in Tornado Alley, you have had tornadoes in your area and will almost certainly see them again.”

2.6.2 Consequence/Impact

Negligible (weight 1)—This would not cause a hiccup in your routine, budget, emergency fund, food/water storage or comfort.

Minor (weight 2)—This may cause a hiccup in your comfort or routine but would not affect your budget, emergency fund or food/water storage.

Marginal (weight 3)—This would probably interrupt your routine and your comfort, you may have to dip into your food/water storage on a short term or medium term basis and your budget might be disrupted slightly but your emergency fund would not be touched and your budget would not be altered drastically or on a long term basis.

Critical (weight 4)—Your comfort and routine will be drastically altered. Your budget will be altered significantly and on a long term basis. Your emergency fund will be necessary and you will be using your food/water storage on at least a medium term basis.

Catastrophic (weight 5)—Your comfort and routine will be completely destroyed. Your budget will be altered drastically and on a long term basis. Your emergency fund will not be enough to repair the damage and you will be relying on your food/water storage on a long term basis.

The total risk impact equals to its likelihood weight versus its consequence weight. For instance, a risk which is unlikely to happen (weight 2), but has critical consequences (weight 4) results in a total impact 8 (2*4).

2.7 Fill the VFD’s Value Identification Matrix

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

2.7.1 Stakeholders’ Identification

The first step while filling the VFD is identifying the stakeholders . Stakeholders have to be considered regardless of whether they are inside or outside of the development company (Fig. 10.6), or if they contribute directly or indirectly to the development (which is the case of regulatory agencies).

Fig. 10.6
figure 6

Where are the stakeholders

Full size image

External stakeholders are the ones who pull value from the product development program’s final results (the product and/or services). They can be encountered when we consider the “Product/Process Follow-up” and the “Product Discontinuation” process groups from the PDP.

Internal stakeholders , by the other hand, relate to the value chain , and are the ones who pull value from the product development program’s intermediate results. They can be encountered when we consider the “Design & Development” and the “Production/Ramp-up” process groups of the PDP.

The following questions support the stakeholders’ identification (adapted from [4]). Being a generic questionnaire, it can be adapted to any environment. In order to be considered a stakeholder, at least one of the questions must have a positive answer. In each question, answer “Who ___________?”

  1. 1.

    approves the development budget?

  2. 2.

    approves the functional requirements?

  3. 3.

    approves the technical requirements?

  4. 4.

    approves the engineering design decisions?

  5. 5.

    approves requirements changes?

  6. 6.

    approve budget changes?

  7. 7.

    is going to use or interact with the produced product or service?

  8. 8.

    defines the organizational goals that led to the development?

  9. 9.

    is going to allocate people to the development team, and determine the amount of hours per day that they will work?

  10. 10.

    is going to approve the contracts with suppliers?

  11. 11.

    is the development sponsor (who can use his authority supporting the team to overcome organizational obstacles)?

  12. 12.

    is going to manage the development (ensuring that tasks are completed on time and within the budget and that problems are identified and resolved)?

  13. 13.

    represents the organizational policies governing this development?

  14. 14.

    represents the regulations and laws that affect this development?

  15. 15.

    will have their work disrupted by the development?

  16. 16.

    will have to change their work systems or processes due to this development and its results?

  17. 17.

    will benefit from this development?

  18. 18.

    will perform the work (including vendors, subcontractors, besides the company’s own employees)?

  19. 19.

    makes the approval decisions for phase change during the development process?

The stakeholders list, thus, can be quite extensive, including from the end user and external customers who decide to purchase the product, to the internal customers of the product such as the sales force, the customer service department production, and so forth. In order to handle this list, we defined the stakeholder relevance according to the following prioritization criteria:

  • Primary: define having the right or wrong product (i.e., the customer/client and the final user), or have the ability to cancel the development (i.e., the sponsor and the shareholder);

  • Secondary: contribute decisively to the development; if not satisfied may cause strong disruptions on the PDP flow, or that might erode the product’s image in the market (if developing a process, they can affect the process credibility) and

  • Tertiary: participate in the development, but have minimum power to impact its flow or results.

Table 10.2 shows some examples of internal and external stakeholders .

Table 10.2 External and internal stakeholders
Full size table

2.7.2 Analyze the Value Items

During the value items analysis, the PD team shall:

  1. 1.

    Identify the pulled value;

  2. 2.

    Solve the ambiguity from the pulled value items.

2.7.3 Identify the Pulled Value

For each identified stakeholder group, the development team must understand the value the stakeholders expect) on their own terms. Several approaches can be used to elicit the value: “go and see,” interviews, and so forth. We strongly recommend using the value targeting process and product use analysis (Fig. 10.7), as presented in Chap. 7, so it makes you “stand in the stakeholder’s shoes” and understand the challenges they face regarding the product, for instance:

Fig. 10.7
figure 7

Genchi genbutsu DNA

Full size image

  • Manufacturing: smooth flow through the line, flexible lines ready, mass customization ready;

  • Distribution: marketing channel strategy;

  • Selling: marketing publicity strategy and point of sale;

  • Service/Use and Maintenance: fulfilling the customer/user’s needs, maintenance;

  • End of life/Disposal: recycle/reuse

To support the value identification and organization, we suggest using a value flow diagram (Fig. 10.8) where the value is pulled by the stakeholders through the PDP’s execution and use phases. In order to build the diagram, for each process group you should ask who are the related stakeholders, and for each stakeholder you should ask what does he/she expect from using the product (in whatever state it is: design, prototype , final product, final process, etc.) during each process.

Fig. 10.8
figure 8

Value flow diagram

Full size image

Another tip is identifying the main functions the stakeholder will perform while interacting with the development results, either final or intermediate, in order to perceive its individual benefits and overall value.

While identifying value, special attention must be given to understand all possible dimensions from which the stakeholder might perceive value. We should not be limited, thus, to product/service use (functional aspects), but also consider all the possible needs beyond the product functionalities, some categories of nonfunctional pulled value can be:

Safety—Safety related value for system functions are determined by identifying and classifying associated functional failure conditions. All functions have associated failure modes and associated effects, even if the classification is “No safety effect.” Safety related functional failure modes may have either contributory or direct effects upon the product safety.

Security—The security related values cover the security-related areas with regard to protecting the confidentiality, integrity, and availability of the product/service itself and the information processed, stored, and transmitted by the product/service. Depending on the development product (from an individual product or service to a complete value chain), these areas might include: access control; awareness and training; audit and accountability; certification, accreditation, and security assessments; configuration management; contingency planning; incident response; maintenance; media protection; physical and environmental protection; personnel security; communications protection; and information integrity.

Performance—Performance refers to parameters such as range, accuracy, capacity, size, weight, consumption, etc. These are the critical performance parameters necessary for delivering the expected value through the complete product lifecycle.

Use—Refers to hours of operation per day, duty cycle, shutdown routines, a percentage of capacity used, and so forth. To what extent will the product be used at each of its lifecycle’s phases? This leads to the determination of the level of stress imposed on the product by anyone who deals with it.

Maintainability—Includes scheduled and unscheduled maintenance needs and any links to specific safety-related functions. Factors such as the percent of failure detection or the percent of fault isolation may also be important. Provisions for external test equipment signals and connections should be defined at this moment.

Distribution—The logistics related values assure the product will be available at the expected distribution places and in the correct amount (or capacity in the case of services).

Reliability—Is quantitatively defined, including cost/effectiveness of the product, operational availability, dependency (coupling with other products), mean time between failures (MTBF) failure rate, readiness rate, maintenance downtime, mean time between maintenance (MTBM), facility use (percent), need for staff and their qualifications, cost, etc.

Certification—This includes additional functions, functional attributes, or implementations that may be required by worthiness regulations or may be necessary to show compliance with worthiness regulations.

Life cycle—Anticipates the product lifecycle. How long will the product be used by the client? What need is there to stock the product and its parts (if any)? Where is the inventory stored?

Environment—Where the product should operate efficiently. Examples include: temperature, shock and vibration, noise, moisture, Arctic or the Amazon, mountainous terrain or plane, airborne, on the ground, boat, space, etc. In which conditions will the product be subjected to throughout its lifecycle and for how long? In addition to issues related to the operation, the environmental pulled value should consider ways of shipping, handling, and storage (it is possible that the product is subject to stricter conditions during transport than during operation).

2.7.4 Solve the Ambiguity From the Pulled Value Items

Finally, since the value initially understood from the stakeholders might not be clear, the development team must work on clarifying that into unambiguous value items. Ambiguity means the existence of multiple conflicting interpretations of the information held and required which leads to a lack of consistent information. Solving ambiguity leads to the search for the meaning of things.

The work of ambiguity elimination is the exact work of requirements engineering. Therefore, the initial pulled value must be drilled into value items, which are very similar to user requirements, once they are written from the stakeholder’s point of view. User requirements define the information or material that is input into the business process, and the expected information or material that is the outcome from interacting with the business process (system), specific to accomplish the user’s business goal.

The value as pulled by the stakeholders is further detailed into value items, by asking “What do you mean by that?” Table 10.3 shows the final set of value items defined from the initial pulled value of [1. Realign the aircraft]; note that the actors were suppressed in the VFD, since the value delivery matrix links stakeholders (actors) to value items.

Table 10.3 From value to value items
Full size table

2.7.5 Prioritize the Value Items

Each considered stakeholder has particular needs, thus rating differently the value items importance. Also, as already stated, each particular stakeholder has different relevance. The value items prioritization takes into account the combination of these ratings. Therefore, the importance of the value item VIi is obtained as:

$$ {\text{IMP}}_{\text{VIi}} = \sum\limits_{{{\text{j}} = 1}}^{k} {{\text{SR}}_{\text{j}} * {\text{IS}}_{\text{j}} } $$
(6)

where:

  • SRj = is the relevance of the jth stakeholder, ranges from 9, 3, and 1, if the stakeholder was considered as primary, secondary or tertiary, respectively:

  • ISj = is the interest from the jth stakeholder on the value item VIi, ranging from 9, 3, 1, and 0, on the case of high, medium, low, and not important for that particular stakeholder, respectively:

When rating the interest to stakeholder consider:

  • High: the item falls into a must have category.

  • Medium: the item falls into a nice to have category.

  • Low: the item relates to the stakeholder (he can perceive it), though he does not care about it at first.

  • None: the item does not have any relation to the particular stakeholder.

Table 10.4 shows the stakeholders and a value items subset from the stall recovery system example, where the linking between the [Client] and the value item [1.1 Quick response to triggering] contributing with “81” (primary * high = 9 * 9). By repeating this calculus trough the line, the total importance of this item is 360 (three hundred and sixty).

Table 10.4 Value item importance
Full size table

2.7.6 Define Measures of Effectiveness (Moe)

A PDP provides no value if it does not have the capabilities required by the end customer. These capabilities must be translated into identifiable and measurable parameters that can be designed, developed, and tested.

In order to verify the presence of the value items in the development results (product and/or services), at least one measure of effectiveness (MoE) must be defined for each value item.

For instance, the measure of effectiveness for the value item [1.2 Return to the normal flight attitude] was [return the aircrafts’ angle of attack (AoA) to M ± D degrees in less than T seconds].

Since we are talking about MoEs for value items, which are very similar to user’s requirements, these measures must be defined in a way that the related stakeholders could measure it themselves (perceive while using the product/process).

2.7.7 Identify Conflicting Value Items

Conflicting value items are items that cannot be optimally delivered simultaneously (like having a robust and fail proof product, while aiming to a minimum mass) if using the current company knowledge and capacity.

The conflicting value items direct the creation of trade-off curves that, besides aiding the development team, are part of the company’s knowledge assets. By challenging and improving the trade-off curves, a company becomes more competitive. These curves, besides supporting decision making, are a simple and convenient way to make reusable knowledge.

Table 10.5 shows one example of conflicting value items, in the context of the stall recovery system. The “primary value” is the value item that has higher importance, in the case of a trade-off they are the ones to be kept a higher values.

Table 10.5 Stall recovering system conflicting value item
Full size table

3 A Practical View

Although this chapter has been mainly practical, some additional tips can also be given:

  • Take some time to prepare yourself for the value identification : read the background, the current condition , and the risks already identified. Value identification is always an opportunity to challenge previously developed information. Understand all types of pulled values.

  • Whenever possible apply the go and see to identify the value, through go and see it is possible to “feel” the real voice of the client. It is an opportunity to perceive important value that the stakeholder would not verbalize and to understand the real priority. When asked, stakeholders tend to request what they like rather than what they need.

  • We know we can’t avoid interviews, but try to use them as a confirmation technique, and always avoid direct questions and questions which answers are monosyllables (like YES and NO).

  • Think simply about the measures of effectiveness. At this moment, we are at the business/user requirements level, therefore the MoE should be stated on terms they understand and are able to check in their environment, without fancy testing tools and procedures.

It’s also important to highlight the difference we consider between value and requirements. Value is described much more in the stakeholder’s language. Even after having the ambiguity reduced and detailed into value items, these items must be easily understandable by the stakeholders who pulled them, while requirements might be written in a way to facilitate the understanding for the product development team.

When we combine the value items with its measures of effectiveness, we have almost the equivalent from system requirements, once we rather describe how the final product/service should interface with its users, than how the product/service architecture is going to be. By having the value item + MoE , a requirement-like criteria is attained:

Necessary. The stated value item is necessary, once it is pulled by one or more stakeholder.

Concise (minimal, understandable). The value item statement includes only one value item stating what must be delivered and only what must be delivered, stated simply and clearly. It is easy to read and understand.

Implementation free. The value item states what is required, not how the value item should be met.

Attainable. (achievable or feasible). Be defining the MoE, it is possible to imagine which validation and verification strategies can be used to confirm that the value is present into developed product/service.

Unambiguous. Each value item must have one and only one interpretation. Language used in the statement must not leave a doubt in the reader’s mind as to the intended descriptive or numeric value.

Some other requirement criteria are not applied to value items. During the execution phase the value items are going to be detailed into requirements, never losing the traceability to the value items they came from. When detailed into requirements the following criteria should also be attained:

Complete. (standalone) The stated requirement is complete and does not need further amplification. Requirements should be stated simply, using complete sentences. Each requirement paragraph should state everything that needs to be stated on the topic and the requirement should be capable of standing alone when separated from other requirements.

Consistent. The stated requirement does not contradict other requirements.

Once the pulled value has been identified and prioritized, the next step is defining how the value set is going to be delivered and understanding the risks for doing so, which is the subject of the next chapter.