Posts Tagged ‘Competitiveness’

It’s good to have experience, until the fundamentals change.

We use our previous experiences as context for decisions we make in the present.  When we have a bad experience, the experience-context pair gets stored away in our memory so that we can avoid a similar bad outcome when a similar context arises.  And when we have a good experience, or we’re successful, that memory-context pair gets stored away for future reuse. This reuse approach saves time and energy and, most of the time keeps us safe.  It’s nature’s way of helping us do more of what works and less of what doesn’t.

The system works well when we correctly match the historical context with today’s context and the system’s fundamentals remain unchanged.  There are two potential failure modes here.  The first is when we mistakenly map the context of today’s situation with a memory-context pair that does not apply.  With this, we misapply our experience-based knowledge in a context that demands different knowledge and different decisions.  The second (and more dangerous) failure mode is when we correctly identify the match between past and current contexts but the rules that underpin the context have changed.  Here, we feel good that we know how things will turn out, and, at the same time, we’re oblivious to the reality that our experience-based knowledge is out of date.

“If a cat sits on a hot stove, that cat won’t sit on a hot stove again. That cat won’t sit on a cold stove either. That cat just don’t like stoves.”  Mark Twain

If you tried something ten years ago and it failed, it’s possible that the underpinning technology has changed and it’s time to give it another try.

If you’ve been successful doing the same thing over the last ten years, it’s possible that the underpinning business model has changed and it’s time to give a different one a try.

Hissing cat” by Consumerist Dot Com is licensed under CC BY 2.0.

Is your project too big, too small, or both?

When choosing projects there are two competing questions: Is it big enough? And, is it small enough? The project must be big enough to generate the profits required by the company’s growth objectives.  Larger growth objectives require larger projects.  Yet the project has to be small enough to be completed within the time constraints defined by the growth objectives.  Tighter time constraints require smaller projects.

When the projected revenue generated by the candidate project is less than what’s needed to meet the growth objectives, the project is deemed “not big enough.”  But what if the candidate project is the largest project that the project team can imagine? Does that say something about the project team’s imagination or the growth objectives?  Open question: How do tell the difference between a project that is too small to meet the growth objectives and growth objectives that demand projects larger than the project team’s imagination?

When the projected launch date of the candidate project is later than the date of first revenue defined in the growth plan, the project plan is deemed “too long.”  The team is then asked to sharpen their pencils and return with a launch date that meets the revenue timeline.  And when the revised schedule also violates the revenue timeline, the project is deemed “too big.” Open question: How do you tell the difference between a project that is too big to meet the revenue timeline and a revenue timeline that is too stringent to allow a project of sufficient size?

Theoretically, there are candidate projects that are big enough to meet the growth objectives and small enough that their launch dates meet revenue timelines.  But in practice, candidate projects are either too small to meet growth objectives or too large to meet revenue timelines.  And, yes, I have seen candidate projects that are both too small and too large.  But this says more about the growth objectives, revenue timelines, and the number of projects that run concurrently (too few resources spread over too many projects).

Growth objectives are good, and so are projects that fit with the team’s capabilities to deliver.  Incremental revenue that comes sooner rather than later is good.  And so are project timelines that are governed by the work content, resources applied to the projects, and good product development practices.

Truth is, we need it all – projects that deliver the sizzle that sells and projects that launch sooner rather than later.  And year-on-year, we need to get better at delivering on all of it.  And the best way I know to do all that is to ritualistically invest in the people that do the work and the tools they use.

Horse Yin and Yang” by onecog2many is licensed under CC BY 2.0.

The best time to design cost out of our products is now.

With inflation on the rise and sales on the decline, the time to reduce costs is now.

But before you can design out the cost you’ve got to know where it is.  And the best way to do that is to create a Pareto chart that defines product cost for each subassembly, with the highest cost subassemblies on the left and the lowest cost on the right.  Here’s a pro tip – Ignore the subassemblies on the right.

