Old Thinking vs New Thinking (Old Thinking Redefined)

The diagram below (from the internet) makes “Old Thinking” sound evil. What if we redefine “Old Thinking” so it doesn’t sound so bad?

Redefinition:

• Employees are biggest risk - we have the best employees; competitors might attract them; let's take care of ours
• Top Down Communication - Ensure everyone is informed of the CEO's thinking and company's plans; no one is unimportant
• Skill Over Behavior - our customers prefer reliable products and services over our friendly apologies
• Manage Time - efficiency and productivity are key competitive competencies
• Rigid Working Schedule - don't work over time, make time for your personal life
• At Your Desk - we provide you with all you need and your own space
• Work for the weekend - work hard, play hard. Complete your work for the week so you can enjoy your weekend
• Corporate Jargon - precise terminology is clear and efficient; be scared when surgeons have the same vocabulary as litigation lawyers
• Double standard - demand more from the experienced; be more tolerant of those learning the ropes
• Fear of Failure - think things through; use risk management
  Enrich shareholders - they are the moms and pops who have invested their lifesaving with us for their retirement
  

Deming and a System of Profound Ignorance

W Edwards Deming's famous (or in some circle, infamous) 14 Points traces its roots from his 'System of Profound Knowledge' (SOPK), a framework for thinking that he developed to help leaders (and really, everyone) understand what they need to know if they are to effectively improve (rather than destroy) the organisations they work in. 

SOPK consists of four components (Appreciation for a System, Theory of Knowledge, Knowledge of Variation, and Psychology) and the interactions between and among each of them.

In order to attain 'profound knowledge' one must have:

