[Infrastructures] RE: ITIL? (Rainer.Heilke@atcoitek.com)

[Rainer.Heilke@atcoitek.com]

> On Tue, Oct 11, 2005 at 09:31:50AM -0600, 
> Rainer.Heilke@atcoitek.com wrote:
> > But I think we may be straying off-topic for this list...?
> 
> Nope -- not off topic, just risking beating the horse well after it's
> dead.  ;-)

Cool. Hence the "?". I'll go ahead and beat the saddle a little, too.
May as well be thorough. ;-)

> The thing that struck me about ITIL when I first saw it was that it's
> completely an organizational solution -- they try to solve everything
> in that layer.  ITIL is so tools-agnostic that it seems to assume
> there are *no* tools -- and things that should be handled e.g. by a
> version control tool get handled by meetings and human procedures
> instead.  

Yet, at the same time, it doesn't really address the people issue. This
was why Microsoft's MOF training was good--they discussed how the
corporate culture and people's attitudes had to adapt. Our's hasn't a
snowball's chance in Hades. ITIL sits comfortably in that zone between
the actual people, and the actual tools. It makes it a very theoretical
construct.

> There is some merit to being tools-agnostic, as long as the document
> suggests that tools would help, and as long as the community culture
> encourages good implementations.  So far I'm not seeing anything like
> those traits in ITIL community culture.  Does anyone know of any ITIL
> implementation which uses anything other than human-executed
> procedures?

Wish I could say, "yes", but it would be a lie. I agree completely with
you.

> I think the success or failure of any of these procedure-based
> standards is all in the implementation.  ISO 9000, for instance, is a
> lot shorter than ITIL, and has a useful key idea; "say what you're
> going to do, do it, then say what you did".

Hence its relative success. I don't know if ITIL says anything
different. It's more a matter of ITIL taking five times as long to say
the same thing. Now, there are various details that flesh out the basic
concepts--which are helpful for companies to grasp the ideas--but the
core ideas boil down to essentially the same thing.

> cleanest was where the organization (IBM's Kingston Programming Lab)
> created a component for each department, team, or major workgroup in
> their existing bug-tracking tool; if something was wrong with any
> group's process, you'd simply write a bug against that group.

Wow, cool idea. We'd have bug reports out the wazoo!

Rainer