Shipulski On Design

Archive for the ‘Constraints’ Category

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

Companies that are good at planning their projects create roadmaps spanning about three years, where individual projects are sequenced to create a coordinated set of projects that fit with each other.  The roadmap helps everyone know what’s important and helps the resources flow to those most important projects.

Through the planning process, the collection of potential projects is assessed and the best ones are elevated to the product roadmap.  And by best, I mean the projects that will generate the most incremental profit.  The projects on the roadmap generate the profits that underpin the company’s financial plan and the company is fanatically committed to the financial plan. The importance of these projects cannot be overstated.  And what that means is once a project makes it to the roadmap, there’s only one way to get it off the roadmap, and that’s to complete it successfully.

For the next three years, everyone knows what they’ll work on.  And they also know what they won’t work on.

The best companies want to be efficient so they staff their projects in a way that results in high utilization.  The most common way to do this is to load up the roadmap with too many projects and staff the projects with too few people.  The result is a significant fraction of people’s time (sometimes more than 100%) is pre-allocated to the projects on the roadmap.  The efficiency metrics look good and it may actually result in many successful launches.  But the downside of ultra-high utilization of resources is often forgotten.

When all your people are booked for the next three years on high-value projects, they cannot respond to new opportunities as they arise.  When someone comes back from a customer visit and says, “There’s an exciting new opportunity to grow the business significantly!” the best response is “We can’t do that because all our people are committed to the three-year plan.”.  The worst response is “Let’s put together a team to create a project plan and do the project.”.  With the first response, the project doesn’t get done and zero resources are wasted trying to figure out how to do the project without the needed resources.  With the second response, the project doesn’t get done but only after significant resources are wasted trying to figure out how to do the project without the needed resources.

Starting new projects is difficult because everyone is over-booked and over-committed on projects that the company thinks will generate significant (and predictable) profits.  What this means is to start a new project in this high-utilization environment, the new project must displace a project on the three-year plan.  And remember, the projects that must be displaced are the projects the company has chosen to generate the company’s future profits.  So, to become an active project (and make it to the three-year plan) the candidate project must be shown to create more profits, use fewer resources and launch sooner than the projects already on the three-year plan.  And this is taller than a tall order.

So, is there a solution?  Not really, because the only possible solution is to reduce resource utilization to create unallocated resources that can respond to emergent opportunities when they arise.  And that’s not possible because good companies have a deep and unskillful attachment efficiency.

Image credit — Bernard Spragg NZ

There are natural limits to the amount of work that any one person or group can do.  And once that limit is reached, saying yes to more work does not increase the amount of work that gets done.  Sure, you kick the can down the road when you say yes to work that you know you can’t get done, but that’s not helpful.  Expectations are set inappropriately which secures future disappointment and more importantly binds or blocks other resources. When preparatory work is done for something that was never going to happen, that prep work is pure waste.  And when resources are allocated to a future project that was never going to happen, the results are misalignment, mistiming, and replanning, and opportunity cost carries the day.

But how to know if you the team has what it takes to get the work done?  The answer is a capacity model.  There are many types of capacity models, but they all require a list of the available resources (people, tools, machines), the list of work to be done (projects), and the amount of time (in hours, weeks, months) each project requires for each resource.  The best place to start is to create a simple spreadsheet where the leftmost column lists the names of the people and the resources (e.g., labs, machines, computers, tools).  Across the top row of the spreadsheet enter the names of the projects.  For the first project, go down the list of people and resources,  and for each person/resource required for the project, type an X in the column.  Repeat the process for the remainder of the projects.

While this spreadsheet is not a formal capacity model, as it does not capture the number of hours each project requires from the resources, it’s plenty good enough to help you understand if you have a problem.  If a person has only one X in their row, only one project requires their time and they can work full-time on that project for the whole year.  If another person has sixteen Xs in their row, that’s a big problem. If a machine has no Xs in its row, no projects require that machine, and its capacity can be allocated to other projects across the company. And if a machine has twenty Xs in its row, that’s a big problem.

This simple spreadsheet gives a one-page, visual description of the team’s capacity.  Held at arm’s length, the patterns made by the Xs tell the whole story.

To take this spreadsheet to the next level, the Xs can be replaced with numbers that represent the number of weeks each project requires from the people and resources.  Sit down with each person and for each X in their row, ask them how many weeks each project will consume.  For example, if they are supposed to support three projects, X1 is replaced with 15 (weeks), X2 is replaced with 5, and X3 is replaced with 5 for a total of 25 weeks (15 + 5 + 5).  This means the person’s capacity is about 50% consumed (25 weeks / 50 weeks per year) by the three projects.  For each resource, ask the resource owner how much time each project requires from the resource.  For a machine that is needed for ten projects where each project requires twenty weeks, the machine does not have enough capacity to support the projects.  The calculation says the project load requires 200 machine-weeks (10*20 = 200 weeks) and four machines (200 machine-weeks / 50 weeks per year = 4 machines) are required.

Creating a spreadsheet that lists all the projects is helpful in its own right.  And you’ll probably learn that there are far more projects than anyone realizes.  (Helpful hint: make sure you ask three times if all the projects are listed on the spreadsheet.)  And asking people how much time is required for each project is respectful of their knowledge and skillful because they know best how long the work will take. They’ll feel good about all that.  And quantifying the number of weeks (or hours) each project requires elevates the discussion from argument to analysis.

With this simple capacity model, the team can communicate clearly which projects can be supported and which cannot.  And, where there’s a shortfall, the team can make a list of the additional resources that would be needed to support the full project load.

Fight the natural urge to overcomplicate the first version of the capacity model.  Start with a simple project-people/resource spreadsheet and use the Xs.  And use the conversations to figure out how to improve it for next time.

When you have no slack time, you can’t start new projects.

When you have no slack time, you can’t run toward the projects that need your help.

When you have no slack time, you have no time to think.

When you have no slack time, you have no time to learn.

When you have no slack time, there’s no time for concern for others.

When you have no slack time, there’s no time for your best judgment.

When there is no slack time, what used to be personal becomes transactional.

When there is no slack time, any hiccup creates project slip.

When you have no slack time, the critical path will find you.

When no one has slack time, one project’s slip ripples delay into all the others.

When you have no slack time, excitement withers.

When you have no slack time, imagination dies.

When you have no slack time, engagement suffers.

When you have no slack time, burnout will find you.

When you have no slack time, work sucks.

When you have no slack time, people leave.

I have one question for you.  How much slack time do you have?

“Hurry up Leonie, we are late…” by The Preiser Project is licensed under CC BY 2.0

Your core business, the long-standing business that has made you what you are, is both your greatest strength and your greatest weakness.

The Core generates the revenue, but it also starves fledgling businesses so they never make it off the ground.

There’s a certainty with the Core because it builds on success, but its success sets the certainty threshold too high for new businesses.  And due to the relatively high level of uncertainty of the new business (as compared to the Core) the company can’t find the gumption to make the critical investments needed to reach orbit.

The Core has generated profits over the decades and those profits have been used to create the critical infrastructure that makes its success easier to achieve.  The internal startup can’t use the Core’s infrastructure because the Core doesn’t share.  And the Core has the power to block all others from taking advantage of the infrastructure it created.

The Core has grown revenue year-on-year and has used that revenue to build out specialized support teams that keep the flywheel moving.  And because the Core paid for and shaped the teams, their support fits the Core like a glove.  A new offering with a new value proposition and new business model cannot use the specialized support teams effectively because the new offering needs otherly-specialized support and because the Core doesn’t share.

The Core pays the bills, and new ventures create bills that the Core doesn’t like to pay.

If the internal startup has to compete with the Core for funding, the internal startup will fail.

If the new venture has to generate profits similar to the Core, the venture will be a misadventure.

If the new offering has to compete with the Core for sales and marketing support, don’t bother.

If the fledgling business’s metrics are assessed like the Core’s metrics, it won’t fly, it will flounder.

If you try to run a new business from within the Core, the Core will eat it.

To work effectively with the Core, borrow its resources, forget how it does the work, and run away.

To protect your new ventures from the Core, physically separate them from the Core.

To protect your new businesses from the Core, create a separate budget that the Core cannot reach.

To protect your internal startup from the Core, make sure it needs nothing from the Core.

To accelerate the growth of the fledgling business, make it safe to violate the Core’s first principles.

To bolster the capability of your new business, move resources from the Core to the new business.

To de-risk the internal startup, move functional support resources from the Core to the startup.

To fund your new ventures, tax the Core.  It’s the only way.

“Core Memory” by JD Hancock is licensed under CC BY 2.0