Design for Six Sigma the Wrong Way

Executive Summary:

The right way to use Design for Six Sigma (DFSS) is to proactively mitigate or eliminate variation in product quality and performance and, by association, production processes.  The wrong way to use DFSS is to turn it into a rigid, inflexible product development checklist that forces every project to execute exactly the same tasks, every time.

The Rest of the Story:

The purpose of the Design for Six Sigma method is to proactively predict and minimize the variation in our products.  Particularly, we want to minimize variation in performance and quality.

When things vary we are inviting something to occur that is outside of acceptable norms.  Something will be too big, or too slow, or too weak, or too late, or too red, etc.  When that happens we must expend energy, time, resources, and money dealing with or correcting the fact that something was too something.

This recognition that variation is a root cause of unnecessary expense or cost or waste within a business is the philosophic principle behind the Six Sigma methodology and DFSS.  Six Sigma declares war on variation.  Design for Six Sigma is the battle plan for eliminating variation from our products.  Good.

As we institute Six Sigma and DFSS we naturally come to the realization that product development is a business process that experiences a great deal of variation, and also unnecessary expense because of those things that tend to vary out of control.  Naturally, we aim our Six Sigma and DFSS tools and methods and skills at that process and we fire away.  “Be gone thou wicked process variation!”

Our intent is good.  Our insight is good.  Unfortunately, our most common solution is poor.  Often, we make the mistake of turning our DFSS problem-solving framework into a product development process and checklist with a declaration that every project shall follow the process exactly the same way every time.  That should eliminate the variation, right?  Wrong!

Put your problem-solving expertise to work on that for a moment.  Where does the variation come from? 

There are two sources.

1. Variation in the various tasks and processes and behaviors that we engage to design and develop products
2. Variation in the scope and complexity and needs of each product development effort

If there is variation in our engineering change order process, or in our supplier selection process, or in how we establish and document our requirements, or how we organize our drawings and documentation, that variation will greatly impact our performance with regard to developing product designs.  Such variation, by all means should be reduced or eliminated and our ability to execute will improve.

However, no two product development projects should ever be the same.  They should always be different.  We should never expect to do the same project twice because every new product should be new and different from every other.

The scope, complexity, technology, expertise, people, time, resources, suppliers, and production processes for a new project will be and should be different from the other projects.  This kind of variation is good!

Now, let’s back up just a little.  How, by dictating that the DFSS method is now a process and associated checklist that, by policy, shall be followed the same way for every project, did we reduce or eliminate either of the two sources of variation we identified above?  We didn’t!

All we accomplished by establishing such rigidity is force every little, simple project to suddenly become a great big project.  Oops!  We don’t even know if we really put in the right details for our really great and complex projects to be done well.  Lastly, we just made everyone associated with product development really turned off about DFSS.  Does that sound right to anyone?  Am I the only one to have experienced this?

By all means, we should attack the sources of wasteful variation we identified.  We should absolutely apply our Six Sigma and DFSS expertise to reducing variation in how we execute engineering change orders, supplier selections, requirements identification and management, etc.  Doing so will definitely help.  But we must understand that these things will continue to vary because our project demands will always vary.

It’s OK.  Remember, it is good that our product development projects should vary in scope and complexity.  With that in mind, our DFSS execution should not be fixed and rigid, but should also vary.

Some projects will require designed experiments, some will not.  Some will need statistical sample sizes and new process capability studies from suppliers or new manufacturing processes, but some will not.  Remain vigilant and protect and promote the understanding that DFSS is a skill and a tool set to help us solve the problem of designing products that do not vary.  We use only the tools and methods we need, not all of them every time.

Take a good look at your own DFSS practice.  Did your organization get the right message, or did it make the common mistake?  Don’t be embarrassed to answer truthfully.  It’s happened to the best of us.  Recognize it and work your influence in your organization to help others recognize it and help you correct it.

If you have not instituted DFSS because you are afraid of stifling creativity or driving an overabundance of rigor, understand that it is not DFSS that creates what you fear.  It is how people and organizations institute it that creates what you fear.  Used properly, it is a powerful tool with excellent stimulus and tools for enabling and driving creativity and improved designs.  It is only when DFSS is used the wrong way that it becomes a burdensome roadblock to execution or innovation.

Stay wise, friends.

Lean in the Office: Single-Piece Flow and FIFO

Executive Summary:

Though the literal applications of single-piece flow and First-In-First-Out (FIFO) have limited opportunity in a project-oriented, office environment, the phenomena of clogged process systems and waiting work created by doing too much all at once are common.  Make your office and transactional processes more efficient and effective by applying the principles, if not the literal practice, of single-piece flow and FIFO.

The Rest of the Story:

Excepting repetitive, consistently similar processes like order entry or engineering change requests, it is difficult to find places in the office environment where Lean methods such as single-piece flow and First-In-First-Out apply.  Even our e-mail inbox is not a good place to practice FIFO because of varying priority and urgency.

However, the Lean principles that drive single-piece flow and FIFO can save us from surprising quantities of man-hours wasted and time lost in a project-oriented, office environment where the tasks are not repetitive, but always different.  By examining the principles of single-piece flow and FIFO we can make our offices more efficient and our projects execute more quickly.

First, let’s examine a common office or transactional process where the single-piece flow and FIFO concepts can be applied directly and effectively, but often aren’t.  It will allow us to examine how to apply the Lean principles in the office directly, and also to examine the principles so we can make a translation to other processes and examples.

For the sake of discussion, let’s examine the processing of engineering change requests.  If your office doesn’t do engineering, this example might apply to any variety of requests, including Information Technology (IT) service requests, or financial authorizations, etc..

So we are all on the same page, let’s consider the engineering change request (ECR) process to work generically as follows.  When an engineer makes a change to design documentation, that change must be communicated to all of the processes and data systems that have something to do with turning the design into an actual product.  Production and material or supply ordering systems must be notified of the change and must change accordingly.

Typically the process begins with the engineer filling out a form that explains the change and why it is necessary.  The form is submitted to the process and enters the queue.  When the form is picked up, after waiting its turn, it usually goes through a process of review and approval. 

