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.