NPD Tales

Ideas Thoughts and Comments on Product Development

DFMEA

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.

Lean Product Development – Batch Size

In an earlier post I introduced the idea of cadence in product development activities.  Of course if you’re going to introduce the concept of reviewing work on a regular basis instead of event or content driven reviews you need to think about the time period between the reviews or in lean manufacturing parlance the batch size.

Obviously there is a balance to be struck between reviewing a large amount of work (with the associated risk of amplification of errors) and having engineers spending too much time reviewing their work.

One important factor to be considered is that frequent regular reviews become a simple low overhead task compared to infrequent irregular reviews where there is a tendency to settle down for a day of coffee, biscuits and talking.  In general, your batch sizes right now are likely to be much larger than optimal.

Lean Product Development – Cadence

One of the key aspects of Lean Manufacturing is Takt Time.  This is a heartbeat of the production process that ensures your production meets demand (but not exceeds – that’s wasteful overproduction) and enables pull scheduling.

Of course trying to precisely transfer lean manufacturing tools across to product development is invariably inappropriate.  But if you think about the concepts behind takt time it can reveal ideas to help in the non-linear non-repetitive world of product development.

For example many existing processes have a small number of review stages that are event or content driven (i.e. at a particular stage in the development).  This results in large amounts of untested or unverified work building up with errors being detected far too late.  In addition if one facet of the design doesn’t meet the milestone for the review point it can cause knock on delays to the whole project.

Consider instead reviews that are scheduled to occur at regular intervals that cover whatever work has been done over each time period.  Errors and deviations from the plan can be detected early and action can be taken to reduce the wastes associated with amplification of errors and waiting.

Who’d be a Mechanical Engineer?

It’s a positive step to get non-engineering functions within an organisation more closely involved with product development.  Greater consideration is paid to manufacturing issues and the input from the sales and marketing team can be effectively used to tighten and speed up customer feedback loops.

But in the rush to reap the rewards of such cross-functional working, one engineering discipline can be adversely affected.

Most people would not review an electronic schematic and make comments to the hardware engineer regarding the design – a few comments regarding connector pinout might be all.  Similarly although a user interface may be scrutinised by a non-software engineer the lines of functional code will for the most part remain hidden.

But the poor mechanical engineer can end up having every aspect of his design reviewed and commented upon.  It’s easy to understand mechanical engineering, the product is tangible – that inherent understanding makes it easy for people to suggest changes to a design that they believe will improve the product.

Of course the physical properties of the product do often have more impact on the customer and manufacturing so this increased scrutiny of the mechanical design has benefit, but it is important that such design reviews are timely and the benefit of any changes outweigh the cost.

Stage Gate – Friend or Foe?

I guess I have to bring up the subject of Stage Gate methodology at some point.  Firstly I should point out that I’ve been involved in a handful of implementations of a Stage Gate product development system and indeed I was instrumental in one of them happening in the first place.

Stage Gate in short consists of a series of stages of work where information is obtained/generated and analysed followed by gates where go/kill decisions are made to continue to invest in the project.

There are many who criticise the system for being too bureaucratic and wasteful.  Gate meetings are often elaborate affairs where countless reporting documents are presented to a large number of senior stakeholders.  In addition the sequence of stages tends to enforce a very linear mindset and delays are introduced into the process.

Mindful of these criticisms the architect of Stage Gate introduced a NexGen version a couple of years ago.  By scaling down the process for lower risk projects, introducing a clearer continuous feedback element and accelerating the gates many of the criticisms were addressed.

An intelligent implementation of some form of Stage Gate methodology need not be the paralysing experience that many have experienced…

Project Plans

When you think about the project plans in your organisation do any of these scenarios have a familiar ring?

•    Created once in a flurry of activity and initial enthusiasm, then forgotten about because something more important crops up
•    Created once, then forgotten about until an important milestone is missed at which point they are dusted off, used to point blame and updated
•    Created in great detail and frequently modified so they are only accurate for tasks that will be completed in the next two days
•    Created in isolation by an individual who doesn’t understand the design process, task dependencies or the accuracy to which each engineer can predict task timescales
•    Completely ignored because they are not understood or trusted

The solutions to these all too common scenarios are simple but you need to apply some effort.  Try these ideas for starters…

Train everyone in project planning
Clearly define and communicate the scope and goal of each project
Create a comprehensive Work Breakdown Structure (WBS)
Break the generation of the plan into multiple smaller batch exercises
Intelligently generate accurate timescale estimates
Communicate the progress and status of the project against plan on a regular basis