Muri – Overburden

Muri is waste associated with pushing people, processes and equipment beyond the limits or overburdening. An organization may be enamored of working large numbers of overtime hours, but any benefit for such some at a cost, and this is an example of overburdening.

I once worked at a place in which the employees averaged being at the organization for between 10 – 20 years, and had vacation time commensurate with being within the organization per the company benefits manual. The people that had been with the company that long had more than 4 weeks of vacation, which is 160 hours off of the 2000 hours or total work hours approximates 1840.  On top of this time off, the company also offered special days that it gave off to everybody – think Thanksgiving and Christmas for example.  Yet when it came to calculate the work the organization could undertake, the organization used 1980 per person to estimate the total amount of … Continue reading

Evolution of the Horseless Carriage

In preparation for our trip to Eindhoven University of Technology to lecture on Configuration Management, we provide a brief excerpt on the evolution of the horseless cariage.

Traditionally new market segments open due to the need to solve a problem. Such problems may be real as in the case of the environmental crisis solved by the automobile or the need may be concocted. New markets and products are rarely developed through the inspiration of a single individual. The automotive market came about through a synergy of the existing body of knowledge and other environmental conditions both in the marketplace and in the nature.

One topic of discussion at the world’s first international urban planning conference in 1898 was the growing health concerns due to horse excretions and the creatures that accompanied them. As the primary means of locomotion for wagons and other forms of transport, horse populations exceeded human population in cities.*

Manufacturers of “horseless carriages” using steam, electric, … Continue reading

Process and Bowling

I have been dabbling once again with bowing.  I did this when I was a kid with my family.  I bowled on a league from time to time as well.  Then you graduate, get a job, wife, and child, and you sort of just stop plying for whatever reason.  As I restart my bowling endeavor, I realize how process intensive it is.  Stand here. Aim at this specific point (dots on the lane).  Walk like this, ball moves out, then back, then forward while moving toward the foul line.  The swing comes forward, ball comes off the hand like this, then follow through, then ball lands on your spot, then look up at the pins to see if you are going to do anything productive.  This should look like a process to you. I notice, when I tick all of the boxes in a good way, I knock down most if not all of the pins. Violation of some of … Continue reading

Let’s Dump the Product Demonstration – Because we are Agile.

It is clear to me that some people think an agile approach means you can willy-nilly delete things in the process. This is also true for conventional project, but I do not think for the same reasons. For conventional projects, it seems time pressures cause elimination of certain functions or processes to keep the schedule. For agile, again no study but based on observed discussions, the elimination seems to be because there is no doctrine or perceived process that is required to be adhered.  This means things can be arbitrarily altered or changed, or even eliminated. That is certainly true, but you must consider the consequences of not performing the activity (for example product demonstration)?  From my perspective, there is a balance between adherence to a process (repeatable and baseline for learning  ) and adapting to the circumstances.

What does this product demonstration do, can I eliminate it, and what will likely be the consequences?

For the record, I am … Continue reading

The Sandbox

The Sandbox

There are times, when every conversation you have with one of your colleagues or family member just brings up a myriad of potential posts for a blog. The latest discussion was around clean your own sandbox. We have written about this in the past, but from a prioritization perspective, that is, why solve a problem within your sandbox that is costing the company tens of thousands, when you have problems across the variety of sandboxes that cost the company millions of dollars. We coupled this with a Pareto discussion as the means to determine which of our sandbox problems is causing the costliest problem.

Interconnected Sandboxes

In my experience, sandboxes are associated with functional organizations.  Each subset of the organization develops a specific focus area and skills allowing for specialization.  However, there is more to this than fix your sandbox. For example, it would be a truly unusual company in which each sandbox is totally independent of another. In … Continue reading

Saving the Business with Assorted Cost Improvement Methods

We see some company responses to economic downturn are to eliminate staff as if that were the only way to become a viable company once again. We wonder if these companies have some cost improvement methodology behind them that would give their management other options than summarily removal of personnel. Continue reading

What is next in our TQM tool work?

We have mapped how long it takes to prepare the vehicle for testing using the histogram. We have used the Ishikawa diagram to generate ideas we wish to investigate as causing the time to be longer than we would like it to be. Our next step is to see if the ideas suggested in the fishbone diagram have merit.

In our fishbone diagram we made note of the quality of the vehicle. We interview people who perform the testing on the vehicles to and find out that many of the vehicles going to electrical test have endured many miles of durability testing.  The vehicle does not represent the production incarnation as well (configuration) including wire harness revision.  These updates to the wire harness can take considerable hours as we take the vehicle apart, update the wire harness to the system content needed for the test, and then put the vehicle back together again.  The errant configuration is not … Continue reading

Random Acts of Product Development

We like the title Random Acts of Product Development.   It often appears that product development is a collection of ill-conceived and poorly executed tasks.  Those planning refuse to recognize dependencies between groups and tasks and are unable or unwilling to acknowledge they are really working within a system – blinded by the solely important launch date.  In fact, I have heard “it is best not to recognize dependencies” explicitly stated in a planning meet for a project.  Those making the plan may not know the reason for the task nor what constitutes “good quality” for that delivery, no fault of their own. It is not possible to know the reason for all the individual tasks and their respective objectives of each of those tasks.  The total product development process varies from company to company (though there are key core attributes).  Additionally, projects by definition have considerable variation due to team composition and risk encountered to which they must respond.

One … Continue reading

Extreme testing

            Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include:

Random voltages within the allowable voltage boundaries Voltage slews Deliberately introduced random noise on the data bus Extremely high bus loading (over 80% and sometimes over 90%) to see how the embedded software handles message dropping Cold and heat because variation in temperature can affect component performance, especially with LCD displays Rapid switching of hardware switches Slow voltage decay across the voltage boundary (which will sometimes cause a microprocessor “latch up,” wherein the micro ceases to function).

      Extreme testing is another discipline where the test suite greatly benefits from the active imagination of the test engineer. This is where we tap into the creativity that can never be automated. Our list is only a subset of the possibilities. We have applied these types of tests for both hardware and software testing, especially in the … Continue reading

Combinatorial Testing

            We know that a very simple product or system can generate a vast number of potential test cases. With more complex systems, this number becomes astronomical. This is the result of a factorial calculation! One technique we use to get around this problem originates with designed experiments. Many designed experiments are based on orthogonal arrays of test values. Two-level testing for each input and output is often represented with a matrix of zeros and ones or of pluses and minuses to indicate the levels. More levels are possible, but increasing the levels increases the number of test cases exponentially. With digital inputs, two levels are adequate.

            In essence, we will stimulate the inputs according to the recipe from any given row of our matrix and observe the behavior of the outputs. This situation means we must understand what the correct outputs are and be able to measure them. Furthermore, for each set of specified inputs, we must … Continue reading

Subscribe to our Newsletter

Subscribe to our Newsletter
Name
Email *
Single Sign On provided by vBSSO