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…

Top Down vs Bottom Up

When constructing a new product development project plan what is the best architecture to use?

Bottom Up entails breaking down the project activities, estimating the time required for each activity and rolling up the tasks to produce an overall schedule and milestones.

Top Down uses ’standards’ to set planned cycle times and define expectations of what needs to be accomplished in a given time.

Top Down is often proposed as the only solution to drive improvements in time to market.  To quote one source ‘Bottom up project planning is the wrong architecture for complex product development projects, because it tends to encourage the accumulation of conservative cycle times, resulting in longer time to market‘.  I’m not convinced by this argument, it smacks of mistrust between management and engineering and certainly doesn’t indicate the presence of common business goals across all functions and at all levels of the organisation.

If estimates of timescales are too conservative then surely it’s better to find better estimation methods to produce challenging targets that the whole team believe in?  Combining this with clearly communicated and compelling business reasons for pushing the engineers to find ways of compressing timescales creates a culture of trust and desire to get the job done.

The alternative approach of imposing artificially constructed deadlines based on previous projects doesn’t seem to be the best solution…

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.

Increasing NPD Productivity – People (2 of 5)

There are two sides to the ‘People’ aspect of increasing NPD productivity.  The first concentrates on the ‘mechanical’ resource issues.  The second deals with the human aspect.

Resource issues are important.  Project plans can only achieve their goal of realistically detailing future activities if the necessary resources are identified and allocated to the tasks that make up the plan.  Project management often falls apart because ineffective methods to plan resource requirements are used.  All too often a project plan is assembled with the assumption that the necessary engineers are allocated and available 100% of the time for the life of the project.  Whilst this is an ideal situation to ensure individual project success, it is inefficient and impracticable.  Equally common is the use of task dependencies to achieve a level resource utilisation with disastrous results as the project progresses.  Of course the most appropriate solution is to have a fully integrated set of project plans with an accurately defined common resource pool.  It’s not an easy job to do properly but it can provide an alternative to the plate spinning technique of resource allocation employed all too often.

Another area of interest regarding engineering resource is utilisation.  Even in the most organised and well planned NPD function it is common for more than 30% of engineer resource to be spent on activities other than those determined by the plan.  Working on the ‘wrong’ projects (helping out on other planned projects or spending time on ‘under the counter’ projects), administrative tasks and customer support are major contributors to this lost resource.  Measuring and setting improvement targets for utilisation is a key activity for increasing NPD productivity. 

Unfortunately many initiatives to increase the performance of NPD activities focus on these resource issues and ignore the human element – in effect treating development engineers as merely ‘assignable resources’.

The three key subjects to consider are motivation, skills and communication.  Finding ways to measure  these and improve them is a difficult but very important activity.  For some inspiration on these check out previous posts on Imposition, Boys Keep Swinging, T Shaped People and You Can’t Control What You Can’t Measure (last paragraph)

Plus since this is an overlooked subject keep an eye out for future posts and ideas.

Increasing NPD Productivity – Introduction (1 of 5)

The overall process of new product development and innovation encompasses an wide variety of elements.  This blog regularly explores a number of ideas and tools which hopefully provide inspiration in the quest to improve the efficiency and productivity of many of these elements of NPD.

This short series of 5 posts will explore the more fundamental issue of how the different pieces of the picture are assembled and how they relate to each other.  The two main conclusions will be how successful NPD depends upon a combination of three main topics: -

- People

- Project

- Portfolio

and the exchange of real time information between these three is as important as improving performance in any specific area.

Lean Product Development – A Roadmap

Previous posts have dealt with the concepts behind Lean Product Development and highlighted the most useful tools.  When embarking on any process transformation project it is important to understand that there is no clear set of directions but your roadmap needs to be developed around a framework.  The following points help define the framework around which you can build the map for your lean journey.

Identify champions. The lean journey is not simple or easy.  Established ways of working often need to be challenged.  Enthusiasm needs to be invoked to encourage involvement.  Positive results need to be identified and communicated to convince others.  The whole package requires strong leadership.

Engage others. Identification of waste and the creation of ways to eliminate it are often best achieved in a team environment.  Involvement of other functions is critical.  Strong facilitation is vital

Start small. Identify pilot projects to achieve early success and facilitate the development of methods and ideas before scaling up

Identify waste. Use brainstorming, structured reviews and process mapping to identify the wastes and where they occur.  Waste is often found in specification generation activities (generating useless information), activity driven reviews (waiting) and resource allocation (disruption and distraction) – but you can find it elsewhere!

Eliminate waste. Combine reviewing best practice, applying lean ideas and creative problem solving to devise methods of working that do not generate waste.  Implement and validate these new methods on pilot projects.

Review Frequently. Drive progress and maintain enthusiasm by frequently reviewing progress, defining actions and communicating success

Scale up. Build on pilot project success and devise a clear plan to scale up and roll out – but don’t forget to review progress frequently!

Planning Poker

The world of Agile Software Development has thrown up a bunch of interesting ideas which are equally applicable in other development environments.  Planning Poker is one of the more interesting ones.

It’s more like a fun version of Wideband Delphi (even the name is more interesting), and is used to generate more accurate estimates of effort to complete tasks.

A group of people are assembled and each participant is given a set of cards with numbers on them.  Sometimes a Fibonacci series is used (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), or some other progression (one set uses the sequence 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 and includes a ‘?’ card and an ‘I need a break’ card in the form of a picture of a cup of coffee).

Each task is discussed (avoiding the expression of opinions regarding the effort required to complete the task to avoid ‘anchoring’).  Then each participant selects the card (in secret) that reflects their view of how long it will take to do the task.  All the cards are revealed – major discrepancies are discussed and the process of selecting cards is repeated until a consensus value for the estimated effort is reached.

The tool needs careful facilitation and a commitment to adhere to the process, but offers a speedy and interesting solution to the task of project planning and task estimation.

Project Kick Off

One Saturday morning a group of footballers meet on a pitch.  They start to kick a ball about, passing to each other, taking shots at goal and practising set pieces.  After more than half an hour a referee turns up, blows his whistle and declares the half time score.  The players are up in arms – ‘we didn’t know we’d started’, ‘we didn’t know who was on which team’ etc.

Of course it would be madness to start a football game like this – so why are so many projects started without a kick off meeting?

It might seem like a waste of time, but it ensures that everyone is on the same page regarding the background to the project, the goals, the budget, the business case and everybody’s roles and responsibilities.

It also reinforces the fact that clear and open communication is the key to a successful project.