Archive for March, 2018

Measurement effects and analysis on personnel and organizations

Posted on: March 29th, 2018 by admin No Comments

By:” Shawn P. Quigley

Whereas we have discussed some of the possible flaws in measurements we can all still agree that they are needed to provide both improvement in processes and the organization. However, other aspects of obtaining data for the production of quantifiable information: trend analysis and process evaluation, is the human factor both workers and management. As in so many of our conversations we look at the affect it has on the people who are essentially being evaluated by the information gathered for these measures. An issue we will discuss later in this post, but first let us look at the management aspect of this equation.

As a quality analysis person data may seem to be clear most of the time, but as a management person how do you gauge the data which is being received? Do you understand its’ meaning? Do you look at the outliers to forecast or do you think they are just noise to distract?  Do you understand the source of the raw data and how it is perceived, collected, gamed, or otherwise manipulated by the workers and/or the people who are packaging it for your review? These questions; if answered honestly will shed light on why the data does not always support what is known about a process or project.

Example: how many times have you as a manager been shown that a project/process is working as anticipated just to be told later that the process needs changing because it cannot be worked as written or the project goes from being on track to weeks or even months behind in the course of one day?

This brings the question: how could we not know this with all the data we collect on everything? Yes, it seems like an endless circle of questions.

To break some of these potential issues let’s look at one at a time:

  1. How do the people who are having their work, adherence to processes, project analyzed, and themselves analyzed perceive the data being collected? It may seem like a small question, but that is commonly where we find our best rewards. If the people perceive the information it as a threat then they may feel the need to manipulate that information to provide what they suspect is a safe environment. If they see no value; personal or professional, added by the data collected they could cause data scatter due to the manner of collection and inattention to that data. Thus again rendering the information to be useless or even worse misleading. Many of these types of issues can be negated by having a “Shared Vision” with those personnel.  Specifically, all levels of the team should understand why the information is being collected and how it will benefit not just the team (company), but the individuals as well. As leaders and managers, we must ensure that our people can understand and see the benefit in these types on analysis. i.e. improving the processes to provide more job satisfaction.
  2. Do we as manager understand the system or systems which we are reviewing the data from? This is Systems Thinking in that an understanding of co- and inter- dependencies must be understood to determine what the data is suggesting ,and how that information should be applied. We have discussed the “Theory of Unintended Consequences” before and how that is most commonly related not to the information collected, but a poor understanding of the system as a whole and thus what the information is attempting to tell us. Systems’ thinking does not only apply to the managerial levels, but to the workers and supervisors as well. As we touched on in the first paragraph when we stated, If they see no value”, this issue can be headed off by ensuring the personnel collecting the information have: at a minimum, a basic understanding of the system as a whole.
  3. Information collected is used to facilitate improvements which come in the form of changes to processes, procedures, or people. This is basic change management in which one must be able to determine the actual starting position to determine a direction which is less likely to lead to a poor course change. I liken it to the thought that a ship crossing the ocean is 5° off when it starts it will arrive on a different continent. This in turn cause a more drastic course correction the longer it is allowed to proceed. Under this thought pattern it would be prudent to take the time to understand before making incorrect changes. This understanding of change management will also aid in minimizing the number of course changes and thus reduce the churn upon those personnel involved in the change and those affected by the change.
  4. While we touched upon information collection possibly being perceived as a threat by those collecting the information in paragraph one and how in paragraph two we discussed using Systems thinking as one way to reduce this concern; we did not address the Team Learning  aspect of information collection and application. Commonly data collected is provided to managers and higher personnel who determine what that information means and what actions need to be taken based upon that information. This approach removes a large talent pool from providing potentially valuable assistance in improving the whole. The incorporation of all personnel; at some level, into the change process also aids in developing ownership of both information collection and application. This in turn could reduce the some of the issues discussed with information collection (data scatter, data manipulation).

We only touched on four points that a manager should understand and apply in data collection and application there are many more to discuss. The point of this brief discussion on measures was to bring to light that; like change management, this process affects all levels of an organization and thus is dependent on all levels of the organization.

Independent Test and Verification

Posted on: March 28th, 2018 by admin No Comments

We are composing a glossary of test terms and we take one from that work today and discuss here.

A development organization can be structured in many ways. The development and testing can be essentially one department under one management structure, or these two areas, development and test can be separated each with a respective hierarchy.  Like most things, there are benefits and drawbacks for each approach.  The trick is to map the biggest benefit to your organization, or reduce the negative effects on your organization.  All of this means the selection for organizational structure is likely not best left to an arbitrary decision.


