Addressing the Hierarchy of Guidance
Greetings from sunny Austin, as we endure our umpteenth consecutive day of record-breaking triple digit heat; today's forecast is only 105 F. I figure we have about 77 more such days to look forward to before we get a meaningful change unless a hurricane pops up in the Gulf. Just so we're clear, I'm not whining, merely sharing. At least you don't have to shovel heat out of the driveway.
I received a comment from Hanu Karavadi on the Stoutlining post from earlier this month, asking if I would explain the difference between various levels of written guidance typically found in organizations. Well Hanu, here we go.
Whenever this subject comes up (yes, it is a regular topic of discussion), I have a little drawing I use to illustrate the concept of the 'hierarchy of guidance.' (If it seems eerily familiar it may be because it was posted in one of my entries way back in November, 2007 titled, A Schedule and Process Walk into this Bar In that post, we took a look at the differences between -- you guessed it -- process steps and schedule tasks.)
This time, let's focus more on written guidance. Although this relatively simple graphic does not fully cover all the possibilities or terms that may be applied, it helps get the basic point across that there should be some clear relationship between various forms of guidance. Much like playing Jenga, removing levels from the middle of this hierarchy can send the whole carefully stacked structure tumbling down in a topsy-turvy cacophony of disarray.
Specific to Hanu's question, policies are typically related to providing high-level governance that is broadly applied as formal and specific expectations. Policies, (along with methodologies and standards) presume that some number of options might be considered generally available; of these alternatives, there are one or more prescribed options that are considered acceptable or otherwise constitute a defined approach. From a glass-half-empty perspective, they can also identify what is excluded or NOT acceptable. Gotta love those dress codes, right? "No shoes, no shirt, no salary."
Perhaps we can use IT as a more useful example. A policy states that all IT expenditures will be charged back to the consumer organizations. This policy may drive the adoption of ITIL or CobIT as the selected approach (as a methodology or standard) to manage IT services and thus fulfill the policy.
At the next level, processes are employed to further establish the specifics of what is to be done, and by whom. To continue the example, ITIL offers a general approach and terminology for how to define and catalog IT services; processes are developed by implementing organizations to specifically lay out the underlying steps taken in this environment, along with roles and responsibilities. Note that now we are discussing organizational specifics. To put it loosely in CDPE terms, a process is a set of interrelated activities that are event-triggered where a set of specific inputs result in a specific set of outputs (results).
But all of this guidance discussed thus far has only prescribed what to do, not necessarily how. How-to guidance is established through procedures, which are step-by-step instructions for how to perform one or more tasks. For example, a procedure might define how to perform the month-end close process for determining IT service costs and charges.
Supporting these processes and procedures are best practices and guidelines. A best practice offers amplifying how-to information that reflects a proven approach; for example, a best practice that explains a the best approach for zero-balancing the IT budget each quarter. Unlike procedures or processes, which constitute what we referred to as "Shalls" in the nuclear industry, best practices and guidelines provide "Shoulds" -- they are suggested but optional approaches that infer some situational flexibility on the part of the user. Best practices tend to be more educational in nature, while guidelines are more often structured like 'soft procedures.'
There are additional levels of guidance that can be established, such as work practices and instructions, but this is where the water gets murky, since these detailed documents are often defined differently within each implementing organization. There is also the concept of 'toolbox skills' which defines a set of minimum competencies necessary in order to be able to perform a given task, often by role or performance grade, but that is for another time.
OK, there you have it -- the hierarchy of guidance, understanding that all of these things we discussed should be driven by the missions and objectives of the organization in question.


