|Kurt Gödel (1906-1978) is |
one of the most important
logicians ever - right up there
with Aristotle. My idea is
not in the same league
as Gödel's Completeness
Theorem, or indeed,
any of his work --
but I find him inspirational
so you get to see his picture.
(Image from wikipedia)
|Julian's Practical Completeness Theorem|
The output is complete enough
when it is useful enough.
This can't be simplified to "the output is complete when it is useful" because that kind of statement puts perfection over performance. This reflects a characteristic of business and biology: performance is determined by being successful enough, often enough. This is distinct from completeness in a logical or mathematical sense: that is determined by perfection. I call this 'performance over perfection' -- one of four Personal Principles that I attempt to adhere to in all things.
What is 'Useful'?
The "useful" part of "useful enough" is determined by asking a few basic BA questions:
1. Who will use the outputs of my work?
2. What will that person use the output for?
Each person using a requirements document could have a different purpose for that document. This means that 'complete enough' is likely to vary for each stakeholder. This is often reflected in the structure of the output, the specific details of the output, and the representation of the output (written, verbal, simulation, model, etc.). An "unmeasurable requirement"* probably isn't useful to the person attempting to create a test case, but a directional goal could be quite useful in a presentation to stakeholders.
What is 'Enough'?
When techniques and templates and standards and reports and so on are based on these ideas they tend to be relatively simple and reasonably reliable. When these things are based on perfection over performance they tend to bloat out with useless information, useless details, and useless tape.***
The Practical Completeness Theorem In Practice"Rules exist so you think before you break them."
- Terry Pratchett
For Change Agents, many rules are encoded in the templates and processes and standards of the change methodology being used. It takes a lot of effort to figure out 'useful enough', and when you repeatedly have the same stakeholders, needing the same information, it makes sense to 'hard-code' those factors into the work. This saves time and effort -- especially mental effort -- and in some cases it can dramatically improve performance.**** There is a cost of this structure, of course: a loss of flexibility.
This means Change Agents often run up against templates and processes and standards that 'don't make sense' or 'get in the way'. When this happens, take Pratchett's advice: think before you break the rule. When a template has a section you don't use, ask "who uses this information, and for what purpose?" If the answer is something like "In 1983 the folks running the punched-card input terminals needed to know it," perhaps it is time for a change to the template. Often the answer will be "Not me, and I don't know," which is not good a enough reason to break the rule. Ask around. Find out. Often, the answer is surprising, and in many cases it will lead to significant improvement opportunities. For example, you may discover that the information is needed by a stakeholder you never considered, and that it could be provided with less effort and in a more useful form.
*In quotes because it isn't a requirement unless it's measurable -- even if you can jam the words together grammatically. "Spantle a kivalot" and "colourless green ideas sleep furiously" are also grammatical nonsense.
**Evidence is usually preferred to belief, but not always. That's another personal principle: evidence trumps experience. The complete statement is "time permitting, evidence trumps reason which trumps experience."
***Of the red kind.
****Checklists for pilots and surgeons are examples.