Chapter 5 – Structuring the Development Funnel

The development funnel provides a graphic structure for thinking about the generation and
screening of alternative development options, and combining a subset of these into a product
concept. It creates the architecture for the set of development activities that must occur as part
of a successful development project. One should remember that there are several ones and not
just one funnel. There are three things that are desirable and challenging when designing the
funnel:

Widen the mouth: The organization must expand its knowledge base and access
to information in order to increase the number of new product and new process
ideas.

Narrow the funnel’s neck: Management must screen the ideas/concepts to focus
its resources on the most attractive ones. (Think about the aggregated project
plan and that they have a similar purpose.)

Deliver the anticipated objectives: To ensure that the selected projects deliver
what they are supposed to.

As mentioned, there are several different tunnels which are more suitable for different
occasions. They are distinguished of its process to develop projects, its means for achieving
convergence to a focused product concept and last are its commitment to the market through
final testing. Here follows three different models.

Model 1: “Technology-driven survival of the fittest” approach, common in

larger, technology-intensive firms which rely on their R&D group to generate
ideas for new products and processes. Creativity and innovatively is the key
words, which forces the funnel to have several screens, commonly at least three
which have different purposes (technical, manufacturing and specific customer
preferences). One problem might be that they aren’t that coordinated which
might make some of the finished projects quite similar. Some downsides are that
it’s expensive and it might be hard to the R&D groups to “kill their darlings”, it
is also rather complicated.

Model 2: “All the eggs in one basket” model which is common and more
favourable to smaller firms (the market needs are to complex otherwise and the
environment it rather fix). They use several sources to collect ideas and combine
these into a single project aimed at meeting a set of market needs which is
launched as soon as possible. Some other problems might be that it’s harder to
kill of these combined projects and it might be quite slow.

Model 3: Is a combination of model two and three and it is called “innovative

and focused”. This model tries to widen the mouth and gather ideas from a
variety of sources and not only through R&D, they also try to encourage
innovations and input from the organization and its surroundings, the functional
maps are also vital. The screenings and narrowing of the neck is also important,
before the first screening advanced development is of essence and is followed
by the first screening which is more of a monthly review of the status of the
projects in the funnel and they are evaluated by how they will fit in the
 aggregated plan. It also has the important task to see so the different projects
aren’t that similar. And if the idea is found to be complete it moves on to the
next stage where it will be more specified, with defining and creating the
appropriate sequence and set of platforms and derivate development projects. In
the second screening the projects are selected that will become development
projects. So in advance to the second screening the information has to be
adapted so the management can make rational decisions.

The design funnel may be used as a diagnostic tool to the managers making them understand
how their development process is now and by that understand how it might be improved. The
three most important issues which usually emerge from this study are:

The importance of the managerial roles: middle management has to do more of

the day-to-day planning meanwhile the senior management should set an agenda
and determine the organizations focus. The management’s role could be
determined by the screens.

The importance of competing projects: When, where and how the competing
concepts and projects should or shouldn’t be encouraged or even allowed. This
competition between different projects might be allowed until the second
screening in the third model.

The importance of the project mix: The mix of development projects, must as an
aggregated project plan, should build both on market position and the
capabilities in certain new areas. As for the managers the screen might be used
to evaluate the right balance of projects.
Chapter 6 – A Framework for Development

To be an outstanding development organization requires a coherent architecture and process

that is well understood, highly capable and in control. It should be rather detailed, addressing
such things as how to execute and control the processes, how the organization is structured
and who will do what. To make this possible the senior management has to be focused and
attend development. Some basic elements of the framework that should have a continuity
must be discussed, they are;

Project definition: This determines how the firm sets the scope of the
development project. It should set the goals, objectives and the resources
required to finish. Avoid fuzzy specifications.

Project organization and staffing: This defines who will work on the project and
how they will organize to be successful. Cross-functional teams might be an
option.

Project management and leadership: Here the roles and nature of the project
leaders are defined and how the project should be sequenced. It also involves
how to divide and group the work in different phases. (When to integrate the
process?)

Problem solving, testing and prototyping: This has more focus in the individual
work steps, how it is conducted and the needed knowledge for the certain task.
This ends up in the use of testing and prototyping and how it is conducted to
validate the progress.

Senior management review and control: How the management reviews and
evaluates the projects over time, also how the responsibilities is empowered to
the employees which will create morale and motivation.

Real-time/midcourse corrections: This takes care of feedback and revisions

during the course of the project because of the uncertainty which always is
included in decision.

Some common pitfalls:

A reactive process, engineering focus, leaderships that shifts by phase, baton

passing, narrow focus on functional problems, fire fighting, late involvement,
bad communication, no cross-functionality, no slack…

Some key mechanisms:

Customer mission statement (the attributes the customer is interested in), the use
of gatekeepers and stakeholders (to guide the project, good with cross-
functionality in this stage), well-defined procedures (creates a common
philosophy which will lead to discipline and clarity) and senior cross-functional
advisory groups.
Some different approaches to project management that are suitable for different situations are;

Phases and gates: Strong functional orientation with discipline and focus in the
processes. Uses phases, gates and customer mission statements. Is usually used
to manufacturing processes and projects where technical advancement is of
importance.

Tollgate process: Functional orientation but with some element of cross-

functionality. Uses tollgates with project managers to review milestones.
Commonly used to enhancements and incremental improvements, technology is
of importance, but a balance with the cross-functionality is vital, speed.

Contract-driven/Cross-functional teams: Teams focus with functional support

and a clear link to senior management. Consists of dedicated core teams and a
general manager as project leader. Used to platform/nest-generation projects
where the system solution is crucial and speed is critical.

Tiger teams: Fully dedicated teams with control over resources and process.
They are co-located and have full budget authority, CEO might be leaders with
hand picked teams. Used for breakthrough projects and projects with high risk.

Some common themes and basic principles for an effective development process are:

Customer Focus: A challenge is to achieve integration across function and yet

obtain excellent solutions to a functional problem. The challenge with the
customer is to understand the future customer requirements and unmet needs
and to translate these to understandable attributes.

Discipline: To cope with complexity discipline is essential. The use of phases

and a clear criterion for moving forward is important to clarify the process. It
can’t be too strict though.

Coherence in Detail: To have a good coherence between functions might be a

challenge, i.e. to have the managers and co-workers to head in the same
direction, so the integration of management is vital.

Fit with the Mission: To establish a fit between the process and the competitive
market and technical imperatives is essential. An understanding to the
surrounding environment is therefore crucial.

Sharing a Pattern: A pattern for development where a model of how ideas are
transformed into commercial products. This will become a shared language
within the organization. It might also improve the communication.

Some good questions for a manager to ask himself are:

Do we have a strong customer focus in our process? Do we have discipline and

thoroughness in what we do? Do we have coherence in the details? Is there a
good fit with the mission? Have we articulated and shared a pattern?
Chapter 7 – Cross-Functional Integration

Outstanding development requires integrations across functions, if not, suboptimizations

might occur when the separate function only maximize their own output. One other issue to
consider are the timing, communication of requirements, sequencing and involvement of all
the tasks and functions, and by optimize these lower the TTM through lower development
lead time. The general goal with cross-functionality is to make several functions influence and
shape each other in an early stage. The integration can also go outside the organization to
provide firsthand information from suppliers. Another approach is to choose the “right”
customer to ask about the product so he is representative for the market and the future
demand.

It’s all about making the development process more parallel with the deferent functions and
making the downstream activity come closer to the upstream. But this is not easy and requires
some supportive functions to be possible, i.e. some kind of information system. Milestones
and visualisation is also important, making the different parts more tangible to each other and
makes it easier to see how the different phases fits together.

Then, how to achieve cross-functional integration? The underlying reason to why cross-
functional teams are needed is because of todays more dynamic markets and technologies
where time is crucial to be competitive. True cross-functional integration occurs at the
working level between functions with a common goal. To make this integration successful a
good communication is vital, and the pattern in which it is delivered, off course feedback is of
importance. The quality of the communication pattern depends on four dimensions;

Richness (Sparse: documents, computer network => Rich: face-to-face, models)

Frequency (Low: one-shot, batch => High: piece-by-piece, on-line, intensive)
Direction (One-way: monologue => Two-way: dialogue)
Timing (Late: completed work ends process => Early: preliminary begins the process)

There are four modes to how the communication between up and downstream can be handled,
and different degrees of how parallel they are. (See page 178 for a good pic)

