Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.


The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."

Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams


Troy On Twitter

Recent Entries



Other Blogs


Friday, February 29, 2008

Mountains, Mole Hills & Dead Buffaloes

When the going gets tough, the tough get going!

Just over a week has passed since Pink’s 12th annual ITSM Event in Las Vegas and I have to say it was the most amazing event of my Pink Elephant journey. Having had the privilege of being at all 12 of our annual shows I can say categorically that this was the most impressive and down right fun on all counts. It was my pleasure to have spoken at several sessions and many of the readers of this Blog came up and introduced themselves with a thank you, and a kind word of encouragement to keep on trucking so to speak.

The topics of my sessions ranged from the lofty heights of IT Governance down into the technical geekdom of federated database strategies. However,  I have to confess that my favorite subject to speak about is Culture and Organizational Change. It also seems to be a favorite subject of many of the conference attendees since the room was packed with over 200 people and the doors had to be closed to the frustration of many who came later.

So why is this topic so important to so many people? In my view it is because the true difficultly in implementing IT Service Management is not a lack of knowledge, resources or tools but it lies in the heart of IT culture, politics and lack of people resources. I wrote of this a while back in a blog post I called “The People, Process Technology Flaw”.

The reality is that most organizations which fail to in their initial attempts at adopting ITIL best practice do so because of an underestimation of the task. The design of a process flow and the documentation of policy and procedure is really not that hard. You can take several smart people, disappear into a meeting room and emerge with a fully documented process in a couple of days. Especially if you leverage a great tool like PinkATLAS.  Ok I am guilty of a little up sell here, but I am very proud of this service smile

So why does it take several months to even begin to deploy this process? That is because, process design is not the hardest issue you face. While changing work practices is difficult you have to also layer on top of that task the requirement to change (beliefs, values, behavior, tools and management reward and incentive structures.) We might as well realize that what your are really doing is re-structuring the DNA of your organization on a shoestring budget.

Once we realize the true size of the task before us we can start identifying all the issues, risks and road blocks that can potentially cause the project and change effort to falter, stall and fail.

As a wise man once said: “A problem defined is a problem half solved”

Early in my consulting career I came across an excellent exercise to identify and develop a strategy for these types of issues called:

Mountains, Mole Hills and Dead Buffaloes


The premise for using this exercise is that you have just formed your new project team and described the vision and scope of the effort to them and you see in their eyes the wordless (and sometimes not so wordless doubts) that plague your own mind. Rather than denying these doubts and gaining an ulcer it is better to get them out on the table so to speak, classify them as fact or fiction and then develop a plan to deal with them.

However, before we go further we need to baseline a few definitions:

  • Mountain:A risk with a large impact and high probability to negatively impact to project success
  • Mole Hill: A risk with a smaller impact and probability to derail or damage the project effort
  • Dead Buffalo: An issue or risk that is perceived or real. However, no one is willing to name it due to political or social risk but it is present in the room like a stinking carcass of a dead animal. (These issues have to be identified and dealt with and hopefully shoveled out the door since they are very unpleasant to have hanging around the room)

To do this I suggest the following team exercise

Duration: 30 Minutes (longer and you risk a spiraling discussion of discouragement)


  • To provide an opportunity for creative risk identification and classification for issues that will potentially cause the project to fail.
  • To separate fact from opinion
  • To define high priority issues and risks. The exercise is not intended to solve issues only name them and place them in perspective.

Method: Using brainstorming techniques discuss all the issues that the group sees as a dead buffalo, mountain or mole hill to achieving a successful process implementation. Each statement must be placed within the following table. (sources of risk: people, politics, resources, time legislation, environment, technology, funding, competing projects….)

Define what constitutes “Fact” (group, consensus, historic, documented, measurable?)
Define what constitutes “Opinion” (group disagrees, difficult to measure, not documented)



  • High Risk - Fact Based: Document these risks in the project charter and request the project sponsor / steering committee to provide leadership and guidance. (this is their job)
  • Low Risk - Fact Based: Capture and monitor these issues in your project management risk log with mitigation strategies and continue to monitor them as potentials to turn into high risks.
  • High Risk - Opinion Based: Assign each of these issues to a team member for further research and follow up to translate them into one of the other 3 categories for the next meeting.
  • Low Risk - Opinion Based: Life is too short to worry about everything so drop these off your radar


With this useful exercise you have accomplished some key objectives.
You have provided a forum for your new team to begin their team bonding by sharing concerns
You have allowed your team to voice their concerns in the open with a constructive output
You have identified and set actions to key project risks
You have hopefully named and dealt with those nasty dead buffaloes

Troy’s thoughts what are yours?

“Great things are done when men and mountains meet.” ~William Blake

