There's a glaring gap between what internal IT knows how to do and what businesses increasingly need IT to do to support the bottom line. To understand (and close) this gap, we have to revisit the difference between processes and practices -- a key, very large difference, especially for next-generation IT organizations.
In other words, IT's traditional emphasis on architecting and integrating large transactional systems may not be IT's best way forward. Luckily, that best way forward can be found in much of the way IT already goes about its work.
[ Find out the 10 business skills every IT pro must master. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line blog and newsletter. ]
Learning from tourism
An example of the difference between practice and process can be found in the hotbed of business innovation known as the Minneapolis tourism industry. Way back in 1996, when I wrote the IS Survival Guide for InfoWorld's print edition, I related the tale of the Minnesota Historical Society's RiverCity Trolley. Had David Wiggins, who ran the program, paid attention to what business consultants were advising, he would have created a well-documented tour process composed of a pre-defined tour route and a written script for his tour guides to follow.
Fortunately, Wiggins was either blissfully ignorant of what the world's business consultants were advising or wise enough to ignore them. What he did was give each of his seven drivers a stack of interesting materials about Minneapolis and its history. He also gave them the freedom to create their own tours. The tours received rave reviews.
Wiggins might not have known the vocabulary, but he understood the concept: Guiding tours is a practice, not a process. When you need quality, defined as the absence of defects, process is essential. But when you require "excellence" -- desirable features, the flexibility to customize, and the ability to outguess a competitor -- the cookie-cutter predictability of a process is exactly what you should avoid. You need a practice.
The practice-process continuum
It's been a while since we visited the subject of process vs. practice. To refresh, a process is a series of well-defined steps, which, if followed as prescribed, yield repeatable, predictable results. Disciplines like Lean, Six Sigma, and Theory of Constraints are about improving the design of business processes.
A practice, in contrast, is a series of broadly defined steps. How each is executed depends on the situation and the judgment and expertise of the practitioner. There are no disciplines or methodologies for designing business practices.
Think of process and practice as two poles of a continuum. Some business functions favor process -- assembly lines, for example. Others, like project management, are close to pure practice, but there are lots of examples that are partway between.
In IT, most of the work is more practice than process. Whether you're an old-school business analyst, new-school internal business consultant, or a project manager, systems architect, application engineer, developer, and so on, lots of what you do can't be reduced to a recipe that, even if followed faithfully, will get you through the day.
This doesn't mean you should be improvising -- far from it. What it means is that you need to recognize the extent to which you should predefine how work gets done and the extent to which you can't or shouldn't.