Serial mode: This is the classic relationship where the downstream group waits until
the upstream group is entirely finished, which is transmitted through a one-shot
transmission of information (a “batch” of information). Not that good…

Early start in the dark mode: This links the two groups in time, but still uses a batch
stile of communication. Often forced upon the downstream team because of a
deadline, but as the name implies, they might be surprised with what they get from the
upstream group. Some parallelism, but the result might be a longer lead time because
of the bad communication.

Early involvement mode: In this mode is there an engagement between the functions
and a bit interactive pattern of communication. The important issue with this mode is
that there is two-way communication enabling the downstream group affect the design
of the product at the upstream group. The net effect is that they are able to complete
their work with a fewer delays and downstream changes.
 Integrated problem solving: Links the two groups both in time and in the pattern of
communication. The downstream engineers don’t only have a good two-way
communication with the upstreamers, but they also use the information to get a flying
start on their own work. The communication has to be rich, bilateral and intense if the
integrated problem solving should be successful. It also requires real time coordination
between the groups.

In the end the real time coordination requires a specific set of capabilities, attitudes and
relationships depending upon if you are an up- or downstream engineer. Some of them are:

Upstream Capabilities: The challenge is to meet the performance objectives and still
complement the downstream work in a good manner.

Downstream-friendly solutions: The upstream groups have to have knowledge about

the constraints and capabilities of the downstream function. Methods as DFM, value
engineering, FMEA and different Taguchi methods are common which makes the
upstream function able to predict the consequences of their own actions.

Error-free design: Minor details often have insidious consequences. This might be
possible through effective design reviews, testing, engineering discipline and by
Poke-yokes.

Quick problem solving: Faster design-build-test cycles in the upstream group and
facilitating short feedback loops and quick mutual adjustments. Standardization?

Downstream Capabilities: The challenge is to get a flying start on development before

getting complete information.

Forecasting from upstream clues: To start on a bit fuzzy definition and forecast
these in an effective manner is vital. This is often based upon experience from
previous tasks. Regular communication is also important.

Managing risk: To know how to make trade-offs between the risks and the benefits
from an early start. This requires skills in applying deliberate and detailed analysis
and calculations in support of a fast change.

Coping with unexpected changes: the downstream group has to be flexible and
skilled at quick diagnostics and solutions. This might be possible by having skills in
problem diagnosis, organization capability in mobilizing resources and to prioritize
the most important problem.

Another important issue is the attitude of the teams. A sense of mutual trust and shared
responsibility (i.e. for the result) is essential to integrated problem solving. The role of senior
management is also of importance, and their role goes beyond to just establishing frameworks
and patterns for the groups. The combinations of team members must also be considered, a
homogenous group isn’t the best solutions, conflict and different attack angles might to some
extent be crucial. The team, and its members, must have the right amount of education,
training and experience to be successful. One final thing to discuss, and a potential pitfall is
the organizations policies and compensation which might be a reason to conflict between
functions.
Chapter 8 – Organizing and Leading Project Teams

There are several different ways to structure a team, and they are also suitable for different
tasks and organizations depending on how the market looks like and the competition in it.
There are four main teams with different attributes, they are: (See page 191 for a pic)

Functional Team Structure: These are common in larger more mature firms and
are the more traditional ones. The engineers in these teams are specialists, and
not that cross-functional. The thing is to find detailed specifications agreed upon
by all parties and align these with occasional meetings and the responsibility
passes sequentially between the functions. Some strength with this kind of team
is that the managers both have control over the resources and the performance of
the tasks, the hard part with this is to divide the teams in a good manner and the
limited coordination. Another strength is that career path becomes more visible
and last that those working with it are really experts within a specific area. It
might be quite slow, costly and not sufficient customer-focused.

Lightweight Team Structure: These teams are still located within their own
function, which has a negative impact upon the communication. But each
function designates a liaison person to represent them in a project coordinating
committee. This team also has a project team manager to coordinate it a bit more
than in the ordinary functional teams. But the manager is still lightweight and
doesn’t have that much authority and is usually only a middle or junior level
person. The strength compared to the ordinary functional teams is that the
project leader makes a bit more cross-functional.

Heavyweight Team Structure: The heavyweight project manager has direct