(1) Comments
Posted by Troy DuMoulin on 02/29 at 10:29 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Friday, February 15, 2008

To Record or Not To Record Password Resets?

Why Bother Recording Password Resets - Isn’t it more work than it is worth?

If you have ever worked on a service desk and or managed one (I have done both) you have probably wrestled with the question about what to do with password resets. Unless you have invested heavily in self service options this is one of the bread and butter elements and daily tasks that make the IT service desk a critical business function. The age old question surrounding this high volume service desk task is whether it is worth the effort to record these actions in your service management tool.

This year the question even got more confusing with the release of ITIL V3 which dictated that the “Password Reset” is not an Incident which is what I thought it was for the last nine years and now calls it a Service Request. The premise being that an Incident is a service impacting event.

Incident: (Service Operation) An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example, failure of one disk from a mirror set.

Service Request: (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example, to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

I suppose the thinking here was that the service is still available whether the user of the service has forgotten their password or not. The call to the service desk in this view is a plea from the user to be let back into the service that is happily humming along without them. Oh well I am not going to argue semantics on this one and in this case an old dog is willing to learn some new tricks and terms.

This re-classifying of the Password Reset now prompts another question above and beyond “should we bother recording it.” Now we need to consider whether the action should be recorded in the incident tracking system or the Request Fulfillment tool.

However, whatever you want to call this task we still need to answer the first question. “To record or not record the Password Reset.”

The arguments for and against this activity typically comes from two different schools of thought.

View Point #1: Best practice theory and principles says that every support or request action taken should be recorded in the service management tool. How else will we learn from our past and capture critical business data for reporting and management decision making. Also, it is important to capture the work effort expended in support actions so that we can accurately assess head-count requirements.

This is the classic view point of the ITIL champions and it makes sense from the point of view of logic. However, there is a counter argument to this view that is also based on logic.

View Point #2: Why should we take the time and effort to record password resets. It takes more time to record the bloody ticket then it does to reset the password. If we were to record a ticket for every time a password was reset we would be spending more time entering data into the service management tool then doing the support work we are being paid to perform. In fact if we record every password then customer service is going to suffer since the phone’s and email will not be answered as quickly.  As long as there has been computer systems with a login people have needed password resets. This is a fact of life and it will not change until all security systems are based on biometrics.

As for myself I am an advocate of view point #1. To provide some context for this opinion I will share with you a story from my consulting past.

The year was 1999 and I was managing a service desk for a major insurance organization. I had recently taken on this role as an interim manager on contract and was covering for a maternity leave.

In order to get to know the support issues I asked my new team for the service desk reports so I could get a feel for what types of issues we were dealing with on a daily basis. While comparing the phone stats for incoming calls with the actual incident records opened I found a huge discrepancy between the numbers. Digging a bit further the agents on the service desk were quite open about the fact that the majority of the calls taken on a daily basis were password resets. In fact over 60% of the calls fell into this category and not one of these calls were being captured in the support tool.

To make an already long article a tad bit shorter I convinced the agents after many discussions to begin tracking these calls in the tool. What we observed is that of the all the password resets they were doing over 50% were from a single mainframe based application.

Now curious and wanting to improve the performance of the service desk team I was managing, we did some digging aka “Root Cause Analysis.” It turns out that the security team had developed a policy so strict for this application that it was almost impossible to come up with any password that could be hacked and for that matter remembered by the users. To ensure that each user had a strong password they had removed the ability to use common words like the days of the week, common names or the months of the year and so on. On top of this they had built in the requirement to change the password every 30 days and of course you could not use the last 9 passwords you had previously.

Having this data I took the information to the security group and explained the service issue and request a change the the security policy for this application. To say they were unmoved by my argument would be an understatement. I was the service desk manager and a contractor on top of that and they were the security group, keeper of the keys.

So with a polite but firm statement that they were not about to change anything, I left the meeting.

For the next 2 months we carefully tracked the volumes of password reset against this application. With this data we developed models which demonstrated the business cost of hundreds of password resets a week on one application. Armed with this data with a business value attached I requested another meeting and presented our case again within the context of financial and productivity impact. The outcome was modest but still was an improvement. They changed the policy from 30 days to 60 for password changes.

Not much of a victory perhaps but this story does shed light on why I believe it is important to capture and record password resets in your service management tool. Yes every one!

The irony of my story is that during this process I found out that the agents were giving the users passwords that they knew would work. These ready made passwords were kept on sticky notes and posted on the walls of their cubicles. So much for security.

So in conclusion, yes it is important to capture data about password resets regardless of the effort.

Troy’s thoughts, what are yours?

What is not defined cannot be controlled!
What is not controlled cannot be measured!
What is not measured cannot be improved!


(6) Comments
Posted by Troy DuMoulin on 02/15 at 02:04 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages