 |
|
|
The product development newsletter no 11 |
| A case study |
| |
| I thought rather that continue previous themes, a particular company
case study might interest you. You might identify with some of their
problems. |
| The company in question had more than 30 years experience at developing
their own products. They were in the general engineering sector with a range
and mix (maybe too large - five companies had merged over two decades) of
up-, and middle-market products. Most were simpler mechanically than they
were electronically. Some were complex and embedded software was key to
their operation. And their physical size range was huge, from hand-size to
container size. |
| The company was fairly typical in that they often did and sometimes
didn't meet predicted sales volumes or make good margins. And like many
others, parts of their range experienced strong price pressure from newly
industrialised nations, which needed action. |
| So their first approach was to cut manufacturing costs to prop up
margins. They did this partly by cutting waste through some leaner (TPS)
manufacturing practices, and partly by outsourcing some parts to the East
(which produced some other problems). This helped but didn't fix their
margins so the CEO reckoned that better returns needed better product
development and, unlike the production area, the fixes didn't seem to be
obvious. |
| So what to do? They had a well developed and audited product development
procedure manual, and a competent technical director who owned the process.
Product managers chivvied him to produce; a remote sales force came up with
ideas; the CEO observed that products arrived but not always as smoothly as
expected or on time. But no one could pinpoint anything obvious they could
change. There were a host of minor (maybe mal-) practices but nothing major. |
| Their situation was that at any one time, around 50 product development
projects were under way. Some went smoothly, others didn't. But, as far as
they knew, that was not untypical. So what were the symptoms? Typical were: |
|
|
|
 |
Some products didn't meet their sales target and so missed their target
return on investment, normally discovered well after the event. |
| |
When you looked deeper, financial analysis was patchy and not related
enough to targets; there were too many local spreadsheets, each to satisfy a
local aim. |
| |
Where the development budget was rigorously enforced, the product was
usually late. |
| |
Some products would meet their sales target volume and target cost, but
still did not make their target margin. |
| |
The occasional project was jump started by sales, whereupon the
technical area didn't manage to meet the promised delivery date. |
| |
Sometimes a customer would not keep their promised order volume either
because the specification had unwittingly drifted or because it had not been
well enough defined at the start, or because it was overly optimistic to
justify doing it in the first place. |
| |
The product development area looked like the second most over-worked,
harassed area in the company. |
| |
Second only to Manufacturing Engineering, whose work was usually
squeezed for time and usually had to be rushed to meet customers deadlines
because projects ran late. |
| |
Some dates were missed because suppliers of critical parts took longer
to de-bug their own product than they expected |
| |
And sometimes projects were late because unexpected development problems
arose that took longer to de-bug than the time line allowed |
| |
|
|
|
These were general symptoms. But from
the CEO's point of view: |
| |
The process, although well documented, seemed to be over bureaucratic on
the one hand but somehow not rigorous enough in various areas, and like
lightning, the same area never seemed to produce the same problem twice. |
| |
Extensive, time-consuming up-front planning set specifications, target
costs and dates. But dates were routinely missed or changed without enough
feedback to top management. |
| |
The project managers seemed to be too close to engineering, too immersed |
| |
in programme detail; were they objective enough? |
| |
Project visibility was lacking. There was no early warning system in
place on cost, timing or specification changes. |
| |
The debate on features versus cost was taking place too low in the
organisation. |
| |
Inputs from areas other than engineering were often late (and often
reluctant), leading to costly late changes and reiterations. Issues were not
elevated clearly enough to enable a timely decision. |
| |
Sourcing was not taking place at the strategic level. Purchasing didn't
have enough power and as a result engineering seemed to be too involved in
vendor selection. |
| |
And it wasn't obvious what the deliverables were that would signal that
the project had ended. There seemed to be different criteria between
purchasing, marketing and engineering about when it had finished. Things
like manuals, translations and brochures weren't built into the process. |
| |
There was no regular post-project review to learn lessons. Nor was there
a clear responsibility to fix issues that were recognised. |
| |
