 |
|
|
The product development newsletter no 7 |
| Topic: How you identify waste in your product development
process - part 2 |
| |
| Another tool and comment on the usefulness of it and value stream
mapping: |
| Another useful tool is design structure matrix (DSM) analysis devised by
professor Eppinger’s group at MIT. This tool enables you to arrange tasks in
the order that wastes least effort. You discover all the product development
task interactions: the outputs that each task generates; and the inputs that
each task needs from others before you should start it. And hence you derive
the order in which you should do all the tasks to avoid wasting effort. |
| You avoid starting tasks before you have the input you need from
completing others. This wastes effort through having to rework tasks that
have been started without the correct data. It is amazingly common in
product development to have to rework tasks for this reason. It can be
applied to many products, complex or not. Because the technique identifies
interdependencies, you can also discover which people should be in which
teams to run the project. Many large complex tasks, such as designing
products with many interacting systems, have greatly benefited from applying
the methodology and it’s certainly one you should know about. It’s useful in
a different kind of way from value stream mapping. |
| Both VSM and DSM suffer the same caveats. You can't include what you
don't know about.. With either analysis, you may not arrive at the best
possible solution because the exercise is limited by your own company’s
experience. The same applies to mapping your production operation. You know
in outline how you will operate because ‘the possible’ is to a large extent
governed by your plant and premises. You can rearrange tasks or equipment,
to improve flow, save time, reduce work in progress, and so on. There is not
exactly the same situation in product development however; you know what you
have done in the past, and you understand what you consider to be best
practice. But there isn’t much ‘fixed plant’ and the product development
process is limited more by your intellectual invention. You could devise
different ways of doing it, akin to bringing in new plant and machines,
whereupon your process map would change. However it’s quite hard to dream up
new ways of doing things, or to realise that it would help to insert a minor
additional task - far harder than deciding to install a piece of new
equipment. There is too much freedom to think how you might do it, and it’s
difficult to home in fast on what would really work so much better. |
|
|
|
This sounds obvious but it hadn’t occurred to me until I discovered it
by accident. If you don’t know that some tasks should be done, or how to do
them, or even that they exist, analysing what you’ve done in past projects
may not reveal that you should do them. You may never have done certain
tasks in your product development process at all; or diagnosed that you
should. I’ve been fortunate in being able to analyse in depth how more than
70 really profitable product developers do it, and no two are alike. (I
continually analyse more.) Nor, within each, are two projects alike. But by
detailed analysis and, perhaps more important, having been there and done
it, I could identify what makes the difference. This led to the discovery
that there is a common underlying baseline blueprint that fits all of them.
But, interestingly, even most of the best don’t do all of it - probably
doing 80% is enough to make them really successful. |
| So it is certainly useful to know how to VSM and DSM your current
process. There are consultancies out there that would love you to pay them
(large sums) to do it for you. But I discovered that it is far less costly
in time and money to learn and adopt a common underlying baseline blueprint.
It gives you at least as much if not more benefit without the time-consuming
analysis, which you can learn later to make even more improvements. It’s
practicable and you can adopt it quickly. You usually use it to fine-tune
your existing process, which is far less disruptive. It involves every area
the product touches - otherwise you miss vital information. And it deals
with the company culture that is needed to do it well. |
| It’s too detailed to put across easily in these newsletters because it
involves such a wide raft of new learning points. So I teach the methodology
in workshops, and those who come are invariably enthusiastic about returning
to base and making some useful improvements; they find it profitable and
useful. We often explain the process to MDs, TDs, MktgDs and senior managers
- the more senior they are, the more likely the company is to benefit. |
| The workshops teach the management methodology and ‘how to’ in great
detail, from strategy through all stages to production handover; either
in-house, if you have 8-16 from a mix of departments who want to learn how
the best to it; or if numbers are small, we (and you) can organise a group
of companies to participate. E-mail me now if you’re interested - the next
series starts in a few weeks time. |
