Structured Methods

A method is formalized experience. Someone encountered a class of problems repeatedly, noticed what worked, and wrote it down with enough precision that others could replicate the success without recapitulating the failures.

This collection draws from multiple traditions — Western, Soviet, Japanese, Chinese, Slavic, Indian, and others as they are added. Each tradition solved different problems under different constraints, developed largely independently, and each produced insights the others missed.

What Makes a Method

A method is not a principle. Principles are true but vague: "understand the problem before solving it." Methods are specific: they tell you what to do, in what order, and how to recognize when you're done.

A method is not a heuristic. Heuristics are rules of thumb that usually work. Methods are procedures that work under specified conditions — and the specification of those conditions, the Limitations, is as important as the procedure itself.

A method is not a framework. A framework provides a way of seeing — categories, distinctions, a vocabulary for analysis. Useful, but not actionable without interpretation. A method has a procedure; a framework does not. You can follow a method; you can only apply a framework. This collection includes methods, not frameworks. Ontologies, taxonomies, and conceptual schemes — however sophisticated — belong elsewhere. If it does not tell you what to do next, it is not a method.

Every method here includes:

Origin: Who developed it, when, and for what problems. Methods carry assumptions from their birthplace; knowing the origin helps you judge transferability.
Mechanism: Why it works. A method without a mechanism is a ritual. Understanding the mechanism lets you adapt when conditions change.
Procedure: What to do. The steps, in order.
Limitationss: When it breaks. Every method is a tool, and every tool can be misused. The Limitationss are not warnings to scare you off — they are part of the method, defining its boundaries.

Using Methods

Methods are tools, not laws. The goal is not to follow them but to use them — and to know when not to.

Start with the problem, not the method. Diagnose before you prescribe. A method applied to the wrong problem is not merely useless; it is actively harmful, because it consumes time and produces false confidence.

Learn the Limitationss as carefully as the procedures. The Limitations is not an edge case; it is the boundary of the method's validity. Operate inside the boundary.

Combine across traditions. The traditions are not competitors; they are perspectives. Each emphasizes what others neglect.

Adapt to context. Every method encodes assumptions about organizations, cultures, time horizons, and problem types. Transferring a method means examining those assumptions and adjusting where they fail to hold.

On Completeness

This collection is not exhaustive. It includes methods that have clear mechanisms, documented Limitationss, and demonstrated value across contexts. It excludes methods that are vague, untested, or fashionable without foundation.

Absence from this collection is not condemnation. Some valuable methods are omitted because they are too domain-specific, too recent to evaluate, or simply not yet included. The collection will grow.