Customer Reviews

IT Problem Management

5 star:		(4)
4 star:		(0)
3 star:		(2)
2 star:		(0)
1 star:		(1)

 

 

This is a great book for anyone involved in help desk or service center activities. I recommend this book for all IT professionals involved with production systems or anyone interested in IT methodology. This book gives the reader an appreciation for the documented processes and documentation that must be in place for a successful help desk venture.

This book has process flows for the entire problem management arena complete with guidelines on how to pick the most successful strategy for your company. It helps you with the decision process by offering pros and cons for each strategy so that you can tailor the strategy for your own goals and objectives. Also present are strategies for escalating problems and the structure that must be in place to support the strategy.

Other strong points of this book include the detail provided concerning the problem prioritization process, documented Triage processes, and escalation procedures. It also covers the documentation that must exist in order for a help desk to strive for cost effectiveness while meeting the goals of its customers.

This books helps IT professionals in the decision making process, whether you are currently involved in help desk activities, preparing to start a help desk, or migrating your current help desk into a service center. I gave this book to our help desk and they quickly ordered a couple of copies for the other managers. This is truly a first rate narrative.

This book does, indeed, represent the first of its kind to extend problem management from a help desk function to an enterprise-wide process. Moreover, it contains some of the best practices and processes I have ever seen in print.

Here are some of the highlights of what the book proposes that I know from experience works in an optimal fashion:

*Managed response model, where the help desk validates issues, prioritizes them and sends them immediately to the proper tier-2 group for resolution. This is far superior to a model where the help desk attempts to resolve the issue because too many go to tier-2 anyway. In my experience the managed response model more closely aligns IT to business (tier-2 also functions in an account management role if the process and organization is mature), and there is no hand-off (tier-2 owns the problem, the help desk owns the problem management process).

*The concept of a service catalog (sometimes called reference data or systems taxonomy) that allows you to capture metrics that lend themselves to Pareto analysis for system failures, etc. This is important for prioritizing fixes and patches to be released in future versions of an application.

*Clear definitions of severity, priority, escalation and elevation. These are too often misunderstood or misused terms, yet each is an important element of problem management.

*Detailed process for escalation and notification, which is not always implemented properly if implemented at all.

*Linking problem management to service level objectives and business goals. This is alluded to in many help desk books, but rarely addressed in the detail that this book provides.

*Alignment of problem management to other related processes, notably, change management. Finally, this dependency is recognized and discussed in a mainstream book. *Complete strategy for gathering and analyzing *relevant* metrics. Some gaps, but the approach is on target.

*Service delivery as a concept and process is clearly described. I cannot count the times I have had to define "service delivery" and distinguish it from "application delivery" (the former addresses supporting applications in production, the latter is how they are developed and released into production - operations and maintenance vs. development and project management).

Nothing is perfect, and here are some of the gaps I found:

*No clearly defined acceptance criteria for bringing applications into production - the service center (help desk) should get, at a minimum, service level agreements, application profiles, troubleshooting guides and a criticality profile for every application going into production. These should be considered to be the minimum entry criteria for supporting an application.

*Excellent discussion on priorities was marred by a lack of discussion about how to go about establishing a uniform baseline. I use a spreadsheet developed with a colleague that computes a criticality profile based on quantitative and qualitative measures. In my opinion there needs to be an enterprise-wide set of criteria for determining the criticality of applications if prioritization of issues is going to be repeatable.

*While the metrics approach is comprehensive it does not address aged issues. Consider how much more effective and meaningful it is to know how many open issues are over 1, 2, 4 and 6 weeks old, and how many from each of these buckets have been closed during a current reporting week. Contrast this with a simpler total open vs. closed this week measurement and you will see how the simpler measurement does not show the true effectiveness of the support organization.

Despite the gaps I noted this book makes an invaluable contribution to service delivery and IT process maturity. Overall I am impressed with the author's approach and consider this book to be essential reading for help desk managers, service delivery professionals and upper IT management. This book with jump-start service delivery if your company does not have clearly defined processes and procedures, and will give those that do some excellent ideas on raising the bar. Gaps notwithstanding, this book earns a solid 5 stars.

Finally! A book that addresses the fact that problem management goes far beyond the help desk domain and extends to encompass all of IT. Problem management the key to IT/business alignment because it directly supports achieving reliability, availability and service objectives.

The approach taken in this book is, like all other books in the Enterprise Computing Institute series, to address people, process and technology.

The authors start this book with standard fare on help desk organization. This information is available in virtually every help desk book on the market. However, the discussion becomes interesting when process is introduced. I thought the chapters on response models and service catalogs were particularly valuable. They certainly reflect the best practices that I have had to discover on my own as a service delivery consultant.

Because I develop and implement service delivery solutions for a living I was gratified to see a chapter on this discipline. While I found little new here (I do this for a living), the approach is sound and the focus on tiers 2 and 3 roles and responsibilities is something that is consciously missing from all of the books on help desk management that I have read.

I did learn a lot from the chapter on knowledge capture and sharing. This is an area that I have found to be weak in every organization in which I have had a consulting engagement. While there has been a lot written about capturing and sharing knowledge at the tier 1 (help desk) level, little has been written prior to this book about capturing and sharing knowledge across IT from a problem management point of view. Although this chapter does not provide detailed solutions it does give ideas and a good starting point from which to approach this aspect of IT problem management.

The book ends with four final chapters that give a high-level overview of managing the process, service level agreements, service center tools and how to motivate IT participants in the problem management process.

This book fills a large void in the IT service delivery body of knowledge because it is the first to address problem management as something larger than help desk operations. It extends the problem management process to tiers 2 and 3, which is something that the help desk books seem to only briefly address if they address it at all. Moreover, this book contains processes that are essential for aligning IT to business. As such this is a valuable addition to the professional body of knowledge for help desks and technical support specialists. If you work in production services or IT management you should definitely read this book you will also find the information in this book to be invaluable.

This is a decent overview of incident management and the processes that go along with the basic running of a Service Center. However, it is by no means about Problem Management as defined by the ITIL framework from which it takes its name! I was astounded to find the book not even distinguish between general help desk functions or workflow and Problem Management. While the book had some good perspective (especially the preface) on the Service Center development from basic help desk to a full-fledge customer support center-- and had some nice overviews and flow charts to illustrate different processes-- this book is not about Problem Management and root cause inquiry at all. While the writing is not great, it's not as bad as others here have portrayed. It does read like a freshman college textbook, which definitely took me aback, and there are points where the author elaborates on points over an entire page that could have been left to a paragraph, but overall the writing is at least straightforward and clear, avoiding hyper-complex sentence structure as I have exemplified in this review. ;-) This book is a decent beginner's overview of incident management and worthwhile reading to those looking for more formal processes, call incident flow charts or are starting a help desk from scratch.

This book appears to be a compilation of some handouts provided during a course or seminar.

I hope there is a better book available.

The content of the book is obviously interesting for people starting a help desk or any IT service department. I would just like to stress that it is badly written. Typical I-don't-have-much-to-say-but-I-will-say-it-in-200-pages syndrom. Example? p36 "Problem can be discovered either before or after they occur" Waow, that's information! p35 "Problem identification is simply the processes, methods, and tools used by the service center to indentify a problem". Hey M Walker, never learnt one should not use a word in its own definition?
What's more the book isn't much instructive. Example? It is said that one can use the "queuing theory" the anticipate resource needs but don't expect the book to explain what this theory is.

I am currently working with returns and customer complains, this book helped me to lay out the problem solving procedures, flow charts and documentation. I would recomment to the people who are seeking solutions for IT or other problems.