Archive

Requirements

Crosby’s Four Absolutes of Quality Reframed

I recently posted a quickie repeating Phil Crosby’s Four Absolutes of Quality.

I accept that many folks find his choice of vocabulary less than clear. So, here’s a reframing of his four absolutes, reframed in the Antimatter Principle vocabulary (a reframing which you may or may not find more helpful).

  1. The definition of quality is meeting everyone’s needs, NOT “goodness”.
  2. The behaviour that causes quality to happen is paying attention to folks’ needs, NOT inspection.
  3. The performance standard for quality is “all needs met, for all the Folks that Matter™️”, NOT “that’s good enough”.
  4. The measurement of quality is the cost of focus, NOT indices.

– Bob

Quintessence: Who Matters?

A sample chapter excerpted from my new book “Quintessence“ – book available now on Leanpub (free sample also available).

Note: Each of the eighty-odd chapters in Part II of the book takes a specific meme, and describes the collective beliefs and assumptions that quintessential organisations hold in regard to the meme. By taking all the memes in toto, we can understand the way quintessential software development organisations see the world of work – and what makes them so effective. This particular sample meme is about who matters.

Chapter 15. Who Matters

Quintessentially

Quintessential organisations regard the needs of their customers, staff, managers, investors, etc. as central to the way the work works. Collectively, these folks are sometimes called The Folks That Matter™️. These organisations invest much effort in:

  • Identifying the various constituencies and the people who belongs to these constituencies.
  • Tracking the set of constituencies, and the changing membership of these constituencies, over time. 

“Understand stakeholder symmetry: Find the appropriate balance of competing claims by various groups of stakeholders.”

~ Warren G. Bennis

The quintessential organisation exhibits the following (collective) attitudes and feelings towards the Folks That Matter™️:

  • A keen urge to understand and track the needs of all the Folks That Matter™️.
  • Inviting folks to come up with explicit policies for defining and tracking membership of the set of all Folks That Matter™️.
  • Practices to both discover and attend to these needs.
  • Defining organisational success in terms of needs met.

Quintessential organisations recognise the major costs and other risks arising from missing out key members from the set of all Folks That Matter™️. These risks receive their continuous scrutiny – both in terms of accurately identifying members and in terms of ensuring these members’ needs are attended to, and ultimately, met. All work of the organisation is geared towards meeting the needs of the Folks That Matter™️. Maximising the amount of work NOT done is achieved by cautious (risk-aware) exclusion of insignificant groups and individuals from the set of the Folks that Matter™️, whilst striving to drive towards zero the instances of omission of significant groups and individuals from the set of the Folks that Matter™️.

Stakeholders

Quintessential organisations recognise the distinction between stakeholders and The Folks That Matter™️. The needs of some stakeholders sometimes don’t much matter, and some of The Folks That Matter™️ aren’t actually seen as stakeholders (employees, for example).  Given these distinctions, choosing different terms helps communication and, more significantly perhaps, improves Cost of Focus.

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.

Who’s Afraid of the Big Bad Wolf?

The wolf in question for this post being “Requirements”. 

In a recent Quickie I presented Phil Crosby’s Four Absolutes of Quality. The first of these four absolutes being:

1. The definition of quality is: conformance to requirements.

Let’s unpack what Phil meant by “requirements”. His meaning was very different from developers’ and software folks’ typical understanding of the term.

Suppliers and Customers All Down the Line

In Phil Crosby’s world, everyone is both a supplier and a customer. “Upstream” folks supply parts, information or other things to their most immediate downstream customer(s). Each such supplier/customer relationship is mediated by a mutual understanding of, and agreement on, what the customer needs, and thus what the supplier recognises they must provide. Hence “Quality”.

And, by the way, reflecting the mental model of an organisation – stretching back upstream into the organisation’s supply chain, and downstream into its distributors and customers – as a “braided river” of value streams (see the image accompanying this post).

Mutually Agreed Interface Standards

It’s this mutual understanding that Phil calls “requirements”. Not some massive document with screeds of tedious detail. Not some specification of the supplier/customer “interface” written and imposed by some more-or-less clueless third party.

Fear

In my travels, I’ve seen folks of every stripe run a country mile from “requirements”.

Senior management don’t like the idea because they fear their freedom of action being constrained by such things. (Untrue, by the way).

Developers don’t like the idea because they fear being dumped-on by some requirements weenie who has a different – and often erroneous – idea of what the customer needs.

And most folks fear being corralled by a set of requirements that, even when accurately reflecting the needs of a customer, hem-in their freedom to supply what they like, rather than what’s needed. 

How do the folks in your organisation regard the idea of requirements? Do “requirements” in your organisation look anything like the Crosby definition?

– Bob

%d bloggers like this: