Archive for the ‘Design Engineers’ Category

Creating a brand that lasts.

chillinOne of the best ways to improve your brand is to improve your products.  The most common way is to provide more goodness for less cost – think miles per gallon.  Usually it’s a straightforward battle between market leaders, where one claims quantifiable benefit over the other – Ours gets 40 mpg and theirs doesn’t.   And the numbers are tied to fully defined test protocols and testing agencies to bolster credibility.  Here’s the data.  Buy ours

But there’s a more powerful way to improve your brand, and that’s to map your products to reliability.  It’s far a more difficult game than the quantified head-to-head comparison of fuel economy and it’s a longer play, but done right, it’s a lasting play that is difficult to beat.  Run the thought experiment:  think about the brands you associate with reliability.  The brands that come to mind are strong, lasting brands, brands with staying power, brands whose products you want to buy, brands you don’t want to compete against.  When you buy their products you know what you’re going to get.  Your friends tell you stories about their products.

There’s a complete a complete tool set to create products that map to reliability, and they work.  But to work them, the commercialization team has to have the right mindset.  The team must have the patience to formally define how all the systems work and how they interact. (Sounds easy, but it can be painfully time consuming and the level of detail is excruciatingly extreme.)  And they have to be willing to work through the discomfort or developing a common understanding how things actually work. (Sounds like this shouldn’t be an issue, but it is – at the start, everyone has a different idea on how the system works.)  But more importantly, they’ve got to get over the natural tendency to blame the customer for using the product incorrectly and learn to design for unintended use.

The team has got to embrace the idea that the product must be designed for use in unpredictable ways in uncontrolled conditions. Where most teams want to narrow the inputs, this team designs for a wider range of inputs.  Where it’s natural to tighten the inputs, this team designs the product to handle a broader set of inputs.  Instead of assuming everything will work as intended, the team must assume things won’t work as intended (if at all) and redesign the product so it’s insensitive to things not going as planned.  It’s strange, but the team has to design for hypothetical situations and potential problems.  And more strangely, it’s not enough to design for potential problems the team knows about, they’ve got to design for potential problems they don’t know about. (That’s not a typo.  The team must design for failure modes it doesn’t know about.)

How does a team design for failure modes it doesn’t know about? They build a computer-based behavioral model of the system, right down to the nuts, bolts and washers, and they create inputs that represent the environment around the system.  They define what each element does and how it connects to the others in the system, capturing the governing physics and propagation paths of connections. Then they purposefully break the functions using various classes of failure types, run the analysis and review the potential causes.  Or, in the reverse direction, the team perturbs the system’s elements with inputs and, as the inputs ripple through the design, they find previously unknown undesirable (harmful) functions.

Purposefully breaking the functions in known ways creates previously unknown potential failure causes.  The physics-based characterization and the interconnection (interaction) of the system elements generate unpredicted potential failure causes that can be eliminated through design.  In that way, the software model helps find potential failures the team did not know about.  And, purposefully changing inputs to the system, again through the physics and interconnection of the elements, generates previously unknown harmful functions that can be designed out of the product.

If you care about the long-term staying power of your brand, you may want to take a look at TechScan, the software tool that makes all this possible.

Image credit — Chris Ford.

Crossword Puzzle – Product, Technology, Innovation

Here’s something a little different – a crossword puzzle to test your knowledge on products, technology, and innovation. Complete the puzzle using the image  below, or download it (and answer key) using the green arrows below, and take your time with it over the Thanksgiving holiday.

Crossword - Product Technology Innovation

What They Didn’t Teach Me in Engineering School

The technical stuff is the easy part. Technical systems respond predictably, but people don’t.

There’s nothing worse than solving the wrong problem, so before you start solving you’ve better done a whole lot of defining.

There is no exact answer; engineering is all about judgment.

Organizational structure is important.  Whatever the structure, see its strengths and make them work for you.  If you try to fight it, it will eat you.

Innovation isn’t about ideas, innovation is about commercializing ideas.

Engineering analysis can win minds, but not hearts. And hearts govern minds.

The engineer’s role is not to minimize risk; it’s to understand the commercial reward and take risk accordingly.

What people believe is far more powerful than what they think.

New technology threatens status quoers, and, in turn, they block it.

There is no problem unless someone important thinks there’s one.

All technical systems are really human systems masquerading as technical systems.

If you let it, fear dominates. Be afraid and do it anyway.  But along the way, keep in mind that others are too afraid to try.

Engineering is not sane and rational; engineering is about people.

Engineering Incantations

Know what’s new in the new design. To do that, ask for a reuse analysis and divvy up newness into three buckets – new to your company, new to your industry, new to world. If the buckets are too big, jettison some newness, and if there’s something in the new-to-world bucket, be careful.

Create test protocols (how you’ll test) and minimum acceptance criteria (specification limits) before doing design work. It’s a great way to create clarity.

Build first – build the crudest possible prototype to expose the unfamiliar, and use the learning to shape the next prototypes and to focus analyses. Do this until you run out of time.

Cost and function are joined at the hip, so measure engineering on both.

Have a healthy dissatisfaction for success. Recognize success, yes, but also recognize it’s fleeting. Someone will obsolete your success, and it should be you.

To get an engineering team to believe in themselves, you must believe in them. To believe in them, you must believe in yourself.

Circle of Life

Engineers solve technical problems so

Other engineers can create products so

Companies can manufacture them so

They can sell them for a profit and

Use the wealth to pay workers so

Workers can support their families and pay taxes so

Their countries have wealth for good schools to

Grow the next generation of engineers to

Solve the next generation of technical problems so…

More Risk, Less Consequence

WHY? To grow sales in existing markets and create sales in new markets.

WHAT? Create innovative technologies and design products with more function and less cost.

HOW? Educate the engineering engine.

This is easier said than done, because for years we’ve set one-sided expectations – new products must work and timelines must be met – and driven risk tolerance out of our engineering engine. Now it’s time to inject it back in.

The message – Our thinking must change.  We must take more risk, but do it safely by reducing negative consequences of risk.

To reduce negative consequences of risk, we must learn to localize risk through the narrowest and deepest problem definition, and learn to secure the launch so it’s safe to try new things.

We must do more up-front technology work, but learn to do it far more narrowly and deeply. We must learn to hold ourselves accountable to rigorous problem definition, and we must put our best people on technology projects.

To focus creativity we must learn to set seemingly unrealistic time constraints; to focus our actions we can look to a powerful mantra – spend a little, learn a lot.

The trouble with new thinking is it takes new thinking. If you don’t have it, go get it. If you already have it, figure out why you haven’t used it.

You might be a superhero if…

You might be a superhero if…

  • Using just dirt, rocks, and sticks, you can bring to life a product that makes life better for society.
  • Using just your mind, you can radically simplify the factory by changing the product itself.
  • Using your analytical skills, you can increase product function in ways that reinvent your industry.
  • Using your knowledge of physics, you can solve a longstanding manufacturing problem by making a product insensitive to variation.
  • Using your knowledge of Design for Manufacturing and Assembly, you can reduce product cost by 50%.
  • Using your knowledge of materials, you can eliminate a fundamental factory bottleneck by changing what the product is made from.
  • Using your curiosity and creativity, you can invent and commercialize a product that creates a new industry.
  • Using your superpowers, you think you can fix a country’s economy one company at a time.

 

Win Hearts and Minds

As an engineering leader you have the biggest profit lever in the company. You lead the engineering teams, and the engineering teams design the products. You can shape their work, you can help them raise their game, and you can help them change their thinking. But if you don’t win their hearts and minds, you have nothing.

Engineers must see your intentions are good, you must say what you do and do what you say, and you must be in it for the long haul. And over time, as they trust, the profit lever grows into effectiveness. But if you don’t earn their trust, you have nothing.

But even with trust, you must be light on the tiller. Engineers don’t like change (we’re risk reducing beings), but change is a must. But go too quickly, and you’ll go too slowly. You must balance praise of success with praise of new thinking and create a standing-on-the-shoulders-of-giants mindset. But this is a challenge because they are the giants – you’re asking them to stand on their own shoulders.

How do you know they’re ready for new thinking? They’re ready when they’re willing to obsolete their best work and to change their work to make it happen. Strangely, they don’t need to believe it’s possible – they only need to believe in you.

