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. 

Agile vs Waterfall

Often heard: "What you experienced was not true Agile."

Never heard:"What you experienced was not true Waterfall."

Not So SMART Objectives

In a VUCA world, objectives must be SMART:

S – Subjective

M – Machiavellian

A – Adjustable

R – Reactionary

T - Tentative

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.

Book Review: Breaking the Code of Project Management

Breaking the Code of Project Management
Alexander Laufer

The genesis of this book come from Laufer’s observation that traditional project management principles need overhauling.  He argues that the growing realisation of the power of empowerment, the poor historical record of project management, the flawed foundation of a major project management tool (PERT), and ‘emerging paradigms’ in research and practice require a new investigation into what is needed to ensure project success.

Laufer is big on using stories as a means of learning and presents his reasons why.  The book brims with stories.

It gave me some discomfort when Laufer referred to the ‘Agile method’ as a ‘project management approach’, given its limited focus on product development (primarily software products).  He also makes the mistake of referring to the ‘four values’ (a pet peeve of mine).

No project management tools appear in this book.  You won’t find discussions of the WBS, PBS, Gantt Charts.  The focus is on what it takes to deliver projects successfully.

Laufer concentrates on what he calls ‘Results-Focused Leadership’, a framework of guiding principles, colour-coded for vividness: yellow for the spirit of will to win, green for planning, brown for implementation, red for people and organisations, and grey for communications.

Recommendation: A practical book on how to deliver projects, yet very different from the standard project management books which cover the tools and principles of project management.  It almost ignores traditional project management.