 |
|
 |
| |
MasterClass 2008 |
|
 |
 |
 |
|
|
 |
Managing the Design
Factory |
| A Product Developer’s
Toolkit |
|
Melbourne Hilton on the Park, 13th &
14th August 2008 |
|
|
| |
Workshop Objectives |
|
| |
This two-day course will focus on:
- Quantifying the value
of cycle time vs. other process objectives
- Developing decision rules to guide process design
choices
- Applying queueing theory to development process design
- Accelerating learning in development processes
- Establishing clear organizational roles and structures
- Designing individual process stages to meet economic
objectives
- Linking product architecture and development process
design
- Generating useful product specifications
- Implementing measurements based on process economics
- Strategies for controlling market and technical risk
- Optimizing testing processes
|
|
| |
Workshop Content |
|
| |
Introduction |
|
| |
Manufacturing processes have advanced substantially in
the past 40 to 50 years. Product development processes
are fundamentally different from manufacturing
processes, yet there are enormous opportunities to
exploit the lessons learned in manufacturing. To apply
these lessons we must respect the critical differences
between these two domains. In this section we will: |
|
| |
- Provide an overview of the Design Factory
- Contrast the critical differences between
product development and manufacturing
- Review how Lean Methods improve product
development performance
|
|
| |
Establishing an Economic Foundation |
|
| |
Making sound business decisions in product development
requires quantification of economics. Actions that are
appropriate when the cost of delay is $1 Million per
month may be inappropriate when this cost is $10,000 per
month. In this section you will learn to: |
|
| |
- Estimate the cost of delay of a new product
- Develop trade-off rules between important
project objectives
- Practice these methods on a case problem
- Incorporate these tools in existing business
processes
|
|
| |
Understanding Process Queues |
|
| |
Queues caused by overloaded resources are a major source
of unnecessary delay in most development processes. Most
developers are unable to make credible financial cases
for interventions to reduce these queues. In this
section you will learn to: |
|
| |
- Apply queueing theory to product development
- Analyze the economics of development process
queues
- Practice these methods on a case problem
- Set the right level of excess capacity and
justify it financially
- Understand the effect of batch size on queues.
|
|
| |
Generating Information Efficiently |
|
| |
The purpose of product development is to generate new
information. We cannot do this by trying to "do it right
the first time" because this limits us to only using
known solutions. In this section we will examine: |
|
| |
- Development as an information generation process
- How improved process design can produce
information earlier
- The critical role of failures
|
|
| |
Choosing an Organizational Form |
|
| |
There is no best organizational structure for product
development. Each organizational form optimizes
different economic factors. In this section you will
learn to: |
|
| |
- Evaluate strengths of various organizational
forms
- Divide responsibilities clearly between teams
and functions
- Exploit the power of colocation and partial
colocation
|
|
| |
Designing the Development Process |
|
| |
Most companies carry excess baggage in their development
processes because they assume they can create a
universal process that meets the needs of all projects.
They use excessively large batch size, and experience
delays at shared resources. In this section you will
learn to: |
|
| |
- Tailor development processes to projects
- Change the way shared resources are measured
- Use WIP constraints and cadence in development
processes
|
|
| |
Using Product Architecture |
|
| |
Choices in product architecture directly affect economic
performance. In this section you will learn to: |
|
| |
- Fit architecture to economics
- Partition architectures to minimize risk
- Identify leverage points for managing
architecture
|
|
| |
Product Specification |
|
| |
Defining requirements is much more complex than asking
customers "what" they want. We must deal with customers
who don't know what they want, and those who change
their mind when they get what they asked for. In this
section we will examine: |
|
| |
- Tools for understanding the customer
- Use of continuous customer feedback
- Processes for creating better requirements
|
|
| |
Selecting Process Measurements |
|
| |
To maximize economic performance we must use process
measurements that fit the economics of the project. In
this section we will show you how to: |
|
| |
- Avoid collecting useless data
- Determine the correct metrics for a specific
project
- Identify leading indicators of future problems
|
|
| |
Risk Management |
|
| |
Risk minimization is not risk management. Minimizing
risk involves avoiding any chance of failure. Managing
risk is taking gambles that make economic sense. In this
section we will examine: |
|
| |
- Technical and market risk
- Tools to manage these risks
- Methods to improve testing processes
|
|
| |
Planning Implementation and Q&A |
|
| |
In this final section we will develop a plan for
immediate next steps and answer any final questions. |
|
| |
|
|
|
|
|
 |
|
 |
