How does IT survive with no policy framework?

Policy - think documentation hierarchy

Some quick brainstorm thoughts: Lack of clearly defined policy is the primary source of process variation. Ed Deming suggested this with his 85 / 15% rule over 50 years ago. ISO 9k suggests a hierarchy of policy, process, procedures and work instructions / details repeated in the ITIL Glossary of Terms. To keep things simple for basic ITSM, consider using language from ISO20k as policy, ITIL as process, then have the people that do the work define procedures; work instructions / details generally include a customization of the tool documentation. This approach takes advantage of several basic realities. 1) Policy is mandated with the statement of you "shall" do this - ISO content provides a low bias source - relatively constant - minimal development cycle time. 2) ITIL is taught as process all over the world - leave it there - ITIL does not describe policy or procedure - it does help suggest procedural elements. 3) Using reference models accelerates the diffusion of innovation. 4) If the people who do the work create the procedures they're much more inclined to be care about performance - buy-in. 5) the people creating the documentation are humans. The book from the Achieving ISO/IEC 2000 series addresses some of these concepts in "Managing decisons and documentation" - see chapter 8 (BIP 0030) (ISBN 0580474585).

Often we find documentation a mix of all types of process related information from policy defined at a task level, to metrics and roles and responsibilities to micro details. Each of these are different elements. ITIL and COBIT documentation clearly separate framework components for a reason. It makes it understandable. This approach is simple and it works. If you start with process maturities less than level one, this approach can help accelerate improvement. ISO 20k's not perfect but when you have no IT policies, how much creativity is needed? And, who can argue with a policy that suggests all changes shall be recorded?

If documentation is a mix of policy, process, procedures and work instructions the shelf life is very short. How often should you need to update policy and process for incidents? I suggest policy and process should withstand organizational changes and be subjected to CAB / Config control. If you mix in procedures and details and tools and organizational unit IDs, with policy and process, and then mix it all together, it's tough to identify the contents and update when needed. Poorly designed documentation can increase process variation over time. This is what we typically have in IT today. Think of how you can increase the life expectancy of your documentation. Separate out the component parts, use the reference models to your advantage and customize your procedures heavily until you minimize your variation. This could be called a common sense approach. Keep IT Simple Smartie!

Oh, back to policy, granted some functional IT groups use the term policy at different levels, like in security or storage. Fine, preface your definitions properly such as IT Security policy, or ITSM Configuration process. An IT policy framework does not exist but the documentation hierarchy does exist - we should all understand the opportunity it provides to improve IT.

Signed, a Skeptic Fan
Thanks for the opportunity to share!

IT Policy and Governance

Often sysadmin make things work in-spite of local policy rather than because of it. At least in my experience. "Good" sysadmin want challenging and rewarding work; not mindless processes and best practices.

I am excited about IT policy and governance in only one major respect: this may allow IT a proper seat at the business table. Rather than being forced to implement and maintain poor strategic business schemes (and then blamed for their failure); IT has the chance to create a better business through externally acknowledged processes.

But, this introduces barriers and red tape to the sysadmin. Apprentice and Journeyman sysadmin should be only gradually introduced to these concepts. Raising caring and intelligent sysadmin is hard. Processes are easy. We need to find a balance for both in this brave new world.