Category Archives: Quality Management

  • 0

Root Cause Analysis

A Management lecturer was talking about “Quality”.

Lecturer: We all know Lord Ram went to spend 14 years in forest and Sita was kidnapped because of a “quality issue”.

Student: How is this anything to do with quality?

Lecturer: Tell me why did Sita go to forest with Ram ?

Student : Because she was his wife and respected his every decision.

Lecturer : OK but why did Ram go to forest ?

Student : Because his father Dasharatha told him to do so and he never disobeyed his father.

Lecturer : OK why did Dasharatha send his son to forest ?

Student : Dasharatha offered his wife (Kaikeyi) two boons , and she chose to make use of them in the future.

And she wanted her son to be king, so on the day of Rama’s crowning,

she asked Dasharatha to send Rama to forest and crown her son; reminding him of his promised boons.

Lecturer : So why did Dasharatha offer his wife two boons ?

Student : Because during a military campaign against Sambarasura, the wheel of Dasharatha’s chariot broke and kakiye inserted her finger to hold the wheel in place.

Touched by her courage and timely service, Dasharatha offered her two boons.

Lecturer: Hence Proved. The quality of Chariot’s wheel was not up to the mark .. leading to kidnapping of Sita…!!!!

So, using the “5 why” technique we see that Quality is very important and if the quality of Chariot’s wheel was good, the Ramayana wouldn’t have happened!

  • 0


Category : Funny , Quality Management


As a family we love to travel, by travelling we get chance to see new places, meet new people, experience difference culture but the most important is the travel time. We prefer to travel by car as we are better connected in the absence of technology. We initiate a discussion or problem or our dreams and by the end of the trip we come out with a solution or a plan of action.

During our recent long trip, we had a wonderful conversion on food. It all started when my wife was enquiring about the Biryani that she cooked a day before. She prepared the Biryani based on phone instructions from my mom. We discussed about the positives, opportunities for improvement and my wife asked a simple question, “I did whatever mom instructed but why the Biryani was not as expected”. I thought about the question and this gave me an opportunity to introduce them about Business Biryani Process Management.  Just like BPM is a discipline, a practice or something we do, Biryani Process Management is also a set of activities that will be carried out to cook an authentic tasteful Biryani.

Our problem statement: When the ingredients remained the same (taken from same lot), and when cooked by different people the output differs.

During our return journey we planned to conduct Biryani experiment and I designed our experiment based on Crosby Maturity Grid.

Just like Philip Crosby Maturity Grid that shows different stages of maturity of the company’s quality management against six different quality management categories our Biryani experiment was aligned with 5 stages of maturity (Uncertainty, Awakening, Enlightment, Wisdom and Certainty).

Crosby Maturity Grid

Measurement categories. Stage 1: Uncertainty. Stage 2: Awakening Stage 3: Enlightenment Stage 4: Wisdom Stage 5: Certainty
Management understanding and attitude. No comprehension of quality as a management tool. Tend to blame quality department for “quality problems” Recognising that Quality Management may be of value but not willing to provide money or time to make it all happen. While going through quality improvement programme, learning more about Quality Management; becoming supportive and helpful Participating. Understanding absolutes of quality management. Recognise their personal role in continuing emphasis. Consider Quality Management an essential part of company system
Quality organisation status Quality is hidden in manufacturing or engineering departments. Inspection is probably not part of the organisation. Emphasis on appraisal and sorting. A stronger quality leader is appointed but main emphasis is still on appraisal and getting product out of the door. Still part of manufacturing or other function. Quality department reports to top management, all appraisals is incorporated and quality manager has role in management of company. Quality manager is an officer of the company; effective status reporting and preventative action. Involved with consumer affairs and special assignments. Quality manager on board of directors. Prevention is main concern. Quality Manager is a thought leader
Problem handing Problems are fought as they occur; no resolution; inadequate definition; lots of yelling and accusations. Teams are set up to attack major problems. Long-range solutions are not solicited. Fire fighting. Corrective action communication established. Problems are faced openly and resolved in an orderly way. Problems identified early in their development. All functions are open to suggestion and improvement. Except in the most unusual cases, problems are prevented.
Cost of quality as % of sales Reported: Unknown.

Actual: 20 %

Reported: 3%

Actual: 18%


Actual: 12%

Reported: 6.5%

Actual: 8%

Reported: 2.5%

Actual: 2.5%

Quality improvement actions No organised activities. No understanding of such activities. Trying obvious “motivational” short range efforts Implementation of the 14 Step Programme with thorough understanding and establishment of each step Continuing the 14 Step Programme and starting Make Certain Quality improvement is a normal and continued activity.
Summation of company quality posture “We don’t know why we have problems with quality. “ “Is it absolutely necessary to always have problems with quality?” “Through management commitment and quality improvements we are identifying and resolving out problems” “Defect prevention is a routine part of our operation” “We know why we do not have problems with quality.”

Quality Maturity Grid – (Source: Quality is Free by Philip Crosby)




Stage 1 – Uncertainty: Experiment 1

  • Ingredients taken from same lot.
  • Cooks: My daughter (very basic like we need to switch on the gas and light it), my wife (basic cooking knowledge with 12 years of experiments) and myself (Loves eating and passionate about food).
  • Process: We did not have any defined process to make a Biryani and it was based on individual cooking knowledge.
  • Output: My daughter was not allowed to cook as my wife did not want to waste food but based on her description it would have been Sam’s Rice but not edible. My wife’s biryani was edible but it’s more of mixed rice than a biryani. Mine was near to Biryani but not an authentic.



Stage 2 – Awakening

Based on the experience from Experiment 1, we realised the importance of a process and we individually designed one each that addressed our major problems. We browsed online and selected the best and easy one to conduct our next experiment.

Stage 3 – Elightment: Experiment 2

  • Ingredients taken from same lot.
  • Cooks: My daughter, my wife and myself.
  • Process: We defined and followed the process individually to make a Biryani.
  • Output: My daughter had a better version of Sam’s Rice but this time it was edible. My wife’s biryani was slighter better than before with few major issues fixed but still not a biryani. Mine was almost similar Biryani but with minor improvements.




Stage 4 – Wisdom

After enjoying the Biryani we identified the root cause as what went wrong in our individual processes and discussed about the positive things. We teamed up to define a single process taking the positive things and corrective actions. We watched few videos, understood the best practices in Biryani making, added more details like temperate control; most importantly we conducted research on the purpose of each ingredients. We discussed the refined process with experts; define couple of checklists for ingredients and process. We were all set to conduct our third experience with a set of process, checklist and defined roles and responsibilities.

Stage 5 – Certainty: Experiment 3

  • Ingredients as defined from our checklist.
  • Cook: My daughter managed the checklist, my wife was assistant chef and myself chief chef.
  • Process: Our refined process to make a Biryani.
  • Output: A perfect Biryani but with few minor improvements and near to authentic.













We continued our experiments, reviewed our process, worked out the best practices and attended training with friends and relatives until we cook a perfect authentic BIRYANI



  • 0

Decision Making Styles

There are alternative styles that a leader can use in guiding decision making in a team setting. Four that are typically used are:

  • Command: Leader makes the decision alone.
  • Consult: Leader gathers input from others, then makes the decision.
  • Majority: Group members are polled for their opinions. The majority opinion becomes the group decision.
  • Consensus: Everyone in the group discusses the subject, arriving at a decision that all members can support. A consensus decision does not have to be unanimous, but all members must be able to live with and agree to fully support the choice.

When making decisions that are significant and that require everyone’s support, it is important to consider discussing and working through all aspects of an issue to arrive at consensus. Since all decisions are not equally important, it can be useful to ask yourself and your team, some questions before automatically choosing a decision making style.

  • How critical is this decision to the success of our project?
  • How important is it that everyone on the team fully supports this decision?
  • Do we need to talk about the issues involved to collect more information before deciding?

Very early in a team’s life it is important to work through decisions together to build trust. Once you have established a good working relationship though, you should begin choosing a style that is appropriate to the decision being made.


  • 0

Managing Differences

Often, when a team is making decisions that involve complex or highly charged issues, differences arise. It is important to remember that differences are not bad. Differences of opinion can lead you to look at an issue more thoroughly, to consider more options and arrive at a more effective decision. While differences aren’t inherently bad, problems can arise if they aren’t managed appropriately.

 1.   Identify Differences

  • Listen carefully to diagnose what’s going on.
  • Ask questions to clarify areas of agreement or disagreement.
  • Check in frequently with the team. Quiet members are often quiet for a reason.

 2.   Analyze the Differences

  • Once differences arise, list the various options on a flip chart. Listing them on a chart makes them just ideas, instead of the conflicting opinions of specific individuals.
  • Look at and analyze the ideas. Explore where similarities exist instead of just concentrating on how far apart you are.
  • Consider alternatives. Often you can merge some of the options to create a new alternative.

3.   Make the Decision

  • Avoid getting stuck in the discussion phase. Move on to a decision point.
  • In choosing an alternative it is important to ask: “Will this choice help us to achieve our team’s goal?” If a decision does not support the team improvement goal, it should probably be questioned and another alternative considered.
  • In some cases, you as the leader may have to use the command or consult decision-making style to avoid getting completely bogged down. If you must do this, it is important to explain the rationale behind your decision so that all understand why you made the choice.

4.   Implement the Decision

  • Once you’ve decided, move on! Don’t allow yourselves to blame and second-guess; make an agreement to support the decision and move on to the next activity.

  • 0

What makes a leader?

Leaders are persons who respond to the needs of their team members and give directions to the group. Five basic principles seem to underlie all of their actions, whether they are facilitating tasks or supporting the interactions within the group.

 Five basic principles for an effective leader:

  • Lead by example
  • Focus on behavior
  • Value others
  • Build constructive relationships
  • Make things better

Effective leaders exemplify all of these interrelated principles. Although no single set of examples can fully describe how to act out these principles, they offer a basis against which a leader can choose specific actions. As a leader you can ask yourself:

  • Am I acting the way that I want others to act?
  • Am I looking at the facts or generalizing?
  • Do my actions communicate that I value your contribution?
  • Is there an opportunity for all to benefit from this change?

Some examples of these principles being transformed into actions include:

  • Developing and following meeting agendas.
  • Completing action items and tasks on schedule.
  • Following the problem solving process (ask Why? 5 times).
  • Listening to team members and allowing everyone to participate.
  • Working to understand the emotions of team members during times of change or conflict.
  • Inviting differences of opinion and then encouraging joint problem solving towards a mutual goal.
  • Constantly focusing attention on the team’s goal.
  • Encouraging the taking of risks.
  • Giving sincere praise to individuals and to the team for the completion of tasks.

  • 0

The Essence of Jidoka

The Toyota Production System is frequently modeled as a house with two pillars. One pillar represents just-in-time, and the other pillar the concept of jidoka. The house will not stand without both pillars. Yet many of us focus on the mechanisms of implementation – one piece flow, pull production, takt time, standard work, kanban – without linking those mechanisms back to the pillars that hold up the entire system.

JIT is fairly well understood, but I believe jidoka to be a crucial key to making the entire system stick. A lot of failed implementations can be traced back to not building this second pillar.

What does jidoka actually mean? A common answer to this question is “autonomation” or “automation with a human touch.” This is usually illustrated by example of a machine that will detect a problem and stop production automatically rather than continue to run and produce bad output.

This is certainly the origin of the principle. It goes back to 1892 when Sakichi Toyoda invented a simple, but ingenious, mechanism that detected a broken thread and shut off an automatic loom. That invention allowed one operator to oversee the operation of up to a dozen looms while maintaining perfect quality. But the system goes much further.

The jidoka pillar is often labeled “stop and respond to every abnormality.” This is obviously much more than having a machine shut down. Toyota refers to every process, whether human or automatic, being enabled or empowered to autonomously detect abnormal conditions and stop. The Team Member pulling an andon cord on the assembly line is jidoka as much as an automatic machine.

At my company we define jidoka as a four step process that engages when abnormalities occur.

  • Detect the abnormality.
  • Fix or correct the immediate condition.
  • Investigate the root cause and install a countermeasure.

The first two steps can be mechanized or automated. Poka-yoke devices are but one method to allow a process to detect a problem and stop. But if you take a broader view every one of the mechanisms of the TPS is really designed to do these two things.

Time itself can be a powerful detection mechanism – if work cycles are paced to the takt time. What should be complete 25% into the takt time? How about 50%? Is the work progressing the way you expect it to? There is a huge opportunity to detect a problem while there is enough time to respond – instead of discovering the end of the day (or the end of the week!) that things are way behind. If the Team Member is given the means to immediately signal that she has encountered a problem (via andon, for example), then the response can be immediate.

Kanban also serves as a system to detect abnormalities. If there is inventory without a kanban attached, I know that either overproduction has occurred or somebody didn’t follow the rules. If the system has been running smoothly and there is a shortage (or overage), I know something has changed.

All of the mechanisms of lean manufacturing follow the same pattern. They are designed to operate with the bare minimum (just enough, just in time) in order to detect abnormal conditions of system changes that might otherwise go unnoticed.

But detecting an abnormal condition does no good unless there is follow up. Visual controls are just decoration unless they trigger action. The second step is Stop. A lot of people have a hard time with this because they think it means bringing all production to a grinding halt until the problem is resolved. Don’t get me wrong – depending on the nature of the problem, sometimes it does. But stop is frequently simply a mental shift. If means stop doing what you were doing because you need to do something different. It is an acknowledgement that some kind of intervention is required. That might mean shutting down a process or machine, or it might means signaling for assistance. What I would not want to happen is to expect the Team Member who discovered the problem to try to fix it without telling anyone. But many times we expect them to do just that – and the rework becomes so deeply embedded into the routine that we can’t even tell it is happening. It seems normal because it has never been flagged as abnormal.

The third and fourth steps cannot be automated. They are entirely the domain of people because they require diagnosis, analysis and problem solving. How well an organization can get through the steps of fix the problem and install a countermeasure ultimately decides whether they move forward into continuous improvement or slip back when just-in-time reveals a problem to them.

Step three: Fix or correct the abnormal condition means to get the train back on the tracks so production can resume. It might entail putting in a temporary countermeasure to avoid recurrence of the problem. It might require some fire fighting. It might require running an exception process such as putting in some temporary kanbans or putting a unit into a rework stall. It might mean shutting down production until a broken tool is fixed. These decisions need to be made at the lowest possible level of the organization, but no lower. As the scope of the issue, and its potential customer and economic impact increases, so must the level of what to do about it. If the solution requires violating the principles of the production system, it should not be taken lightly. There are plenty of ways to solve problems while maintaining system integrity. Every time you ‘bust the system’ to get something done you erode confidence just a little bit.

The last of the four steps is to investigate the root cause of the problem and install a permanent countermeasure. This is an opportunity to expand your knowledge of your processes and your production system. Depending on the nature of the problem, it could be a straight-forward solution. Of course it might also require enlisting your Friendly Neighborhood Six-Sigma Black Belt. Either way your system is improved. You will certainly have to prioritize your efforts, but do not just stick chronic problems into the “too hard” box.

JIT is powerful because it not only drives out unnecessary cost but it also helps detect problems that are the causes of waste. But jidoka is the response to problems. JIT is relatively easy to implement, but with out the mechanisms of jidoka in place to support it, JIT quickly erodes and the waste finds its way back in. When JIT and jidoka work together they form the engine of kaizen that drives your system to get better every day.

  • 0

What does JIDOKA mean?

In order to produce world-class, quality automobiles at competitive price levels, Toyota developed an integrated approach to production, which manages equipment, materials, and people in the most efficient manner while ensuring a healthy and safe work environment.

The Toyota Production System has been built on two main principles: “Just-In-Time” production and “Jidoka.” Underlying this management philosophy and the entire Toyota production process is the concept that “Good Thinking Means Good Product”.

Jidoka (or Autonomation) is one of the pillars of the Toyota Production system or TPS. Denso’s objectives should be to deliver products of a quality, price, and within a timeframe defined by the customer. Jidoka is the concept of adding an element of human judgement to automated equipment. In doing this, the equipment becomes capable of discriminating against unacceptable quality, and the automated process becomes more reliable.

The Japanese kanji characters for JIDOKA (pronounced gee dough kah) are a kind of pun on another word in Japanese also pronounced the same but written with a different middle character and meaning simply “automation.” The English word Autonomation (or “autonomous operation) was coined to convey the meaning of “automation with a human element,” because the middle kanji for DO in Jidoka includes a character representing a human being.

A good example of Jidoka is the Toyota power loom developed in the early 20th century. A problem existed with shuttlecocks that would stick and create defects in the cloth being produced. Before power looms, a weaver would be able to remedy any such problems before proceeding, but power looms continued mindlessly on, producing unacceptable quality that required the cloth to be unravelled and backed up, boosting costs and making quality suspect. The Toyota loom incorporated a simple stopper that was activated by a sticking shuttlecock, and thus the machine became more “human,” and “knew” when to stop. The end result was a reliable system that was cheaper to operate and produced the expected quality. JIDOKA prevents products with unacceptable quality from continuing in the process.

Examples of Jidoka in common use at Denso are the stamp interlock system on the testing stages. The stamps are inaccessible unless the testing process has been achieved successfully. The stamp must be replaced before the next test can be started. Another example is the go, no go gauges on the pipe bulging process. The operator must check the part in the gauge, which is interlocked to the machine. Only a successful bulge will allow the operator to proceed. A further example is the system of holes located in the side of the condensers. These holes identify to the machine the model and variant of condenser, fool proofing the build.

Summary Jidoka – Intelligent Automation, also called ‘autonomation’ and ‘intelligent automation’ is a pillar of the Toyota Production system.  Jidoka focuses on separating human and machine work by automating one element at a time cost effectively.  Productivity is improved and the operator’s role is changed to that of a load and unload role.  Error proofing and error detection is built into the machine process so that defects are not passed on.

• Improve productivity
• Improve quality
• Improve safety
• Enable multi-process handling
• Achieve low-cost automation

  • 0

Why Bill Clinton is alive and Steve Jobs is not

Transparency, the intention to treat and analysing data.




Why Bill Clinton is alive and Steve Jobs is not.


How do you select a surgeon or a Hospital? How, assuming you are sufficiently rich and powerful that you want the “best in the world”, do you find the best (or hire the best finder to find the best)?


If you need a liver transplant, you can go to a website called SRTR — Scientific Registry of Transplant Recipients. At this website, you can look up the mortality, one-year survival, five-year survival, waiting list mortality and other such statistics for various liver transplant centers. You can also look at waiting times for getting a liver and, if you have a private jet at your disposal which can take you anywhere, you can get listed at multiple centers which have a low mortality and a short time to transplant. Perfect, isn’t it? I’m sure the team which did Steve Job’s research for him did something like this.


To reiterate some of the information available in the public domain, Steve Jobs was initially diagnosed with a tumor in the pancreas. At the time of diagnosis, there was no evidence of the tumor having spread anywhere else and he was advised to undergo surgery to remove the tumor. Surgical removal is, for all practical purposes, the only treatment which can potentially cure a pancreatic malignant tumor. Steve Jobs, often prone to magical thinking and a personal ‘reality distortion field’ decided to treat the tumor with various quackeries including a vegan diet, acupuncture, herbal remedies and the services of a psychic. The tumor proved resistant to such measures and 9 months later he underwent surgery. It is possible that in that 9 months, the tumor spread to the liver. It was a relatively indolent tumor called a neuroendocrine tumor.


We do not know when it was discovered that the tumor had reappeared in the liver or what treatment he received. However, metastases from a neuroendocrine tumor to the liver do offer another opportunity for cure if the liver is removed and replaced by another transplanted liver. It is essential to ensure in such situations that there is no tumor anywhere else but the liver.


We know that he underwent a liver transplant at Methodist University Hospital Transplant Institute in Memphis, Tennessee. This center had a short waiting time to transplant and Steve Jobs, with a private jet at his disposal, was able to reach the hospital quickly when a liver became available. We also know that when he had the transplant, he had tumor deposits in the peritoneum. It is likely that if the patient had been anyone other than Steve Jobs the transplant would have been called off and the liver given to the next patient on the waiting list.


One of the things which keeps tumor under control is the immune system of the patient. It is known that tumors progress quicker in immunosuppressed patients and this is true of neuroendocrine tumors as well. In any case he died about 2.5 years after the transplant. He got what he wanted rather than what he needed.


Bill Clinton, on the other hand, seems to have done his research better. In 2004, Bill Clinton was discovered to have fairly severe coronary artery disease affecting multiple arteries. This would require a fairly complex cardiac operation. He underwent the operation successfully in the hospital that had the highest mortality for this operation in New York State, almost double the average for the State.


Why did Clinton pick this hospital and this surgeon?


One of the problems with having mortality rates and survival rates in the public domain is that it discourages surgeons from taking a risk.


If the median survival rate from liver transplantation (for instance) is 90% and the transplant team encounters a patients who is sicker than usual, say with a 70% chance of surviving the operation, the team becomes understandably reluctant to take on that patient. One option is to reject the patient before listing as ‘too sick to transplant’. If the patient was okay at the time of listing and becomes sicker while waiting for a liver then he can be removed from the waiting list as ‘too sick to transplant’. Once he is off the waiting list, he does not show up on the ‘waiting list mortality’ statistics. The patients who actually make it to transplant are those who have already passed this test by ‘survival of the fittest’. A center which decides to give the 70 percenters a chance at life will inevitably find their survival statistics drifting away from the median. When they move two standard deviations away, the program is on probation and soon insurance will stop paying for transplant at that center. However, one must remember that for the patient denied transplant, there is only death to look forward to.


Now let’s look at this from an ‘intention to treat’ perspective. We begin with 100 patients who need a liver transplant. At one extreme we deny all of them transplant and all 100 die.


In a more realistic scenario, we decide to assess the risk of transplant and we find:


10% mortality: 50 patients

20% mortality: 20 patients

50% mortality: 20 patients

90% mortality: 10 patients


Now Center A, which wants to keep up with the 90% survival statistics offers transplant to only the 50 patients whom they judge have a 90% chance of making it through the transplant. So they do 50 transplants, 45 of the transplanted patients survive. The remaining 55 patients die (5 after transplant and 50 without). The center transplant survival rate is 90%.


Another Center B, willing to be bit more aggressive and take on patients with 80% or more chance of survival transplants 70 patients. Of these, 45+16=61 patients survive and 39 patients die (9 after transplant and 30 without). The center transplant survival rate is 61/70=87%.


Center C doesn’t give a damn about their statistics. They just want to give every patient who comes to them a chance. They transplant all 100 patients. 45+16+10+1=72 patients survive. The center transplant survival statistic is 72%. 28 patients die.


If we judge each center by survival outcomes alone we see A:90%, B:87% and C:72%. The choice is easy isn’t it?


On the other hand if we look at how many of the 100 patients who presented with liver failure are alive at the end then it looks very different. A: 45%, B: 61% and C: 72%.


I’m not sure how Clinton managed to figure it out but he realized that the hospital in NY with the highest mortality was the one which was taking on the most difficult and high risk cases. They were used to managing such cases and gave him the best shot at recovery. Or maybe he just ‘went with the flow’. Either way it turned out to be a good decision.



  • 0

Most valuable metrics for a software project:

The Pizza Metric
How: Count the number of pizza boxes in the lab.

What: Measures the amount of schedule under-estimation.  If people are spending enough after-hours time working on the project that they need to have meals delivered to the office, then there has obviously been a mis-estimation somewhere.

The Aspirin Metric
How: Maintain a centrally-located aspirin bottle for use by the team. At the beginning and end of each month, count the number of aspirin remaining aspirin in the bottle.
What: Measures stress suffered by the team during the project. This most likely indicates poor project design in the early phases, which causes over-expenditure of effort later on. In the early phases, high aspirin-usage probably indicates that the product’s goals or other parameters were poorly defined.

The Beer Metric
How: Invite the team to a beer bash each Friday. Record the total bar bill.
What: Closely related to the Aspirin Metric, the Beer Metric measures the frustration level of the team. Among other things, this may indicate that the technical challenge is more difficult than anticipated.

The Creeping Feature Metric
How: Count the number of features added to the project after the design has been signed off, but that were not requested by any requirements definition.
What: This measures schedule slack. If the team has time to add features that are not necessary, then there was too much time allocated to a schedule task.

The “Duck!” Metric
How: This one is tricky, but a likely metric would be to count the number of engineers that leave the room when a marketing person enters. This is only valid after a requirements document has been finalized.
What: Measures the completeness of the initial requirements. If too many requirements changes are made after the product has been designed, then the engineering team will be wary of marketing, for fear of receiving yet another change to a design which met all initial specifications.

The Status Report Metric
How: Count the total number of words dedicated to the project in each engineer’s status report.
What: This is a simple way to estimate the smoothness with which the project is running.

If things are going well, an item will likely read, “I talked to Fred; the widgets are on schedule.”

If things are not going as well, it will say, “I finally got in touch with Fred after talking to his phone mail for nine days straight. It appears that the widgets will be delayed due to snow in the Ozarks, which will cause the whoozits schedule to be put on hold until widgets arrive. If the whoozits schedule slips by three weeks, then the entire project is in danger of missing the July deadline.”


  • 0

Pencil that has an eraser on both ends

Category : Facts , Funny , Quality Management

In an effort to get registered, an organisation had written, rewritten and written again many of it’s manuals, procedures, process descriptions and control documentation causing one of the staff to ask “what’s the difference between a regular pencil and an ISO 9001 certified pencil? ”

Answer: The ISO 9001 pencil has an eraser on both ends.

We certainly hope you don’t have this much difficulty meeting the requirements of the standard, and also recognize that the standard applies to organizations, not to products.