Archive

Monthly Archives: January 2016

We’re All In This Together

Creating, sustaining and continually improving effective ways of New Product Development requires the efforts, commitment and active participation of everyone in the organisation. It’s not something that can be delegated, offloaded or left to just one department, function or silo.

In my previous post, I mention a number of constraints which typically prevent an organisation from having an effective product development approach. If you take a look at that post, you may begin to see how these particular constraints are organisation-wide. And how reducing or eliminating them requires the active participation of everyone, from the CEO, through function heads, to the front-line workers:

Whole Products means specialists (sales people, marketeers, finance, operations and customer service specialists, etc.) from across the organisation are needed for each and every new product development.

SBCE means changes to accounting practices, personnel recruitment, allocation and training (HR), as well as the understanding and involvement of senior executives in investment and strategy decisions for the longer term.

Flow means reorganising and smoothing the internal operations (explicit or implicit value streams, customer journeys, etc.) which run through the daily business as usual of the whole organisation.

Transitioning from a projects-based approach to New Product Development to something more effective (such as FlowChain) requires the overhaul and replacement of many policies, procedures and expectations across the organisation.

Cognitive Function asks us to learn about topics – psychology, neuroscience, sociology, anthropology – with which we may have had little experience before. And to prevent just one group (NPD) getting wildly out of step with the rest of the organisation, most people coming into contact with these new ideas and ways of relating to each other will need to at least understand what’s going on.

A clearly-articulated and jointly-created product development doctrine offers a means to encourage debate, and understanding, across the whole organisation.

Summary

Each of the above changes requires new understandings and new behaviours – including e.g. cooperation, collaboration, trust, and support – from every department in the organisation. Existing incentives, goals and rewards schemes tailored to individual performance and local (function-specific) results will directly oppose these new behaviours, so must be replaced with schemes designed to foster the new behaviours. Old assumptions and power structures, again supporting of traditional ways of doing things, must be overhauled to become more relevant to our new, more effective ways of New Product Development.

Ultimately, we will find ourselves asking the question “Is it worth it? Does an amazing uplift in our organisation’s ability to release new products and product updates with:

  • fewer delays and overruns
  • higher quality
  • lower cost
  • better product-market fit

warrant the root-and-branch changes necessary for success? Are we in business for the long-haul? And do we each want to be proud to have played our part in creating something truly awesome?

– Bob

 

Constraints On Effective Product Development

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

The Simplest Thing That Could Possibly Work

Here’s an excerpt (pp 206) from “Birth Of the Chaordic Age” by Dee Hock, about “an odd project management scheme” they adopted in the early days – circa 1974:

“Swiftly, self-organisation emerged. An entire wall became a pinboard with every remaining day calendared across the top. Someone grabbed an unwashed coffee cup and suspended it on a long piece of string pinned to the current date. Every element of work to be done was listed on scraps of paper with the required completion date and the name of the person who had accepted the work. Anyone could revise the elements, adding tasks or revising dates, providing they coordinated with others affected. Everyone, at any time, could see the picture emerge and evolve. They could see how the whole depended on their work, and how their work was connected to every other part of the effort. Groups constantly assembled in front of the board as need and inclination arose, discussing and deciding in continuous flow; then dissolving as needs were met. As each task was completed its scrap of paper would be removed. Each day, the cup and string moved inexorably ahead.”

I’m struck by the similarities with FlowChain, and as with FlowChain, it seems an exemplar of simplicity and flow. I also note the implicit “Advice Process” vibe, and the emphasis on “making the work visible” (Cf Personal Kanban).

– Bob

Further Reading

Surely You Can’t Mean That?

I regularly talk with business people about improving their software and product development, and their businesses as a whole, more and more dependent as these businesses are on these capabilities. The reaction I see far more often than most others is – incredulity.

“Surely you can’t mean that??”

Collaborative Knowledge Work

“Collaborative knowledge work is fundamentally different to the kinds of work you and your people are used to. It will require fundamental shifts in how you approach the whole idea of work.”

“What?!? Surely you can’t mean that?”

Managers

“Managers and management are antithetical to collaborative knowledge work – you’ll have to find some other things to which these folks can apply their skills and experience.”

“What?!? Surely you can’t mean that?”

Workers

“The best people to decide how the work should work are the people doing the work. Not the managers.”

“What?!? Surely you can’t mean that?”

Scrum

“In Scrum, there are only three roles: Developer, Scrum Master and Product Owner.”

“What?!? Surely you can’t mean that?”

Relationships

“The one key element to productivity in collaborative knowledge work is the quality of the relationships between people.”

“What?!? Surely you can’t mean that?”

Projects

“Doing work in projects inflates your costs, demoralises workers, and sucks management attention. You would be well served to find some other approach.”

“What?!? Surely you can’t mean that?”

Certainty

“Looking for certainty – of timescales, costs, quality, outcomes – is a Fool’s Errand. Get comfortable with uncertainty, and focus instead on flexibility and reducing delays.”

“What?!? Surely you can’t mean that?”

Strategy

“The days of a sellers’ market are over. Winning businesses will be those that discover how to compete successfully in a buyers’ market.”

“What?!? Surely you can’t mean that?”

Telling

“Telling capable employees what to do and how to do it only demoralises and demotivates them. Move from telling to serving.”

“What?!? Surely you can’t mean that?”

Incredible

All these are incredible, unbelievable, and utterly essential ideas in the world of collaborative knowledge work. How can we all stop drawing sharp intakes of breath, and come to terms with these – and many other –  impossible-to-believe ideas?

– Bob

 

The Concept Of Value

Many folks talk about value. I have a distinct suspicion that few have any clear idea of what they themselves mean by the term. And of those few, I suspect each might have a different meaning in mind. I myself attempted to define the term some years ago.

This post doesn’t try to define “value”, but it does suggest how we might broaden and bring about a more shared understanding of the term. Please do suggest how this particular quantification (see below) might be improved.

Quantification As A Means To Shared Understanding

Tom Gilb suggests that to better understand a thing, we might choose to quantify various characteristics of that thing.

Example: Quality

Quality is characterized by these traits:

  1. Quality describes ‘how well’ a function is done.
  2. Quality describes the partial effectiveness of a function (as do all other performance attributes).
  3. Quality is valued to some degree by some stakeholders of the system
  4. More quality is generally valued by stakeholders; especially if the increase is free, or lower cost, than the value of the increase.
  5. Quality attributes can be articulated independently of the particular means (designs) used for reaching a specific quality level –
    even though all quality levels depend on the particular designs used to achieve them.
  6. A particular quality can be a described in terms of a complex concept, consisting of multiple elementary quality concepts.
  7. Quality is variable (along a definable scale of measure: as are all scalar attributes).
  8. Quality levels are capable of being specified quantitatively (as are all scalar attributes).
  9. Quality levels can be measured in practice.
  10. Quality levels can be traded off to some degree; with other system attributes valued more by stakeholders.
  11. Quality can never be perfect (100%), in the real world.
  12. There are some levels of a particular quality that may be outside the state of the art; at a defined time and circumstance.
  13. When quality levels increase towards perfection, the resources needed to support thoselevels tend towards infinity.

The Concept Of Value

Value: the concept, the noun.

[Note: the Planguage/Competitive Engineering concepts glossary has an entry for Value (*269)]

A ‘value’ is

– A scalar attribute

– reflecting a need

– someone has

Value is characterized by these traits:

  1. Value implies the meeting of ‘a need’ someone has (generally, a someone that matters).
  2. Value is theoretical, at least until someone has something tangible in their hands and can try it out to see it it does, indeed, meet their proposed need, or not.
  3. Value is time-sensitive. What meets someone’s need on a given day may not meet their need a week before, or a week after.
  4. Value attributes (the characteristics of a given need) can be articulated independently of the particular means (designs) used for reaching a specific value level – even though the meeting of each need depends on the particular designs – or strategies – used.
  5. A particular value can be a described in terms of a complex concept, consisting of multiple elementary value concepts.
  6. Value is variable (along one or more definable scales of measure: as are all scalar attributes).
  7. Value levels are capable of being specified quantitatively (as are all scalar attributes).
  8. Value levels can be measured in practice.
  9. Value levels can be traded off to some degree; with other value levels.
  10. Value can never be perfect (100%), in the real world.
  11. There are some levels of a particular value that may be outside the state of the art; at a defined time and circumstance.
  12. When value levels increase towards perfection, the resources needed to support those levels tend increase geometrically.

Quantification Of The Concept Of Value

[TBD – Contributions and suggestions welcomed]

– Bob