Shipulski On Design

Archive for the ‘Constraints’ Category

To do new things, you’ve got to stop old things.

If you don’t stop old things, you can’t start new things.

Resources limit the work that can be done.

If you have more work than resources, you won’t be able to complete everything.

Spread your resources across fewer projects, and you’ll accomplish more.

If you run more projects, you’ll get fewer done.  Resource density matters.

For new behavior to start, old behavior must stop.

If you don’t stop old behavior, you can’t start new behavior.

When your standard work no longer works, it becomes non-standard work.

When it’s time for new work, non-standard work becomes standard work.

To get more done, improve efficiency.

To get the right work done, improve effectiveness.

New behavior requires a forcing function.

No forcing function, no change.

Things change at the speed of trust.

No trust, no change.

Transformational change isn’t a thing.

Evolutionary change is a thing.

Starting new projects is easy.

Finishing new projects requires stopping/finishing old ones, which is difficult.

Creating a start-doing list is common.

Creating a stop-doing list is unheard of.

Image credit — Demetri Dourambeis

No gets attention.

No creates a constraint that all can see.

No is a forcing function.

No preserves bandwidth.

No drives a workaround.

No forces a tack or jibe.

“No, and here’s why” is a good way to deliver a no.

No can secure a future yes.

No shifts strategy.

No requires courage.

No keeps your power dry.

No creates trust if your actions align.

No creates stress.

No is more powerful than yes.

No is not negative.

No is difficult to say.

Judge me by what I say “no” to.

Image credit — Kjetil Rimolsrønning

Give me fewer people than I need.  That will force me to come up with a better way.

Tell me what to do, but not how to do it.  If you know how to do it, I’m not your person.

Give me far less time than I need – months not years, weeks not months, days not weeks.  I will have no choice but to focus on the most important elements, and I will make decisions quickly because there is no time for indecision.  And I will have fun.

Tell me you don’t know.  That builds trust.

Give me bad tools, slow computers, and crappy infrastructure.  That will require me to make magic.

Tell me the truth.  That builds trust, too.

Give me a challenging task and tell me what I can’t do.  That will allow me to do anything else.

Tell me why you want the problem solved and get out of the way.  Everything will go better that way.

Give me a micro problem – move one atom, spin off one electron, make one photon, deliver one amp, limit me to one volt, give me a single gram.  I won’t be intimidated, and I will be able to see the physics.  Then, once solved, I will expand the solution to a size that fits our customers.

Tell me you need help, and I will help you.

Image credit — JD Hancock (Bizarro Superman)

Good teachers change your life.  They know what you know and bring you along at a pace that’s right for you, not too slowly that you’re bored and not too quickly that your head spins. And everything they do is about you and your learning.  Good teachers prioritize your learning above all else.

Chris Brown taught me Axiomatic Design.  He helped me understand that design is more than what a product does.  All meetings and discussions with Chris started with the three spaces – Functional Requirements (FRs) what it does, Design Parameters (DPs) what it looks like, and Process Variables (PVs) how to make it. This was the deepest learning of my professional life.  To this day, I am colored by it.  And the second thing he taught me was how to recognize functional coupling.  If you change one input to the design and two outputs change, that’s functional coupling.  You can manage functional coupling if you can see it.  But if you can’t see it, you’re hosed.  Absolutely hosed.

Vicor Fey taught me TRIZ. He helped me understand the staggering power of words to limit and shape our thinking.  I will always remember when he passionately expressed in his wonderful accent, “I hate words!” And to this day, I draw pictures of problems and I avoid words.  And the second thing he taught me is that a problem always exists between two things, and those things must touch each other.  I make people’s lives miserable by asking – Can you draw me a picture of the problem?  And, Which two system elements have the problem, and do they touch each other? And the third thing he taught me was to define problems (Yes, Victor, I know I should say conflicts.) in time.  This is amazingly powerful.  I ask – “Do you want to solve the problem before it happens, while it happens, or after it happens?” Defining the problem in time is magically informative.

Don Clausing taught me Robust Design.  He helped me understand that you can’t pass a robustness test.  He said, “If you don’t break it, you don’t know how good it is.”  He was an ornery old codger, but he was right.  Most tests are stopped before the product fails, and that’s wrong.  He also said, “You’ve got to test the old design if you want to know if the new one is better.”  To this day, I press for A/B testing, where the old design and new design are tested against the same test protocol.  This is much harder than it sounds and much more powerful.  He taught me to test designs at stress levels higher than the operating stresses.  He said, “Test it, break it, and improve it.  And when you run out of time, launch it.”  And, lastly, he said, “Improve robustness at the expense of predicting it.”  He gave zero value to statistics that predict robustness and 100% value to failure mode-based testing of the old design versus the new one.