Someone checks to make sure that the form and information are correctly completed and the process is enabled.  Someone will review the request and make sure that it makes sense and is appropriate – that it’s not going to create a problem.  Finally, the notification of the change will go to everyone responsible for an affected system so the change can take effect.  The data in the system us updated to show the change and the revision code for the documentation is ratcheted.

Sounds simple right?  If you have an engineering function, how long does it take to actually execute the process described; days, weeks, months?  If your answer was multiple days, weeks, or even months, you are not alone.  It’s common.

Now answer this, if you “walk” an ECR through the process, stopping at each desk and approval with that form in your hand, can you get it done in a single day, or less?  Most of us would probably answer in the affirmative.  Are your alarm bells going off yet?

When we “walk” our form through the process and get it done in a single day, it shows us the process time or “lead-time” to which we are entitled.  Therefore, all of the other days, weeks, or months that it takes a request to work its way through the system are waste.  Go ahead, you’re allowed to groan.

How does something that should only take a few hours end up taking weeks?  Here are some common occurrences.  The people processing the forms may or may not take them in order.  Certainly, many ECR processes allow for some variety of urgency or priority preference to be placed on different requests.  Those with lower priority wait.  The people reviewing the requests have other duties too.

The other duties of approvers may seem, at any given time, to be more important or urgent than reviewing requests.  Certainly, they are probably more interesting.  So, the requests don’t get reviewed until something changes that perception of urgency or importance or interest.  Usually that requires that someone else makes it painful for the reviewer to procrastinate any longer, which happens when the request has sat around long enough to get a certain level of attention.  Then, when attention finally is directed to the requests, they may or may not be handled in order.

Additionally, many ECR processes use approvals where notifications would be more appropriate.  For example, many request processes have a standard list of people that need to review the request.  Maybe the Marketing Manager is on that list because an engineering change could necessitate changes or impacts to marketing materials, product catalogs, or otherwise affect customers.

However, if an engineer simply replaces one screw with another that costs less, that Marketing Manager could care less.  Still, the request will go to that manager for approval and sit there.  Every approval, appropriate or not, is an opportunity for that ECR to sit in “inventory” and for the people or other resources associated to “wait.”  How many standard approvals does your request process require?

I could write a whole book just on the subject of the sources of waste for ECRs and how to streamline ECR processes.  For now, suffice to say that the requests in the system create or experience a great deal of “waiting” or “inventory”-time to use Lean lingo.

OK, so let’s look at the Lean solution to the inventory and waiting problem called single-piece flow and FIFO.  Philosophically, single-piece flow and FIFO battle against processing in batches.  Anything piling up in a queue or pile or batch is sitting and not getting done.  In other words, it’s experiencing wasted time and opportunity.

An ideal application of single-piece flow and FIFO for the ECR process would look like this.  A form would be submitted to the system.  The form would be error-proofed or “poke-yoke” to a degree to minimize the need to review the form and information, or eliminate the opportunity for an error to be introduced, thus eliminating the necessity to review the form for errors before processing the request.

Allowing that a review of the change is necessary and unavoidable, the resources necessary to make the judgment would immediately review and either approve or reject the request.  Approved requests would enter the data system with the changes and new revision code, and only the appropriate, parties would be notified.  It would take place just as fast as “walking” an ECR does, if not faster.

The resources for review and approval and otherwise processing the changes would be dedicated to the process in sufficient quantity to more-or-less handle a steady flow of requests without letting a queue build up that couldn’t be drained back down in a few hours or at most, a day or two.

Now, we all understand that for most of us, it’s simply not appropriate to dedicate an engineering manager or two to the ECR process for the sole purpose of reviewing and approving requests.  We couldn’t expect to pay someone with the right knowledge or experience to sit and do that job.  Even if we did, in that role they wouldn’t stay knowledgeable.  Their involvement in the whole business and function of engineering is what makes them knowledgeable.

So, pragmatically, we must accept that our requests are going to wait until that authority has an opportunity to break away from other things to review and approve requests.  We can set guidelines or rules such as, requests have 4 business hours to be reviewed before the alarm goes off, for example.  (Every office culture would need to develop its own appropriate rules and consequences)

Also, requests should be processed in the order they are received (FIFO).  Eliminate the system of urgency or importance preferences.  It causes more harm than it solves.

See if this sounds like it happens in your office, in some similar way or shape.  Two ECRs are submitted.  One is for a change to a design already in production, one is for a design that failed testing and needs the change to go back into testing, so it can pass and launch as a new product.  The Marketing VP notifies the ECR process team that he needs the in-development ECR to process with greater priority because the failed test is pushing back the launch date and the business depends upon it.

So the ECR team pushes the in-development ECR through first and engineers begin making phone calls and visiting various approvers to expedite the process.  Suddenly, dozens of people are not getting real work done because they are trying to get the ECR done.

Meanwhile, the in-production ECR is sitting and getting no attention.  Unfortunately, the reason for the request is that the production floor is out of the material typically used, and won’t get a re-supply in time to prevent the production line from stopping.  A source of equivalent material is on hand, but the design documentation is too specific to allow the substitution.  An engineer has evaluated the situation and determined that the substitution is a good option and therefore, filled out the request to change the documentation.

While the in-production request is waiting, the engineer and production team talk with the test lab and inform them that they need to produce a sample with the alternative material and run a verification test so the quality documentation for product certification can demonstrate that the substituted material has been tested and approved.  They communicate the urgency and the test lab agrees to set up for the test.

Subsequently, the in-development ECR is processed first, and hits the test lab and wants to re-enter testing.  The test lab has re-configured to run the other test though.  Now the test lab manager goes to a number of different leaders and tries to get two different VPs to settle the debate over whether the in-development project, or the production floor change is the bigger priority.  This takes another day at least.

In the mean time, the in-production ECR is finally processed and the samples are produced for testing.  They get to the test lab, get set up, and start running just in time for the command decision to test the in-development project first.  So they stop testing and re-configure the lab, which takes another day and begin testing the new-product-to-be.  When that’s done, they reconfigure the lab, another day, and finally test the substitute material.

Unfortunately, the extra days going back and forth in the lab and with the leadership has caused the launch to miss its big day and cost the business a great deal of money moving press releases and accommodating distributors, retailers, and customers.  Likewise, the substitute material was not verified in time to prevent the production line from shutting down.

If the first ECR had just been processed with single-piece flow urgency (immediately) and the second ECR processed right behind it, no one would have waited for more than perhaps an hour, at worst a single day.  Days would not have been wasted debating priority, and days would not have been wasted jerking the test lab around.  Both efforts might have made their deadlines.

When everyone can count on the process taking one or two days, instead of anywhere from 2 days to 2 months, people don’t go out of their way to work around the system.  Working around the system for one piece, creates excess waste for every other piece.  Make the process efficient and consistent and it will stay that way.  Don’t allow anyone, including the VPs to work around it.

The single-piece flow and FIFO methods eliminate or minimize pieces of work stacking up and waiting in queues.  Everything is handled with the same priority, and that priority is “immediately.”  Yes, the ECR we are handling at the moment might not be urgent while the one behind it is.  If so, get it done immediately so that you can get the urgent one done.  Don’t make any ECR wait and no ECR ever will.

It is a very simple concept.  Changing people’s discipline and habits and expectations to implement it is not so simple.  You will need to pull out some solid change leadership methods to make it happen, but it definitely works.

So would we apply the same practice to our e-mail?  We can, but it isn’t always that simple.  A request to put together a presentation to be delivered in three weeks might come in moments before an invite to an urgent meeting.  If we spent 6-hours working on the presentation and then read the e-mail about the meeting, we would miss the meeting.  That doesn’t make sense if the presentation isn’t due for three weeks.

We might not fulfill all of the tasks delivered in our e-mail in-box exactly in order, but we can read our e-mails in order of delivery and prioritize tasks or respond.  That way we don’t start at an interesting topic and process from there, fail to finish reading our e-mail before going home, and end up missing an important piece of information when it was relevant.

Let’s get even more difficult.  What about projects?  Every project is different, they don’t take the same resources, or the same amount of time, and we have resources to work on more than one project at a time.  Does it make sense to do only one project at a time?

Let’s look at that.  The purpose of single-piece flow and FIFO is to eliminate waiting and pieces of work sitting around without getting done.  Therefore, the correct answer to the question of doing only one project at a time must be the one that creates the least opportunity for work to be sitting (inventory) or for resources to be “waiting.”

The short answer is that an organization should do more than one project, but a project team should not.   Here is also where I call the remedy a disease and the cure a cause.  Let me explain.

Your business might have enough resources to do more than one project and probably does so deliberately so that it has that privilege.  Good.  The problem is not in an organization doing more than one project at the same time, the problem is doing too many.

Recall the ECR process discussion above.  We said the ideal state is dedicated resources to the process, but that dedicating approvers is simply not pragmatic.  We accept that the request will have to wait for an approver with other duties to make time to review and approve the request.  That reality identifies the key to eliminating waste in the forms of inventory and waiting.  Other duties are the cause of waiting and inventory.  We otherwise call the phenomenon of multiple duties “multi-tasking.”

When we work on a project, we naturally experience periods where we are waiting on someone or something to do something in order to continue.  We as human beings hate to wait, so we find something else to do while we wait.  We pick up another task.  Managers know this takes place and deliberately assign multiple efforts to personnel so that while personnel are waiting on one effort they can work on another and further the business objectives in a planned way.

Therefore, multitasking is a symptom of the waste of waiting.  We treat it like a remedy and plan things such that resources are allocated to multiple projects.  However, what happens when we pick up a task and then our previous task returns to our workspace for our further work.  Do we drop the second right away and pick up the first, or do we keep working on the second and let the first sit?

The answer depends on a lot of things including urgency, how interesting one task is, how well we are paying attention, and how many of these multi-task commitments we have.  Think for a moment.  Are your assignments really limited to just two?  How many work assignments are you juggling right now?  How many of them are sitting while you are working on one?  How many people are waiting for you to do your piece so they can do theirs?

If your answer to the last question is, “none because they all have other things to work on too” then this last assertion is for you!  Multitasking is not a cure for the wastes of waiting personnel and sitting work, it is the cause!

Take the following mental exercise very seriously.  Pick one of the projects you are on.  How long will it take for that project to get done?  Now, imagine that every member of that project team, including you, has no other assignments.  If you didn’t work on anything but that project for 8 hours a day, 5-days a week, how fast could your team get the project done?

Such a scenario may not sound very attractive to most professionals.  We know that we’ll spend some time waiting and that our different assignments are probably part of the appeal of our jobs.  But we also know that things would certainly happen a great deal faster.

A pragmatic adaptation of the single-piece flow and FIFO concept of the Lean methodology to a list of projects is as follows.  Assign one project to a single team.  Let that project be that team’s sole priority.  Let team members who are waiting invest their free time in improving the processes to minimize that waiting phenomenon.  Let them help team members with their tasks to speed up work and eliminate waste.

Allow managers to assign tertiary tasks to members of that project team which they are allowed to do while they wait.  These can be research and development assignments, non-urgent problem-solving challenges, or learning new skills.  The key is, they must be assignments that can be picked-up or dropped at a moment’s notice when the work for the priority project re-appears.

I have worked with more than one organization to improve the rate at which engineering design and product development took place.  We made a large number of process improvements that each made its own contribution to the improvement.  I keenly observed, though, that the closer we moved to the model I described of a single priority project assignment and only tertiary tasks for multi-task work the faster everything moved.

We have a human behavior of inserting one more thing in our agendas until we feel the pain.  If you don’t see it, go to your favorite restaurant and order your favorite appetizer, entre, and desert.  Tell me that you put your fork down before you get that uncomfortable feeling in your belly and that you didn’t exceed your necessary calorie intake for your dinner meal.  Yeah, we do it at work too.  We keep giving our teams just one more bite of work until they complain.

Unfortunately, the complaint of too much work occurs well after we have multi-tasked our personnel into a zone where our projects and tasks are spending more time sitting than getting processed.  Just spend one week with a piece of scratch paper and take notes every time something that you could be working on isn’t getting done because you are working on something else.  Compare that with how much you actually got done.

Take those numbers and multiply it by the number of people in your office.  Granted, it’s just a ballpark number, but that should give an order-of-magnitude estimate of just how much is sitting in your office.  I dare you to try it.  You will be astonished.  I dare you too to estimate a dollar value.