Use your costed Bill of Materials (BOMs) to create the Paretos.  You’ll be told that the BOMs are wrong (and they are), but they are right enough to learn where the cost is.

For each of the highest-cost subassemblies, create a lower-level Pareto chat that sorts the cost of each piece-part from highest to lowest.  The pro tip applies here, too – Ignore the parts on the right.

Because the design community designed in the cost, they are the ones who must design it out.  And to help them prioritize the work, they should be the ones who create the Pareto charts from the BOMs.  They won’t like this idea, but tell them they are the only ones who can secure the company’s future profits and buy them lots of pizza.

And when someone demands you reduce labor costs, don’t fall for it.  Labor cost is about 5% of the product cost, so reducing it by half doesn’t get you much.  Instead, make a Pareto chart of part count by subassembly.  Focus the design effort on reducing the part count of subassemblies on the left.  Pro tip – Ignore the subassemblies on the right.  The labor time to assemble parts that you design out is zero, so when demand returns, you’ll be able to pump out more products without growing the footprint of the factory.  But, more importantly, the cost of the parts you design out is also zero.  Designing out the parts is the best way to reduce product costs.

Pro tip – Set a cost reduction goal of 35%.  And when they complain, increase it to 40%.

In parallel to the design work to reduce part count and costs, design the test fixtures and test protocols you’ll use to make sure the new, lower-cost design outperforms the existing design.  Certainly, with fewer parts, the new one will be more reliable.  Pro tip – As soon as you can, test the existing design using the new protocols because the only way to know if the new one is better is to measure it against the test results of the old one.

And here’s the last pro tip – Start now.

Image credit — aisletwentytwo

Small Teams are Mighty

When you want new thinking or rapid progress, create a small team.

When you have a small team, they manage the handoffs on their own and help each other.

Small teams hold themselves accountable.

With small teams, one member’s problem becomes everyone’s problem in record time.

Small teams can’t work on more than one project at a time because it’s a small team.

And when a small team works on a single project, progress is rapid.

Small teams use their judgment because they have to.

The judgment of small teams is good because they use it often.

On small teams, team members are loyal to each other and set clear expectations.

Small teams coordinate and phase the work as needed.

With small teams, waiting is reduced because the team members see it immediately.

When something breaks, small teams fix it quickly because the breakage is apparent to all.

The tight connections of a small team are magic.

Small teams are fun.

Small teams are effective.

And small teams are powered by trust.

 

LEGO Octan pit crew celebrating High Five Day (held every third Thursday of April)” by Pest15 is marked with CC BY-SA 2.0.

Things I Sometimes Forget

Clean-sheet designs are fun, right up until they don’t launch.

When you feel the urge to do a clean-sheet design, go home early.

When you don’t know how to make it better, make it worse and do the opposite.

Without trying, there is no way to know if it will work.

Trying sometimes feels like dying.

But without trying, nothing changes.

Agreement is important, but only after the critical decision has been made.

When there’s 100% agreement, you waited too long to make the decision.

When it’s unclear who the customer is, ask “Whose problem will be solved?”

When the value proposition is unclear, ask ‘What problem will be solved?”

When your technology becomes mature, no one wants to believe it.

When everyone believes the technology is mature, you should have started working on the new technology four years ago.

If your projects are slow, blame your decision-making processes.

Two of the most important decisions: which projects to start and which to stop.

All the action happens at the interfaces, but that’s also where two spans of control come together and chafe.

If you want to understand your silos and why they don’t play nicely together, look at the organizational chart.

When a company starts up, the product sets the organizational structure.

Then, once a company is mature, the organizational structure constrains the product.

At the early stages of a project, there’s a lot of uncertainty.

And once the project is complete, there’s a lot of uncertainty.

Toys Never Forget” by Alyssa L. Miller is marked with CC BY 2.0.

Why are people leaving your company?

People don’t leave a company because they feel appreciated.

People don’t leave a company because they feel part of something bigger than themselves.

People don’t leave a company because they see a huge financial upside if they stay.

People don’t leave a company because they are treated with kindness and respect.

People don’t leave a company because they can make less money elsewhere.

People don’t leave a company because they see good career growth in their future.

People don’t leave a company because they know all the key players and know how to get things done.

People don’t leave the company so they can abandon their primary care physician.

People don’t leave a company because their career path is paved with gold.

People don’t leave a company because they are highly engaged in their work.

People don’t leave a company because they want to uproot their kids and start them in a new school.

People don’t leave a company because their boss treats them too well.

People don’t leave a company because their work is meaningful.

People don’t leave a company because their coworkers treat them with respect.

People don’t leave a company because they want to pay the commission on a real estate transaction.

People don’t leave a company because they’ve spent a decade building a Trust Network.

People don’t leave a company because they want their kids to learn to trust a new dentist.

People don’t leave a company because they have a flexible work arrangement.

People don’t leave a company because they feel safe on the job.

People don’t leave a company because they are trusted to use their judgment.

People don’t leave the company because they want the joy that comes from rolling over their 401k.

People don’t leave a company when they have the tools and resources to get the work done.

People don’t leave a company when their workload is in line with their capacity to get it done.

People don’t leave a company when they feel valued.

People don’t leave a company so they can learn a whole new medical benefits plan.

People don’t leave a job because they get to do the work the way they think it should be done.

So, I ask you, why are people leaving your company?

“Penguins on Parade” by D-Stanley is licensed under

Stop reusing old ideas and start solving new problems.

Creating new ideas is easy.  Sit down, quiet your mind, and create a list of five new ideas.  There.  You’ve done it.  Five new ideas.  It didn’t take you a long time to create them.  But ideas are cheap.

Converting ideas into sellable products and selling them is difficult and expensive. A customer wants to buy the new product when the underlying idea that powers the new product solves an important problem for them.  In that way, ideas whose solutions don’t solve important problems aren’t good ideas.  And in order to convert a good idea into a winning product, dirt, rocks, and sticks (natural resources) must be converted into parts and those parts must be assembled into products.  That is expensive and time-consuming and requires a factory, tools, and people that know how to make things. And then the people that know how to sell things must apply their trade.  This, too, adds to the difficulty and expense of converting ideas into winning products.

The only thing more expensive than converting new ideas into winning products is reusing your tired, old ideas until your offerings run out of sizzle. While you extend and defend, your competitors convert new ideas into new value propositions that bring shame to your offering and your brand.  (To be clear, most extend-and-defend programs are actually defend-and-defend programs.)  And while you reuse/leverage your long-in-the-tooth ideas, start-ups create whole new technologies from scratch (new ideas on a grand scale) and pull the rug out from under you.  The trouble is that the ultra-high cost of extend-and-defend is invisible in the short term. In fact, when coupled with reuse, it’s highly profitable in the moment.  It takes years for the wheels to fall off the extend-and-defend bus, but make no mistake, the wheels fall off.

When you find the urge to create a laundry list of new ideas, don’t.  Instead, solve new problems for your customers.  And when you feel the immense pressure to extend and defend, don’t.  Instead, solve new problems for your customers.

And when all that gets old, repeat as needed.

“Cave paintings” by allspice1 is licensed under CC BY-ND 2.0

Supply chains don’t have to break.

We’ve heard a lot about long supply chains that have broken down, parts shortages, and long lead times.  Granted, supply chains have been stressed, but we’ve designed out any sort of resiliency.  Our supply chains are inflexible, our products are intolerant to variation and multiple sources for parts, and our organizations have lost the ability to quickly and effectively redesign the product and the parts to address issues when they arise. We’ve pushed too hard on traditional costing and have not placed any value on flexibility.  And we’ve pushed too hard on efficiency and outsourced our design capability so we can no longer design our way out of problems.

Our supply chains are inflexible because that’s how we designed them.  The products cannot handle parts from multiple suppliers because that’s how we designed them.  And the parts cannot be made by multiple suppliers because that’s how we designed them.

Now for the upside.  If we want a robust supply chain, we can design the product and the parts in a way that makes a robust supply chain possible. If we want the flexibility to use multiple suppliers, we can design the product and parts in a way that makes it possible.  And if we want the capability to change the product to adapt to unforeseen changes, we can design our design organizations to make it possible.

There are established tools and methods to help the design community design products in a way that creates flexibility in the supply chain.  And those same tools and methods can also help the design community create products that can be made with parts from multiple suppliers.  And there are teachers who can help rebuild the design community’s muscles so they can change the product in ways to address unforeseen problems with parts and suppliers.

How much did it cost you when your supply chain dried up? How much did it cost you the last time a supplier couldn’t deliver your parts? How much did it cost you when your design community couldn’t redesign the product to keep the assembly line running? Would you believe me if I told you that all those costs are a result of choices you made about how to design your supply chain, your product, your parts, and your engineering community?

And would you believe me if I told you could make all that go away?  Well, even if you don’t believe me, the potential upside of making it go away is so significant you may want to look into it anyway.

Image credit — New Manufacturing Challenge, Suzaki, 1987.

What do you like to do?

I like to help people turn complex situations into several important learning objectives.

I like to help people turn important learning objectives into tight project plans.

I like to help people distill project plans into a single-page spreadsheet of who does what and when.

I like to help people start with problem definition.

I like to help people stick with problem definition until the problems solve themselves.

I like to help people structure tight project plans based on resource constraints.

I like to help people create objective measures of success to monitor the projects as they go.

I like to help people believe they can do the almost impossible.

I like to help people stand three inches taller after they pull off the unimaginable.

I like to help people stop good projects so they can start amazing ones.

If you want to do more of what you like and less of what you don’t, stop a bad project to start a good one.

So, what do you like to do?

Image credit — merec0

Three Things for the New Year

Next year will be different, but we don’t know how it will be different. All we know is that it will be different.

Some things will be the same and some will be different.  The trouble is that we won’t know which is which until we do.  We can speculate on how it will be different, but the Universe doesn’t care about our speculation.  Sure, it can be helpful to think about how things may go, but as long as we hold on to the may-ness of our speculations.  And we don’t know when we’ll know. We’ll know when we know, but no sooner. Even when the Operating Plan declares the hardest of hard dates, the Universe sets the learning schedule on its own terms, and it doesn’t care about our arbitrary timelines.

What to do?

Step 1. Try three new things. Choose things that are interesting and try them.  Try to try them in parallel as they may interact and inform each other. Before you start, define what success looks like and what you’ll do if they’re successful and if they’re not.  Defining the follow-on actions will help you keep the scope small.  For things that work out, you’ll struggle to allocate resources for the next stages, so start small.  And if things don’t work out, you’ll want to say that the projects consumed little resources and learned a lot.  Keep things small.  And if that doesn’t work, keep them smaller.

Step 2. Rinse and repeat.

I wish you a happy and safe New Year.  And thanks for reading.

Mike

“three” by Travelways.com is licensed under CC BY 2.0

When you decide you have enough, the right work WILL happen.

If you are happy with what you have, others have no power over you.

If you don’t want more, you call the shots.

If you have nothing to prove, no one can manipulate you.

If you have enough, the lure of more cannot pull you off the path of what you think is right.

If you don’t need approval from others, you can do what you think is right.

If you know what’s important to you, you can choose the path forward.

If you know who you are, so does everyone else.

If you know who you are, you don’t care what others think of you.

When you don’t care about what others think about you, you can do the right work.

When you can do the right work in the right way, you are impervious to influence.

When you are impervious to influence, the right work happens, despite the displeasure of the Status Quo.

 Anne Ruthmann is licensed under CC BY-NC-ND 2.0

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives