Which comes first, the process or the tool?

If you have embarked on Service Management improvements you have undoubtedly looked at tools to support process needs.  Whether that is a CMDB, Service Monitoring tool, release management tool, etc.  I was recently participating in a discussion on purchasing a tool prior to process development or whether it was best to take the time to define the desired process and purchase/build a corresponding tool that meets the criteria.

My thoughts were along these lines... At a basic level, when an IT shop is looking at purchasing a tool of some kind, they should always have requirements identified ahead of time.  This doesn't always happen, but it should.  Depending on the estimated cost of the product or solution, a formal RFP might be developed to map out the IT shop’s requirements for that product.  Otherwise, how do they know what to get?  If they don’t figure that out first, how will they know they have what they want when they buy it?  Whether simple or very detailed, an RFP of some sort is usually created.

IMHO, the same is true with respects to the tools and processes.  How can I get a tool if I have not identified the requirements first, which in this case, would be the process.  Take SMS as an example.  If I need a solution for mass software distribution (and that is strictly how I view my need) then I come up with all the technical requirements (very few based on process most likely) for an RFP and, of course, I end up getting SMS as the best solution :). If, however, I want to find a software tool to support my Release Management process, assist in configuration management, and provide ways to speed up incident resolution, now I am viewing it differently.  By stating it this way, I have a desired process need identified as my requirement, and then I would look at a tool to allow me to best automate parts of that process.  Now typically no tool satisfies all my needs completely out of the box, so I would head towards the most easily extendible solution available so I could build custom solutions around it, again to meet my process needs.  Still SMS of course. :)

I have seen many instances where this happens in reverse.  Typically where a "cool new tool" is discovered in the media and the search begins for a "need" to fit it.  The tool is purchased and then dictates the process.  In many cases, what is missing is just a better process.  This usually causes a step backwards and more time is spent in “reactive mode” with respect to process needs than would have been envisioned.  Then worst of all, this results in defining a process in the middle of reaction (usually crisis mode), which can create a process that breeds more crisis.

This said, I think there is a balance of getting to a v1.0 of the desired process and finding those tools(s) to help automate / supplement that process.  At some point the line must be drawn for something to be in production or it will never get to production.  Process assessment, development, implementation, optimization is a cycle that shouldn’t end, but caution should be taken to not get stuck in development with respects to process.

In short, I would always encourage process first, but that's just me.