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…


Head over to NPD Express and type ‘DFMEA’ in the Search box to link to a newly published paper on Design Failure Mode and Effect Analysis.

Does the world really need another DFMEA article?

Well I think it does.  Design FMEA was obviously derived from Process FMEA and uses the same effective but simple matrix to quantify risk of failure.  But there’s a big difference in the meaning of some of the terminology between the two.  Most importantly, DFMEA should focus on component function and the ‘Detection’ ranking should ideally focus on design controls and how effective they are at eliminating the risk of product failure in the field.

Because the majority of the trainers and facilitators involved in FMEA have a process improvement background many  Design FMEA exercises have focused on the process of using  the product (or even manufacturing it) and the assignment of the ‘Detection’ ranking has focused on changing operating procedure or improving the manufacturability of the product.  There’s nothing wrong with looking closely at those issues but when they cloud the results from a really powerful tool that can really impact product reliability then there’s a problem that needs addressing – hence my new article.


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…

You Can’t Control What You Can’t Measure?

During my time immersed in Six Sigma culture this phrase became a mantra for the Black Belts.  I wouldn’t deny its validity for a second.

What I do challenge is the validity of so many common measures that people apply to product development.

On a strategic level it is valuable to measure how much of your sales are associated with products introduced in the last ‘x’ years.  But that’s not going to provide you with rapid feedback to help you control your NPD activities at a tactical level.

Software engineers are an easy target, the amount of work they produce can be easily measured at a microscopic level (lines of code anyone?), rapid iterations and automated tests add to the picture with bug production rates…

With electronic hardware and mechanical design it’s much harder to quantify how much work has been done.  Cycle times of several weeks make it harder to devise actions based on the performance of prototypes.

From a project management perspective I often found that a business wanted to feel more confident in the timescales and milestones associated with a project so I would focus on accuracy of plan and task durations provided by the engineering team.  But this can feel artificial and removed from the goal of developing successful products.

Some have suggested more subjective measures that tap into a team’s psyche (’How do you feel about…’).  I’m intrigued by this approach and would also suggest that if your aim is to increase customer feedback (both internal and external) then it could be extended to include an ongoing external assessment of a project’s ‘health’ – with potential for providing evidence of problems yet to surface…

Design for Six Sigma

Several years ago I was working for an American company who had embraced the ideas and thinking behind Six Sigma.  Unfortunately the introduction of the culture and mindset associated with what were a powerful set of tools was not implemented in an ideal manner and the value of the exercise was somewhat lost along the way.

For me, Six Sigma is a label that was attached to a toolbox.  Some of the tools were new to me, some of them I was already familiar with.  But in the same way that you use a real toolbox, the real value is in selecting the right tool to do the particular job.