NPD Tales

Ideas Thoughts and Comments on Product Development

Stand Up

There are times in some NPD projects or moments in the development of a specific team dynamic where there are a multitude of concurrent activities, a large number of people involved, interactions between tasks and most importantly many ways in which the whole thing can go off the rails.

Indeed there are some organisations where that is the norm…

In such a dynamic multi-faceted scenario even a weekly review meeting is just too infrequent.  But many project review meetings turn into long winded talking shops that preclude them being held any more frequently.

A daily stand up meeting might just do the trick – here’s some pointers on how to create value out of a short review meeting.

• Stand up, no chairs

• Same place and time every day

• Fifteen minutes, no more

• Control the attendee list – only those who are directly involved

• Each participant answers three questions

- What did you do yesterday?

- What are you going to do today?

- What obstacles stand in your way?

• Focus on removing obstacles

• Stop long winded discussions before they get going, note and action them for resolution outside the meeting

Most engineers have a dislike for review meetings simply because most review meetings aren’t run like this…

Standing up for the Pointy Haired Boss (for once)

Of course, I’m a huge fan of Scott Adams.  Yes, I  nod knowingly at the hilarious observations of Dilbert’s working life.

But from time to time I think someone needs to stand up for the pointy haired boss…

progress report dilbert

If he thought for one moment that Wally would pro-actively volunteer information on technical issues that endanger the successful timely completion of the project he wouldn’t need to ask the question.

The desire of many engineers to exist in an undisturbed vacuum only surfacing to tell someone that they’ve just missed a deadline is not something to be lauded (or encouraged).

Increasing NPD Productivity – Integration (5 of 5)

The previous posts have focussed in turn on the three key factors influencing NPD productivity (People, Project and Portfolio).  However substantial improvements to the overall performance of NPD activities can be achieved by examining the interface between all the associated elements of the three factors – for example.

- Resource availability influencing project prioritisation

- Engineer motivation being increased by communicating the reasoning behind portfolio management decisions

- Having a real time exchange of resource planning and project planning throughout the life of the project to adapt to changes in project schedule or priorities

- Effective communication of the results of project reviews to ensure engineers are not ‘left in the dark’

- Identifying the dependence of sales forecasts on launch date to ensure project planning and control are meeting business needs

- Feeding back project review results to drive portfolio management activities and adjusting priorities of all projects accordingly

The list is almost endless and the key is a dynamic exchange of information.  How can that be achieved?

I’ve raised the subject of Enterprise Wikis before and there is an increase in the number of real time collaborative tools (like SamePage, BaseCamp and MS SharePoint).  Some even suggest that a complex extension of highly integrated ERP or PLM tools are the answer.  I feel that understanding the need for such exchange of information is as important as the choice of tool.

Increasing NPD Productivity – Project (3 of 5)

The ‘Project’ aspect of increasing NPD productivity is initially concerned with building a strong plan.

The foundation of a good project plan is a clearly defined goal, a well constructed work breakdown structure and accurate timescales.  Weakness in any of these is amplified into a very weak plan that will soon be of no use.

Even though these simple methods are practised in many organisations, they are only one side of the coin.  The other side is concerned with maintaining and using the plan to drive progress.

The key concepts to effective project control are regular reviews and management by exception.  There’s little point in having large event driven review meetings that cover every task in the plan in detail – a smaller regular review that quickly identifies tasks or activities that are not going to plan and identifies corrective action is a much better use of everyone’s time.

In almost all organisations, one person is responsible for the planning and control of projects.  However substantial increases in NPD productivity can be gained by introducing collaborative project planning and control.  The value that a well facilitated exercise in developing a work breakdown structure or defining task durations is well established, but more collaborative, multi-input methods of controlling projects can be very effective.

See Project Plans, Visual Project Management, Lean Product Development – Cadence and Planning Poker for more ideas on how to revitalise your project planning and management and hence increase your NPD productivity.

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.

Visual Project Management

It doesn’t matter how complex your project plan is, there’s always the issue of how you present the results and use the plan to drive and manage progress.

It’s important to think about the different ‘customers’ of the information that you wish to impart and what their needs and expectations are.  Do they have the time (or indeed knowledge) to understand a series of Gantt Charts (conversely do they have a voracious appetite for detailed information)?  What actions do they need to take to meet the plan?  How can they contribute to implementing corrective action to pull a project back on schedule?  What are their responsibilities in dealing with unrecoverable delays?

There are many templates and ideas for presenting project plans – take time to explore them and tailor them for the needs of your ‘customers’

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