5S

If you have spent any time in the automotive industry you have probably spent time working within a system called the 5S. Continue reading

Muda – Waste

For those familiar with the lean approach to the work or the Toyota Way, you my already know about the concept of Muda. Muda is one of the three categories associated with lean that impact performance and costs to the organization.  Muda is regarded to have seven waste types or areas or actions that cause waste.

Over Production

Just like it sounds, making more of something than the need for that something.  This does not just mean parts, but also extends to work product deliveries throughout the work pipeline. Think SIPOC (Supplier-Input-Process-Output-Customer), in this case any output from a process (P) delivered before the depending process (C) or work can start, leaving the work product just sitting there.  Another variant of this waste would be working on products that are not for the next work process, but some prioritized work that is further down or upstream.  When this is not coordinated well, we end up with rework, and if changes are required … Continue reading

Starting a Fire

Do you know how to start a fire?  I am not talking about charcoal briquettes, or the use of combustion material such as  lighter fluid, gasoline, or those special wax products that can be used in your fireplace, no propane or gas used either.

I’m talking about the fires we make in the woods when we go camping. It is okay if you do not know how, in fact my life as had quite a few times when my boy scout experiences have been a benefit to more than my family or those with whom I am camping.  My son and I have made many campfires for cooking out or roasting marsh mellows. Before this, I had camped out without a tent and used the fire for warmth (and to keep away the vermin while we slept).  We have started fires when the material may be damp, but that is not to suggest that it is easy to start a fire … Continue reading

Value, Scope and Change Requests

Value, Scope and Change Requests

Change requests are part of any development project.  Change requests are sometimes necessary as we learn by building and doing the work.   In my experience, change requests often are born from requirements we thought we understood, only to learn by working with the product or system that we really did not have enough understanding to be able to record this in the form of specifications.  We think we are making things better when we spend an abundance of time documenting the requirements, at least those requirements about which there is uncertainty. That is not to say this is not a worthwhile endeavor, we have been in product development long enough to know there are downsides to delivering a product that has no associated documentation.  The testing and manufacturing portions of the work will make use of these requirements documentation and the errant or lack of documentation makes the work of these areas and more difficult … Continue reading

Common Cause and Special Cause Variation

Variation!

Though sometimes we may refuse to recognize it, the world is a full of variation, even in the things we think or believe are constant. For example, my wife has been known to say, “you always do…” or “you never do…”, to which I retort, I am human and I am not that repeatable.  I say that, but it is not just humans that are not so repeatable.  Everything has variation, and understanding this variation, is important for product development, project management, manufacturing, product testing and so much more.  To master this work, we need to understand this variation as completely as possible.

Common and Special Cause Variation

Shewart is credited for developing the concepts of special and common cause [1].  Special cause variation, are variations that are outside of the expected (intermittent) range of possibilities. Common cause variation, are the variation expected, we know about these, these are predictable, provided we have put some effort into learning about … 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

Estimates are not Law nor Fire and Forget

by: Jon M Quigley

There has been some twitter-go-round regarding estimates. Estimates are not always guesses, but very frequently these maybe just that. If we chose not to delude ourselves, we know when we have some substance behind our estimates, that is our estimates are based upon some relevant historical data that allows us to see the range of possibilities for this specific type of work as part of deriving the estimates. That is not to say that this is perfect only to say that there is some historical reason for our estimates, the further afield this specific work is from those earlier types of work, the more risk in the estimates.

In many cases estimates should not be point source estimates, that is a single number. This provides the illusion of certainty to those looking at the estimates. I think this is probably one of the reasons why managers and executives seem to treat these numbers as if … Continue reading

One Throw-Away Product – Or Refactoring

I have been speaking at many PMI chapter events in North Carolina this year. I enjoy doing these events, meeting new people, discussing different and new things, and sometimes, being introduced to cool old things.  One such event was the PMI Asheville Chapter where I met some really interesting people including Eric W.

Mythical Man Month

 

 

Eric is a software person, he writes code and in our conversation at the meeting (the topic was risk and risk management) it became clear he is also one of those that have been around software development for years. Shortly after that meeting I received a package via amazon from Eric W, the book, The Mythical Man Month.  This book is interesting for several reasons, not the least of which is it was written by a North Carolinian, or at least a professor at North Carolina University.

This is an old book, from the 1970’s and I am sorry … 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

Single Sign On provided by vBSSO