PDOS Archives

PDOS Page 4

We’re habitual beings. We tend to do things the way we’ve always done them. I want to write about specifications in that context today. A lot of the organizations we work with utilize a specification sheet or template in to which a fill-in-the-blanks exercise is executed to create a spec sheet and communicate design intent to engineering. The problem with boilerplate templated spec sheets is they don’t distinguish the value that differentiate one spec from another —e.g. which spec is important, less important, arbitrary, etc.

A way of dealing with that issue is to divide your specifications into three categories: Musts, Coulds, and Shoulds. The Musts are those requirements that without which you don’t have a product. Without them you don’t have a competitive position in the marketplace. The Shoulds are the things on which your competitive advantage is built; things you’re trying to accomplish in your value proposition. The Coulds are things that would enhance the value of your product, but may not be worth focusing on and investing efforts to achieve.

These three categories still could be communicated as point specifications, but we can increase the value and information being communicated by expressing them differently. One way would be expressing them as ranges. Instead of having a point spec you then have a range of values. Hitting any of the points within that range would provide value as perceived by the market place. Those ranges can be communicated to the engineer and used to guide whether they reached sufficiency in their design effort.

You can take these ranges and enhance them further and make them communicate better information by placing them beside a graph to show how the market value will change over the range. That way an engineer can see that they’ve achieved the target, but with a little more effort they can achieve more value. It’s meaningful information to them for their design.

The third way of communicating the Should to engineering would be as goals, as word/statement based ideas of what you’re trying to accomplish with a particular design. The communication of goals takes this point focus defined by specifications and opens it up broadly — bounded only by conceptual boundaries defined by the goals.

The communication of Shoulds as goals allows the focus to shift from achievement of various points to the generation of new knowledge and looking for alternative ways of solving a technical problem. It allows us to rethink the very nature of how we manage engineering and product development. It also frees us from the pain and misery of testing to spec – pass/fail testing – to testing for knowledge and learning. And this knowledge that we gain from testing a full range of technology allows us to capture and apply knowledge as innovation within product design.

Contact us to learn more about how Systems Thinking and the application of our Product Development Operating System can help your organization become more efficient, productive, innovative, and competitive.

Follow Bill at http://www.twitter.com/systhinking

I personally have a problem with the term “problem solving”. Let me explain it to you. First problem — whenever we deliver problem solving training for organizations people have a very difficult time organizing their thoughts into a problem. If you take a problem and look at it as current situation, future or better situation, and the gap between the two, then you have defined your problem in a way that will allow you to improve the situation.

The other problem I have with problem solving is the word “solving.” Solving implies a total solution – a “fix it once and for all” mindset. In Lean we look not to solve or attain a perfect state. Instead we look to make measurable and cost effective progress towards an ideal state. We look for intermediary desirable states and balance out the costs of getting there against the gains in the situation that this better state will provide.

Even though I have issues with the term “problem solving”, and much prefer the term “continuous improvement”, problem solving is so well known and so accepted in organizations that we will accept the term. But please understand, when we use the term problem solving we really mean continuous improvement and making progress towards a better state.

Follow Bill at http://www.twitter.com/systhinking

The Pareto Principle comes to us from quality guru Joseph Juran. He named it the Pareto Principle in honor of Vilfredo Pareto who was an Italian economist. Pareto himself first developed the concept by recognizing that 80% of the land in Italy was owned by 20% of the people. This was reinforced when he realized that 80% of the harvest of peas in his garden came from 20% of the pods. This has been generalized in business into the Pareto Principle that states “80% of your sales come from 20% of your customers. And that 80% of your problems come from 20% of your issues.”

In it’s most general sense Pareto says that 80% of gain comes from 20% of the effort. And the last 20% of the potential gain requires 80% of the effort…four times the effort required to reach 80%.

The Pareto principle argues for the lean concept — which is the concept of the interrupted journey. The cost benefit ratio favors limiting your aspirations to 80% or less of your way to the ideal state. When you execute an improvement effort in Lean — when you apply PDCA or the Deming Cycle — you make this targeted state explicit. You look for the balance between your opportunities and your constraints. You get done what is available to get done at manageable expense. This is all done in the effort, not of a complete and total trip to the ideal state, but a trip to a better state and improved situation.

Follow Bill at http://www.twitter.com/systhinking

If you’re familiar with the world of Lean, then you’ve probably heard the expression “it’s a journey.” This expression has become a little trivial or trite. It’s become a little hollowed out, sort of like the term empowerment or win-win. I have a colleague who hates the expression win-win. He hates it because it is always used as a mask when he finds himself in a win-lose situation. But Lean really is a journey and I want to articulate the elements of that journey for you today.

First, you need to define your starting point, like a journey. Then you define a destination or where you want to go. Finally you have a rate of progress towards your destination. So, if you’re traveling from New York to California, you have your starting point in NY and your destination in CA. You have your rate of progress that includes intermediate states. You might stop in PA and visit some friends. You might only have enough money to get to IN. If that’s the case then you’ll need to stop and make some money for a little while before you pack up and continue west as far as you can go. California represents the ideal state and you have some intermediary states along the way.

In the world of Lean you define the current state, you consider your ideal state, you understand your limits, you identify targeted improvement states — way stations along the way, you go there and reach a steady state, then you prepare the next move on your continuous journey when the time is right. And that’s how Lean is represented as a journey.

Follow Bill at http://www.twitter.com/systhinking

I want to offer a challenge to people involved in product development. When we begin a Lean initiative we consider current situation and define an ideal state. The distance between the current and ideal situation is the space where you should focus improvement efforts.

When the Toyota production system was studied and converted into Lean Manufacturing they could clearly define the ideal state. The ideal state in Lean Manufacturing/The Toyota Production System is defined by the following:

Can produce defect free
Able to produce a batch of one
Can produce on demand
Can be delivered immediately
Can operate in a process with no waste
Can operate in an environment safe for the people involved physically, psychologically, and professionally

These all have been generalized into the Lean Manufacturing concepts:

Zero defects
Single piece flow
Pull
Lead time
Value added processes
Human factors

I’m challenging you to consider your product development system. Can you define your ideal state? If you can’t define the ideal state then what is the direction of your continuous improvement efforts? So please, seriously, give thought to and consider this – what is the ideal state of your product development system?

If have ideas and you’d like to turn this into a dialogue please email them to us or put your thoughts in the comments below and we’ll be happy to dialogue with you about defining the ideal state of your product development.

Follow Bill at http://www.twitter.com/systhinking

We were having fun the other day. We were talking about the LAMDA process. For those of you that maybe haven’t heard of it, the LAMDA process (Look, Ask, Model, Discuss, Act) is an action based instructive form of PDCA devised by Allen Ward, a University of Michigan researcher. Ward developed LAMDA while looking for an action-based way of describing the Plan, Do, Check, Act (PDCA) process.

The closed loop feedback step in PDCA informs improvement ambitions and initiatives. It turns our product development into a closed loop system. Having fun we asked “what is the alternative in the current default Taylor based management system?”

First we looked at what happens when Taylorism is applied in product development. The first thing you get is a learning disability and a belief that “The problem is out there. Others impose their problems upon me.” This also leads to a blaming culture. The idea that “That organization is causing problems for me and my organization.” It also leads to positioning and assumptive leaps as well as a sense of helplessness in the face of problems.

When Taylorism is applied in product development it leads to a culture that embraces the idea that “The problem is out there.” A blaming culture that embodies the famous cross armed move that leads to assumptive leaps and helplessness.

So in counter point to LAMDA we came up with the LLAMA model. It stands for Look, Look, Assume, Maybe Act. And that’s the counterpoint between Deming and Taylor. Deming gives us an opportunity and methodology for solving our problems and continuously improving. The Taylor system puts us in a position where we blame others and find our selves helpless when facing the problems of our workplace.

Follow Bill at http://www.twitter.com/systhinking