Juran on Quality by Design (Chapter 2)

Reading Chapter Two of Juran on Quality by Design (paid link)

Chapter 2 "Establish Quality Goals"

NOTES

A goal is an "aimed-at" target. A quality goal is a quality target you are aiming for. The goal would typically include "a number" and a "time table"

Some consider that setting quality goals is part of quality planning, whereas others have the view that quality goals are set outside of quality planning -- the purpose of planning in this case is establishing how to achieve the quality goals.

A vision has no connection to reality until it is translated into quality goals.  Planning is impossible until goals are established.

Tactical quality goals refer to goals designed to meet human (customer) needs. These include product features, process control features, etc.  They are set by middle management in order to meet the strategic goals.

Strategic quality goals are set at the highest level of the organisation. They are often driven by the company's strategic vision and policies. Examples of strategic goals are: "Improve product and service quality ten times (Motorola)", and "Reduce billing errors by 90% (Florida Power and Light Company)". 

Upper management should not become involved with individual tactical quality goals as there are too many, but they need to be involved with them at the 'collective' level.

Quality goals do not only come from customer needs. They can be driven by a company's concept which may need to be marketed to customers (an example is Walkman, which no customer 'needed' or asked for). Goals can originate from regulations, or from internal human desires to be meticulous.

Some of the most important bases of quality goals:

• Technology - in the form of specifications and procedures
• Market - quality goals that affect saleability should be based on the market
• Benchmarking - quality goal made with reference to what other companies are achieving
• Historical - performance in the past is used as the basis for performance in the future. Sometimes the goal is to improve on past performance. Sometimes the goal is ensure stability with past performance.  This basis can be a double-edged sword.

Quality goals are a hierarchy. Primary goals are at the top. These include 'personal health' or, for a car, 'effective transportation'.  Secondary goals are essential in achieving the primary goal, tertiary goals help achieve the secondary goals, and so on until each sub-goal is achievable in technological terms.

Planning is an essential part of achieving generating and achieving quality goals. Planning helps identify what sub-goals are needed (by asking: how can we achieve the primary goals?) and how each sub-goal can be achieved.

Deployment of Quality Goals

'Deployment' means allocating the goal to someone who will deliver the goal.

Strategic goals are subdivided in smaller and smaller sub-goals which are then allocated to someone (eg a middle manager). In Japan, that someone determines what resources they need to accomplish the sub-goal. This arrangement enable participative two-way planning.

Strategic goals are too big and systemic to assign to one person. However, it is imperative that every goal be 'deployed' (ie, allocated). One solution is 'teams'. A team is formed and assigned to deliver the goal. The example mentioned in Chapter 2 is 'Team Taurus', tasked to deliver the strategic goal of making Taurus quality best in class.

Provision of Resources

Goals need resources to achieve them. A key blocker to achieving strategic quality goals is the non-provision of resources to achieve them. The practice of developing strategic quality goals seeks to reuse the existing practices in business. Businesses have processes to allocate resources to define, administer, and delivery business goals.  Strategic quality should be approached the same way.

Corporate Interference

Expect resistance from various areas of an organisation when developing strategic goals. The key cause of resistance is the reduction in autonomy of the various divisions and functions. Strategic goals are directions from above, plans to achieve them by the divisions are approved from above, and people from above will be monitoring the division's achievement of those goals.  All three aspects are reductions in the autonomy of the division, and can cause friction, even in the most harmonious relationships.

Idenitfying the Customer

It's curious that Juran says the "next step" after establishing the quality goals, is identifying the customers.  It seems counterintuitive. Wouldn't you need to know your customers first before meaningful quality goals can be established?

Software Development Tools

 A job ad for a software engineer listed the following tools. I'm not familiar with half of them (not even by name).  Writing down the list as I'm curious to do some digging and find out what each are:

• Jenkiins (a continuous integration and deployment framework)
• AWS Cloud
• Azure
• Splunk (for logging and metrics)
• App Dynamics (for loggin and metrics)
• ECS
• Github
• Artifactory
• Kong
• OAuth
• Serverless technologies
• Node.js
• Automation
• Ansible
• Terraform
• Python 
• Java
• Linux
• CloudFormation
• RDS
• PostGresSQL
• NoSQL
• Angular
• ReactJS
• GIT
• Spring Boot

Make Up Your Mind (Chapter 2)

I have quite a number of books in my library, virtually all of them non-fiction. I'm starting to think there's not enough time to read them all. Skimming each one doesn't really help me absorb them, so I thought it might be interesting to explore the books by reading Chapter 2 of each.

Today's book is Make Up Your Mind, by Hal Mooz. The author is well-known in the Systems Engineering community as co-author of Visualizing Project Management, and Communicating Project Management.

Chapter 2 of this book is "Decision Fundamentals for Thinking Clearly". It's a short chapter and touches very briefly several topics relevant to thinking clearly.

We get a reminder that decision rigor is 'driven by the fear of a negative outcome'. This is something we all instinctly already know. We become more anxious when the decision has serious consequences (eg, which univerisity to go to), and are rightly less rigorous when the consequences are not serious (eg, what to have for lunch).

An interesting paragraph is on when do we actually 'make' a decision? Does deciding one way or another constitute making the decision or is further action required?  Some decision experts say you make the decision when you irrevocably allocate resources. (I had not heard of this before.  I think it's a good criteria). The author argues against it because it fails in some cases. His example is the decision to lose weight and deciding to eat less. Contrary to this criteria, the decider has actually decided NOT to allocate resources (food).

The author defines a good decision as 'applying informed judgment based on relevant facts and quality ethics to select an alternative and act on it'.

A short paragraph reminds us that the outcome does not define whether a decision is good or not. This is pretty much an obligatory topic in any decision making text.  Another paragraph covers another obligatory topic -- the fallacy of sunk costs.

Mooz introduces a concept new to me: 'Cost / Price of Indifference'. It is the purchase price at which you don't care (emotionally) whether you get the goods or not. He suggests this is a time saving concept when purchasing or selling anything. Rather than agonising hours and hours over how much to bid, just bid at this price.  He did not discuss this in the context of buying stock market shares. I think that will be interesting to consider. 

There are two stages to decision-making. The first is Decision Preparation. This is about getting the decision statement right, setting up the decision type frame, and the decision solution frame correct.  The second stage Deciding, which is about the act of selecting from the alternatives that were set up in the decision solution frame.  (The author didn't mention this, but I recognise this 2-stage framework as  classically systems engineering).

Other short topics covered is the decision maker's viewpoint, decision fitness, and decision fatigue. Decision Fitness is another concept I had not heard of before. This is a concept about the fitness of the person making the decision. They must be proficient at the following skills:

• Specifying the decision and context
• Determining the decision type
• Creating the decision type frame
• Developing the decision solution frame
• Creating viable alternatives
• Identifying and geting the comparative information
• Knowledgeably selecting the right judgment basis
• Skillfully applying the appropriate judgement process

A quick glance at the table of contents reveals many of these topics are covered in the rest of the book. 

This is a short book. At only 166 pages and with larger than normal font, it is misleadingly light-looking. Judging from the concepts introduced in the Chapter 2, it seems like a concept-heavy, deeply useful text.  Just considering the list of skills listed in order to be 'decision fit' shows you how much is required to be a good decision maker.  I'm not sure this thin book will be able to cover what is required to be decision fit, but if it gives exposure and awareness of the concepts, it will be worth further study.