Assigning only a single project to a project team and allowing some tertiary work to occur as it may, might not be exactly the application of single-piece flow or FIFO to which we are accustomed in the production environment, but it fulfills the principle of eliminating the opportunities for work to sit waiting to be worked.  In an ideal case the project would never experience any sitting time and the people working it would also refine their methods to a degree where they don’t experience any waiting either.

We may never find that ideal state in most of our business environments, but I have experienced without a doubt that the closer to it we get, the faster our projects get done and the faster their savings or revenues or profits hit our bottom line.  It can be a huge business saver.

Take a good look at your office habits and behavior.  Look for opportunities to banish multi-tasking and to apply single-piece flow and FIFO either directly to your request processes or similar opportunities, or in principle to your project portfolios and teams.  Even when Lean can’t be applied directly, the principles hold true and can be applied in the office and transactional environment for significant benefits.

Stay wise, friends.

What’s True in Games is True in Life: Play To Your Strengths

Executive Summary:

We often get carried away trying to research and adopt the various programs and crazes of the day that other businesses have used to become successful.  As much as those initiatives and programs may be effective when employed correctly, there may be a simpler solution to drive your business’s success.  If you do something exceptionally well, then focus your business strategy on that.

The Rest of the Story:

I have found that the games that endure and are the most engaging are the ones that emulate life in some way.  They involve real challenges requiring strategy, solid decision making, optimizing our resources, and adjusting to changing threats.  Often, they involve skill, experience, and a little luck.  Just like life, and just like business.

Therefore, what is true in games is true in life and in business.  Pick your favorite game or sport and take some lessons from it to drive better performance for your work team or business.

Recently, my family and I were visiting with some friends and we ended up playing a board game.  I know, it sounds lame, but it was a fun game, very engaging, and I’m betting that some of my readers might run in geeky circles just like me.

Anyway, my wife lamented as she began the game with a highly biased playing piece.  It was weak in every attribute but one and had no remarkable perks to balance it out.  Her piece had only one strong attribute, which was exceptional.  Because of the obvious limitations, my wife thought she was doomed.

As you might guess at this point, she trounced the rest of us handily.  It wasn’t even a decent contest.  She did it by playing to the one strength of her playing piece.

She deliberately sought out opportunities where her one strength was an advantage.  In some cases she created them deliberately.  She avoided situations where her weaker attributes would be a disadvantage and eventually acquired supplemental pieces to replace or shield her weaknesses.  She cleaned up.

In business, we can do the same.  I’m reminded of two recent small business encounters where the businesses succeed by playing to their strengths.  The first is a small parts machining operation.  The second is a small-town water sports vehicle shop.

The small machine shop possesses a special talent for rapidly turning models or drawings into machine programs and producing small orders with a quick response.  It keeps a small inventory of common materials on hand and has a supply chain that can help it get small quantities of just about any material in a short time when necessary.

As a result, this machine shop sells itself as the place to call when you need your order filled tomorrow, or even today.  It has developed a relationship with manufacturers and engineering businesses in the local area that often need rapid replacement parts or quick prototypes, and it is a rather successful, if small, operation.

This machine shop seeks out businesses that need quick response and small quantities.  It deliberately avoids customers looking for large quantities or small and intricate, highly complicated components for very good reasons.  Why would it do this?

If the machine shop were to accept a large order, it could not compete with larger shops for cost because it’s own capital equipment is too small or too few to process large orders without a great deal of set-up or manual intervention.  It also could not process the large order as quickly, assuming a competitor could start at the same time.

Similarly, the machines this shop has are very good, but they are not ideal for machining highly complex components.  Again, to do so requires a great deal of extra programming, set-up, and human intervention.  The owner actually sends that business to his friend who specializes in machining the impossible (who also reciprocates appropriately).

It’s one thing to recognize that your abilities are not as high-performing as a competitors, but the real reason this shop turns away large orders or intricate designs is that while this machine shop would be struggling to process a large order, it could not respond to its customers demanding a quick response, which it does do better than anyone else.

Sure, the owner plans to grow his business and be able to start taking larger orders, but he has no intention to sacrifice his responsiveness strength to do so, and he will need some significant capital to do it.  In my book, he’s very smart.

Let’s look at another example where the strength is not so obviously one-dimensional.  Let’s look at a small town boat shop.

This boat shop is the only one located on the main drag of a small town where yearlong residents, seasonal residents, and tourists gather to enjoy access to beautiful lake country.   Let me outline what this shop has done to stay in business where the customer base is limited.  You see if my outline shows how the shop is playing to its strengths.

It sells most of its watercraft through catalogs and keeps very little inventory on site.  In fact, most of the vehicles on site are for rent, or are used and for sale on consignment.  Now the presence of rental and used equipment means that the business needs to service these vehicles.

Because it is a small town, the boat shop employs its own mechanic and services its own equipment.  Well, it keeps its mechanic busy by servicing anyone’s watercraft.  Also, since watercraft engines and other small engines such as snowmobiles, lawnmowers, and yard tractors, are all basically similar and the supply chain is the same, it also services these other small engines.

Lastly, the boat shop has some extra space in its building, and because many of the summer water sport customers are also fall and winter outdoor enthusiasts, the boat shop rents some of its store space to a local gunsmith.

In a small town full of empty storefronts and businesses for sale, this one is proving to be reasonably successful.  Clearly, the strategy is to maximize the offerings to a limited customer base with the resources it needs to operate and has on hand.  Do you see how that strategy makes the most of the boat shop’s strengths?

The boat shop’s particular strengths are presence, and service.  Its presence on the main strip of this small town makes it the most accessible place to buy, sell, rent, or service watercraft and related equipment.  It leverages store space to another, business that shares the same market, but doesn’t compete. 

It also services as much as possible to make the most of its mechanics.  It doesn’t risk its limited cash flow by investing in new inventory that may or may not sell.  Instead, it makes it easy and risk free for customers to pick craft from a catalog and purchase it through the store.  Perhaps this means it can offer more brands as well.

Finally, while the laid-back personas of the personnel do not immediately shout professionalism, they are friendly, and they are highly focused on meeting a customer’s needs.  When I rented a jet ski for a day, I asked what time they opened, or what time they would deliver it.  They opened at 9:00, but they would deliver it whenever I wanted to start.  We settled on a plan where I would just call when I was ready and they would run it out.  However, laid-back it was, it was easy as can be for me:  good service.