access to and responsibility for the work of all those involved in the project and
are often more senior managers. The functional managers are more involved and
marketing might also be integrated to a greater extension. The core team is often
relocated so they may work integrated together, meanwhile the basic functions
might still be in their original department. These core members evolve by
working in these teams, but might need to go back to the lightweight team for a
while to avoid the “burnout effect“.

The lightweight and heavyweight teams might be in a kind of greyzone, but they are
distinguished by some factors as, “span of coordination responsibilities”, “duration of
responsiveness”, “working level contact with engineers”, “role in conflict resolutions”, the
influence in engineering, marketing and manufacturing, etc. (See page 195 for more)

Autonomous Team Structure: Common in “life or death” situations and where

there are a big potential, they are usually referred to as “tiger teams”. Because of
their focus they tend to be rapid and efficient. A smaller team that is totally
relocated and has a heavyweight leader. It usually has full responsibility and
accountability and starts out with a clean sheet of paper. Some disadvantages
thus are the solutions could be to unique and don’t fit with the rest of the
product portfolio, this is because of the unclear guidelines. The management
tends to be rather nervous and it is hard for them to evaluate the project during
the process.
What kind of teams that the organizations have depends on the size of it and in which area it
acts and it usually evolves over time. It also depends in what kind o project it is, like if it is a
derivate or a breakthrough project. For smaller projects, the functional might be suitable,
because it doesn’t need that much integration, meanwhile smaller and more revolutionizing
organizations which are technology intensive the tiger teams and for new platforms and
breakthroughs the heavyweight teams might be more appropriate. As mentioned, the mix of
projects, as an aggregate project plan, must have a good mix of projects. Another mix which
is of importance is the human resource allocation, because it’s often here the limit might be.

The heavyweight team might be the most important one, so here is some more information
about that one. They offer improved communication, stronger identification with and
commitment to the project and a focus for cross-functional problem solving. Functions as
human resources and accounting/finance might be included. A clear vision for the entire team
is also important to become successful.

Some challenges for a heavyweight team thus might be the relation to senior management and
their control. There are quite free and sometimes they might become tiger teams, working on
things that aren’t prioritized. You could say that they sometimes have too much power. Some
things that could restrain this might be to establish make-buy guidelines and clear priorities.
Another challenge might be to create a balance between the needs of the individual projects
and the needs of the broader organization. The lack of deep knowledge might also be a
downside compared to the functional ones.

Some ways of managing these challenges will now be discussed:

The project charter: A heavyweight team needs a clear mission. A project

charter is a good tool to enable this by visualizing and set up the performance
objectives, these could be stated before selecting the teams.

The contract book: This defines, in detail, the basic plan to achieve the stated
goal. Then the team establishes their own detailed work plan by how they will
conduct the project and estimate the required resources and its result.

Staffing: Typically there is a cross-functional team with one core team member
from each primary function of the organization. The members should be viewed
both as individuals and as a collective. The relocation of team members is also
important to solve real-time problems. The usage of employees should also be
considered.

Project leadership: These leaders are concept champions and have a lot of
authority in the project. His task is to communicate the vision to the team
members and evaluate the process. He shouldn’t spend that much time at a desk,
he should prioritize to manage the process and overview the communication
flow. There are five roles/tasks for a project leader; provider of a direct
interpretation of the market and customer needs, to be a multilingual translator,
to coordinate and direct the engineering subfunctions, to keep the project in
motion and to be a concept champion.

Team member responsibilities: There are two main ones, the “functional hat”
which involves the responsibilities of the individuals of the team as
 representatives for their function. The other one is the “team hat” which is
includes the responsibilities of the overall team.

The executive sponsor: He has a role as a coach and mentor for the project
leader and the core team. They should stake out some guidelines upon the
decision-making criterions and when they should call for him. Some areas
which he might want to keep control over are; resource commitment, pricing for
major customers, slips in milestones, reviews at major milestones and rewards,
etc.

Some final comments, the heavyweight teams should be used in platform or next-generation
development projects, to use them in smaller ones might be overkill. These teams could also
be considered as the aggregate project plan, there has to be a balance between them, you
shouldn’t only have the heavyweight ones. But if the organization heads to use heavyweight
teams, it’s hard to keep the functional structure as it is.
Chapter 9 – Tools and Methods

All things previously mentioned are important, but without a detailed problem solving at the
working level an outstanding development process is almost impossible to achieve. An
important issue regarding problems is that they often might cut across functions, so to solve it
where the root-cause is vital, to do this a thorough problem definition is essential.

