Understanding the difference between process and practice is the key to moving IT forward. After all, modern business is transforming from mass production in favor of customized services, and IT will have to alter its approach to support this ongoing evolution.
Process consulting, whether Lean, Six Sigma, Theory of Constraints, or Figure It Out 'Cause We're Smart People, is a practice, not a process. Interestingly enough, most of its practitioners don't even understand the distinction, even though understanding the difference between the two is critical to figuring out how work should be performed. Irony, anyone?
[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]
Process, you'll recall from last week's Advice Line, "Why the future of IT rests on one person," is essential when your goal is mass production -- in other words, to efficiently create large quantities of identical products. So long as everyone involved in the process executes each step and handoff correctly, the outcome is success. (Everyone actually includes everything, too, as some steps will be handled by information technology, robots, and other forms of automation.)
Practice, on the other hand, is the emphasis when each work product is tailored and distinct. Creating process designs, for example, falls under the heading of practice. If a process consultant were to follow a process -- that is, perform the exact same steps the exact same way every time -- well, it can't happen because consulting in all its forms involves, at times, asking people questions, noting their answers, and asking new questions based on their answers. The exact same steps, executed the exact same way? It can only happen if the consultant ignores what the respondents are saying.
(No wisecracks, please, and whatever you do, leave "Office Space" out of this. My name is, after all, Bob and I am a consultant.)
When do you need a single-actor practice -- a practice handled by an individual? Before we take that on, let's drill into the concept a bit because the line dividing single-actor practices from other forms isn't hard and bright. It is, in fact, quite fuzzy.
In its purest form, a single-actor practice requires only an individual. A financial analyst, for example, is a single-actor practitioner, answering questions asked by various executives through the use of everything from garden-variety Excel to a business intelligence (BI) tool connected to the company's data warehouse to Internet-driven access to external research to ...
Hold da phone. That external research: It was performed by human beings, which means the single-actor practice technically involves multiple actors.
Maybe that's OK because there's no interaction between the analyst and outside researchers. But how about situations where the analyst has to call executives, managers, and line employees to gain additional understanding of how things really work?
Call it the John Donne effect: No one is an island, not even the practitioner responsible for a single-actor practice. It's still a single-actor practice if the practitioner sometimes calls on others for information.
Let's go to stage two. We'll call stage two hub-and-spoke practices. Take life insurance claims handling; it's a good example because it also illustrates the luxury/commodity divide that's one of the driving forces behind the rise of single-actor practices.
Many, and perhaps most, people who have life insurance carry a single policy. When they pass on, their beneficiaries contact the life insurance company, which notes the date on which the policy holder died, issues a check or checks to the beneficiary or beneficiaries, and terminates the policy. The beneficiaries interact directly with the insurance company's claims-handling process. Interactions are undoubtedly polite, but probably impersonal except for a courtesy call from the insurance agent who sold the policy.
Single-policy customers are the 80 percent who provide 20 percent, more or less, of a life insurance company's profits. (More accurately, they provide 20 percent of the investment capital the insurance company uses to make its profit -- a distinction that's important if you're running a life insurance company but not for our purposes here.) The important customers, the ones who provide 80 percent of the profits, own a variety of financial products: for example, a small burial policy, universal life, one or more annuities, and a mutual fund portfolio, all managed by the life insurance company as part of its financial services.
Imagine we're responsible for designing the system through which our hypothetical life insurance company handles claims driven by the demise of one of these high-value customers. Would we apply a process discipline to define a workflow that's as efficient and automated as possible, driven, perhaps, by a Web-based front end? Of course we would -- if our goal was to maximize the loss of investment capital while reducing profits and cutting the number of those pesky high-value customers we have to worry about.
If, on the other hand, we're designing the system for a for-profit (as opposed to anti-profit) provider, we'd do something quite different. The magic buzz phrase in life insurance is "case management," and it's a fine example of a hub-and-spoke practice.
In our hypothetical system, when the beneficiary or executor of a high-value customer contacts us to begin the claims process, something in the system recognizes their high-value status and routes their call to a case manager.
Case managers look a lot like single-actor practitioners. They have access to the various systems the company uses to manage the items in a client's financial portfolio along with the complete account history. They're highly trained, with financial planning credentials, and can offer to transfer ownership of the investment products without cashing them out if that makes the most sense for the beneficiaries. They can also invest whatever cash payouts are due, either in short-term vehicles until the beneficiaries are ready to deal with financial matters or in longer-term vehicles if they prefer, and so on.
The case manager would keep the insurance agent who worked with the high-value customer in the loop if that agent is still active, and might even turn over case management responsibility to the insurance agent if he/she is active and has a strong relationship with the family. Whoever it is, the case manager is responsible for establishing and developing a relationship with the beneficiaries in order to keep as much of what they're inheriting as possible under the life insurance company's management.
Case managers aren't truly single-actor practitioners, though; in addition to having access to all of the relevant information systems needed to work with the beneficiaries, they have access to the company's back-office processes, not all of which are fully automated. That is, case managers are the hub of activity. The company's systems and processes are the spokes.
Should we call this sort of practice a single-actor practice? I'd say yes, and since I coined the term, I win. If you don't like it, sue me. Contact a good lawyer -- and you'll find that most lawyers operate as the hub of a hub-and-spoke-style single-actor practice, too.
That gets us to stage three: team practices. In IT we're used to these, although we haven't used the terminology. Every time we organize an application development or application integration team, they engage in a practice -- not a process. It doesn't matter whether you use waterfall methodologies, RUP (Rational Unified Process), eXtreme, Scrum, kanban, or Conference Room Pilot. They're all practices, not processes.
Let's hope they stay that way. If we truly managed to turn application development into a process, everyone would just faithfully follow the recipe and a great application would always come out of the oven.
I trust this sounds as dreary to you as it does to me.
This story, "The new business mandate for IT," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.