Our strengths can be versatility, or diversity.  They don’t have to be singular like the machine shop or my wife’s playing piece.

The plethora of other specialized experts enabled by the internet makes it easy for us to focus on what we do best, and partner with someone else to bolster or take care of the rest.  We can outsource logistics, warehousing, accounting, sales and marketing, and even engineering design, just to name a few.

As much as we can use partner or contracted services to cover our weaknesses, we can also carefully select partners with skills or specialties that further support or enhance our strengths.  If your specialty is low-cost operations, you might obviously select a low-cost logistics partner over a more expensive, rapid response or plethora of services logistics specialist.

My point is that we should take some time and determine what are our business strengths and make sure that our strategy is designed to capitalize on them.  Particularly for small and medium-sized businesses, focusing business strategy on strengths can be much more effective than adopting popular programs.   Just make sure that as you align your strategy with your strengths you also exercise the discipline to not accept business that sabotages your strongest performance, just as the rapid response machine shop avoids large orders. 

If you have exceptional strengths, play to them and avoid situations where you are not strong and you might just wipe the game board clean with your competitors.

Stay wise, friends.

Sanity is the Right Mission Statement

Executive Summary:

When we endeavor to produce a new product, a service, or a business solution, our very definition of that solution drives all other decisions.  Therefore, our mission statement or solution vision reflects the most important decision in the solution development process.  Make sure that you have a solid system for declaring the right mission and avoid investing resources developing the wrong thing.

The Rest of the Story:

One of my closest friends works with an engineer that tells a sad, but not uncommon story.  Before working with my friend, he worked at NASA, on the space program.

He tells of a two-year long project to develop a treadmill for the space station.  I’ll give you another paragraph to ponder the meaning of such a mission.

When we engage in the development of new products or other solutions, naturally we seek to develop a solution to solve our customers’ problems.  Many times we even go so far as to ask our customers what they want from us.  Unfortunately, what our customers say they want isn’t always what will make them happy.

When I first heard the story of developing a treadmill for the space station, before even hearing the adventures that the project entailed, I immediately, intuitively, smelled disaster at the disclosure of the project’s mission statement.

Whether you are an Engineering, Marketing, or Sales professional, or just a common sense person, I’d be willing to bet that you also smell a “booby trap” project.  The first and most obvious challenge is that it is difficult to run on a treadmill where there is no gravity.

Of course, other challenges spring to mind as well.  Can the space station handle the repeated impact and vibration that a treadmill induces, or is a complex dampening system necessary?  What about power?  Would the electric motors powerful enough to drive the tread belt tax the space station’s power budget?

Obviously, the purpose for the treadmill is to facilitate exercise, especially aerobic exercise, for astronauts spending weeks or months on the station.  I suppose that a treadmill meets the requirements of being a compact solution.  We can get versions for our homes that fit under the bed or fold up against the wall.  It’s also universal to every body shape and fitness level.  But surely there must be a more practical exercise solution for a zero gravity, limited power, weight-constrained environment.

The rest of the story goes as we might expect.  In spite of objections to the direction, the team was told to develop the treadmill because that is what the contract dictated.  After two years of development, the team had a design, which was not put into production because a more practical solution had emerged in the mean time.  Yes, our tax dollars probably paid for that two-year project.

I have worked in the engineering services long enough to appreciate the value of a “customer is always right” approach.  But when the customer requests a specific solution that isn’t well thought out or practical, even if you build what they asked for, they won’t be happy.

The problem in the space treadmill example is precisely that.  The mission defined a specific solution.  Maybe it was the first idea that came to mind.  Certainly it was an idea that didn’t consider the environmental challenge.  Wherever it came from, it was a poor solution for the true problem.  Our customers do this to us all the time.  Sometimes we do it to ourselves.

New products and solutions often turn out best when the mission is, “solve the following problem,” not, “build me this.”  Unfortunately, it’s easy to fall into the trap.  When we talk to customers and ask them to tell us what would make them happy, they answer with the problem in mind.  Meanwhile, we interpret their desires with the product in mind, and we miss the fundamental problem.

Take the example of the luggage design urban legend.  According to the legend, two competing luggage companies engaged traveler customers at approximately the same time and asked similar voice-of-the-customer questions.  They both arrived at the same customer complaint and desire.  “My luggage is too heavy.  It hurts to carry it.  Can you please make it lighter?”

One company fell into the trap.  They heard, “Make your next luggage product lighter.”  What the customers probably really meant was, “make my burden easier to carry.”

As a result, the first company spent time and resources exploring lightweight materials and minimalist designs and produced a product that was incrementally lighter than the competition’s.  Unfortunately, those few ounces they saved became unnoticeable compared to the weight of the stuff a traveler puts into the luggage. The problem wasn’t solved.

The second company, instead, dug deeper into the problem and returned to work with a mission statement that was totally different.  Instead of a mission that stated, “Develop a lighter luggage product,” they had a mission more along the lines of, “Make it easier for a traveler to carry or transport his/her luggage.”

The second company eliminated the customer’s complaint by putting a handle and some wheels on the luggage.  Voila!  The rollerboard-style luggage we all travel with today was born, or so goes the legend.  By the way, the rollerboard is heavier than the carry-type luggage.

Have you ever been told to develop a solution that didn’t make sense, or wasn’t practical?  Have you ever done so without knowing it at the time?  I have.  It happens easily, and frequently because the mission statement isn’t thought through.

Prevent the two-year long space treadmill and lighter luggage projects by installing a very simple check-and-balance system that challenges every new product or new solution definition.  I have converged on three questions that prevent most disasters.

1. Is this a problem statement or a solution statement?  (If you can’t drive a behavior of focusing on problems instead of solutions right away, substitute this question:  Does this idea solve the customer’s problem?)
2. How do we know this is the right problem(solution)?
3. Will it be easy for a competitor to follow with a “leap-frog” solution?

A leap-frog solution is one that offers incrementally better performance, or the same performance for lower cost, than your own solution and, thus, steals the market.  Of course you can add questions or modify the wording to suit your own organization.