The people I work with don’t know Chris, Victor, or Don. But they know the principles I learned from them.  I’m a taskmaster when it comes to FRs-DPs-PVs.  Designs must work well, be clearly defined by a drawing, and be easy to make.  And people know there’s no place in my life for functional coupling.  My coworkers know to draw a picture of the problem, and it better be done on one page.  And they know the problem must be shown to exist between two things that touch.  And they know they’ll get the business from me if they don’t declare that they’re solving it before, during, or after.  They know that all new designs must have A/B test results, and the new one must work better than the old one.  No exceptions.

I am thankful for my teachers.  And I am proud to pass on what they gave me.

Image credit — Christof Timmermann

Tariffs.  Economic uncertainty.  Geopolitical turmoil.  There’s no time for elegance.  It’s time for the art of the possible.

Give your sales team a reason to talk to customers.  Create something that your salespeople can talk about with customers.  A mildly modified product offering, a new bundling of existing products, a brochure for an upcoming new product, a price reduction, a program to keep prices as they are even though tariffs are hitting you.  Give them a chance to talk about something new so the customers can buy something (old or new).

Think Least Launchable Unit (LLU). Instead of a platform launch that can take years to develop and commercialize, go the other way.  What’s the minimum novelty you can launch? What will take the least work to launch the smallest chunk of new value?  Whatever that is, launch it now.

Take a Frankensteinian approach. Frankenstein’s monster was a mix and match of what the good doctor had scattered about his lab.  The head was too big, but it was the head he had.  And he stitched onto the neck most crudely with the tools he had at his disposal.  The head was too big, but no one could argue that the monster didn’t have a head.  And, yes, the stitching was ugly, but the head remained firmly attached to the neck.  Not many were fans of the monster, but everyone knew he was novel.  And he was certainly something a sales team could talk about with customers.  How can you combine the head from product A with the body of product B?  How can you quickly stitch them together and sell your new monster?

Less-With-Far-Less. You’ve already exhausted the more-with-more design space.  And there’s no time for the technical work to add more.  It’s time for less.  Pull out some functionality and lots of cost.  Make your machines do less and reduce the price.  Simplify your offering and make things easier for your customers.  Removing, eliminating, and simplifying usually comes with little technical risk.  Turning things down is far easier than turning them up.  You’ll be pleasantly surprised how excited your customers will be when you offer them slightly less functionality for far less money.

These are trying times, but they’re not to be wasted. The pressure we’re all under can open us up to do new work in new ways.  Push the envelope. Propose new offerings that are inelegant but take advantage of the new sense of urgency forced.

Be bold and be fast.

Image credit — Geoff Henson

If you try to change what you cannot, your trying will not bring about change. But it will bring about 100% frustration, 100% dissatisfaction, 100% missed expectations, 0% progress, and, maybe, 0% employment.

Here’s a rule: If success demands you must change what you cannot, you will be unsuccessful.

If you try to change something you cannot change but someone else can, you will be unsuccessful unless you ask them for help.  That part is clear.  But here’s the tricky part – unless you know you cannot change it and they can, you won’t know to ask them.

If you know enough to ask the higher power for help and they say no but you try to change it anyway, you will be unsuccessful.  I don’t think that needed to be said, but I thought it important to overcommunicate to keep you safe.

Here’s the money question – How do you know if you can change it?

Here’s another rule: If you want to know if you can change something, ask.

If the knowledgeable people on the project say they cannot change it, believe them.  Make a record of the assessment for future escalation, define the consequences, and rescope the project accordingly.  Next, search the organization (hint – look north) for someone with more authority and ask them if they can grant the authority to change it.  If they say no, document their decision and stick with the rescoped project plan.  If they say yes, document their decision and revert to the original project plan.

If you do one thing tomorrow, ask your project team if success demands they change something they cannot.  I surely hope their answer is no.

Image credit — zczillinger

What would happen if the factory had to support demand that increased one percent per week? Without incremental investment, how many weeks could they meet the ever-increasing demand?  That number is a measure of the system’s flexibility.  More weeks, more flexibility.  And the element of the manufacturing system that gives out first is the constraint.  So, now you know how much demand you can support before there’s a problem and you know what the problem will be.  And if you know the lead time to implement the improvement needed to support the increased demand, in a reverse-scheduling way, you know when to implement the improvement so it comes online when you need it.