The essence of product and process development problem may be defined as a performance
gap between current practice or designs and the desired target. Two other important aspects
which has to fit and have in mind is the design parameter (tolerances, number of parts etc.),
which are the decisions under the control of the design or engineers and the customer
attributes/customer requirements (wait time, sound, reliability, might be good to try to
quantify these numbers if possible). Each of the design parameters might affect several
customer attributes, so it’s important to strike an effective balance between them. This is
where the design-build-test cycle gets in the picture.

As it is a cycle, problem solving is a learning process which leads to that the engineers has to
go through several iterations, the quality actually in the number of iterations. They must also
be linked to the overall system to be coherent. (See pic. 9-3 page 224) The characteristics of
the phases are:

Design: In this phase the developer frames the problem and establishes goals for
the problem-solving process, the problem framing is crucial (some kind of root-
cause analysis?) and the definitions of the gaps to find the underlying reason to
these. The frame also depends upon how the objectives are defined. When the
problem is framed the design phase continuous to the generation of alternatives.
These alternatives depend on the skills and understanding of the relationships
between the design parameters and the customer attributes, the purpose of a
design might well be to find the relations between these. (Pugh?)

Build: In this phase of the problem-solving cycle the developer builds working
models of the design alternatives. The purpose of the phase is to build
alternatives designs into a form that allows testing. Depending in which phase of
the building the developer is, computer simulations like CAD might be to great
help in the beginning meanwhile closer to the testing real physical prototypes
might be necessary.

Test: This phase tests the prototypes from the previous phase, both working
models and computer-generated ones. It also has the function of understanding
the connections between different design parameters which impossible without
real testing. Which kind of test that is conducted also depends upon which phase
the cycle is in, early cycles might focus on more detailed problems and so on.
The fidelity of a test refers to the extent to which the test being conducted
reflects the actual case of interest, thus it might be hard to interpret the results of
testing. To understand how and were the customer uses the product might also
be of interest.

A variety of methods are used to improve the problem solving, most of them could just be
seen as a structured form of common sense, but he difficulty is in finding a method and logic
that works where people, information, objectives and capabilities interact in a complex
system. One of the most common pitfalls is the lack communication and shared vision
between the function. There are two good methodologies that shall be discussed now, the first,
QFD, is often used in the early stages of development where the targets are set and the basic
product or process architecture is established, meanwhile the second, DFM, is applied to the
later stages of development where detailed engineering is in focus.

QFD (Quality Function Deployment): AKA “the house of quality” This will only be
discussed very briefly because the knowledge is already quite good regarding this tool. The
method is used to identify critical customer attributes and to create a specific link between
customer attributes and the design parameters. It organizes information and helps the
developer to answer three questions; what attributes are critical to our customer? What design
parameters are important in driving those customer attributes? And, what should the design
parameter target be for the new design? To fill this house, there are five stages (see page 229-
231 for these). One thing to remember is that the QFD is only a summary of information, it’s
the usage of it that is powerful, and it is also good because it visualize the problem making it
easy to understand through a common framework. It also helps in an early stage to identify
gaps in the engineering and marketing knowledge.

DFM (Design for Manufacturability): This methodology brings the manufacturability into the
design process earlier. There are two kinds of DFM methods, design rules and design for
productivity.

Design rules: These express the constraints and boundaries that the
manufacturability has over the design. One way of doing this is by establish
setting rules and guidelines to what the manufacturing department actually can
do. There are some usual rule of thumb to have in mind; minimize the number
of parts in the design, minimize the number of part numbers, eliminate
adjustments, eliminate fasteners and eliminate jigs and fixtures. These design
rules could result in significant reduction in assembly time, reduction of number
of parts which drives the overhead cost, reduces the number of tools needed and
finally it might reduce the number of suppliers.

Design for Productivity: Quite similar to DFA (Design for Assembly), which
focus in individual parts and consider ways to simplify these by combine them
with other parts or making them easier to assembly. One downside though might
be that the parts becomes to complex (i.e. the mold might be to complex). So to
calculate the impact of manufacturing performance (over the lifetime) might be
good, where such things as labour-, material-, system-, capital and time cost are
considered. The flexibility also has to be considered in respect to variety and
responsiveness to shift the product mix. An approach is the combinatorial
method which concerns the design for modularization. In this approach the
interfaces between parts is essential.