Now the tough part: There’s a lot of new thinking out there. Which to choose?

Whatever the new thinking, it must make sense at a visceral level, and it must be simple. (But not simplistic.) Don’t worry if you don’t yet have your new thinking; it will come. As a seed, here are my top three new thinkings:

Define the problem. This one cuts across everything we do, yet most underwhelm it. To get there, ask your engineers to define their problems on one page. (Not five, one.) Ask them to use sketches, cartoons, block diagram, arrows, and simple nouns and verbs.  When they explain the problem on one page, they understand the problem. When they need two, they don’t.

Test to failure. This one’s subtle but powerful. Test to define product limits, and don’t stop until it breaks. No failure, no learning. To get there, resurrect the venerable test-break-fix cycle and do it until you run out of time (product launch.) Break the old product, test-break-fix the new product until it’s better.

Simplify the product. This is where the money is. Product complexity drives organizational complexity – simplify the product and simply everything. To get there, set a goal for 50% part count reduction, train on Design for Assembly (DFA), and ask engineering for part count data at every design review.

I challenge you to challenge yourself: I challenge you to define new thinking; I challenge you to help them with it; I challenge you to win their hearts and minds.

Fix The Economy – Connect The Engineer To The Factory

Rumor has it, manufacturing is back. Yes, manufacturing jobs are coming back, but they’re coming back in dribbles. (They left in a geyser, so we still have much to do.) What we need is a fire hose of new manufacturing jobs.

Manufacturing jobs are trickling back from low cost countries because companies now realize the promised labor savings are not there and neither is product quality. But a trickle isn’t good enough; we need to turn the tide; we need the Mississippi river.

For flow like that we need a fundamental change. We need labor costs so low our focus becomes good quality; labor costs so low our focus becomes speed to market; labor costs so low our focus becomes speed to customer. But the secret is not labor rate. In fact, the secret isn’t even in the factory.

The secret is a secret because we’ve mistakenly mapped manufacturing solely to making (to factories). We’ve forgotten manufacturing is about designing and making. And that’s the secret: designing – adding product thinking to the mix. Design out the labor.

There are many names for designing and making done together. Most commonly it’s called concurrent engineering. Though seemingly innocuous, taken together, those words have over a thousand meanings layered with even more nuances. (Ask someone for a simple description of concurrent engineering. You’ll see.) It’s time to take a step back and demystify designing and making done together. We can do this with two simple questions:

  • What behavior do we want?
  • How do we get it?

What’s the behavior we want? We want design engineers to understand what drives cost in the factory (and suppliers’ factories) and design out cost. In short, we want to connect the engineer to the factory.

Great idea. But what if the factory and engineer are separated by geography? How do we get the behavior we want? We need to create a stand-in for the factory, a factory surrogate, and connect the engineer to the surrogate. And that surrogate is cost. (Cost is realized in the factory.) We get the desired behavior when we connect the engineer to cost.

When we make engineering responsible for cost (connect them to cost), they must figure out where the cost is so they can design it out. And when they figure out where the cost is, they’re effectively connected to the factory.

But the engineers don’t need to understand the whole factory (or supply chain), they only need to understand places that create cost (where the cost is.) To understand where cost is, they must look to the baseline product – the one you’re making today. To help them understand supply chain costs, ask for a Pareto chart of cost by part number for purchased parts. (The engineers will use cost to connect to suppliers’ factories.) The new design will focus on the big bars on the left of the Pareto – where the supply chain cost is.

To help them understand your factory’s cost, they must make two more Paretos. The first one is a Pareto of part count by major subassembly. Factory costs are high where the parts are – time to put them together. The second is a Pareto chart of process times. Factory costs are high where the time is – machine capacity, machine operators, and floor space.

To make it stick, use design reviews. At the first design review – where their design approach is defined – ask engineering for the three Paretos for the baseline product. Use the Pareto data to set a cost reduction goal of 50% (It will be easily achieved, but not easily believed.) and part count reduction goal of 50%. (Easily achieved.) Here’s a hint for the design review – their design approach should be strongly shaped by the Paretos.

Going forward, at every design review, ask engineering to present the three Paretos (for the new design) and cost and part count data (for the new design.) Engineering must present the data themselves; otherwise they’ll disconnect themselves from the factory.

To seal the deal, just before full production, engineering should present the go-to-production Paretos, cost, and part count data.

What I’ve described may not be concurrent engineering, but it’s the most profitable activity you’ll ever do. And, as a nice side benefit, you’ll help turn around the economy one company at a time.

We must broaden “Design”

Design is typically limited to function – what it does – and is done by engineering (red team).  Manufacturing is all about how to make it and is done by manufacturing (blue team).  Working separately there is local optimization.  We must broad to design to include both – red and blue. Working across red-blue boundaries creates magic.  This magic can only be done by the purple team.

Below is my first video post.  I hope to do more.  Let me know what you think.

 

 

WHY, WHAT, HOW to Improve Engineering

When asked how to improve manufacturing, the recipe is clear: lean.  When asked how to improve engineering, the recipe: there isn’t one.  Each engineering improvement effort is unique; though there are common themes and building blocks, each has its own fingerprint.

Each company has its own strengths, weaknesses, opportunities and threats; each company has unique products and markets; each its own goals; each its own culture; each its own future state. Informed by uniqueness, the recipe is unique. To create your unique improvement recipe, I suggest WHY, WHAT, HOW.

WHY
Before your engineering improvement recipe can be formed, the fundamental shaping question must be answered.  Take a breath, fire up your laptop, put on your headphones, and queue up your best music. Type this question:

WHY does our business demand we improve engineering?

Now, type the answer. (Literally.) Use nouns and verbs to explain why engineering must improve. If you can’t, stop. Without a clear, concise, jargon-free answer nothing can be done to advance the cause.  (Though there can be plenty of activity, there can be no progress.) Without the WHY, you cannot pass GO.  You must create a clear, concise WHY.

Seek out help from trustworthy people to create the WHY. Don’t move forward until you understand it well enough to explain it to the engineering organization.  Now, with WHY in place, it’s time for WHAT.

WHAT
Informed by WHY, it’s time for WHAT. Secure a quiet spot, scare up a big piece of paper, and grab your favorite pen. On the top of the page, write this question:

WHAT does engineering improvement look like?

Now, draw the picture. (Literally.) Use sketches, scribbles, arrows, blocks, and people’s names to describe what improved engineering looks like.  Sit in the future and describe it in present tense.  Once drawn, review it with folks you trust, revise it, and repeat.  If you cannot draw the future, keep trying.  Once you have something, review it with folks you trust, revise it, and repeat. Don’t move forward until you draw it clearly enough to explain it to the engineering organization. And with WHAT in place, it’s time for HOW.

HOW
The first step of HOW is similar to WHAT. Pick up your favorite pen, come back to the now, and draw a picture of today’s engineering capabilities, engineering’s current state.  Again, use scribbles, blocks, arrows, and names.

The second step is to define the difference between future and current states.  With future and current state pictures side-by-side, perform a mathematical subtraction: future state – current state.  The difference is HOW. A block in future state that’s not part of the current state is a new thing that must be created; a new arrow in the future state is an activity, interaction, or relationship that must be created; a new person, named or unnamed, represents new thinking. Things that appear in both states are strengths to build on.

The third step, prioritization.  Start here:

What engineering strengths will we build on?

It’s important start with strengths. It sends the right message to the engineering organization: we must build on build on what works, build on what got us here. Engineers need to know that, fundamentally, their work is good, and major building blocks are in place, the foundation is solid.

What development areas will we improve?

Take care with this one.  To avoid a demoralized engineering team, there should be fewer development areas than strengths.  Though there may be many development areas, call out only the most important.

What’s the right first bite?

The most important improvements are those that strongly support the WHY; there’s a natural sequence of things (socks before shoes) that must be respected;  and there’s a finite amount of work that can be done.  Use these three lenses as the start of a prioritization framework.

Building blocks for engineering improvement are the same for all companies: people, tools, and processes, but there are many types of people, countless engineering tools, and all processes can be improved. WHY, WHAT, HOW can help define your unique improvement fingerprint: the right people, the right tools, the right processes, shaped by your unique company goals, and improved in right sequence.

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner