When All You Have is a Hammer, Everything is a Nail

May 14th, 2015 | Posted by Don Boylan in Tools

HammerHave you ever heard the saying “If all you have is a hammer, then everything is a nail”?

This saying is often applicable to corporate environments when you only have a few (or one) of the core ITIL processes in place.

Since no company can simply let broken computers stay broken, they all have some form of Incident Management. At the earliest stages of a company’s maturity, they will have a tech expert… maybe an IT professional or maybe an amateur technical expert. They are the person you call when you have an issue with your computer. One company I know hired a stand-up comedian to help out with computer issues, and as the company grew, they promoted him until he was an IT Director. In most cases, this situation is not sustainable. At some point, the company reaches a critical size and realizes that Information Technology is a profession, not a hobby.

By the time the IT professionals join, the only process worth mentioning in these companies is Incident Management. The hobbyist who was hired off the street to be the Tech Guy/Girl probably cobbled together a tracking system using Access, FileMaker, or even (shudder) Excel. This primitive ticketing tool may hobble along as IT Professionals join the company, but at some point the company will be forced to replace it with a true IT Incident Tracking tool. As more IT Professionals join the company, they will start to look around for what tools are available to do their jobs, and since the Incident Tracking tool is the only player in town, they will start to use it for whatever function they need.

I have seen Service Request, Change, Release, and even the Software Development Lifecycle managed by borrowing the Incident Ticketing system’s tracking and notification capabilities. Can you track Changes or Releases in an Incident Tool? Sure, but there are a couple of issues here.

First and foremost, if you don’t have sophisticated reporting capabilities, you are really going to skew your break/fix metrics. I once saw an Incident ticket transferred 21 times between groups before realizing it was the programmer and QA teams passing a software defect back and forth as it went through its SDLC.

Second, Incident Ticketing tools are designed to capture details around outages and then enable IT to get the user back up and running as quickly as possible. Incident Tracking tools typically won’t have the flexibility to handle complex approvals (Change and Service Request) or testing and review cycles (SDLC and Release).

Using an IT tool for a purpose other than what it was designed for is the case where all the company has is a hammer, so everything becomes a nail.

Can you remove a screw from a piece of wood with a hammer? Sure, beat on the piece of wood until it’s destroyed and pick out the loose screw from the debris. Can you clamp two pieces of metal together with a hammer? Sure, if you pound on those two pieces long enough, they’ll stick together.

Can you use a Change Management tool to perform Release Management? Yes, but it’s a poor substitute for a Release Management tool that’s designed to track all stages and sub-tasks involved in complex releases.

Don’t beat on IT until there’s nothing left but debris, and then try to pick out the solution you should have provisioned in the first place.


You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

2 Responses

  • Bravo, your opinion is useful

  • Stan Eads says:

    Neil – These are excellent points, and I love this illustration about using the right tool. I have one question about your terminology. You say “Incident Ticketing tools are designed to capture details around outages and then enable IT to get the user back up and running as quickly as possible”. My question is around the assumption in this statement that an Incident (any incident) is associated with a “user”, when the ITIL definition of Incident makes no mention of a user at all. Incidents are events that impact or may impact the delivery of an IT SERVICE, and it may or may not involve impact on a user. In my organization, most Incidents are detected, and normal function restored before any user is impacted at all, therefore there is never a user directly associated with such an Incident.

    In the cases where users are impacted, they call the Service Desk, and trouble tickets are entered. These are then linked to the Incident. When the Incident is resolved, the Trouble Ticket owners are automatically notified, and they can notify the users. This rarely happens, except in the case of network/wireless Incidents.

    I would like to hear your thoughts on this.


Leave a Reply

Your email address will not be published. Required fields are marked *