NPD Tales

Ideas Thoughts and Comments on Product Development

Discard or Fix?

I’ve blogged in the past about Lean Product Development and how I see the real process improvements can only be realised by considering the fundamental principles behind lean (identification and elimination of non-value added activities) and applying them to the non-linear non-repetitive world of product development.

On a number of occasions, in my role of facilitating organisations on their lean journey we have encountered existing processes or rigidly adhered tools which have been identified as a major source of waste.  Over complicated ‘gates’ in stage gate methodology, bloated QFD matrices, ‘rubber stamp’ specification sign-off process that delay progress there are many other examples.

The temptation to rip up and destroy these wasteful ‘offenders’, replacing them with something new and ‘Lean’ is indeed great – and I’d admit to encouraging such zealous behaviour in the past.

But recently I helped a group explore how to remove the waste from their Stage Gate process but still leave some of the principles of the process intact.  For an organisation with very high capital costs associated with their product development right from the start of the project it made sense.

If it’s broke then consider fixing it rather than throwing it away…

Imposition

If you look back on my previous posts you’ll find many examples of methods and tools that I’ve found to be either useful, interesting or intriguing (Enterprise Wikis, Planning Poker, Atlassian – FedEx Days and even Boys Keep Swinging and a whole lot more).

There’s a fundamental problem with the introduction of any new ideas into a product development process (or indeed completely re-engineering a process) – and it’s all about how the ideas are introduced to the engineers and how the methods are adopted.

Unfortunately many of these new ideas are introduced superficially and imposed upon the product development team, sometimes with a fervour that verges upon the religious (with the associated need for faith).  Not surprisingly there is resistance which by itself is a problem, but far more damaging is the rigid way in which the ideas are expected to be applied.

Far greater value can be gained by understanding the ideas, methods and tools then adapting and adopting them to suit the organisation, business environment and technology in which the team operates.

I’ve been hearing a lot of horror stories about Agile Software Development that remind me of previous reports of Six Sigma, PRINCE2 and Stage Gate…

Shu Ha Ri

The concept of Shu Ha Ri is rooted in Eastern philosophy and martial arts.  It describes the stages that a student practitioner must follow to learn and apply a technique.

Shu (’keep’, ‘protect’) – the stage where you follow the defined methodology precisely and comprehensively.

Ha (’detach’, digress) – the stage where you start adapting the techniques to suit particular circumstances.

Ri (’leave’, ‘transcend’) – the stage where your knowledge and skills allow you to blend and develop the techniques in a creative and unique way.

When exploring a new methodology for product development it is easy to fall into the trap of having only a limited knowledge and experience of a particular concept (like Stage Gate or Agile or Lean) and leaping straight to the ‘Ha’ or ‘Ri’ stage without having really explored or understood the basics by passing through the ‘Shu’ stage.  This can often have disastrous results…

Of course the key is to find ways of accelerating your progress through the ‘Shu’ stage.