Three Most Important Rules

<-- -->

The First Principle of Success


1. Define The Requirement
2. Define The Requirement
3. Define The Requirement

On the surface this seems like an obvious statement. I maintain that those who profess this as obvious are victims of its deception. The author has experienced this malady at all levels of business, corporate structure and while there is enough experience to write a book on this topic a few, simple principles will be examined.

In any effort there are competing department objectives and concerns. This can create a situation, which often produces results that reflects one department’s greater influence compared to others. For this reason, a neutral, comprehensive objective effort to “Define the Requirement” has a greater likelihood to achieve the desired results.

To “Define the Requirement” may seem intuitive and obvious, for the words seem to be self-defining. This is the insidious nature of this critical step. There must be a commensurate effort.

If you can’t clearly describe your requirement in words, perhaps it is not clear in your mind. Spoken words do not always accurately reflect what is in the mind, and spoken words heard are not always accurately understood. However, once the requirement is committed to words the chances of sender and receiver mis-communications are reduced, and more importantly, queries and arbitration and yield a set of words whose meaning can be agreed upon. COMMENT: Put the requirement in writing and coordinate the written requirement among the key, associated persons and reach a consensus.

Is your need a “goal” or an “objective”? A goal is not a requirement. An objective may be a requirement and a “task” is a requirement. A requirement MUST contain the specific information necessary to allow it to be achieved. If there are hard performance parameters, these MUST be specified. If you don’t know them, then you must either do the research to allow them to be quantified or you must state the range of acceptable parameters or state that they are unknown. Specifying the unknown is often as important as specifying what is known.

Often, once the requirement is specified the cost of acquisition or development can be quantified. Certainly a clearly defined requirement will be more accurately cost-estimated or budgeted, than a poorly defined requirement

After a requirement is specified in writing it is ready for formal coordination and approval. The decision-making level must have the necessary information before providing an approval to proceed or implement.

<-- -->

The Corollary to the First Principle

The best engineering solution is wasted solving the wrong problem.

Considering the corollary, extreme care must be taken to ensure that requirements definition is derived from those directly knowledgeable of the requirement. Second, the requirement must be stable, and not changing as it evolves in the mind of the those with the “requirement”. This may be an iterative process, and hopefully it will reach a point in the evolution where is becomes stable. The solution cannot be changing to match an evolving requirement.

Think About the Following

Getting what you asked for…
And it’s wrong.

Works great today…
But not adaptable/scalable tomorrow

Having the “Dog Watch the Hamburger”…
Better -- Unbiased checks and balances to insure compliance

Specifications and Deliverables…
Unless these are specified, the results are arguable.
Must have Statement of Work and List of Deliverables

Who’s on First?
Abbott and Costello classic is to be avoided.

All must speak the same language…
And are able to understand the language.

What is a POC?
Single Point of Contact – A must have.

Clear lines of management…
Designation of responsibility and authority