Shipulski On Design

Archive for the ‘Fundementals’ Category

Efficient – How do we do more projects with fewer people?

Effective – Let’s choose the right project.

Would you rather do more projects that miss the mark or fewer that excite the customer?

Efficient – How do we finish the project faster?

Effective – Let’s fully staff the project.

Would you rather burn out the project team or deliver on what the customer wants?

Efficient – How do we reduce product cost by 5%?

Effective – Let’s make customers’ lives easier.

Would you rather reduce the cost or delight the customer?

Efficient – How can we go faster?

Effective – Let’s get it right.

Would you rather go fast and break things or get it right for the customer?

Efficient – How many projects can we run in parallel?

Effective – Let’s fully staff the most important projects.

Would you rather get halfway through four projects or complete two?

Efficient – How do we make progress on as many tasks as possible?

Effective – Let’s work on the critical path.

Would you rather work on things that don’t matter or nail the things that do?

Efficient – How can we complete the most tasks?

Effective – Let’s work on the hardest thing first.

Would you rather learn the whole thing won’t work before or after you waste time on the irrelevant?

If there’s a choice between efficiency and effectiveness, I choose effectiveness.

Image credit — Antarctica Bound

At the start, it’s impossible to know the right thing to do, other than the right thing is to start.

If you think you should have started, but have not, the only thing in the way is you.

If you want to start, get out of your own way, and start.

And even if you’re not in the way, there’s no harm in declaring you ARE in the way and starting.

If you’re afraid, be afraid. And start.

If you’re not afraid, don’t be afraid.  And start.

If you can’t choose among the options, all options are equally good.  Choose one, and start.

If you’re worried the first thing won’t work, stop worrying, start starting, and find out.

Before starting, you don’t have to know the second thing to do.  You only have to choose the first thing to do.

The first thing you do will not be perfect, but that’s the only path to the second thing that’s a little less not perfect.

The second thing is defined by the outcome of the first. Start the first to inform the second.

If you don’t have the bandwidth to start a good project, stop a bad one.  Then, start.

If you stop more you can start more.

Starting small is a great way to start.  And if you can’t do that, start smaller.

If you don’t start, you can never finish. That’s why starting is so important.

In the end, starting starts with starting.  This is The Way.

Image credit — Claudio Marinangeli

It’s fine if you’re asked to do too much occasionally.  Things come up and must be addressed.  Sometimes it’s your turn and sometimes it’s others’ turn.  No one can argue with that.  And sometimes the work demands your special skills and you go the extra because the work is important and urgent.  You know how to do it and there’s no time to bring someone else up to speed.  That makes sense to everyone.  We all know sometimes is our turn to take on too much.  That’s just how it is.  But it’s not sustainable (or fair) when doing too much once in a while becomes insufficient and you’re expected to do too much all the time.  But this creates a problem.

You want to grow in your career and you want to get ahead.  That’s good.  But when “too much every day” becomes the norm, your desire to climb the ladder makes it difficult to say no to “too much every day.”  Say yes to too much and you’ll earn your stripes.  Say no and your career plateaus. What to do?

I think the only way to beat this double bind is to be happy with your current role, be satisfied with your strong efforts to make meaningful (and reasonable) contributions, and continually grow and develop. I think this recipe will lead to great work and I think doing great work is the best way to battle the double bind.

And when it comes to great work, you are responsible for doing great work and your company is responsible for how they respond.  If you hold onto that, your next steps will be clear.

When you do great work and your company doesn’t notice, their response sends a strong message.  And your next step – do more great work.  Their response will change or you will change companies.

When you do great work, your work gets noticed, and all your company gives you is more work, their response sends a strong message.  And your next step – do more great work but constrain your output to a reasonable level.  Their response will change or you will change companies.

If you do great work, your work gets noticed, and you get a raise, a promotion, a bigger team, responsibility for the most important projects, and the authority to get it all done, your company’s response makes it easy for you to do more great work for them.  And that’s just what you should do.

Keep it simple – when in doubt, do great work.

Image credit — _Veit_

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

When you catch someone doing good work, do you praise them?  If not, why not?

Praise is best when it’s specific – “I think it was great when you [insert specific action here].”

If praise isn’t authentic, it’s not praise.

When you praise specific behavior, you get more of that great behavior.  Is there a downside here?

As soon as you see praise-worthy behavior, call it by name. Praise best served warm.

Praise the big stuff in a big way.

Praise is especially powerful when delivered in public.

If praise feels good when you get it, why not help someone else feel good and give it?

If you make a special phone call to deliver praise, that’s a big deal.

If you deliver praise that’s inauthentic, don’t.

Praise the small stuff in a small way.

Outsized praise doesn’t hit the mark like the real deal.

There can be too much praise, but why not take that risk?

If praise was free to give, would you give it?  Oh, wait.  Praise is free to give.  So why don’t you give it?

Praise is powerful, but only if you give it.

Image credit — Llima Orosa

In business, we have vision statements, mission statements, strategic plans, strategic initiatives, and operating plans. And every day there are there are countless decisions to make. But, in the end, it all comes down to one thing – how we allocate our resources.  Whether it’s hiring people, training them, buying capital, or funding projects, all strategic decisions come back to resource allocation.  Said more strongly, resource allocation is strategy.

Take a look back at last year.  Where did you allocate your capital dollars?  Which teams got it and which did not?  Your capital allocation defined your priorities.  The most important businesses got more capital.  More to the point – the allocated capital defined their importance. Which projects were fully staffed and fully budgeted? Those that were resourced more heavily were more important to your strategy, which is why they were resourced that way. Which businesses hired people and which did not?  The hiring occurred where it fulfilled the strategy. Which teams received most of the training budget?  Those teams were strategically important.  Prioritization in the form of resource allocation.

Repeat the process for this year’s operating plan.  Where is the capital allocated?  Where is the hiring allocated?  Where are the projects fully staffed and budgeted?  Regardless of the mission statements, this year’s strategy is defined by where the resources are allocated.  Full stop.

Repeat the process for your forward-looking strategic plans.  Where are the resources allocated?  Which teams get more?  Which get fewer?  Answer these questions and you’ll have an operational definition of your company’s forward-looking strategy.

To know if the new strategy is different from the old one, look at the budgets.  Do they show a change in resource allocation?  Will old projects stop so new ones can start? Do the new projects serve new customers and new value propositions?  Same old projects, same old customers, same old value propositions, same old strategy.

To determine if there’s a new strategy, look for changes in capital allocation.  If the same teams are allocated more of the same capital, it’s likely the strategy is also the same. Will one team get more capital while the others get less?  Well, it’s likely a new strategy is starting to take shape.

Look for a change in hiring.  Fewer hires like last year and more of a new flavor probably indicate a change in strategy.  And if people flow from one team to another, that’s the same as one team getting new hires and the other team losing them.  That type of change in resource allocation is an indicator of a strategic change.

If the resource allocation differs from the strategic plan, believe the resource allocation. And if the resource allocation is the same as last year, so is the strategy.  And if there is talk of changing resource allocation but no actual change, then there is no change in strategy.

Image credit – Scouse Smurf

If you didn’t get what you wanted, why not try wanting what you got?

If the timing isn’t right, what can you change so it is right?

If it could get you in trouble, might you be on to something?

If it’s impossible, don’t bother.

If it’s easy, let someone else do it.

If there’s no possibility of bad things, there’s no possibility of magic.

If you need trust but have not yet secured it, declare failure and do something else.

If there is no progress, don’t push.  Move the blocking agent out of the way.

If you don’t know where the cost is, you can’t design it out.

If the timing isn’t right, why didn’t you do it sooner?

If the project went flawlessly, you didn’t try to do anything meaningful.

If you know some people won’t like it, isn’t that reason enough to do it?

If it’s almost impossible, give it a go.

If it’s easy, teach someone else to do it.

If you don’t know where the waste is, you can’t get rid of it.

If you don’t need trust, it’s the perfect time to build it.

If you try the hardest thing first and it doesn’t work, at least you avoid wasting time on the easy stuff.

If you don’t know the number of parts in your product, you have too many.

If the product came out perfectly, you took too long.

If you don’t give it a go, how can you know it’s impossible?

If trust is in short supply, supply it.

If it’s easy, do something else.

If forgiveness is so much better than permission, why do we like to do things under the radar?

If bad things didn’t happen, try harder next time.

Image credit — Gabriel Caparó

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

Praise is powerful, but not when you don’t give it.

People learn from mistakes, but not when they don’t make them.

Wonderful solutions are wonderful, but not if there are no problems.

Novelty is good, but not if you do what you did last time.

Disagreement creates deeper understanding, but not if there’s 100% agreement.

Consensus is safe, but not when it’s time for original thought.

Progress is made through decisions, but not if you don’t make them.

It’s skillful to constrain the design space, but not if it doesn’t contain the solution.

Trust is powerful, but not before you build it.

A mantra: Praise people in public.

If you want people to learn, let them make mistakes.

Wonderful problems breed wonderful solutions.

If you want novelty, do new things.

There can be too little disagreement.

Consensus can be dangerous.

When it’s decision time, make one.

Make the design space as small as it can be, but no smaller.

Build trust before you need it.

Image credit – Ralf St.

With projects, there is no partial credit.  They’re done or they’re not.

Solve the toughest problems first.  When do you want to learn the problem is not solvable?

Sometimes slower is faster.

Problems aren’t problems until you realize you have them.  Before that, they’re problematic.

If you can’t put it on one page, you don’t understand it. Or, it’s complex.

Take small bites.  And if that doesn’t work, take smaller bites.

To get more projects done, do fewer of them.

Say no.

Stop starting and start finishing.

Effectiveness over efficiency. It’s no good to do the wrong thing efficiently.

Function first, no exceptions. It doesn’t matter if it’s cheaper to build if it doesn’t work.

No sizzle, no sale.

And customers are the ones who decide if the sizzle is sufficient.

Solve a customer’s problem before solving your own.

Design it, break it, and fix it until you run out of time.  Then launch it.

Make the old one better than the new one.

Test the old one to set the goal. Test the new one the same way to make sure it’s better.

Obsolete your best work before someone else does.

People grow when you create the conditions for their growth.

If you tell people what to do and how to do it, you’ll get to eat your lunch by yourself every day.

Give people the tools, time, training, and a teacher.  And get out of the way.

If you’ve done it before, teach someone else to do it.

Done right, mentoring is good for the mentor, the mentee, and the bottom line.

When in doubt, help people.

Trust is all-powerful.

Whatever business you’re in, you’re in the people business.

Image credit — Hartwig HKD