I am sure we see the obvious benefit of having the test personnel integrated with the development staff.  Those who have been in development for awhile no doubt understand the communications challenges that can come with separating groups when interaction between those groups is paramount for project success.  So, the benefit of these two disciplines is one less barrier to communication. However, there is more to it than that.  For example, consider a company that develops manufactures sells and supports the product after launch, like perhaps an automobile.  When communication between the development group and the test group takes on a more informal approach (verbal) we lose some of the ability to propagate the details of the product.  In my experience, the veracity of the documentation has a big impact on the depending activities of such an organization. For example, design documentation can serve as the core for service and troubleshooting of the customer’s product.  I have personally witnessed where an increased or sole reliance upon informal communication rather than technical documentation, meant the technical documentation was not promptly (or ever) updated to meet the actual product when informal communication is largely or solely the vehicle for this exchange. Those that get the formal documentation, are receiving outdated and errant information from which aftermarket product documentation and troubleshooting manuals may be derived.  In an instance like this, we exchange the improve quick interactions between the developers and the testing group, but it can come with consequences to those downstream.

Familiarity – not via communication

Integration of the development and the test groups comes with another potential downside.  We are all on the same team, we can suffer from group think. That is, we do not see the blind spots. We are on the same team, the level of critique from the testing group may suffer.  This relationship between the developers should be cordial, but not so familiar that the testing is soft on the product for fear the developers will take the feedback poorly.  I liken it to yin and yang or offense and defense in a sport (football).   I have seen the level of formalism descend to the occasional excel sheet tracking what is found and those depending activities defect correction and overall assessment of the product’s quality become difficult – who has the latest excel sheet, or is there an excel sheet with the sum of the defects found that will help support an informed decisions about the product’s suitability for launch.


Specialty Division

Creating both a development team and a test team provides space for specialization.  That is, the test team can develop their processes, tools and talents to meet the demands, and so too can the development group. We do not have development personnel burdened or distracted by the test activities within the group and vice versa for the test group.

Fault reports and escalation

Testing finds defects or non-conformance’s in the product.  The splitting of the development from the testing can put both disciplines on an equal playing field.  For example, consider the development manager that has test personnel also within the staff.  During a project, decisions must be made regarding the product suitability for launch.  The launch of the product is approaching, and testing finds some things pending evaluation but really has not concluded their work.  The manager will likely feel compelled to launch the product and there is not entity designated to defend an alternative viewpoint.  What do you think the probability of launching the product is, when the only person to make that decision is responsible for both the development and the testing in their hands?  With another hierarchical structure in place, there is a counter argument and discussion that can take place regarding any latent reliability risks that may come our way.

There are many things to consider when structuring your organization.  The organization’s culture, the level of risk toleration based upon the product, company and industry and many other nuances.  It is not as easy as just keep the existing structure or “spin” off the testing from the development.

My personal experience suggests a division between the development and the testing is helpful.  I can assume that many will disagree with this position.  However, my experience has been that a close connection between developers and testers impedes objectivity. Sometimes this is a management issue.  How do we know the ideal structure for our organization?  How do we get an objective and unfettered view of the product?

Reducing Cost – Homegrown Way.

Posted on: March 26th, 2018 by admin No Comments

Below is an excerpt from Reducing Process Costs with Lean, Six Sigma, and Value Engineering Techniques by Kim H Pries and Jon M Quigley pages 41 – 44

Reducing Porcess Costs with Lean Six Sigma and Value Engineering Techniques (Duplicate)


The brainstorming technique is attributed to Alex Faickney Osborne as explained in his 1953 book, Applied Imagination. The technique arose from frustration with the inability of employees to develop creative solutions for problems. Personal experience suggests this is a valuable tool when deployed appropriately and the guidelines are followed. If we populate the team with diverse backgrounds we can see ideas build on other ideas very rapidly.

To really find the areas for cost improvement we must let go of our mental impediments to uncovering these opportunities. It is very probable that there are plenty of cost improvement possibilities. However, in our daily work execution we may not find the time to free our minds to consider these possibilities. A brainstorming exercise can go far to fuel the imagination, to open a “space” to think laterally at what may be possible. We have successfully employed this technique to:

  • Reduce costs
  • Generate intellectual property
  • Reduce weight for the vehicle
  • Solve product design constraints

