A great article on how technology does not fix process in CMDB

Here is another source, George Spafford, saying that tools are not the solution to configuration problems, change process is. As I have said, technology does not fix process. People Process Technology, in that order.

Thanks, George.


the order of PPT

With all due respect: I disagree on your order of PPT. People are attracting more and more attention, simply because this 'component' appears to be responsible for a large portion of the mess. But that is a temporary situation. The order of PPT - imho - would be Process - People - Technology.

You first need to know what you need to do. You can't start with a bunch of people and then think "Hey - What kind of business will we be doing the next year? Any decent product we may develop together? And would anyone buy that?"

Then you need to determine who will do that: find/train competent people to do the work. Even if we start out with an existing company, we will need to consider the question: "Given our line of business and the improvement we need to make to it, are these people the right people to get the job done?" Massive lay-offs that follow changing business patterns are a well-known phenomenon.

And finally you need to determine how you want the people to do the work and provide them with adequate tools to make the best of it. We have all seen the incompetent manager saying that their tool provider will solve their management problem...

This applies to a greenfield situation as well as to a redesign or improvement initiative.

Agree, mostly

Jan, I agree with you. I've always regarded process as the thing that helps you define the people factors - numbers, skills, organisation - and then tools at the bottom. There's always some feedback (yes, tools can suggest useful changes to process), but this is the ideal order.

The only sense in which I prefer people > process > technology is that you're usually using the formula to try to persuade people to do something. I have yet to try to persuade a process to change. (Persuading a bit of technology to change ... often tried, with great frustration!)


The Visible Ops Handbook


You should read George's book, "The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps", co-authored with Kevin Behr and Gene Kim.

Don't just read the content, look at the ads and the testimonials.

Some highlights:

Something must need improvement - Otherwise, why read this? pg 11
Electrify the fence. pg 28
Appendix F: CMDB table structure. pg 86 AND 87

George is not related to Gene Spafford the co-author of TripWire, page 98. This fact is submitted as proof I read this book cover to cover. It is a recommended read from the VP of IT where I work.

Read it? I own it

Read it? I own it, first edition.

The Visible Ops Skeptic

Did you see the graph an early chapter? Is it a graph of random dots? Can you find any real data behind it? "Top Performers" circled in the top right just where the reader would expect them to be!

"Top Performers" always find the root cause of problems. That's brilliant, why didn't someone think of that before.

Repeatable Build Library - "Servers are like fuses". Don't waste time repairing them, it's faster to just rebuild. REALLY? What about the data? How do you avoid losing data back to the last recovery point? And didn't Visible Ops just say "Top Performers" find the root cause of problems?

Why would a non-profit organization, itpi.org need to produce a book full of advertisements and testimonials?

Food for thought, Tom,

Food for thought, Tom, thankyou.

You give me the urge to re-read it, but that won't be happening for a while with my current workload. In the meantime perhaps some other reader cares to comment on the book?

IT Process Benchmark

Only $995


Cognitive Dissonance

I would recommend reading it more than once. The authors are very good at using cognitive dissonance to keep the reader on the hook.

An example:

* Some top performers can approve 1000-1500 changes per week with a 99% success rate.

* With practice a change meeting can take 15 minutes.

Most readers will probably remember just one of the previous statements and forget the one that does not reinforce their existing vision of a change process. If the two thoughts can be merged into one coherent process for change Visible Ops doesn't make an attempt.

I apologize for not being able to produce exact quotes or page numbers, I borrowed a copy of the book.

Am I missing the point?

I suspect that coginitve dissonance lies at the heart of many problems with organisations implementing service management, but I don't see how it applies in this case?

Organisations that operate effective,and efficient change management do the following:

They manage and control changes throughout their lifecycle - bad changes are identified as early as possible for rejection or re-submission following re-work.

They manage changes according to their priority, impact and urgency, taking into account risk. Hence most management effort goes into managing a very samll percentage of changes.

Authority to authorise changes is delegated and fedralised within a common overall change process.

