Shipulski On Design

Archive for the ‘Constraints’ Category

Things aren’t impossible on their own, our thinking makes them so.

Impossible is not about the thing itself, it’s a statement about our state of mind.

When we say impossible, we really say we lack confidence to try.

When we say impossible, we really say we are too afraid to try.

The mission of impossible is to shut down all possibility of possibility.

To soften it, we say almost impossible, but it’s the same thing.

When we say impossible, we make a big judgment – but not about the thing – about ourselves.

We don’t know the question, but the answer is innovation. And with innovation it’s more, more, more. Whether it’s more with less, or a lot more with a little more, it’s always more. It’s bigger, faster, stronger, or bust.  It’s an enhancement of what is, or an extrapolation of what we have. Or it’s the best of product one added to product two. But it’s always more.

More-on-more makes radical shifts hard because with more-on-more we hold onto all functionality then add features, or we retain all features then multiply output. This makes it hard to let go of constraints, both the fundamental ones – which we don’t even see as constraints because they masquerade as design rules – and the little-known second class constraints – which we can see, but don’t recognize their power to block first class improvements. (Second class constraints are baggage that come with tangential features which stop us from jumping onto new S-curves for the first class stuff.)

To break the unhealthy cycle of more-on-more addition, think subtraction. Take out features and function. Distill to the essence. Decree guilty until proven innocent, and make your marketers justify the addition of every feature and function. Starting from ground zero, ask your marketers, “If the product does just one thing, what should it do?” Write it down as input to the next step.

Next, instead of more-on-more multiplication, think division. Divide by ten the minimum output of your smallest product. (The intent it to rip your engineers and marketers out of the rut that is your core product line.) With this fractional output, ask what other technologies can enable the functionality? Look down. Look to little technologies, technologies that you could have never considered at full output. Congratulations. You’ve started on your migration toward with less-with-far-less.

On the surface, less-with-far-less doesn’t seem like a big deal. And at first, folks roll their eyes at the idea of taking out features and de-rating output by ten. But its magic is real. When product performance is clipped, constraints fall by the wayside. And when the product must do far less and constraints are dismissed, engineers are pushed away from known technologies toward the unfamiliar and unreasonable. These unfamiliar technologies are unreasonably small and enable functionality with far less real estate and far less inefficiency. The result is radically reduced cost, size, and weight.

Less-with-far-less enables cost reductions so radical, new markets become viable; it makes possible size and weight reductions so radical, new levels of portability open unimaginable markets; it facilitates power reductions so radical, new solar technologies become viable.

The half-life of constraints is long, and the magic from less-with-far-less builds slowly. Before they can let go of what was, engineers must marinate in the notion of less. But when the first connections are made, a cascade of ideas follow and things spin wonderfully out of control. It becomes a frenzy of ideas so exciting, the problem becomes cooling their jets without dampening their spirit.

Less-with-far-less is not dumbed-down work – engineers are pushed to solve new problems with new technologies. Thermal problems are more severe, dimensional variation must be better controlled, and failure modes are new. In fact, less-with-far-less creates steeper learning curves and demands higher-end technologies and even adolescent technologies.

Our thinking, in the form of constraints, limits our thinking. Less-with-far-less creates the scarcity that forces us to abandon our constraints. Less-with-far-less declares our existing technologies unviable and demands new thinking. And I think that’s just what we need.

Some thoughts on no:

• Yes is easy, no is hard.
• Sometimes slower is faster.
• Yes, and here’s what it will take:
• The best choose what they’ll not do.
• Judge people on what they say no to.
• Work and resources are a matched pair.
• Define the work you’ll do and do just that.
• Adding scope is easy, but taking it out is hard.
• Map yes to a project plan based on work content.
• Challenge yourself to challenge your thinking on no.
• Saying yes to something means saying no to something else.
• The best have chosen wrong before, that’s why they’re the best.
• It’s better to take one bite and swallow than take three and choke.

The new product development process creates more value than any other process. And because of this it’s a logical target for improvement.  But it’s also the most complicated business process.  No other process cuts across an organization like new product development. Improvement is difficult.

The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together.  Don’t know the problem.  Stepping back, who will lead the charge? Whose problem is it?

The goal of all projects is to solve problems.  And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem.  And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products.  Yikes.

Problems are informed by outcomes.  Make a short list of desired outcomes and show the CEO.  Your list won’t be right, but it will facilitate a meaningful discussion.  Listen to the input, go back and refine the list, and meet again with the CEO.  There will be immense pressure to start the improvement work, but resist.  Any improvement work done now will be wrong and will create momentum in the wrong direction.  Don’t move until outcomes are defined.

With outcomes in hand, get the band back together. You know who they are.  You’ve worked with them over the years. They’re influential and seasoned.  You trust them and so does the organization.  In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.)  If they’re the right folks, they’ll say they don’t know.  Then, they’ll craft the work to figure it out – to collect and analyze the data.  (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist.  Any work done now will be wrong.  Don’t move until problems are defined.

With outcomes and problems in hand, meet with the CEO.  Listen.  If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO.  Review outcomes and problems.  Listen.  If there’s agreement, it’s time to put a plan together.  If there’s disagreement, stop.  Don’t move until there’s agreement.  This is where it gets sticky.  It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge.  No words of wisdom on than – don’t move until outcomes and problems are defined.

There’s a lot of emotion around the product development process.  We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument.  Analyze your process and define outcomes and problems.  The result will be a well informed improvement plan and alignment across the company.

What’s the risk?

What’s to lose?

What’s in the way?

What are you afraid of?

a

Try it.

Mental walls are more powerful than physical ones.

With physical walls you know where they start and end and know if you can bust them down. With mental walls, you’re not sure.

With physical walls you know they exist – that they’re real. With mental walls, you’re not sure.

With physical walls you can blame someone for bad workmanship. With mental walls, you’re the workman.

The only way to tell a real wall from a mental one is to to take a run at it, but even then, you’re never really sure.

We all have computer models – economic models, buying models, voting models, thermal, stress, and vibration. A strange thing happens when our models reside in the computer: their output becomes gospel, unchallengeable. And to set the hook, computerized output is bolstered by slick graphics, auto-generated graphs, and pretty colors.

Model fundamentals are usually well defined, proven, and grounded – not the problem. The problem is applicability. Do the fundamentals apply? Do they apply in the same way? Do different fundamentals apply? We never ask those questions. That’s the problem.

New folks don’t have the context to courageously challenge fundamentals and more experienced folks have had the imagination flogged out of them. So who’s left to challenge applicability of fundamentals? You know who’s left.

It’s smart folks with courage that challenge fundamentals; it’s people willing to contradict previous success (even theirs) that challenge fundamentals; it’s people willing to extend beyond that challenge fundamentals; it’s people willing to risk their career that challenge fundamentals.

Want to challenge fundamentals? Hire, engage, and support smart folks with courage.

Focus, focus, focus. Measure, measure, measure. We draw organizational boxes, control volumes, and measure ins and outs. Cost, quality, delivery.

Control volumes? Open a Ziploc bag and pour water in it. The bag is the control volume and the water is the organizational ooze. Feel free to swim around in the bag, but don’t slip through it because you’ll cross an interface. You’ll get counted.

Organizational control volumes are important. They define our teams and how we optimize (within the control volumes).  We optimize locally. But there’s more than one bag in our organizations.

The red team designs new products. They wear red shirts, red pants, and red hats. They do red things. We measure them on product function. The blue team makes products. They wear blue and do blue things. We measure them on product cost. Both are highly optimized within their bags, yet the system is suboptimal. Nothing crosses the interface – no information, no knowledge, no nothing. All we have is red and blue. What we need is purple.

We need people with enough courage to look up one level, put on a blue shirt and red pants, and optimize at the system level. We need people with enough credibility to swap their red hat for blue and pass information across the interface. We need trusted people to put on a purple jumpsuit and take responsibility for the interface.

Purple behavior cuts across the fabric of our metrics and control volumes, which makes it difficult and lonely. But, thankfully some are willing to be purple. And why do they do it?  Because they know customers see only one color – purple.

“Constraint” is most often an excuse rather than a constraint. In fact, there are very few true constraints, with most of them living in the domain of physics.

A constraint is when something cannot be done. It’s not when something is difficult, complex, or unknown. And, it’s not when the options are costly, big, or ugly. There are no options with a true constraint. Nothing you can do.

The Physical Constraint
If your new product requires one of its moving parts to go faster than the speed of light, that’s a physical constraint (and not a good idea). If your new technology requires a material that’s stronger than the strongest on record, that’s a constraint (and, also, not a good idea). If your new manufacturing process consumes more water than your continent can spare, that’s a constraint. (This may not be a true constraint in the physics sense, but it’s damn close.) Don’t try to overpower the physical constraint – you can’t beat Mother Nature. The best you can do is wrestle her to a tie, then, when you tire, she pins you.

The Legal Constraint
If your approach violates a law, that’s a legal constraint. Not a true constraint in a physical sense, as there are options. You can change your approach so the law is not violated (maybe to a more costly approach), you can lobby for a law change (may take a while, but it’s an option), or you can break the law and roll the dice. To be clear, I don’t recommend this, just wanted to point out that there are options. Options exist when something is not a constraint, though the consequences can be most undesirable, severe, and may not fit with who we are.

The Emotional Constraint
If a person in power self-declares something as a constraint, decides there are no options, that’s an emotional constraint. Not a true constraint in a physical sense, but it’s the most dangerous of the triad. When there is no balance in the balance of power, or the consequences of pushing are severe, the self-declared emotional constraint stands – there are no options. Like with the speed of light, where adding energy cannot overcome the speed constraint, adding reasoning energy cannot overcome the emotional constraint. I argue that most constraints are emotional.

Physical and legal constraints are relatively easy to see and navigate, but the emotional constraint is something different altogether. Difficult to see, difficult to predict, and difficult to overcome. Person-based rather than physics or law-based.

Strategies to overcome emotional constraints must be based on the particulars of the person declaring the constraint. However, there is one truism to all successful strategies: Just as the person in power is the only one who can convince himself something is a constraint, he is also the only one who can convince himself otherwise.