• A solid understanding of each component from a conceptual perspective (e.g., what is variation and why do I need to know about it?)
• A solid understanding of how each component interacts with the other three, from a conceptual perspective (e.g., how does a theory of knowledge impact how you interpret a system's behaviour?)
• A solid understanding of the above as applied to a domain (e.g., software development)
• A solid understanding of the above as applied to a specific organisation (e.g., this team)

Most of us will be familiar with one or more of the above components. But what about those who occupy leadership positions but are not aware of any of them? If they're using a different set of components, then they are using an alternative thinking framework, an anti-SOPK. The opposite of knowledge is ignorance, therefore such a framework can be said to be a SOPI - a System of Profound Ignorance.

What might the effects of such a framework look like?

• Lack of Appreciation for a System - SOPI practitioners focus on optimisation of each organisation sub-units, often turning them into 'profit centres', and comparing the profitability of each against the other. The psychology of survival kicks in within each sub-unit: Sales makes unachievable promises to customers, Purchasing seeks the lowest cost vendors, to the detriment of quality or reliability. Traders step over the bounds of ethics, The result: a system consisting of sub-units that fight for their own survival, a system that turns against its own best interests.
• Lack of Knowledge of Variation - SOPI practitioners look only at the most recent numbers. They celebrate when a target is exceeded, dishing out 'Well Done!'s to a few, and words of encouragement to 'Keep up the good work'. Disappointment occurs over the next several month's results as normal variation kicks in.
• Lack of a Theory of Knowledge - opinions and gut-feel rule the day. There is no appetite for going to the place where the data occurs (the gemba), no interest in persistent monitoring of phenomena, no rigorous approach to theory and experimentation to understand why things are as they are.
• Lack of appreciation for Psychology - SOPI practitioners ignore the psychological nature of people. They are surprised when people behave in ways that do not fit a deterministic, 'rational', linear cause-and-effect paradigm.

SOPK is both easy and demanding. The framework is easy enough to understand: just four components and their interactions; Deming suggests proficiency of any of the concepts is not required to begin using SOPK. 

Though easy, it is nevertheless demanding, for at least three reasons. 

First, each of the components can be a deep subject in its own right. Mastery of the concepts and principles take time. To reuse a description: a mouse can wade in any of them, yet an elephant can drown in any of them.

Second, while beginning to use SOPK is easy, the actual usage can be tedious. It is, after all, a scientific system demanding theories, experiments, validations. Mastery of application takes longer. Tenacity is required to keep using it.

Third, the insights that SOPK brings places its practitioners square against the mass of 'common sense'. The insights may say a cultural change is needed. Sometimes they direct us to a required change in the larger system. These types of changes take time and effort. In an era where instant results, 'decisive thinking', and putting out fires are what attracts attention and praise, it's not an easy place to be.

SOPK requires faith. But SOPI is the path of least resistance and instant rewards.

Hard Stuff is Sometimes Hard Stuff

Glen Alleman has a great little post about two ways to solve a problem (http://herdingcats.typepad.com/my_weblog/2016/10/making-hard-stuff-into-east-stuff.html)

The story about the mathematician who ‘reduced’ the problem to a known one is funny, and easily recognisable to software developers as well – solve part of the problem and hand the rest to a function library that knows how to solve the revised problem.  It is logically sound, even if impractical if taken to the extreme as in the story.

However, it may be too simplistic an example in the argument against #NoEstimates. If you were asked to estimate how long it would take to boil away a potful of water, you might think to revise the problem into looking up (or estimating) how long it would take to boil away a tablespoon of water, and then multiply that by the number of tablespoons of water contained in the pot. In this case, you have reduced the problem into multiple known ones.  All that’s left is to combine the results of the solved problem.  I don’t know for sure, but I suspect the actual time to vaporise the whole potful will take significantly longer than the sum.

Another thing that makes project estimating hard is the dissimilarity between projects (the ‘uniqueness’ of each project) -- it’s not always about boiling the same volume of water in the same pot. It’s boiling potentially a different volume of a different kind of liquid, using a different kind of pot, using a different kind of heat source, in an area with a different temperature and different air density, with different stakeholder requirements about governance and reporting of the progress.

Einstein–We Cannot Solve Problems With The Same Thinking…

When Einstein said “We cannot solve problems with the same thinking we used when we created them”, almost nobody takes this to mean that we need someone else to solve the problems created by another.

Book Notes: The Science of Success

The Science of Success: How Market-Based Management Built the World’s Largest Private Company by Charles G. Koch

Charles Koch, CEO of Koch Industries and son of Fred Koch, the founder of Koch Industries (originally Winkler-Koch), reflects on the principles and values embraced by Koch industries.  The author expounds on the strengths of the liberal approach to the market (liberal, as in ‘free market’, F.A. Hayek, von Mises, Milton Friedman).

This is a thoughtful reflection on how Koch developed and met its challenges. Not a lively read, brimming with common sense.

Some notes:

• The quotes at the beginning of each chapter is carefully selected and profound.  For example: “There is a natural aristocracy among men. The grounds of this are virtue and talents.”

Teamwork

Came across this advice.  From a systems perspective it makes sense.  The most team is not the one where everyone tries to be the best, but the one where everyone works well together.  The surest way to destroy a team is to rank the members.

To make the best team, make sure everyone is trying to be the best for the team, not the best on the team.

Except, people’s competitive nature will show up:

A: “I’m the best for the team!”

B: No, you’re not. I am!”

Two Corinthians and Trump

Some online commentators are sniggering at Trump for reading “2 Corinthians 3:17” as “Two Corinthians three seventeen”, instead of the more formal and conventional way of saying it as “Second Corinthians three seventeen”.

https://www.youtube.com/watch?v=8EIgHsGZAmk

Krauthammer says of Trump: “ …thereby betraying a risible lack of familiarity with biblical language and usage.”

Except that “2 Corinthians”, whether you read it as “Two” or “Second” is not biblical language. Not one person in the Bible refers to this book by the name it’s now known. The title “2 Corinthians” was given outside of the Bible; we probably don’t even know who first coined it and when. 

It’s genuinely easy for people to refer to it as “Two Corinthians” because it is written as “2 Corinthians” rather than “2nd Corinthians”  But it’s such a minor gaffe, I don’t even think it merits criticism. Certainly it’s not ‘wrong’. (Although it’s very clear from the video Trump was not at all, or no longer is, familiar with reading scripture)

I bet many people refer to those books that have numbers in front of their names as “Two Chronicles”, or “Two Kings”, especially in informal settings.  I know I do, even though I am familiar enough and interested enough to have learned to read Koine Greek at some point.

Two Lions (Humour)

Two aging, hungry lions spot a zebra.  One of them starts putting on his Nikes.  The other asked, “What are you doing?  Even with running shoes on, you can’t outrun that zebra!”  The other replied, “I don’t have to outrun the zebra, I just have to outrun you!”

Creative CV

Came across this very creative CV on LinkedIn.  It’s a great reminder that a CV is a marketing tool. It’s not an epitaph, or a chronicle.

Here’s a link to the original higher resolution image: Link.

Verification (and Validation) is a Waste of Time

Verification adds no value and should be eliminated from the system life-cycle.

From the point of view of quality control, verification (and to a lesser extent, validation), is no different to inspection.  Anyone who has taken to heart Deming’s teachings on the quality understand that inspection does not produce quality; it can only detect problems (and only some of the problems), but can neither prevent them nor fix them.

Deming on Inspection

“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

What is Verification?

Verification is the act of inspecting an artefact to confirm that it meets the conditions it is subject to.  For a manufactured products, this means it meets dimensional specifications, for example. In the case of a set of requirements, verification is about confirming that the requirements faithfully and completely address the agreed needs from which they were derived.  That is, if the requirements are fully implemented, they would resolve the problems stated in the needs.

(Lou Wheatcraft extends the definition of verification to include assessing the requirements against policies on how to write requirements, but the distinction is not relevant for this post).

Why is Verification a Waste of Time?

Whatever the scope of verification is, it’s about taking the artefact that is the set of requirements, and comparing it against the source from which they were transformed, in this case, the stakeholder needs.  If a discrepancy is found, then a different set of activities (not verification) is taken to fix the problem.  Verification DOES NOT transform the set of requirements.  According to the principles of lean, any activity that does not transform the product can be considered a waste that should be removed if possible.

Why do we need to perform Verification?

If it’s a waste of time, why do it?  The primary reason is because the methods and procedures we use to transform the set of needs into the set of requirements is imperfect; it provides us no guarantee that the transformation is complete. 

Think of that transformation as the function F(). We can model F() as:

F(N1, N2, N3, … Nn) = Ra, Rb, Rc, … Rz

where the set of R’s is the perfect set of requirements required to satisfy the set of needs (the N’s). If F() was perfect, and could be executed perfectly, we would not need to perform verification of this transformation.  The R’s we get perfectly deliver the set of needs N.

However, the resulting set of R’s is seldom perfect, because of two reasons:

1. We do not have a function F() that can produce it perfectly

2. Whatever imperfect versions of F() we have, we do  not execute it perfectly.

Therefore, we need to inspect the result (but what is that method we use to inspect and find the gaps? Could we not have used that in the transformation? No, because it’s not perfect either)

To further illustrate, when were taught how to do long division, we were also taught how to verify the results.  To divide 27 by 3, we execute the long division process to get the result:

F_division (27 / 3) = 9

To verify that the resulting output (‘9’) is a correct transformation, we use another function F_multiplication():

F_multiplication(9 * 3) = 27

If F_multiplication() results in a number that do not confirm the results of F_division(), we review the execution of the function, not the function itself.

Until we have a similar function or process or algorithm to transform needs into requirements, we are forced to do verification.  We can continue to look for ways to become more and more efficient in this waste activity, but we should attempt to keep improving the transformation function so we do less and less verification

Why do we need a WBS?

What is the use of a Work Breakdown Structure? There are several uses, but the main one is to let you break up and structure the project into smaller, ‘bite-size’ pieces.

Each of those pieces is a mini-project. You can apply project management principles to each of them.  Apply cost management, scope management, schedule management to each one. And because they are smaller projects, they will be easier to manage.

You can even delegate the management of each mini-project to a mini-project manager. Just remember that each little project is subject to its own constraints of scope, cost, and time, and therefore will focus on its own constraints, not on the constraints of the whole project. This is where integration management (the science of herding cats) is important.

Q: What’s the difference between a sceptic and a cynic?

A: I doubt there's any difference. Even if there is, I'm not gonna tell you what I think; you'll just make fun of me.