Define the Problem First
On the maxim often attributed to Albert Einstein: "I would spend 55 minutes defining the problem, and five minutes solving it."
This principle cannot be verified in Einstein's documented writings. The earliest traceable version appears in a 1966 industrial engineering publication, attributed to an unnamed Yale University professor. The Einstein attribution solidified in the early 2000s and now circulates in dozens of variations.
The irony is instructive. The uncritical attribution to Einstein is itself a failure of the very analytical rigour the quote describes — people reached for the most comfortable source without verifying it. The quote became misattributed precisely because no one applied its own principle to the question "who said this?"
The core principle holds with full force regardless of its origin: in software engineering, systems analysis, and advisory practice, the most expensive mistakes occur not in execution but in problem framing. An elegant solution to the wrong problem wastes more resources than a rough solution to the right one.
A requirement stated as "the system should be faster" is not a problem definition — it is a symptom. A test that fails because "something doesn't work" is not a defect — it is noise. The first deliverable in any engagement is a verified, shared problem statement.
For MIM2000 advisory practice this means: measuring and improving the precision of problem definition is itself a form of value delivery. The crew bridges the gap between vague intent and precise requirement.