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…

Motivation – Recognition and Reward

I first saw this fantastic animated version of Dan Pink’s talk on Motivation last summer.

The assertion that Autonomy (Atlassian FedEx Days), Mastery (Linux, Apache) and Purpose (Skype, Apple) are three important factors in motivation is undeniable.  The evidence that Reward is not an important factor for all but the most mundane tasks seems sound.  However I feel strongly that Recognition is a powerful factor that is all too often ignored or even worse lumped in with Reward and discredited…

The Wisdom of Crowds Revisited

My earlier post on the collaborative approach to portfolio management from Inkling prompted me to pick up my copy of The Wisdom of Crowds by James Surowiecki.

It’s a fascinating read whereby Surowiecki proposes and illustrates that a co-ordinated ‘wise’ crowd will make better decisions or solve problems quicker than a leader or expert.

Of course the devil is in the detail of what constitutes a ‘wise’ crowd – the author states diversity (of opinion), independence (from influence) and decentralisation (of control) as the key factors.

The other important issue is the efficiency and accuracy of the mechanism of co-ordination.  Technology obviously provides better and better ways of achieving this.

It’s not a theory I would wholeheartedly endorse but it’s certainly worth bearing in mind when the considered ‘wisdom’ doesn’t appear to be working…

A Fresh Perspective on Portfolio Management from Inkling

Nathan Kontny from Inkling introduced a novel idea associated with Portfolio Management.

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.

An example portfolio has been set up (Inkling Portfolio Management Example) and you can try the system out with your on collection of projects (Inkling Portfolio Management Tool).

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…

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…

There’s only one way to find out… FIGHT!

An interesting post on the Behance 99% blog regarding the value of ‘fighting’ in deciding between opposing solutions to problems (Fight Your Way to Breakthroughs).

Although it’s written from the perspective of a more artistically creative team the key issues are equally applicable to new product development.

- Problems invariably involve consideration from people with different areas of expertise

- These people often have different ‘answers’

- The resulting conflict is either carefully avoided or a dominant force wins out

Their assertion that this does not always result in finding the best answer and carefully managed impassioned ‘fighting’ can help find a better solution is certainly worth consideration.

What gives this an interesting twist is that in my experience engineers possess more than their fair share of  reluctance to be confrontational, but there is a tipping point where the levels of passion for their line of thought become so large that their belief they are right is almost unshakeable.

Engendering conflict in these circumstances require some very careful management indeed!

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.

Boys Keep Swinging

For two weeks I’ve been enjoying the beautiful island of Menorca and not thinking about innovation or product development.  Apart from one occasion when my iPod shuffle landed on ‘Boys Keep Swinging’ by David Bowie.  I was reminded of the unconventional method by which the track was recorded.

What we did on this one was to have everybody play the instruments they didn’t usually play.  Suddenly we had Carlos Alomar, who is rhythm guitarist, on drums and Dennis Davis, on bass.  What was extraordinary was the enthusiasm that came from musicians who weren’t playing their usual instrument.  They became kids discovering rock ‘n’ roll for the first time again.

If you took your engineers out of their comfort zone and asked them to perform in a different discipline would you get similarly fresh perspective and new levels of enthusiasm?..

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…

Colocation #2 – The Faction Factor

Most people recognise the importance of colocated teams and will strive to have all the members of a project or functional team in the same place.  However, there are often barriers to doing this and the second best option of having a small number of sub-teams in different locations is adopted.  Frequent communication is encouraged and the anticipated result is that the whole team operates almost as effectively as if they were all together in the same office.

Unfortunately, this scenario is an ideal breeding ground for factions.  Continuous off-line discussions within each sub-team can erode the group consensus.  Resentment and secrecy can build  up and this can then easily develop into emotional detachment.  The planned regular communication acts as an occasional pressure release valve but never really addresses the underlying differences of opinion.

More careful management that is aware of the faction factor and can take action to address the problems at the outset of it developing is the only answer.

Of course factions can also develop amongst groups who are all sitting in the same office, but the signs are much more obvious…