Shipulski On Design

Archive for the ‘Constraints’ Category

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

We get what we measure and, generally, we measure what’s easy to measure and not what will build a bridge to the right behavior.

Timeframe. If we measure people on a daily pitch, we get behavior that is maximized over eight hours.  If a job will take nine hours, it won’t get done because the output metrics would suffer.  It’s like a hundred-meter sprint race where the stopwatch measures output at one hundred meters.  The sprinter spends all her energy sprinting one hundred meters and then collapses.  There’s no credit for running further than one hundred meters, so they don’t.  Have you ever seen a hundred-meter race where someone ran two hundred meters?

Do you want to sprint one hundred meters five days a week?  If so, I hope you only need to run five hundred meters.  Do you want to run twenty-five miles per week?  If so, you should slow down and run five miles per day for five days.  You can check in every day to see if the team needs help and measure their miles on Friday afternoon. And if you want the team to run six miles a day, well, you probably have to allocate some time during the week so they can get stronger, improve their running stride, and do preventative maintenance on their sneakers. For several weeks prior to running six miles a day, you’ve got to restrict their running to four miles a day so they have time to train.  In that way, your measurement timeframe is months, not days.

Over what timeframe do you measure your people? And, how do you feel about that?

Control Volume. If you have a fish tank, that’s the control volume (CV) for the fish.  If you have two fish tanks, you two control volumes – control volume 1 (CV1) and control volume 2 (CV2).  With two control volumes, you can optimize each control volume independently. If tank 1 holds red fish and tank 2 holds blue fish, based on the number of fish in the tanks, you put the right amount of fish food in tank 1 for the red fish and the right amount in tank 2 for the blue fish.  The red fish of CV1 live their lives and make baby fish using the food you put in CV1.  And to measure their progress, you count the number of red fish in CV1 (tank 1). And it’s the same for the blue fish in CV2.

With the two CVs, you can dial in the recipe to grow the most red fish and dial in a different recipe to grow blue fish. But what if you don’t have enough food for both tanks? If you give more food to the blue fish and starve the red fish, the red fish will get angry and make fewer baby fish.  And they will be envious of the blue fish.  And, likely, the blue fish will gloat. When CV1 gets fewer resources than CV2, the fish notice.

But what if you want to make purple fish?  That would require red fish to jump into the blue tank and even more food to shift from CV1 to CV2. Now the red fish in CV1 are really pissed.  And though the red fish moved to tank 2 do their best to make purple guppies with the blue fish, neither color know how to make purple fish.  They were never given the tools, time, and training to do this new work. And instead of making purple guppies, usually, they eat each other.

We measure our teams over short timeframes and then we’re dissatisfied when they can’t run marathons.  It’s time to look inside and decide what you want.  Do you want short-term performance or long-term performance?  And, no, you can’t have both from the same team.

And we measure our teams on the output of their control volumes and yet ask them to cooperate and coordinate across teams.  That doesn’t work because any effort spent to help another control volume comes at the expense of your own.  And the fish know this. And we don’t give them the tools, time, and training to work across control volumes.  And the fish know this, too.

“Purple fish” by The Dress Up Place is licensed under CC BY-SA 2.0