Does anyone know what the difference is between process and methodology? I sure as heck don’t, or at least I didn’t. So I looked both words up at webster.com and this is what I found:
Methodology: a body of methods , rules, and postulates employed by a discipline : a particular procedure or set of procedures.
Process: a series of actions or operations conducing to an end; especially : a continuous operation or treatment especially in manufacture.
We’ll get back to this in a minute, but first, a brief aside: The definition for the word process had five different usages. The fifth one was slang, apparently from a different era/locale than the one I reside in. It meant “conk”. You know, like “I’m going to conk you over the head if you don’t update that project plan.” I like the idea that even Webster sometimes feels beat over the skull by process.
Okay, forget about conk for now. I’m sure that was unnecessarily distracting, but I couldn’t resist throwing it in. Go back to the two definitions I mentioned and review the differences between them.
When I read them, and thought about them for a minute, I started to think about the biases about these two words that I already have (I hate process, but embrace methodology). I found the reasons for these biases in these definitions, and now I can boil it down to two simple metaphors.
A methodology is a box of tools. Use them however/whenever you wish.
A process is an instruction book, the step-by-step kind that come with a child’s bicycle or a new VCR.
This clarity of meaning was a sort of revelation to me. I now know why I hate process – it’s the same reason I have to force myself to read the instructions that come with new devices. 99% of the time I don’t need them!
I also understand why I tend to embrace methodlogies. I love tools! I recently bought a $500 commercial grade paint sprayer (not the crappy Wagner kind) just to paint my house with. That’s how much I love tools. Tools are always a value add – they have so many uses!
Process on the other hand, has little residual value once the “assembly” is done. Once that lawn mower or grill is put together, you can throw the “process” in a drawer (or trash) and never use it again! And there is certainly no value in memorizing the assembly process for a mower, unless you are going to be assembling the same mower over and over again.
Now, let me get one thing straight. I’m not saying there is no value in process. Process has its place. In corporate IT, process belongs in one place only, at a low level in repetitive maintenance/support activities, where it directs the step-by-step efforts of a minimally skilled IT worker or to implement controls around certain decision-making activities. For instance, it is probably worthwhile to define a process for shutting down an employee’s access once the decision has been made to terminate them. Also, a process should exist for the approval of expense reports, etc. These make sense.
Process is especcially useful in any sort of repetitive task, which is why it’s so great in manufacturing. Making the same thing over and over and over again certainly lends itself to a particular set of steps that ought to be optimized. Every scrap of waste effort should be eliminated to make the set of steps as simple as possible, reduce the number of tools needed, and the skills required to do the work.
I think this version of process would work great for IT work – at least that part of IT work that is essentially the same set of tasks repeated over and over. Unfortunately, very little of IT work that I would be interested in doing is this type of work. In fact, this is exactly the kind of work that is being out-sourced (rightly so, I might add). I don’t want to do it, and if you’re smart neither do you.
But the important work in IT, the progressive work that makes the company stronger, adds new capabilities, and enhances competitive advantage, is not repetitive, mindless work that we can slap a process on and turn over to an unskilled work force. Strategic work, work that matters, doesn’t come with a checklist or detailed step-by-step set of instructions. If it did, IT’s business partners wouldn’t need us.
No, the work that matters most needs two things: good people and good tools. Both are essential. Good people will generally find a way to get things done even without good tools, but they’ll quickly move on to better environments if their requests for improvements go unheeded. Good tools become weapons of mass destruction in the hands of the incompetent.
Good people and good tools (methodology) are more important than good process. As we mentioned before, good process is only applied to repetitive tasks. It shouldn’t be applied to work that is different every time (projects). Instead, IT needs to have the mindset (and confidence) to let good people take their toolboxes to a project, figure out the best way to use them, and then start getting things done.