The behavior to drive is that of asking and answering a very few, quick questions to ensure that your decision about what to develop is made wisely.  I strongly suggest involving a selection of cross-functional minds in the question and answer activity.

I know that sometimes our Marketing folks don’t like to include engineers in product definition discussions because the challenges to the practicality of the ideas become wearisome and often sabotage a group’s optimism.  However, many times the engineers can insert a level of pragmatism or effectively simplify an idea.  Likewise, Sales personnel often have a strong sense of what customers say and can provide an excellent reality check.

In my experience, the strongest tool for driving focus on the real problem instead of the first inspirational solution idea is a well-constructed problem statement.  With a little practice, it becomes an almost automatic activity.

A good problem statement includes the following pieces of information, no more, no less.

• What the problem is
• How you know
• When or under what conditions the problem occurs

A good problem statement must not contain the following information, though the natural tendency is to do so.

• Opinions
• Solutions

The point of the problem statement is to make sure that everyone understands the problem the same way and remains focused on the true problem, not someone’s idea of a solution to the problem.  Focus on the problem itself allows creative brainstorming and innovation processes to produce a selection of possible solutions and the all-important decision of which one will be the vision for the solution development effort.

I appreciate that challenging your product development or other solution directives in a committee will take more time and involve more discussion than we typically care to entertain in our business decisions.  About this I want to make two points.

First, a clear and well-crafted problem statement keeps the discussion to a minimum.  It quickly gets everyone to the same understanding about the opportunity of concern.

Second, how long does your business take to develop a new product typically?  How many resources are involved?  Isn’t it worth a few hours to be sure that the investment in your next product will drive a successful offering?  Isn’t an hour-long meeting to prevent spending months or years developing the wrong solution worth the time?

Businesses that do this regularly become practiced at it and the discussion only takes a few minutes.  A 1-hour review of proposals for the product pipeline can permit the above question-and-answer activity for several projects.

The mission statement is an outcome of the most important decision you will make in product, service, or solution development.  Don’t fall into the trap of automatically doing what a customer asks when a better, more practical solution can be produced.

Protect yourself from “booby trap” projects by asking a few simple questions to ensure that you are solving the real problem and that your solution will succeed.  Use tools like problem statements to facilitate your decisions.  You will issue your mission statements wisely and with greater confidence, and your failure rate will decline.

Stay wise, friends.

Design With Failure In Mind

Executive Summary:

When we design new products, we tend to focus on the requirements that will make the product a success.  However, unanticipated weaknesses or flaws can drive failure.  As you design new products, challenge your teams to actively find those flaws and weaknesses and eliminate them before you launch.

The Rest of the Story:

In one of my career steps I worked for a business that designed and developed security devices for residential and commercial buildings, namely door locks.  As you can imagine, the last thing we could tolerate in a product was a Web site or YouTube video publishing how easy it was to thwart one of our locks.

Our design teams got in the habit of challenging each other to find a weakness in our new designs.  We would offer lunch or other rewards for any business personnel who could identify a practical weakness.  Many of us just wanted to be the one clever enough to out-think his peers and thwart a design.

We would often begin the process as soon as digital CAD models were rendered and would continue the challenges through the various prototype and testing phases.  We even engaged outside locksmiths whom we identified as having especially creative problem solving talents to try and crack our locks.

For the most part, these challenges were cheap to the point of being nearly free.  Most of us made our attempts to break our peers’ designs in our spare or personal time.  Why?  It was fun.  Like solving a puzzle.  Sure we would be thinking about it in the backs of our minds while at work, but we were still getting our work done without much distraction.

Most of our engineers became trained in varying degrees of locksmith expertise to learn the tools and methods, and thought processes, of the trade.  It helped us be better designers of locks.  And we practiced.  We would buy our competitor’s products and find ways through them as well.

For example, I found a way to bypass a competitor’s premium deadbolt product in the residential market repeatedly in 15 to 30 seconds using a simple piece of steel strip 3-4 inches long.  I didn’t publish my discovery on the Web to discredit a competitor (it was not in my interests or our company’s culture to risk people’s security by telling criminals how to break locks), but it did go into our database of bypass possibilities.

The games we played with our designs and competitors’ product paid off.  On several occasions we identified genuinely practical bypass methods before launch and blocked or removed them.  We also identified difficult, but plausible weaknesses and eliminated those wherever possible within the cost constraints of the product.

Looking back, it was a virtually free exercise that potentially saved the company hundreds of thousands of dollars in liability or product recalls and lost sales due to product insecurity or reputation.  What’s best is that the engineers started the game and challenge because they recognized the potential.

Given the recent news articles about hacks into Netflix and Citibank, and recent identification of potential avenues of insecurity in several of Apple’s portable electronics products, it seems that many product development agencies could benefit from similar practices.  Some of the recent hacks have been embarrassingly simple.

Even if the products or solutions that your business develops are not security or safety devices, your designs might still benefit from a focus on actively finding their failures.  Take a moment and go through your own catalog and see if maybe it could be true.

We don’t always naturally do so.  We focus on ensuring success by identifying the right requirements and then we focus on meeting those requirements with our designs.  We try to build test plans around verifying the requirements and validating performance, and sometimes those test plans include environmental or use-and-abuse tests.

Many of us incorporate risk analysis and mitigation methods such as Fault Tree Analysis and Failure Modes and Effects Analysis (FMEA).  However, even those risk practices tend to focus on how our designs might fail to function under normal circumstances or fail to meet a requirement.  We don’t necessarily think about how our products might be accidentally or deliberately undone.

I’ll give you an example.  My neighbor goes through a-lot of car batteries.  Her minivan will leave the dome light on any time the door is open.  Sound’s perfectly reasonable, except that she has a large family with children of various ages who don’t always agree about who’s job it is to close the door or don’t appreciate the importance of doing so.

As a result, the car door might be left open overnight after one of them has come back to get something and neglected to close it, or because the last one out didn’t close it.  It sounds like a small thing, but it’s enough of a defect for her that she has declared that her next vehicle will be from a different automotive brand.

Granted, it’s hard for a design team to think of every possible thing, especially for a system as complex as an automobile, but it’s easier for an entire population of engineers and product development personnel to think of them.  Also, a small change to the car’s program concerning dome lights would be a very simple change if it were made during the development process.  The light in my truck goes off after a set time regardless of door operation.

Regardless of how much your own development teams currently address possible failures and risks, or what methods you use, take some time and evaluate if you can reasonably turn your entire product development population loose on the task of finding faults in designs before they are finalized or launched.  The cost of doing so is negligible and the benefit of it could be priceless.

Stay wise, friends.

Product Innovation Through Process Knowledge

Executive Summary:

We innovate new products and solutions every day, but do those innovations really solve our customers’ problems, or are they just novel?  To ensure your new solution is a winner, understand your customers’ process and problems and how your innovation will make things better.

The Rest of the Story:

This week I took my children to the dentist and got my first taste of our pediatric dentist’s new digital system for managing patient information.  I was handed an iPad and asked to use the touch screen to update information for our family’s insurance and for my children.

It was pretty slick and easy to do.  But in the end, I ran into a few shortcomings of the whole solution that reminded me of an innovation challenge that I have encountered many times, both as a customer and as a designer.  That is truly knowing how a customer will use the solution.

First, the system would only let me update one child’s information easily.  I had to go through some special process, with the help of the receptionist, to update my other child’s information because my other child didn’t have an appointment that day.  Second, there was no solution to capture my signature, so I still needed to sign a piece of paper.  Bummer.

In terms of solving problems for my dentist, I can see how having the client enter information directly into the data system saves hours and hours of data entry and error-prone interpretation of various handwriting styles.  It’s a great solution in that sense.  It will also allow me to use the Internet to update information in the future. 

There is one significant problem that you probably already perceive.  It didn’t make anything any easier for the client.  In fact, excepting the novelty of playing with an iPad, the process is slightly more difficult for the client.  Of course, if it is difficult enough, clients will request to fill out the paper form instead, or will otherwise voice their opinions about the system and the dentist’s problems will return in a new form.

In short, whoever developed the solution probably considered how to make things easier and more manageable for the dentist, but didn’t consider the dentist’s clientele well enough.  For the client, filling out a paper form compared to a digital form is no different, except to the computer-phobic who will protest.  But the ways the system’s rules are set things are in some ways more difficult for the client.

This happens often with the development of new solutions, particularly electronics and software interfaces.  Consider for a moment the last time you ran into a product or a solution that must have made sense to the programmer or designer, but doesn’t make sense to you?  Was it within the last week?  Probably you ran into at least one in the last month.  It might have been a smart phone app, or a Web site, or the instructions for an electronic gadget.

I’m a firm believer that as we begin to develop solutions for a diverse customer base, we naturally make the mistake of believing that the way we envision the solution to help, is not what really helps.  This is because we become focused on the technology, the possibilities, on optimizing performance, and we tend to think in one of two ways.

Either we dictate the only way to use our solution because it is clearly the best and simplest, and simple is good, or we create as many options, choices, and possibilities as possible, because more choices is better.  If you need a metaphor, think Mac vs. PC.  Mac is really easy to use, as long as you are willing to do it the way the Apple designers envisioned.  Heaven help you if you want to do it differently.  PC gives you many ways to do one thing, which drives some people crazy because they don’t care to become computer geniuses; they just want to get one thing done.

There are benefits and penalties to both approaches, but there is also an alternative, particularly if you are trying to make an existing customer activity easier.  That alternative is to learn how the customer already does it, and make it easier to do it the customer’s way.  Alternately, if the customer’s way is full of work that you can eliminate, then eliminate it, but not at the expense of the outcome or by putting the work on someone else.

I have a fair amount of experience solving process problems, and I have been able to turn that process understanding to use in identifying customers’ processes and opportunities for products or services to solve customers’ problems.  It is a very powerful approach.  In terms of innovation methods that do this, I have really only encountered and used two.  One is called Outcome-Driven Innovation.  The other I learned from Value Engineering.

The Outcome-Driven Innovation methodology provides a structured approach to discovering the various outcomes that a customer already achieves well with current solutions, that the customer achieves, but not well, or that the customer simply does not achieve.  The last group can be split into outcomes that would be beneficial to achieve, and those that are not achieved because they are not needed or desired.  It’s a very well thought-out process.

The Value Engineering science utilizes a tool called Function Analysis, in particular, the Function Analysis System Technique for FAST Diagram.  This approach begins by identifying a specific task then asks the question “how” to derive the various ways the task is accomplished.  It generally results in a tree of functions and supporting functions or activities to complete the task.  The tool then compels the user to ask the question “why” while retracing the tree in the opposite direction.  Eventually the user understands how and why each activity is performed.  Now the user can look for ways to simplify either how something is done, or otherwise satisfy one of the whys in order to build a simpler or more effective solution.

As I said, I have used both of these methods.  I find them to be very similar to each other, though one claims no influence from the other.  They are both very useful and effective if used properly.  However, they both take some experience to become proficient.  Don’t expect your first attempt at either to be a smooth execution without the mentoring of someone who is experienced.

Whether by use of Outcome-Driven Innovation, or FAST Diagrams, or my own investigation and breakdown of customers’ processes and activities, I have had great success, and have mentored teams to great success in developing highly satisfying solutions when the customers’ actual activity or process is understood or addressed.  It takes time and effort, and sometimes money, to gather the information, but it can mean the difference between a novel, but unsuccessful solution, and one that everyone is jumping to own.

Let’s look at the example from my dentist.  If each client of the dentist had a username and password or PIN, I suspect the signature problem could be eliminated.  I know that all of my insurance companies accept my on-line credentials for every transaction.  Also, if the rules for access to client information were not limited to the time around appointments, then information could be updated when the client was thinking about it, or already in the system, eliminating the number of times a client is required to interface, or the number of steps required to interface.

The fixes are simple, but the developers in this case didn’t anticipate them.  Perhaps they didn’t walk the process from the client’s perspective, or they developed what seemed like the best system in the mind of software developers, but didn’t understand the mind of the customers and their clients.

Don’t make the same mistake with your own products.  Make it part of your innovation or product development process to examine and map out how your customers, and their customers, will interface with your solution.  Identify the opportunities to make things easier.  Make sure that you don’t just pass the work to someone else. 

Novelty is great, but it quickly wears off.  When it does, will your solution still be the cat’s meow, or will it be buyer’s remorse. 

Stay wise, friends.

Integrate the DFSS Roadmap Into Your Product Development Process

Executive Summary:

If your business is adopting the Design for Six Sigma (DFSS) methodology, don’t make the mistake of replacing your product development process with the DFSS Roadmap.  Instead, make the DFSS Roadmap fit your existing product development process.

The Rest of the Story:

Design for Six Sigma is a powerful tool for many businesses.  It gives a design team the power to predict the performance and the defect rate of a product before it’s launched.  Actually, it gives the design team the power to control the defect rate of a product.

It is every bit as powerful as it sounds.  DFSS is the key to truly achieving the 3 defects in 1-million opportunities performance that the Six Sigma methodology chases.  However, DFSS isn’t for every business.

Design for Six Sigma requires a substantial investment in skill set development and a strong discipline to spend more time and energy early in the design process so that the latter stages will progress more swiftly.  It requires a significant cultural change for most businesses.

If your business has decided that Design for Six Sigma is the right solution, then I offer you some advice to make the transition much easier.  Do not replace your product development process with the DFSS Roadmap.  Instead, make the roadmap fit into your existing process.

The DFSS Roadmap is a guideline to step us deliberately through the DFSS problem solving methodology.  It must be followed in order for the DFSS method to work, but it is a problem solving approach, not a product development process.

There are several popular DFSS Roadmaps to choose from including PIDOV (Plan-Identify-Design-Optimize-Verify), and DMADV or DMADOV (Define-Measure-Analyze-Design-Optimize-Verify/Validate) to name the most common two or three.  The fact that there are several to choose from should be our first clue that we can manipulate the roadmap to meet our own needs.

Rather than trying to pick the best roadmap, we should instead study the content of the various roadmaps to understand the problem solving method.  Once we understand the method, we can incorporate it into our existing process.

There is a basic sequence that every DFSS Roadmap has in common, regardless of the acronym.

1. Define what the solution must be, do, or have – define what success looks like
2. Establish what your current, related production processes can and can’t do, particularly understand the variation of the processes
3. With process capability in mind, design the solution, optimize performance while minimizing the probability for defects caused by variation
4. Verify that the solution follows the predictions and performs appropriately before launching it

Look at the sequence again.  Excepting perhaps the investigation into process variation and capability, your product development process probably already follows the same sequence, roughly speaking.

What the DFSS Roadmap does not provide are the triggers for supplier contracts and communication, marketing materials and promotions, packaging design, writing of instructions, and a myriad of other activities needed to smoothly execute a complete product development effort.  Believe me, you do not want to throw out all of the product development knowledge and experience you have established over years or decades of practice.

So how do we follow DFSS if we don’t follow the DFSS Roadmap for product development?  The answer is that we do absolutely follow the DFSS Roadmap, but we follow it within our product development process, not instead of our product development process.

Here is what I mean.  Suppose that you are developing a product that is a complex system including several subsystems, electronics and mechanical components, and potentially more that one manufacturing or assembly facility.  There will not be one round of defining requirements, measuring processes, analyzing capabilities, or designing and verifying (DMADV) 

You will define the overall product requirements, but later, as the product concept starts to become complete you will also need to define specific subsystem requirements.  You may measure and analyze production data, but as you begin detailing the design, analyses may show that certain requirements are not met or that defect rates will be too high.

You will make adjustments to the design that might require changes in suppliers or manufacturing processes, which leads to more measure and analyze steps.  Subsystems will not be designed absolutely concurrently and two subsystems will not move from Analyze to Design or from Design to Verify at exactly the same time.

So if IPDOV or DMADV is not a perfect fit for product development, why do we need it at all?  As I mentioned earlier, it defines a problem solving structure and for DFSS to work we must adopt a discipline of following that structure throughout our design process and decisions.

For a successful incorporation of DFSS into your product development process, here is what I suggest.    Diagram the DFSS Roadmap you have selected, or that your consultant has promoted, as part of your product development process.

For example, suppose that your phase-gate style product development process is defined as Requirements-Concept-Design-Test-Launch.  You can match up the DFSS Define and Measure with Requirements, Analyze with Concept because here is where you are solidifying a plan to satisfy the requirements and the analysis will be part of your confidence the plan is good.  Obviously, Design matches Design, and Verify matches Test.  Launch remains on it’s own.

Now you have a diagram to communicate to managers and design teams alike, how the DFSS methodology and your product development process will work in concert to drive success, or more powerfully, how DFSS and your product development experience have been merged to provide a single methodology for better products and business success.

Don’t get too rigidly glued to the model we just described, however.  The truth of the DFSS roadmap and the method it describes lives at a much lower level of your product design execution.

When you go about collecting voice-of-the-customer data so you can establish your product requirements, if you truly understand and adopt the DFSS methodology, you will first Define your market for the product and the customers to consult, you will Measure or gather data, you will Analyze that data, and then you will use that information to Design your product requirements.  Lastly, you will return to those customers and Verify that if you produced what you defined that they would buy the product for the price you target.

You see, you will treat individual components of the product development process as unique problems and utilize the DFSS methodology to solve each problem.  In this example I outlined the complete DMADV sequence within the single Requirements/Define step of the product development process.

The same thing will happen with the concept, with each subsystem, even with the development of your test plan.  You will define the limits of the test, measure and analyze the noise involved in the test, design the test, and verify that the test apparatus performs before actually testing your prototypes.

None of the DFSS textbooks that I have read, and I’ve read many of them, have explained how to truly incorporate the DFSS roadmap into complete product development activity.  In fact, most of them make it easy for managers and leaders, for any of us really, to misinterpret how to use the method to develop solutions.

As a result, it’s a common mistake to throw away the existing product development knowledge-steeped process and try to replace it with the DFSS roadmap.  I’ve even argued with a few consultants who insisted on doing exactly that.  Don’t make the mistake.

The DFSS roadmap cannot replace years of product development knowhow, which you have carefully built into your process.  It does, however, provide a powerful discipline for addressing each and every step or problem within the process so that your team can predict and control the defect rate of your products.

Take the advice above to heart.  Not only will it make it easier for your teams to incorporate the DFSS methodology into their daily practices, it will make both your product development and your DFSS practices more powerful.

Stay wise, friends.