Common Cause and Special Cause 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

Missing Requirements

Missing Requirements

Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray.

Wearing Many Hats

I worked at a small company a long time ago. I am glad I did, as I wore many hats and learned something new every day while having this job at this small company.  This particular instance, we were to design and build an embedded control system for a large manufacturer, and the requirements were listed on a short sheet of paper as a bulleted list of the objective the constraints, and the general performance expected.

Product Development Input

The primary source of contact and the requirement was the head of marketing. This company generally had short communication and hierarchy chains.  However, the marketing person was essentially a customer advocate and not really an engineer.  In … Continue reading

Requirements and Project Success

We have written much on requirements in other blog posts.  We have been maintaining this blog for years, admittedly sometimes more fervently than others.  We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the website.

There seems to be a myth that “waterfall” development requires ALL of one step in the delivery sequence before the next step can begin.  For example, all requirements must be written before work commences on the development work.  I have worked in what I would call traditional development approaches that some would refer to as waterfall, and at no time did we believe or act as if all requirements must be known and documented before we moved to the next stage, the actual development.  Even PMI recognizes the need work with the level of detail that can be known from where the … Continue reading

Requirements, Benchmarking and Teardowns

Requirements and Benchmarking

One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have met the specific challenge, or more importantly, how we can develop the product in an even better way.   Benchmarking can provide us with performance metrics for the product.  Knowing this, we can establish the performance expectations from our product which will show up in the requirements for the product.

Requirements and Teardowns

Teardowns are also useful when it comes to requirements generation.  We can learn what drives the cost in at least one incarnation of the product, which is how the competition has chosen to meet the customer demand.  We then are able to gain some measure of understanding of at least one possible incarnation … Continue reading

Requirements Management and Distributed Teams

There are a number of factors that can influence the approach we take to managing the requirements.  I provide a brief list below (this is not an exhaustive list):

the technical sophistication of the product the risk associated with a mistake distribution of the team

The more technically complicated the product the more diligent our handling of the requirements.  To manage complexity will require coordination of the incoming product information stream.  You can perhaps think of this as the carpenter’s adage; measure twice, cut once.  This leads us to the second item in the list, the risk associated with a mistake. For example, if little management of the requirements places the customer and the organization at risk.  Consider for example, when our product is low cost (no tooling and non-recurring engineering or NRE) and has low consequences when failing (think sillybands).  The risks associated are so low and therefore low impact and so it is possible to approach the requirements with … Continue reading

Requirements and Work Breakdown Structure

Scope, Requirements, and Work Breakdown Structure

The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS.  In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture the items associated with evoking, understanding and documenting the requirements.  We may (should) have one of the top levels of the work breakdown structure hierarchy that specifically address those items and things we should do when it comes to the requirements.  The decomposition of this portion of the project will ensure we consider all of the activities required to allocate both project time and talent to ensure the requirements gathering and documenting are given the diligence that this key part of the development of the product is due.  For example:

That is not the end of the work breakdown structure.  The contents of the requirements … Continue reading

Sweet Iced Tea Please (requirements?)

I have spent considerable time in the south, specifically North Carolina.  My dad was retired Special Forces and closed out his career at FortBragg (we lived in SpringLake).  Those not from the south, or have not spent much time here, may not know about sweet iced tea.  Sweet tea is a wonderfully refreshing concoction, especially in the summer.  It is ubiquitous with copious flows from most restaurants.  Sometimes I go out to lunch with my family.  The wait staff comes to the table and takes our drink order.  My wife requests sweet tea.  My son requests water or some other drink.  Then I request sweet iced tea.  My family then gives me some good natured ribbing for ordering the “sweet iced tea”.  I explain, if I order sweet tea alone, the tea can come back directly from the tea urn (tepid) they will not have delivered what I want, but will have met what I have asked.  If they come … Continue reading

Requirements and Decomposition

The customer can seldom articulate the technical details of the product.  The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible.  We will need some type of document to begin describing in technical terms the product that acts as a bridge from customer language to technical language.

One of the companies at which I have worked had a document that described the subsystem interactions.  This was called a cross-functional specification.  The cross-function refers to the interactions of the many electronic control units on the vehicle that were networked together.  The document described how the system would achieve the goals of the project, identifying specific signals, particular communications requirements and performance expectations from the numerous components on the vehicle network.  This essentially apportioned the function (distributing specific responsibility) across the numerous components of the network.  However, this homegrown document filled a very necessary role … Continue reading

Toxic Requirements

This blog post originates from Capers Jones LinkedIn comments about toxic requirements.  He posted a comment to a requirements article and brought up bloated requirements and toxic requirements.  I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it.  However, I believe I have experienced toxic requirements.  An example I have frequently witnessed would be requirements that are politically charged, not in the governmental sense but in the organization’s sense.  Have you seen the same set of requirements come in on many different projects? Each time the requirements are deferred or remove, yet these continue to re-appear.  These requirements may have little to do with the project objectives, but these requirements are the “pet” of some person or entity within the company.  We spend more time wrestling with these requirements than building the product. We will risk the significant portions of the project, specifically, those requirements that will actually achieve … Continue reading

Requirements Evaluation

Requirements Language

As we collect requirements we are going to need to perform some sort of evaluation.  We know the attributes of good requirements, now we will compare those attributes against the documented requirements.  However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that can cause difficulty for the effective and efficient development of the product.


We are likely to have multiple stakeholders and customers that will drive the end product expectations.  Experience suggests this multiplicity and diversity of input can put the product requirements at odds.  In other words, some requirements that conflict with others and customer prioritization of the requirements may also be in conflict.  We will then need to juggle the requirements that make it to the final product and further refine those; specifically, what appears in which instantiation of the prototype or product iteration.  To do effectively, we will need to balance stakeholders as … Continue reading

Subscribe to our Newsletter

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