Non-standard and emergency changes are the exception, not the norm. Wherever possible changes
are proceduralised.

Multiple changes are manged within a single release.

CAB is a decison making body, not a forum for discussion.

Where these approaches are taken it is quite feasible to manage 1500 changes a week and for CAB to last 15 minutes. Their will be a very small number of unique, high risk changes that CAB has to pay particular attention to, and because CAB will have been kept informed of the history of those changes throughout their lifecycle the memebers won't be coming to the meeting 'cold'

Did you find that in Visible Ops?

* Authority to authorise changes is delegated and fedralised within a common overall change process.

* Non-standard and emergency changes are the exception, not the norm. Wherever possible changes
are proceduralised.

These seem like reasonable and important points that could allow an organization to manage a large amount of change. But that's not what Visible Ops recommends, "Electrify the Fence" remove authority to make change. If an organization has already delegated much of this authority for change, but never had a federalized change process, would "Electrifying the Fence" help? A more cost effective route to a federalized change process might be to document the organizations existing change processes and integrate them into the overall change process.

In addition, I don't believe delegated or procedural change is ever discussed in Visible Ops. But I will read it again and post pages numbers if found.

* CAB is a decison making body, not a forum for discussion.

I need some clarification on what you mean by this. I think you mean that the CAB is not a forum for discussing technical risk and possibly other topics. I would expect that it could be a good forum for a cost/benefit discussion.

If you know of any guidelines on what subjects should be included/excluded from a change meeting please let me know where I can find them.

Fair cop

No, Tom , I didn't find it in the book. I was basing my comments on what I've seen work in multinational banks, telcos and energy companies who have managed to get a handle on the change process.

I was a little hesitent to put in the comment about change being delegated and fedralised because it is open to misinterpratation. It only works if people are clear that overall authority comes from the centre, and can be withdrawn at any time. It doesn't work if people carry on making decisons about changes because they always have done in the past. Tortuous analogy but my farmer friends usually only need to switch on their new electric fences for a few days before their sheep begin to presume the fence is electrified, after which the fence is as effective whether it is switched on or off.

As to the role of CAB - nothing that is debated at CAB should come as news to anybody. The CBA should be done the first time a major change comes before CAB, where a decision is made to proceed with design and build activity. When the change comes before CAB for authority to implement experts should have done the technical risk assessment, CAB has to decide if the residual risk is acceptable.

The overloading of Change and the CAB

OK - jimbo - you are articulating a point of view I have found very confusing in ITIL. Where the IT Skeptic says that the ITIL CMDB "can't be done," I say that the ITIL concept of Change "can't be done" and is so far removed from my operational reality as to be baffling.

I think we both have some significant experience under our belts; I've worked in education, retail, consulting, and banking, in organizations with a combined annual spend of $3.5 billion on IT. I have NEVER seen a CAB do cost/benefit analysis. That front end to the IT service lifecycle is variously called project portfolio management, project initiation, customer relationship management, demand management, and other terms. I have NEVER seen it called "Change Management."

Nor are the senior executives responsible for authorizing those investments ever assembled together in anything called a CAB or something similar. There is always an IT executive committee reviewing the major investments, but that's just part of their job, and the overlap between that group and the operational CAB is small.

Am I generalizing from too small an experience basis? Let me tell you a story. I presented at the 2006 ITSMF Upper Midwest (U.S.) regional, to a very full room of about 100 people, on an enterprise architecture approach to understanding ITSM. I posed the question to them:

"Do you see Change Management as

" 1) a holistic process for initiating all changes to IT services, including cost/benefit analysis and approval of major change initiatives even pre-project? Or

" 2) a primarily operational process with a 1-4 week lead time, focused on specific configuration changes to managed environments, for the purpose of communication and coordination?"

100% of the people chose #2. And there was a lot of muttering as people digested this. Some didn't even seem to realize that ITIL calls for #1.

Admittedly at one national EAC conference I asked the same and got a small minority indicating that they lean more towards #1.

See http://erp4it.typepad.com/erp4it/2006/05/whats_a_change_.html


Charles T. Betz

I'm not disagreeing with you....

....for instance with my current client even though the CAB is relatively high powered they only make cost benefit decisions about operational changes, for projects the CBA is done by the project steering group. However the project CBA is still seen by both projects and the CAB as part of both the change management process and the project lifecycle (which are integrated as part of an over arching Service Lifecycle)

Of course ITIL 3 will make the link to the service lifecycle much more explicit.

Just to clarify an ambuiguity in my earlier post -I'm not advocating that CAB does the CBA, but that the CAB should ensure a CBA has been done.

I'll be having a go at it

I believe ITIL has aspirations beyond its station. ITIL is an operational framework for IT production environments. So long as it knows its place and sticks to it, all is well. But every now and then it gets an inflated view of its own importance and starts poking into the development aspects of IT, or worse still the strategic ones. this is an example of the latter, where the book is hopelessly confused between operational and strategic aspects of change. the forums (fora?) are littered with confused postings. Sometimes a RFC is something that fixes a problem, at other times it is something raised by an end user, e.g. a request for application enhancement. the two are totally different things.

the answer I give clients right now is your option 2, Charlie. In a smaller organisation it can (in fact should) be 1 and 2. "Smaller" defined as "what's project portfolio?"

I'm holding off on this one until I get my hands on the V3 books, to see if they systematically address business change as compared to operational change. or put another way, ITIL V3 can do either of two things to clarify this: (1) grow to properly cover more than production operations (2) pull its head in to only cover production operations. If it does either, then issue solved. If not, I'll be having a go at it :-)

Tough row to hoe

ITIL will find it has a much tougher row to hoe in demonstrating relevance to IT portfolio management or enterprise architecture. It is seen as operational. The people who attend the ITSMF conferences are operations staff. They run data centers, Help & Service Desks and Change/Incident/Problem processes, with some spillover into the infrastructural ICT engineering concerns - not strategic IT. (You go to the CIO Magazine, Gartner, or similar events for that.)

The sponsors of the ITSMF conferences are selling operations management products. Portfolio management vendors are not there. SDLC/ALM vendors are not there. Enterprise architecture vendors are not there. If it's an HP or an IBM, they are selling their operations stuff, not their portfolio management or ALM solutions.

Agree completely with "aspirations beyond its station." While it has set the standard for IT operational terminology, it comes across as idiosyncratic with odd blind spots when it starts "poking into" those other established practice areas. I predict some strong, not entirely favorable reactions to material like the Service Strategies volume, regardless of the merits of its content. Turf conflicts? Almost certainly. Of course, that makes it all the more interesting.

I too am looking foward to seeing ITIL v3, but my skepticism runs even deeper than yours perhaps. It's a big IT community out there. When Peter Weill, Jeanne Ross, John Zachman, or Paul Strassman endorse ITIL v3...

Charles T. Betz

A CMDB relief

Listening to the podcast allowed me to feel it was OK to have "CMDB data" in different data sources (as long as there was a solid process). I keep thinking we were somehow doing it wrong. The vendor cool aid was giving brain freeze.

Thanks for the thaw!

Your comment provoked a new

Your comment provoked a new blog entry, thankyou.

Change process being the solution for configuration?

Change is not the reason for configuration management. It is a partner in the real task - understanding what IT infrastructure is required to provide a specific level of service and ensuring that changes to the items involved can be made in a risk managed manner. The level of risk deemed acceptable is likely a negotiated settlement between the service provider and the customer (buyer) of the service. We really need to start looking at the business reason for a configuration management system that is more formalized than the yellow sticky or personal memory of the staffers.

cool CMDB tools will not fix the problem

Change is not the reason for configuration management, agreed. That is not what the article said. It said that when there are configuration problems (i.e. the data is screwed), then cool CMDB tools will not fix the problem; decent change process will. As you say, the processes are partners.

Syndicate content