What are NPD Tales?

Some random thoughts and ideas on the general subject of new product development. Exploring the process of turning an idea into a successful product I’ll cover a wide variety of topics on a regular basis. From practical insights into the problems faced by product development teams on a daily basis through to thought provoking ideas and news (including comments on product failures and successes) there should be plenty to keep coming back for. Click on the link above to subscribe and receive e-mail notifications of new posts

I’ve spent some time recently working much more closely with the 37 Signals product BaseCamp (more about that another day).

Whilst looking over the company website I stumbled upon their ‘book’ Getting Real. It’s an easy read that really gives you a comprehensive picture of the culture at 37 Signals. It’s also full of some fantastic ideas many of which present a fresh viewpoint on the process of product development. I would recommend people to read it.

The authors admit that the book’s emphasis is on building a web application but do suggest that ‘a lot of these ideas are applicable to non-software activities too.’

I’d add that I feel the book’s emphasis is on building mass market web applications, some of their ideas in the chapter on Feature Selection (’Start With No’, ‘Forget Feature Requests’) might not be perfect advice in a more specialist or niche field.

Is that the point of this type of book – to provoke debate and ask questions on how you do things whilst presenting a smorgasbord of ideas from which you can create your own way of working? If that’s the case then there is always the risk that the reader will cherry pick the ideas that reflect their current state and achieve no improvement in the way they develop products…

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…

Portfolio Management ultimately depends on forecasts and predictions of development cost, sales volumes and revenue to provide a method of prioritising projects. With a nod to James Surowiecki, Inkling have produced a tool that facilitates a more collaborative approach to refining those forecasts and predictions. By answering some simple questions based on the original ‘guesses’, multiple users have an influence on adjusting the values for expected launch date, development cost, ROI etc.

The idea is still at prototype stage and Nathan is looking at refining it – particularly the parameters that people will be asked to give their opinion on, but it looks very interesting even at this early stage…

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…

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.

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.

Portfolio Management when applied to new product development is simply a multivariate analysis of the factors that determine the importance of a new product development opportunity and a method of assigning a priority to each opportunity.

At it’s basic level it should involve some quantitative analysis of the forecast revenue, profit and return on R&D investment. The biggest challenge here is to get accurate sales forecasts, it’s usually easier to predict R&D costs. I have seen analysis that has used simple statistical analysis of the product financials to take into margins of error for the forecasts and estimates.

More complex analysis of qualitative factors (like technical risk, existing market fit and strategic value) can be achieved by assigning quantitative values to them. At this point the analysis becomes much more interesting – advanced visualisation can be used to determine the viability and priority of each project against the whole portfolio and where it fits in the overall innovation strategy.

Of course it’s important not to get carried away – an incremental approach of starting simple and increasing the complexity of analysis over an extended period of time can deliver early benefits before finding the optimum level.

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.

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 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.