The implementation of DFM is framed within these three terms; establish the envelope for the
existing process, identifying important connections between design choices and
manufacturing system performance and establishing key dimensions of the product
architecture and its impact on the overall manufacturing system. Wheelwright and Clark
introduce the “house of productivity” which consists of a design matrix (which links
product/process parameters) and a manufacturing performance matrix (which connects
process design parameter and manufacturing system performance (see page 240).
Chapter 10 – Prototype Test Cycles

The old approach was that prototyping manly was a technical tool to be used by engineers
responsible for the progress of technical activities and related development (usually divided
into concept, design verification, engineering verification and pilot production). Nowadays
prototyping is the build and test activities of each design-build-test cycle and seen as a key
management tool for guiding development projects and not just a technical one. Management
can use prototyping cycles to guide and pace development projects and to assess their
progress, pinpoint unresolved issues and focus resources and attention to certain projects.
Prototypes might answer questions regarding customer reactions, industrial design, durability,
fit and finish and manufacturing costs. As discussed previously, the number of cycles in the
design-build-test cycle determines the role of the prototype. Prototyping is a core element in
development and a major area of opportunity for management seeking to improve the
efficiency of the development process.

Traditional prototyping: The purpose is to demonstrate to the organization that

the design has outstanding quality and high levels of manufacturability, it also
indicates how far the process has progressed. Depending upon which cycle it is
in, different functions is involved, usually the earlier in the process it is, the
cheaper it is to change. The stages are; concept (ends when a model
demonstrates feasibility of the product core concept), design verification (ends
when a prototype unit demonstrates the functionality required to meet the
performance requirements), design maturity (ends when a prototype works
reliably under stress and conditions that represents the customers environment)
and product verification (ends when the product passes test related to
manufacturability). A downside with this one is that the role of the customer
enters very late in the process.

Prototyping could be conducted through four different best practices, depending upon what
the goal is for the prototyping.

Low-cost prototypes: Often computer aided approaches which are easy to

change. To increase this type of prototyping is desirable.

Prototyping Process Quality: Making sure that the process is a qualitative one
may improve the reliability and learning’s that occur in each cycle. Improving
the response time and shortening the feedback loop is also desirable, this could
be done through “Rapid Prototyping”. The faster a cycle might be done, the
better, at least in early stages in the development when current thinking is if
importance.

Timing and sequence: It important to not overlap individual cycles, then people
lose track of status and what has been done and so on. So to ensure that testing
is completed and getting closure to the cycles is important.

Building Knowledge: To use the prototypes to capture and enhance the

knowledge regarding prototyping will provide leverage to organizations. A bit
of continuous improvements.
Another issue to consider is who builds the prototypes, in-house or out-house? Why this is
important is that they have different focus.

How the organizations uses prototyping could be divided into three models; the standard
traditional which has been discussed, the revised traditional (which uses milestones to a
greater extent, has an earlier functionality/fidelity and broadening of the test criterions) and
the periodic which we will dive deeper into in a while. The usage of milestones (to gradually
review the process) and test strategies (to get a representativeness for the entire project)
should be considered.

Through a managerial perspective prototyping has four roles:

Feedback and Learning: An organization might learn things regarding as form,

style, feelings, functionality, performance and interactions with the customers.
These issues might get the organizations to see trends and usual outcomes. They
are technical in nature but some marketing knowledge might also be the result.

Communication and Information Sharing: They should serve as bridges between

individuals and groups with different backgrounds, experiences and interests. It
also visualizes the problem making it easier to communicate.

Outside Evaluation: Prototypes makes is possible to get feedback from

customers, but also the suppliers may be able to provide better feedback.
Prototypes may also help set the expectations and influence the behaviour on the
part of anticipated customers.

Establishing, pacing and monitoring the development schedule: To manage

these cycles is often the best way manage the rate of convergence and the cycle
time of the overall development effort.

Periodic pattern of prototyping: Is a restructured of the traditional cycle regarding its

sequence, number and duration of cycles. It is promising in platform and next-generation
products carried out in cross-functional heavyweight (that it is a heavy weight team with
authority and responsibility is vital) teams. One definition of periodic prototyping is “an
approach to prototyping that fulfils the technical role, but exploits managerial potential more
than the traditional model, could be of substantial value.” The key is to balance the technical
and managerial roles, and integrate these throughout all cycles, even the early ones and the
prototyping is done on a regular schedule. It often leads to innovative solutions, which is
required in the platform and next-generation products. Another special issue with the periodic
compared to the traditional is the amount of information exchanged which enhances the cross-
functionality. The support groups have a particularly crucial role to play. It also involves
much more testing, and therefore needs more prototypes.

The environment of the project is determined by three characteristics, the importance of

advanced and innovative technical developments, the importance of balanced, total system
solution to customer choice and the importance manufacturability. Rapid response to
engineering is well suited to technical breakthrough, it uses best practice, provides early
feedback and has a good balance between functions. Replicate manufacturing early is more
suited for incremental improvements where manufacturing is important. Finally matching the
mode of prototyping is essential.
Chapter 11 – Learning from Development Projects

The ability to sustain significant improvements in development over long periods of time rests
on the capability to learn from experience.

A framework for learning:

The potential for learning is not limited to things gone wrong. However,
episodes where things go wrong (or sometimes, right) are the raw material for learning.
Critical events are also potential issues for learning. What makes an event critical is its
connection to an aspect of the development process that drives performance. While the event
itself may be a symptom, pursuing it can lead to a deeper understanding of the forces that
influence the speed, quality, and productivity of development.
Learning requires a lot of people within the organizations. Because the
development process is so complex and involves so many different people in different groups,
and because the issues cut across groups, departments, functions, and organizations, learning
is likely to require careful, systematic effort.
For the individuals, learning can be done thanks to “learning by doing”: you pay attention to
the task and develop ways to remember what you learned.

Organizational learning: Five crucial themes in successful systematic learning about the
process:
- Learning as a Team Process: learning should be done within teams as teams members bring
different perspectives and different capabilities to the whole group.
- A Model of the Process: when solving a problem, engineers should understand the technical
determinants of the performance they search as well as the organizations processes designed
to carry out the specific technical tasks.
- Data and Analyses: Understanding of problems must also be achieved with data and
analyses of that data.
- Search for Patterns: The team shall compare its experience with other past examples in
order to try to recognized some patterns.
- Root Causes: Some causes might be uncovered even with a heavy search for understanding.
That is the reason why teams should also seek for deeper understandings of the root causes of
their problems.

Capturing Insight and Learning to Change the Development Process:

There are five areas of focus for an organization to focus in order to learn. They
establish the framework for development in the organization. These areas – procedures, tools
and methods, process, structure, and principles – provide ways for the organization to
“remember” what it learns from development projects. Tools and methods is an important
area in those circumstances where the opportunity for improvement requires new capability.
The principles include concepts, ideas, and values that provide more fundamental guidance in
situations that may be unfamiliar.
One of the key learnings is usually to enhance integration across functions for improving
product development.
Armed with that framework the organization may interpret critical events that
raise questions about its current procedures, tools and methods, processes, and the structures
and principles it uses to guide development. In order to be effective, learning must also extend
to the introduction of change into the organization – capturing the insight and incorporating it
into behaviours. These changes become integral aspects of the revised framework for
subsequent development projects, as the learning cycle begins again.
The Project Audit: A Framework for Development:
The project audit is a systematic project review conducted by a cross-functional
team which is particularly useful in organizing and managing the search for understanding
and insight from specific projects. The audit is thus a learning project conducted by a project
leader and involving individuals from the key functions represented in development.
The purpose of the project audit is to help the organization learn from its experience.
Senior management plays an important role in this kind of project.

Conclusions and Implications:

Learning from development projects is one of the most difficult things that an
organization can do.
Thus, from senior management’s perspective, the important mission is to foster an
environment in which learning takes place at every level, and to create the capability to learn
about specific development projects through a process built of several elements, such as the
development audit.

Chapter 12 – Building Development Capability

In order to be a source of sustainable advantage, development capability must be continually

expanded, upgraded, and improved. Building development capability takes determination,
persistence, and careful attention to those aspects of the development process that are most
crucial in a given organizational situation.

Four Approaches to Building Capability:

Sustained learning is the goal, and inevitably that requires a systematic, managed process of
improvement.

- Creating A Development Strategy

It is a useful starting point for building the required capability. Series of discussions and
analyses conducted within the senior management group will create a development strategy.
The goal is also to achieve a high degree of communication and a great shared understanding
of the development process and development strategy among the senior management group
and key functional executives in engineering, marketing, and manufacturing.
- Changing the Development Process
A fruitful starting point for bringing about significant change is often the overall architecture
of the development process. By introducing a restructured sequence of activities and
redefining both the phases of development and the milestones that characterize completion of
each phase, firms may create a new framework.
- Creating Building Block Skill and Tools
A focused effort to substantially improve an organization’s capability in executing that critical
activity can often result in significant development performance improvement. Improving
such critical activities often requires creating new or improved capability in basic tools and
skills. Furthermore, the introduction of new set of tools can create significant opportunities
for change in other aspects of the development process.
- The Demonstration Project
Such a project is designed to teach the organization a new mode of development by
employing new concepts directed at a specific product or process. The aim of such a project is
to become a model for subsequent development efforts; having “demonstrated” what was
possible and how it could be achieved in the company.
Building Capabilities: A Comparison of Alternatives:
The selected approach (between the previous four) should both fill gaps in the organization
and exploit opportunities with large payoffs. Each approach has some advantages and risks
for being implemented in a special context: for more information, refer to Exhibit 12-1 page
324.

Creating New Development Capability: General Observations:

Although the starting points of each approach are different, there is no doubt that they are the
beginning of a series of changes that will, if successful, build support and momentum and
pervade the development system. It is also worth noticing that more than one of the
approaches may eventually come into play as the organization proceeds on its journey to truly
outstanding development capability. That is why this effort is referred as a journey.
Whichever point an organization chooses to launch its effort in creating new capability; it
must recognize that that effort is not a single step, but one of many along a path.
Perhaps one of the most powerful levers managers can use is the process of benchmarking
their organization against other similar organizations, thus building awareness of their
competition.

Building capability requires a development strategy which includes at least three kinds of
efforts:
Building capability through product and process development projects. Ongoing projects can
often be a vehicle for introducing new skills or tools, and may be used as demonstration
projects.
Independent efforts to build capability. Outside of ongoing product and process development
projects, the organization can undertake separate efforts to build new skills and tools, create
new processes, and in general create new capability.
Project audits. These ongoing efforts to identify opportunities for substantial change and
improvement need to be coordinated with and linked to ongoing efforts in product or process
development.
Thus, a capability strategy can also serve to improve identification, motivation,
and desire within the organization. Where it succeeds, this strategy and a path for building
capabilities does so because it increases the knowledge and skills of the individuals in the
organization.

Changing Behaviour and Overcoming Obstacles:

Building capability requires change, not just in systems or procedures, but ultimately in
individual behaviour. Thus, the challenge is to build capability while creating processes that
change behaviour.
People in the organization must understand that learning is not just a nice thing to have, but an
essential element of successful development.

Building Capability: Management Leadership:

Managers recognize in the first instance that building capability is a journey, not a destination.
The critical problem is to chart a path and sequence of efforts over time that will address the
organization’s opportunities and needs effectively.
There are three modes of management leadership that represent different objectives, styles,
and perspectives on the role of development in competition:
- Mode one: Seek relief: Change in this mode focuses on the product itself, not the
development process. Its focus is fundamentally short term and its impact on competitive
position is unlikely to be lasting.
- Mode two: Close the gap: Managers here define the problem they confront in terms of a gap
between their own and important competitors’ performance. It gets at important underlying
issues and builds new capability. Managers focus on changing the organization’s capacity to
act in ways that will make it more effective relative to its competitors. It misses, however,
some of the important long-term benefits.
- Mode three: Competitive Advantage. The hallmark of mode three is its focus on building
lasting advantage in development. Managers operating in mode three, therefore, keep the
entire horizon – both for long and short term – within their purview. Managers focus not only
on how work gets done, but also on helping the organization discover what new things it
needs to do to be successful.
Leaders in mode three rethink the organization’s approach to development and create a gap
that competitors may not have considered. Leaders in mode three concentrate on doing new
things better.

Leadership that offers a compelling vision of the new development path – that provides
energy and momentum to the organization; encourages, coaches, and supports; develops
substantive principles and teaches them to the organization; and helps apply those principles
in solving problems – is the kind of leadership essential to building development
capability.