It is not even necessary to have a team with you to accomplish this lateral thinking, creative thinking, or thinking outside the box. Whatever you call it, the objective is to alter the perspective or view of the problem in order to perceive alternative possibilities. We can do this as a solo activity or we can use a group of individuals. If we are doing this as a group exercise we must make certain the event hygiene is managed. Of course, we are not talking about cleanliness of the team but the ability of the team to work together to produce some ideas that may solve the issue (cost) at hand.

Product, Process or Service Preparation for Critique

We need to make sure we are well prepared for the brainstorming event. This means selecting a cross-functional team with the wherewithal to achieve the objective of the exercise. They must have example material to review or peruse before the event. It is often helpful to have the material available during the exercise as well.

Problem Statement

To be effective, we must set the objective of the brainstorming activity. This in effect is the problem statement that we wish to solve. For example:

  • Reduce the product material costs by 10%
  • Reduce manufacturing costs by 6%
  • Reduce shipping costs by 3%

We direct the team’s attention (or even our own if we are the only person involved) toward this specific objective.  This is necessary lest we end up with an array of ideas of which few or any meet our objective.

Review Material

If we have a product or service that we are trying to improve the cost, we can have the product available as a teardown sample for our team to review. We can have the tools available to take the product apart during the exercise. This dissection of the product helps the team learn about the product and provides grounds for idea generation. We have had good experiences with a teaming exercise between the supplier and the customer, with each organization supplying a group of engineers from various disciplines from product design going through the product. For example, we may have mechanical and electronic engineers from both organizations generating ideas for cost and quality improvements.

We can also have drawings of the product available for our team’s review. We may choose to do this prior to the brainstorming event getting our team the understanding of the product, process or service prior to the event to maximize the idea generating time available.

We need not constrain our work to drawings of products. We can use this same approach to evaluate any process or processes we have within our organization that we wish to consider for improvement. In these cases we will need the process documentation and any process performance documentation that may be available. We should have a good idea of the performance of that process the same as we would with the performance of the product.

Numbers Count

The objective of a brainstorming exercise is to put as many ideas as possible for later consideration. The operative word is later. At this point in the process, we are trying to educe many ideas that we will consider at a later time. At some future date we will assess these ideas.

At the start of a brainstorming exercise, we will generally see the easy ideas emerge first—those ideas that have been discussed previously in the back rooms of the organization. We may not see any unique or fresh set of perspectives until we have exhausted these recycled ideas. That is not to say that these first ideas will not be appropriate, only that the new perspective will usually appear after we have already emitted those initial clusters of ideas—those at the forefront of our minds.

The generation of a mass of ideas has the added benefit of providing fodder for future cost improvement exercises without having to start at the brainstorming session again. If we generate enough ideas, we can investigate and prioritize each, thus filling the pipeline for future actions the organization can take to improve the cost, all based on this one event. Consider for example, an investment of five people during two hours that produces 40 ideas that could work, which is better than that same number of hours that produced 10 ideas that are workable. We now have a backlog of ideas for our cost improvement efforts from which we can execute.

Suspend Judgment

We do not want to stall progress on the idea generation by going through a premature critique of the ideas. If we are consuming time to assess the quality of the idea, we will have a reduced number of ideas for the time invested. The focus is on the problem statement and the range of possible solutions to address the demand articulated in the problem statement.

Besides the diffusion of the available time from generating ideas, if we critique what is being provided from the participants prematurely, we run the risk of shutting their contribution down. If we alienate a team member by assailing their idea, we may run the risk of reducing their contribution. We need a multitude of ideas and a safe nonjudgmental place to generate them.

Lastly, there are plenty of instances where radical or contrary ideas have produced exceptional results. Think of the Wright brothers, and Albert Einstein.

Build on Ideas

If we have a group of people generating the ideas, we may see a combination or building of larger ideas from a core idea or central theme. We may see a number of variations from that theme giving us a number of iterations or permutations of possible solutions. This is encouraged as well. We are looking for large volumes of ideas from which we can explore for validity at a later date. This poses the most challenging part of this process and that being the focus of the ideas. Our goal is to produce a number of solutions that could possibly meet the objective. The team may sway from the objective in the rush of ideas being proposed for consideration. While we suspend judgment, the caveat is not to diffuse the focus on the problem statement.

Mind Mapping

Mind mapping is not a new methodology. In the book How to Think Like Leonardo da Vinci: Seven Steps to Genius Every Day by Michael J. Gelb[1], we see that Leonardo da Vinci used this technique to build associations and ideas. We see that the technique of graphically associating or linking ideas is not new. This technique was further refined (and marketed) in the 1970s by Tony Buzan[2].

Mind mapping is a diagramming technique used to generate associations between tasks or ideas and some central theme. The technique makes it possible for the person generating to group ideas that are associated with a central theme and generate additional ideas for each of those subthemes. In the end, we have a hierarchical view of based on the central theme. Often these maps make extensive use of pictures or other graphical representation, not just text or even predominantly text[3].

If the radiant thinking ability of the brain can be applied to the left cortical skill of words, can the same power be applied to the right cortical skill of imagination and images? In 1970, Scientific American magazine published Ralph Haber’s research showing that individuals have a recognition accuracy of images between 85% and 95%[4]6. We associate and remember images because they make use of a massive range of our cortical skills, especially imagination. Images can be more evocative than words, more precise and potent in triggering a wide range of associations, thereby enhancing creative thinking and memory. These findings support the argument that the mind map is a uniquely appropriate tool. It not only uses images, it is an image.

If you have thoughts on cost reduction via homegrown approaches, please visit our discussion board at



[1] Gelb, Michael. How to Think like Leonardo Da Vinci: Seven Steps to Genius Every Day. New York City, NY: Delacorte Press, 1998.

[2] Buzan, Tony, and Barry Buzan. The Mind Map Book. New York City, NY: Plume/Penguin, 1993.


[4] Retrieved September  20, 2012.


I know, let’s use the outlier as a baseline

Posted on: March 12th, 2018 by admin No Comments

You will find this very difficult to believe, but I recently had a discussion with a person working at another company. This person is responsible for the statistical analysis of the work that other parts of the organization is to perform.  Those looking for the information come to this person to make some sense out of the historical record.

In the recent history of the work, there was an event, in which hour estimates were made for the work, in the middle of the work, it became necessary to close the work up as best possible and stop since a hurricane was in bound.  It was not possible to keep the project going given this storm so the work is prematurely closed out best possible to allow all to reach safety.  Those on the team know this antecedent event and the subsequent consequences to the effectivity work.

Given the knowledge that this last point is an outlier, and we know the reason for it being an outlier, you would think the choice for the next effort would exclude this value, as it does not represent what is likely to happen, or at least happen in the way that truly meets the project objective.  Yet, the outlier is the number the team wanted to use even though this number and situation do not represent typical performance.

What would make a team choose this? This value is lower than all previous values, but represent an anomaly from previous performance.


Team Player

Posted on: March 6th, 2018 by admin No Comments

There is considerable writing on creating and being a team player. There is much more to this than platitudes and poetic prose.  Some time’s the saying team player is preceded by saying you are not being a – team player.  One should especially fear this admonishment or condemnation.  It may not mean you are in fact, not a team player, but a ruse for manipulation by a person with interest in the outcome, sort of coercion through soft name calling, and appealing to your inner team spirit.

How many of us DO NOT want to be team players? Personally, while I do both solo and team type work, I would not want to be considered not a team player by the team in which I am a part.  I once ha a job in testing and was asked to alter the testing results, specifically, close fault reports prematurely before any evidence of corrective action has taken place.  I presented my position to the other team members, that was, fault reports should not be closed on a desire or thinking that maybe we have found the cause and corrected it, but something much more tangible.  Additionally, since the tests conducted by this part of the team did not find the defects in their part of the work, I must question their ability to assess the real closure of the bug report.  My thinking was logical, and was grounded in the process as defined by that department.  If you found the defect, you are the one to test again and close if the anomaly has been solved.  Thus, my answer was principled, and process based, it had everything to do with building a good product, which, in my mind, should be the team’s objective.  I believe my unwillingness to manipulate the system or violate principles or process relegates me to the realm of non-team player.  The irony or sad part, is this group of individuals was not involved with this part of the testing team (or me) until it was obvious the defect rate was soaring, and the defect closure time was too long to make the project look as if it would be completed on time, on budget, and at the desired quality.

So, what is the motivation behind labeling a team member as not being a team member?  Does it effectively mean:

  • Bend to my will
  • See it my way
  • Do as I say or be so branded
  • If you don’t see it this way it is because you think poorly of the team


Not going along to get along can be a measure of integrity or commitment.  It could also be an endeavor to improve things, to push to a greater point, to not accept remedial or lack-luster performance.  Going along to get along when you are as certain as you can be, with measurements backing you up, that things are going wrong, is not the at of a team player either.  Do team players allow the team to crash? By acquiescing to things, they know or believe to be wrong.



Subscribe to our Newsletter

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