On the Critical Chain Project Management group I was suspected of being unprincipled because I made some disparaging remarks about rules (My view is that operating based on rules is less effective than operating on principles. Project Management is not one-size fits all.).
It prompted me to clear up some of the definitional issues. So first a few definitions I'm sympathetic with. First Rule:
- A prescribed guide for conduct or action
- An authoritative statement of what may or may not be done.
- Dominion: dominance or power through legal authority.
- Convention: something regarded as a normative example.
Next Principle:
- A fundamental basis for action.
- A fundamental truth as a basis of reasoning.
- A fundamental doctrine, truth or motivating force upon which something is based.
- A basic truth or law or assumption.
I've left out a number of definitions which state that a principle is a rule because, well, Humpty Dumpty said it best:
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less."
The definition is rather slippery. Here are some more thoughts on it:
"A principle internally motivates you to do the things that seem good and right. People develop principles by living with people with principles and seeing the real benefits of such a life. A rule externally compels you, through force, threat or punishment, to do the things someone else has deemed good or right. People follow or break rules. - source
"Principles are riverbeds, rules are pipelines." -source
"* rules: set limits, are a basis for exclusion, enable to us to argue right and wrong
* principles: are a basis for us to grow and expand, are a basis for inclusion, enable us to learn from differences." - source
My real point in this is that a set of project management rules is initially derived from a set of principles. It would be unusual for them to just be made up on a whim. They are perfectly valid and sound in the environment they grew up in, but sometimes they take on a life of their own and the fundamental principle behind them may fade from memory. Principles (in principle) are unchanging, but the environments that they exist in can be very diverse and a rule developed in one environment to achieve the desired actions may bring different actions in a different environment.
In practice, we often mix rules and principles in a single system. For example in Theory of Constraints the underlying principle is to focus on the constraint (identifying, exploiting, subordinating other processes to it, elevating it). A perfectly reasonable and useful principle. As this principle was put into action a number of rules of thumb came about. Some revolve around the mechanics - sizing of a project buffer for example, some are concerned about implementation - the rule that TOC must be adopted across the whole organization as another example, but my contention is that the "rules" should be reviewed and possibly adjusted for each different environment they are applied in. And when a rule does NOT comply with the principles, it should be eliminated or revised.
Rejecting or challenging or examining a rule in this situation does not indicate a lack of principle, rather it is a sign of attention to principle. Those who speak loudest about the tyranny of rules are often the most principled of all.
One quick way to determine if you have a principle or a rule is to ask "why?". If your explanation takes more than a sentence or two, then you have a rule.
