Shipulski On Design

Posts Tagged ‘Competitiveness’

The projects you choose define the problems you solve.

The problems you choose to solve define the novel value delivered to the customer.

The people you choose to run the projects set the character of the projects.

The choice of the projects’ character defines how the people feel about working on the projects.

How people choose to feel about working on the projects influences the character of the projects.

The people on the projects choose how the problems are solved.

How people choose to solve problems defines how well the problems are solved.

The choice around how well problems are solved sets the level of goodness delivered to the customer.

The level of goodness you choose to deliver to the customer governs the incremental revenue you create.

It doesn’t seem right that the amount of incremental revenue is a choice.

But, when you choose the right projects and the right people to run them and you choose the right problems and the right people to solve them, incremental revenue becomes your choice.

image credit — officallychaz

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

X: Of the pool of candidate new product development projects, which project should we do first?

Me: Let’s do the one that makes us the most money.

X: Which project will make the most money?

Me: The one where the most customers buy the new product, pay a reasonable price, and feel good doing it.

X: And which one is that?

Me: The one that solves the most significant problem.

X: Oh, I know our company’s most significant problem.  Let’s solve that one.

Me: No. Customers don’t care about our problems, they only care about their problems.

X: So, you’re saying we should solve the customers’ problem?

Me: Yes.

X: Are you sure?

Me: Yes.

X: We haven’t done that in the past. Why should we do it now?

Me: Have your previous projects generated revenue that met your expectations?

X: No, they’ve delivered less than we hoped.

Me: Well, that’s because there’s no place for hope in this game.

X: What do you mean?

Me: You can’t hope they’ll buy it.  You need to know the customers’ problems and solve them.

X: Are you always like this?

Me: Only when it comes to customers and their problems.

image credit: Kyle Pearce

What does work look like when you prioritize your happiness?

When it’s announced that open positions will not be backfilled to meet the practical realities of a recession, you reduce the scope of your projects and push out their completion dates to match the reduction in resources. And the impact on your career?  I don’t know, but the people that work for you and everyone else that knows how the work is done will move mountains for you.

Under the banner of standard work, you are given the same task as the one you just completed.  Sure, you can do it efficiently and effectively, but if you do that same work one more time, your brain will fall off.  So, instead of doing it yourself, you give the work to a lesser-experienced person who is worthy of investment and help them get the work done.  They get to learn new skills and the work is done well because you keep them on the straight and narrow. And you get to be a teacher and create a future leader that the company will need in a couple of years.  And the downside?  The work takes a little longer, but so what.

What does work look like when you prioritize your health?

When an extra-early meeting is scheduled because everyone’s regular day is already fully booked with meetings, you decline the meeting so you can get the recommended amount of sleep recommended by the health professionals.  And the negative consequences to your career progression?  Well, that’s a choice for your company.

When you get home from work, you disconnect your phone from the company network so you won’t be distracted by work-related interruptions.  Because you separated yourself from work, after dinner is cleaned up you can make a healthy lunch for tomorrow.  If there’s some downside risk to your career, find another company to work for.

What does work look like when you prioritize your family?

When an extra-late meeting is scheduled because everyone’s regular day is already fully booked with meetings, you decline the meeting so you can cook dinner and eat with your family.  The conversation with the kids is mundane and meaningful and ten years from now they’ll be better for it. And the negative consequences?  None, because tomorrow morning you can read the minutes of the meeting.

When you’re on your yearly holiday with your family and your boss calls your cell phone to ask you to come back to work early to deal with an emergency, you don’t answer the call and let it go to voicemail.  Then, when you get back to the office after vacation, you listen to the voicemail and check in with your boss.  And because you didn’t pick up the call, someone else had greatness thrust upon them and developed into someone who can solve emergencies.  Now there are two of you.  And the downside?  Well, I think that depends on your boss.

“Looking For Clues (188 / 365)” by somegeekintn is licensed under CC BY 2.0.

Breaking up work into small chunks can be a good way to get things started.  Because the scope of each chunk is small, the cost of each chunk is small making it easier to get approval to do the work.  The chunk approach also reduces anxiety around the work because if nothing comes from the chunk, it’s not a big deal because the cost of the work is so low.  It’s a good way to get started, and it’s a good way to do a series of small chunks that build on each other.  But what happens when the chunks are successful and it’s time to scale up the investment by a factor of several hundred thousand or a million?

The scaling scenario.  When the early work (the chunks) was defined an agreement in principle was created that said the larger investment would be made in a timely way if the small chunks demonstrated the viability of a whole new offering for your customers.  The result of this scenario is a large investment is allocated quickly, resources flow quickly, and the scaling work begins soon after the last chunk is finished. This is the least likely scenario.

The more chunks scenario. When the chunks were defined, everyone was excited that the novel work had actually started and there was no real thought about the resources required to scale it into something meaningful and material.  Since the resources needed to scale were not budgeted, the only option to keep things going is to break up the work into another series of small chunks.  Though the organization sees this as progress, it’s not.  The only thing that can deliver the payout the organization needs is to scale up the work.  The follow-on chunks distract the company and let it think there is progress, when, really, there is only delayed scaling.

The scale next year scenario.  When the chunks were defined, no one thought about scaling so there was no money in the budget to scale.  A plan and cost estimate are created for the scaling work and the package waits to be assessed as part of the annual planning process.  And as the waiting happens, the people that did the early work (the chunks) move on to other projects and are not available to do the scaling work even if the work gets funded next year.  And because the work is new it requires new infrastructure, new resources, new teams, new thinking, and maybe a new company.  All this newness makes the price tag significant and it may require more than one annual planning cycle to justify the expense and start the work.

Scaling a new invention into a full-sized business is difficult and expensive, but if you’re looking to create radical growth, scaling is the easiest and least expensive way to go.

“100 Dollar Bills” by Philip Taylor PT is licensed under CC BY-SA 2.0.

Before you decide which project to start, decide which project you’ll stop.

The best way to stop a project is to finish it.  The next best way is to move the resources to a more important project.

If you find yourself starting before finishing, stop starting and start finishing.

People’s output is finite. Adding a project that violates their human capacity will not result in more completed projects but will cause your best people to leave.

If people’s calendars are full, the only way to start something new is to stop something old.

If you start more projects than you finish, you’re stopping projects before they’re finished.  You’re probably not stopping them in an official way, rather, you’re letting them wither and die a slow death.  But you’re definitely stopping them.

When you start more projects than you finish, the number of active projects increases.  And without a corresponding increase in resources, fewer projects are completed.

The best way to reduce the number of projects you finish is to start new projects.

Make a list of the projects that you stopped over the last year.  Is it a short list?

Make a list of projects that are understaffed and under-resourced yet still running in the background.  Is that list longer?

A rule to live by: If a project is understaffed, staff it or stop it.

If you can’t do that, reduce the scope to fit the resources or stop it.

Would you prefer to complete one project at a time or do three simultaneously and complete none?

When it comes to stopping projects, it’s stopped or it isn’t.  There’s no partial credit for talking about stopping a project.

If you want to learn if a project is worthy of more resources, stop the project.  If the needed resources flow to the project, the project is worthy.  If not, at least you stopped a project that shouldn’t have been started.

People don’t like working on projects where the work content is greater than the resources to do the work.  These projects are a major source of burnout.

If you know you have too many projects, everyone else knows it too.  Stop the weakest projects or your credibility will suffer.

“Circus Renz Berlin, Holland 2011” by dirkjanranzijn is licensed under CC BY-ND 2.0.

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.

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.

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

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.

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.