What would happen if the factory had to support demand that increased one percent in a week?  How about two percent in a week, five percent, or ten percent?  Without incremental investment, what percentage increase could they support in a single week?  More percent increase, more flexibility.  And the element of the manufacturing system that gives out first is the constraint.  So, now you know how much increased demand you can support in a single week and you know the gating item that will block further increases.  You know now where to clip the increased demand and push the extra demand into the next week.  And you know the investment it would take to support a larger increase in a single week.

These two scenarios can be used to assess and quantify a process of any type.  For example, to understand the flexibility of the new product development process, load it (virtually) with more projects to see where it breaks.  Make a note of what it would take to increase the system’s flexibility and ask yourself if that’s a good investment.  If it is, make that investment.  If it isn’t, don’t.

This simple testing method is especially useful when the investment needed to increase flexibility has a long lead time or is expensive.  If your testing says the system can support five percent more demand before it breaks and you know that demand will hit the system in ten weeks, I hope the lead time to implement the needed improvement is less than ten weeks.  If not, you won’t be able to meet the increased demand.  And I hope the money to make the improvement is already budgeted because a budgeting cycle is certainly longer than ten weeks and you can’t buy what you need if the money isn’t in the budget.

The first question to ask yourself is what is the minimum flexibility of the system that will trigger the next investment to improve throughput and increase flexibility? And the follow-on question: What is needed to improve throughput? What is the lead time for that solution? How much will it cost? Is the money budgeted? And do we have the resources (people) that can implement the improvement when it’s time?

When the cost of not meeting demand is high, the value of this testing process is high. When the lead times for the improvements are long, this testing process has a lot of value because it gives you time to put the improvements in place.

Continuous improvement of process utilization is also a continuous reduction of process flexibility.  This simple testing approach can help identify when process flexibility is becoming dangerously low and give you the much-needed time to put improvements in place before it’s too late.

Image credit — Tambako The Jaguar

When “it’s impossible” it means it “cannot be done.”  But maybe “impossible” means “We don’t yet know how to do it.” Or “We don’t yet know if others have done it before.”

What does it take to transition from impossible to newly possible? What must change to move from the impossible to the newly possible?

Context-Specific Impossibility. When something works in one industry or application but doesn’t work in another, it’s impossible in that new context.  But usually, almost all the elements of the system are possible and there are one or two elements that don’t work due to the new context.  There’s an entire system that’s blocked from possibility due to the interaction between one or two system elements and an environmental element of the new context.  The path to the newly possible is found in those tightly-defined interactions.   Ask yourself these questions: Which system elements don’t work and what about the environment is preventing the migration to the newly possible?  And let the intersection focus your work.

History-Specific Impossibility.  When something didn’t work when you tried it a decade ago, it was impossible back then based on the constraints of the day.  And until those old constraints are revisited, it is still considered impossible today.  Even though there has been a lot of progress over the last decades, if we don’t revisit those constraints we hold onto that old declaration of impossibility.  The newly possible can be realized if we search for new developments that break the old constraints. Ask yourself: Why didn’t it work a decade ago? What are the new developments that could overcome those problems?  Focus your work on that overlap between the old problems and the new developments.

Emotionally-Specific Impossibility. When you believe something is impossible, it’s impossible.  When you believe it’s impossible, you don’t look for solutions that might birth the newly possible.  Here’s a rule: If you don’t look for solutions, you won’t find them. Ask yourself: What are the emotions that block me from believing it could be newly possible? What would I have to believe to pursue the newly possible?  I think the answer is fear, but not the fear of failure.  I think the fear of success is a far likelier suspect. Feel and acknowledge the emotions that block the right work and do the right work.  Feel the fear and do the work.

The newly possible is closer than you think. The constraints that block the newly possible are highly localized and highly context-specific. The history that blocks the newly possible is no longer applicable, and it’s time to unlearn it.  Discover the recent developments that will break the old constraints.  And the emotions that block the newly possible are just that – emotions.  Yes, it feels like the fear will kill you, but it only feels like that.  Bring your emotions with you as you do the right work and generate the newly possible.

image credit – gfpeck

Stop, Start, Continue is a powerful, straightforward way to manage things.

If it’s not working, Stop.

If it’s working well, Continue.

If there’s a big opportunity to grow, Start.

Sounds pretty simple, but it’s often executed poorly.

The most dangerous variant of Stop, Start, Continue is Start, Start, Continue.  Regardless of how well projects are doing, they Continue.  The market has changed but the product hasn’t launched yet, Continue the project.  Though the technical risk is increasing instead of decreasing, keep your mouth shut and Continue the project.  Though resources have moved to different projects (that have recently started), Continue the project and pretend progress is being made.  And though Continue is a big problem, Starting is a bigger one.

With Start, Start, Continue, the company’s eyes are too big for their stomach.  Because there is no mechanism to limit the start of new projects based on the available resources (people, tools, infrastructure), projects start without the resources needed to get them done.  In the short term, there’s a celebration because an important new project has started.  But a month later, everyone on the project team knows the project is doomed because the project is largely unstaffed. And because of the tight lips, no one in company leadership knows there’s a problem.  The telltale signs of Start, Start, Continue are long projects (insufficient resources) and a lack of Finishing (too many projects and too little focus).

There is a little-known process that can overpower Start, Start, Continue.  It’s called Stop, Stop, Stop.  It’s simple and powerful.

With Stop, Stop, Stop, stalled projects are stopped and resources are freed up to accelerate the best remaining projects.  Think of it as moving from Continue existing projects to Accelerate the most important projects.  And with Stop, Stop, Stop, there is no starting.  None.  There is only stopping, at least to start.  Pet projects are stopped. Long-in-the-tooth projects are stopped. Irrelevant projects are stopped.  And even good projects are stopped to allow great projects to Start.

With Stop, Stop, Stop, at least two projects must stop before a new project can start.  And it’s better to stop three.

The result of Stop, Stop, Stop is a glut of freed-up resources that can be applied to amazing new projects.  And because the resources are unallocated and ready to go, those new projects can be fully staffed and can make progress quickly.  And because there are now fewer projects overall, the shared resources can respond more quickly for double acceleration.  And with fewer projects, there are fewer resource collisions among projects and fewer slowdowns. Triple acceleration and a lighter project management burden.

If your projects are moving too slowly, use Stop, Stop, Stop to stop the worst projects.  If you have too many projects and too few resources, Stop, Stop, Stop can set you free.  If you want to Start an amazing new project, use Stop, Stop, Stop to free up the resources to make it happen.

Before you Start, Stop.  And before you Continue, Stop. And instead of pretending to Stop or talking about Stopping, Stop.

When there are too many projects, all the projects move too slowly.

When there are too many projects, adding resources doesn’t help much and may make things worse.

To speed up the important projects, stop the less important projects. There’s no better way.

When there are too many projects, stopping comes before starting.

All projects are important, it’s just that some are more important than others.  Stop the lesser ones.

When someone says all projects are equally important, they don’t understand projects.

If all projects are equally important, then they are also equally unimportant and it does not matter which projects are stopped.  This twist of thinking can help people choose the right projects to stop.

When there are too many projects, stop two before starting another.

Finishing a project is the best way to stop a project, but that takes too long.  Stop projects in their tracks.

There is no partial credit for a project that is 80% complete and blocking other projects.  It’s okay to stop the project so others can finish.

Queueing theory says wait times increase dramatically when utilization of shared resources reaches 85%.  The math says projects should be stopped well before shared resources are fully booked.

If you want to go faster, stop the lesser projects.

Image credit – Rodrigo Olivera

If you want your new product development projects to go faster, reduce the number of active projects.  Full stop.

A rule to live by: If the new product development project is 90% complete, the company gets 0% of the value.  When it comes to new product development projects, there’s no partial credit.

Improving the capabilities of your project managers can help you go faster, but not if you have too many active projects.

If you want to improve the speed of decision-making around the projects, reduce the number of required decisions by reducing the number of active projects.

Resource conflicts increase radically as the number of active projects increases.  To fix this, you guessed it, reduce the number of active projects.

A project that is run under the radar is the worst type of active project. It sucks resources from the official projects and prevents truth telling because no one can admit the dark project exists.

With fewer active projects, resource intensity increases, the work is done faster, and the projects launch sooner.

Shared resources serve the projects better and faster when there are fewer active projects.

If you want to go faster, there’s no question about what you should do.  You should stop the lesser projects to accelerate the most important ones.  Full stop.

And if you want to stop some projects, I suggest you try to answer this question: Why does your company think it’s a good idea to have far too many active new product development projects?

Image credit — JOHN K THORNE