ITSM Weekly the Podcast (Week11)

WOW what a privelege and a treat this weeks podcast.


Malcolm Fry, "founding father" of ITIL as he is known in the industry was our special guest.



Malcolm's insight and inspiration is truly fantastic, and it was a real treat to have him on the show.  He introduces to us "ITIL Light".  Which to be honest, I thought was going be just a chopped approach to ITIL.  Leave out the meaningful stuff and focus on the easy bits.


Well I was wrong.  (enjoy this comment while it lasts, as I'll be deleting it from history)

His approach seems not only logical, but productive.  Though I still questions the CMS phasing and starting point, it really is something I believe any shop no matter their size or level of maturity can start to undertake.

I look forward to finishing the book and sharing it's value with others.

Show Notes by the man Chris Dancy Here:  http://www.servicesphere.com/blog/2010/4/17/itsm-weekly-the-podcast-week-11.html
Thanks again to Matt Beran for his amazing audio editing.





ITSM Weekly The Podcast (Week 11) from ServiceSphere on Vimeo.

Immediate value of a CMS - yes it's possible

Configuration Management Systems (CMS) = VALUE... not for most people.

In fact most IT shops I've spoken to over the past 6 months have abandoned their CMDB/CMS strategies. Why?  ‘No immediate value’ has been their biggest complaint.  They are not seeing the benefits of having the relationships of assets. 
The clear distinction, between the organizations that are moving forward with their CMDB and CMS strategies and those who have thrown in the towel, has been the ability to effectively tie in their visual operations to their CMS. 
These successful organizations are leveraging the relationship information to show which apps are running on which pieces of the infrastructure and are providing a view of this relationship to their 1st and 2nd tier support teams.  Empowered with this information they are finding their troubleshooting process of elimination faster and more efficient. 
As any of us in the support arena know, the work to get systems back on line consists of 80% finding the problem and 20% fixing it.  So armed with this visual aid to help root out and verify the components that are working, the practitioner is closer to finding the one that is not.

So here is my advice if you are on the verge of blowing up your CMDB: 
First: Verify that you have the right grouping.  If your CMDB is grouped by technology, then it will not help Tier1 and Tier2 teams, who are  getting complaints about applications. 
Second: Create a visual element for the application and show logical relationships to the systems that support it.  Link those elements to your existing CMDB for more current and accurately collected data.   

It's by no means the Nirvana that ITIL V3 pictures for us, but it will at least allow you to leverage the work that you have done, and to start making the data and information you have more meaningful and relevant.

Check out these tools for a quick start and easy deployment: 

OpenSource - OneCMDB or BizDiag

Commercial  - NI2or MS Viso

Of course, BSM tools can be leveraged, but they are not going to be quick and easy to deploy.

Special Note: I am doing a weekly Internet Radio show called "ITSM Weekly" with Chris Dancy (ServiceSphere) and Matt Beran (Service Desk Manager).  Please check it out. Would love to hear your feedback.

ITSM Weekly The Podcast Week 1 from ServiceSphere on Vimeo.

Next BLOG - Is ITIL losing its steam?  Seems like the process framework is losing ground in the US; what does that mean?  What will replace it? 

The Art of Triage

To many, troubleshooting seems to be a gift that either you have or you don't. For instance, my father is a mechanic. When he owned his own repair shop he would hire young guys who would spend hours troubleshooting a problem, but then within minutes from my old man getting involved he could quickly diagnose the cause of a problem. The timing belt, carburetor issues, whatever it was, he was quick to pinpoint. Inevitably once the problem was found there was the “oh, of course” from the Junior grease monkey.

I was too clumsy to be a mechanic, so my dad fired me and forced me into Computers. However, I didn’t forget what I had learned about troubleshooting.

First, troubleshooting is not something you are born with. It is a skill that is harnessed based on 3 common factors:
1) What you know
2) What you don’t know
3) What you are learning

When you piece these 3 factors together you create the framework for discovery. By adding at negative and positive approach will then lead you down a path of what good troubleshooters simply call the process of elimination.

Do you know what is working? Do you know what is not working?
What don’t you know is working? What don’t you know is failing?
What have I proved with this step? What have I disproved with this step?

So when it comes to troubleshooting complex systems, the same principle applies. You just need to analyze them in layers. Here are the layers that VIGILANT has documented as the logical points to eliminate.

Infrastructure: Hardware, Networking, Operating Systems
Application: 3rd party application services
System Interfaces: Connectivity between dependant systems
Business logic: Business rules that cause transactions to operate differently
Business Process: The way the end-user is executing the transaction
Business Service: Dependency on data or other elements for success

For really complex issues, take each of these tiers and apply the 3 principles of discovery to them and you fill find the problem is not as much as a black-hole as you thought it was.

Why are we still fighting fires?

"We have spent so much money on monitoring tools and consulting, why are we still fighting fires?" I heard this from a recent prospect. The simple answer is because we live in a complex and high demand world. As IT proffesionals we are trying to do a lot with a little; little training, little vision, little strategy, little focus. Organizational process alone is not going to cut it. If we want to fight fires, then we have to campaign like Smokey the Bear. "Only you can prevent forest fires!" was his motto. What is yours?

How about these? "Only you can prevent outages from unplanned changes!"- By implementing some more rigourous controls around change and release management.
"Only you can prevent unnecessary downtime by distracting priorities!" - By implementing better incident management procudures, you could avoid the "SWOT" call mentality that takes the engineers attention off of restoring the service and diverts it into CYO for mangaement.
"Only you can prevent business impact from IT service failure!" - By properly planning and validating your infrastrcuture through capacity and load testing, infratstucure validation for fail-over and applicaiton profiling, you can ensure your build and release managment processes are catching issues before your users do.

Why are you still fighting fires? Probably because your processes are like disconnected piles of twigs and your culture is overly reactive.