Constraints On Effective Product Development

Constraints On Effective Product Development

Bottlenecks

What company wouldn’t love to have its product development efforts be more effective? Be able to release new products and product updates with fewer delays and overruns, with higher quality and at lower cost? And be sure of the product-market fit, too?

Many companies spend inordinate amounts of time, effort and management attention on just this. And yet reap little in the way of benefits from that investment.

Why is this? What are the blockers (constraints) frustrating these ambitions?

I see the same patterns time after time. Patterns that stymie effective practices and lock in ineffective approaches and poor results. Here’s some of the more common ones:

Whole Products

Few companies are able to reap the benefits of a Whole Product approach to New Product Development. The constraint here is the ability of people and teams from different functional areas across the business to come together (literally and figuratively) for the duration of a product’s development. Toyota have long eliminated this constraint through their Obeya concept, and unique matrix structure.

Set-Based Concurrent Engineering

Most companies suffer unpredicted (yet predictable) overruns and delays in the development of many (most) of their products. One key constraint in play here is the lack of options when a particular component or subsystem – on the product’s critical path – proves problematic. SBCE eliminates this constraint by purposely providing options at every stage of the product’s development. At each “integration point” during a development, the most promising (and always 100% viable) option is selected. SBCE as a solution is predicated on the organisation’s ability to save its learning on and investment in the “pruned” options, for future products or upgrades.

Flow

Organising around flow offers a number of benefits, not least reduced costs and delays. Many companies attempt to organise traditionally – around skills and functional silos. The traditional approach chokes flow and reduces the effectiveness of product development.

NoProjects

The almost universal use of projects as the containers for product development work again constrains our efforts to the relatively ineffective end of the spectrum. The many drawbacks of the “projects” concept are well-known. Yet the constraint here is no so much projects themselves, but the way in which an organisation’s policies, procedures and assumptions lock in the idea of projects. Moving to a non-project approach, such as FlowChain, is a political and social challenge of the first order.

Cognitive Function

Many companies understand the issues of engagement and the need for innovation. Fewer understand the nature of collaborative knowledge work, its fundamentally differences from more traditional forms of work, and the need to approach it with a fundamentally different set of assumptions. Assumptions absent which, effective product development – as the archetype of collaborative knowledge work – is impossible. The traditional assumptions at the heart of traditional management of traditional organisations are the key constraint here. These assumptions prevent us realising the high levels of employee engagement, the innovation culture and the high levels of cognitive function so necessary for effective product development.

Doctrine

Few organisations have a clearly articulated and debated doctrine describing their approach to product development. This absence of clarity constrains the whole organisation, with folks constantly wondering what they should be doing, why they’re doing it, and how everyone’s efforts fit together.

Summary

The above are just a few of the key constraints condemning product development efforts in most organisations to the ghetto of high costs, poor quality and interminable delays. None of these constrains are simple or easy to tackle. But identifying them is the first step to dealing with them. What constraints are limiting your product development effectiveness?

– Bob

Further Reading

Product Development for the Lean Enterprise ~ Michael N. Kennedy
It’s Not Luck ~ Eliyahu M. Goldratt
The Principles of Product Development Flow ~ Donald G. Reinertsen

4 comments
  1. People/team work are another constraint. If you don’t have a project plan, that can be a mistake, Accountabilities and responsibilities should be in place. If you don’t Value Engineer during New Product Development, that is a big mistake: retain the function reduce the costs without ever jeopardizing quality. The hand off to production/manufacturing has to be seamless.

  2. dancres said:

    I would contend there’s no such thing as hand-off in new Product Development. Unless of course, you’re ceasing development at the start of the very first production run. i.e. You’ll ship whatever it is to customers and make no adjustments or introduce any variance ever because what you have is already perfect.

    Flow, done well, alongside SBCE and iteration will look after costs IMO. Further any form of focused cost reduction has a nasty habit of backfiring as Seddon says:

    “If you manage costs, costs go up.”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: