Archive for May, 2013

SIPOC – Customer

Posted on: May 16th, 2013 by admin No Comments

The customer is the receiver of the output; the customer can be an internal end customer or an intermediary to the next “chain” of events on the way to the final customer. Ultimately, we are aligning our actions (Suppliers, Inputs, Processes, and Outputs) in a way that provides the biggest benefits for our final customer. The presumption is that satisfying the intermediary customers will improve the probability of ultimately satisfying the final customer’s needs.  This stands up to logic. Imagine deliveries to the transitional organization that are such that the organization cannot use. For example, imagine our systems specifications were not written good enough so as to allow for the generation of the software specifications. We now are at risk of delivering something totally errant, or revisit and deliver the specifications yet again. This amounts to a waste of time, talent and resources.

Using SIPOC as a process review, critique or simply uncovering how you work makes it possible to streamline the delivery of the final product. Additionally, you will find that your team will become more aware of what constitutes successful delivery (metrics) even for the intermediate. This is where we find our leading indicators.

Lead and Lag Indicators

Posted on: May 11th, 2013 by admin No Comments

To go on further with the output discussion, we need to make sure we have an understanding of indicators.  Indicators inform us what is going on. My stomach growling is a pretty good indicator that I am hungry, and sweating while mowing the lawn is a good indicator I will need a refreshing beverage upon completion.  Similar mechanisms should be used to understand the state of the product development system.  To determine the indicators, we must understand the system.

Lead indicators, are those metrics that allow us to predict with some confidence – what is going to happen next.  For example, when we test the product “appropriately”, we learn something about the products ability prior to the launch.  The failures we witness during our testing provide a glimpse of what we can expect see in the field. Thus it is a leading indicator – we are able to make some prediction on the final output based upon this earlier variable.  Some examples of these leading indicators:

  • Defect arrival rate
  • Defect closure rates
  • Distribution of severity (minor blemish or safety issue)
  • Distribution of faults found through the development cycle (development iterations)
  • Percent coverage or ratio of test cases conducted to total test scope

Lag indicators, on the other hand, do not allow you to predict in advance.  Lag indicators are measurements that do not offer this p

In our testing example above, the lag indicator would be:

  • Rate of failure in the field
  • Type of failures in the field
  • Cost of quality

With some planning and identification of key metrics, we can be in a position to predict and not just react to the situations we find ourselves.  Some systematic thinking up front can save you greatly in the end.

Successful Output means…

Posted on: May 10th, 2013 by admin No Comments

How do we know when our output is successful?  Well, when the customer takes acquisition can be the first tangible evidence for many organizations the output is “good”.  So we know what we mean by good, I provide a brief list:

  • capabilities of the output can be deployed
  • suitable quality (Key Product Characteristics are met)
  • customer is pleased

Key Product Characteristics are what makes the product the product.  Consider a tire pressure monitoring system that mounts into the tire. We have physical characteristics and electrical characteristics (see outline below)

  1. Physical
    • Fit and mount to tire rim
    • Seal and mounting valve
  2. Electrical
    • Radio frequency (transmission frequency variance and strength)
    • On / off mechanisms (for example: turns on when wheel is in motion)

It seems the identification of these Key Product Characteristics does not happen.  It happens even less when we are working with the intermediate outputs (output from groups to group and not the final customer – see previous blog).  However, these intermediate “outputs” can be just as critical.  The sum of these intermediate outputs will ultimately “provide” us with the end product quality (Garbage-In-Garbage-Out.)

If we do not build the intermediate outputs in a way the depending organization can use, we have added to our time of development and probably degrade our final product quality.

SIPOC – Output Organization Structure

Posted on: May 8th, 2013 by admin No Comments

Our organization’s structure can confound what constitutes and output.  Consider the company that is structured as a “functional” organization, the output from one group will typically go to another group in the system.  This organization structure is sometimes referred to as “silo” since each part of the company, group or department is segregated by expertise.  This has the benefit of developing that individual area of expertise. However, it comes with some negatives also.  The experts may know their part of the work, but they may not know the details of how their output is used by the depending group (the group that uses their output as an input).  We will call these outputs “intermediate outputs”. That is these outputs are not the final incarnation to the final customer but outputs that are actually inputs to this depending process. See illustration:

SIPOC Illustration

In the example above, Organization A is the supplier for Organization B.  We can also see that the output from Organization B is the input to the next part of the chain or Organization C. We can call these intermediate outputs as these do not go to the end customer however, the quality of these deliveries impact the quality of the final product.

If we are a project organization, that is an organization where the group consists of all aspects to deliver the product in one group, the output from one member of our team then becomes the input to another team member (the same thing only different). In our previous example, our Systems level specifications could generate software specifications from the next person rather than a depending organization.

We can see organization structure has implications on the way the work is performed, however, the same SIPOC approach makes possible the understanding of the constituent parts of the system and those interactions.

SIPOC – Output

Posted on: May 8th, 2013 by admin No Comments

Each process produces some sort of, at least intermediate output. The ultimate output will be the resultant of the series of inputs, processes and outputs, and will be directed toward the ultimate end customer. Therefore the ultimate output capability is the collection of all of the inputs and processes of the systems of the organization. With specific measurements we can learn about the process capability of the intermediate steps and the final customer output.  This gives us the opportunity to adjust the elements of the system to improve the ultimate output.

Process in SIPOC

Posted on: May 7th, 2013 by admin No Comments

The process refers to the actions or activities we will take to achieve our objectives.  This link to specific objectives is essentially the rationale for the process. In our previous example, the Systems Engineering group may have requirements elicitation activities as well as concept generation and critique actions culminating in system requirements specifications.  These various steps may have some guidance for the method to achieve or perhaps detailed step by step instructions, either of which are processes.

The process may be for things like:

        • incoming inspections
        • work instructions for doing the work
        • material handling
        • scope identification (clear objective)
        • planning and scheduling
        • reviews and audits

At the top level, the process may describe how the various processes work together, the output of one, is the input of another depending process.

With our process documented, we will then train our people in the reasoning behind the process and the workings.  With a documented and performed process, we are now able to take key measurements to assess process capability exactly as a manufacturing line would.

SIPOC – Input

Posted on: May 4th, 2013 by admin No Comments

When we write about input, we are discussing the nature of the exchange to the depending group. The Systems Engineers, in our previous example, need some input from the Marketing staff to be able to design something to achieve the marketing personnel objective and subsequently meet the customer’s need.  What is that input? For example, the input can vary by:

  • Organization
    • domain
    • structure
    • development philosophy
  • scope of the work of the dependent group
  • regulatory or legal implications

All of these go into determining the nature and details required input of each group or subgroup.  It is important that both parties (the sender and the receiver) understand these exchanges. It is not the time to find out that the material delivered to the receiving group is not relevant, or missing key information at the time of delivery. This is where a good many quality problems first appear. For example, our input comes from the previous group, but they do not know what we need to do our job, nor the quality metrics associated with that delivery.  Given this unknown, it is possible from them to delivery anything – but that may not be something that the depending organization can use.  Getting this input correct are key for an efficient and successful project and product delivery.


Posted on: May 4th, 2013 by admin No Comments

The next few blogs will be further elaborating on the systems concept of SIPOC.  Upon completion of the characters or phases in the systems thinking and chain of events (SIPOC itself), we will illustrate how we can use these to improve our organization’s capability.

This post will treat “suppliers”. We are not referring to drug dealers, and we are not referring to solely external to our organization or to our company.  We are describing one end of a chain of events that will ultimately culminate in a final conclusive output.  For example, the supplier to the development organization could be the marketing organization as they supply the development organization with the target, “we need …..”  They in turn get their input from customers external that have a need.  So we see an example of the sequence of customers.

Marketing -> Systems Engineering -> Software Engineer -> Verification Engineer -> Etc.

Suppliers need to know what they are delivering to the system including what constitutes sufficient quality for the next person in the chain of events to be able to achieve their respective objective and the entire organization to achieve their overall objective.  We would not hand a piece of plastic to a depending portion of the organization, and expect them to be responsible for converting and delivering a metal part from it.  We are assuming they are not alchemists.  To make the objective of the organization we must have systems thinking and this starts with the supplier or who delivers what to whom.

Random Acts of Product Development

Posted on: May 3rd, 2013 by admin No Comments

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 way to solve this is to make sure the team has a strong detailed view of their portion of the execution or tasks.  In addition to that, the team members must know the dependencies between their part (tasks) and the prior and post tasks (Supplier-Input-Process-Output-Customer) .  In other words, our people (or some subset of our people) must have knowledge of the organization as a system. We will write more on this topic in subsequent blogs.

Sponges are not always helpful!

Posted on: May 2nd, 2013 by admin 1 Comment

We see well-meaning people adopt an attitude “if it needs done, then I will do it” even if their job or position in the company does not define them as the person to solve the problem. I call this absorption and it is part of the much ballyhooed “can-do attitude” upon which many companies thrive.  There is nothing wrong with a can do attitude. However, when the can do attitude camouflages an organization’s failures or failings then we are doing the organization and our talent within that organization a disservice.

Consider the person who regularly has to do part of somebody else’s job to perform their own. As an arbitrary example, let us say it is testing people who cannot work from requirements because the requirements never reflect anything remotely akin to the actual product performance.  Of course, it is true that it can be difficult to maintain the requirements through the development work. Change happens faster than the ability to respond to. However, it is also true that having test personnel running around asking assorted people (hopefully those that know) how the product is supposed to function is not an optimum use of the test personnel.  Having the test folks gather the “requirements” thusly means traceability to the end product is now word of mouth.  Additionally, our management will see that our test group consumes considerable hours to accomplish their work.  This leads to the false conclusion that verification area is an area rife for improvement. The test group will then come under scrutiny regarding those hours.  All the while, those at the executive level are blissfully unaware there is a problem.

Absorption, while moving the company ahead for the immediate term, sets the company up for failure.  A good book describing the problems with absorption (and solutions) can be found at:

Subscribe to our Newsletter

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