The hard truth about IT process success

The key to running an effective organization, we’ve been told for decades, is delivering work products through well-designed and -managed processes. Process is hailed as the path to organizational nirvana, in the form of repeatable, predictable results.

But CIOs who start process initiatives by designing processes and training staff in their use are akin to math students who enroll in differential calculus without first passing algebra and trigonometry. To succeed in any discipline, one must first master the prerequisites.

For any process initiative to succeed, there are, in fact, four prerequisites: (1) a process culture; (2) a clear understanding of the difference between processes and practices; (3) the ability to design, manage, and interpret process metrics; and (4) trust among everyone involved in the execution of the processes.

Without these prerequisites, no process initiative, whether it’s ITIL-based IT service management, a standardized systems development lifecycle, or an IT mergers and acquisitions playbook can succeed. Put these four fundamentals in place and success is almost unavoidable.

Process culture

“Culture” is a term that’s uttered far more often than it’s defined. For business purposes, think of culture as how we do things around here. It’s the set of shared beliefs and assumptions that go into the decisions and work habits of all employees in an organization.

If an IT organization has a process culture, then no matter what situation employees face, they’ll improvise only when dealing with a situation for which no standard, documented process or procedure has been defined. And when they do improvise, they’ll document what they came up with, its results, and potential improvements to include should a similar situation arise in the future.

That’s in contrast to a culture built around the premise that “We’re smart people. We’ll figure this out.” Not that having the confidence to figure out how to handle something unexpected is intrinsically bad. It’s just that when figuring it out from scratch is where employees start, they’re expressing the surreptitious opinion that they’re smarter than the last bunch of employees who had to figure the same thing out — possibly that they’re smarter than everyone who has ever faced a situation similar to the one at hand.

Intrinsic to organizations that succeed through well-defined processes is the attitude that everyone involved, all the time, is responsible for constantly perfecting “how we do things around here.”

Processes vs. practices

A process is a set of tasks, executed according to a defined sequence and flow, that produces repeatable, predictable results. Processes are recipes: Follow the instructions precisely and you can’t avoid producing a delicious, say, paella.

Organizations built to rely on processes are, as the saying goes, “designed by geniuses to be run by idiots,” although “average schmoes,” while less punchy, better describes the people who end up doing the actual work than “idiots,” and many of the process designers aren’t always Mensa material.

As the supply of average schmoes usually exceeds the availability of geniuses, the recipe model isn’t a bad fit for a lot of business situations.

But not all situations lend themselves to recipes. Litigation is an example — attorneys who execute the exact same steps the exact same way in every lawsuit are unlikely to win cases when opposed by a more imaginative opponent who is a better judge of which candidate jurors are more likely to be sympathetic to their client’s cause, and who is more imaginative in developing convincing narratives likely to persuade those jurors.

This is why we refer to law as a practice, not as a process.

In IT, a lot of what we do fits the process model — building a test environment, for example.

A lot, that is, but far from all. Take project management. It follows a series of steps, but that doesn’t mean performing each step the same way in every project is a good idea.

Project management involves too many variables for any one-size-fits-all recipe-based approach: Different sponsors respond differently to the risks and issues that arise in the course of a project, and for that matter the risks and issues that arise differ from project to project. The same may be said for the core project team (no two teams have the same strengths and internal dynamics) not to mention the SMEs and business users who comprise the extended project team.

Oh, and what different projects are supposed to produce as their work products isn’t uniform either: Skyscrapers are fundamentally different from aircraft carriers, which have little in common with PowerPoint decks or cost/benefit analyses.

And so on.

The purpose of all business functions — the collective term for processes and practices — is to turn inputs into outputs. Processes depend on how well those who do the work of the process follow task steps to the letter. Practices depend on the deep knowledge, expertise, and judgment of the practitioners.

Understanding this basic and fundamental divide will keep CIOs from falling into the trap of trying to use recipes when they just don’t fit the situation.

It’s also worth noting that process vs. practice isn’t a binary choice. They’re more the poles of a continuum of possibilities. Some business functions are more process-like; others are more practice-like, but few are purely one or the other.

In the end, processes and practices are different, equally valuable tools for getting an IT (and, for that matter, non-IT) organization’s work done. Use the right one for the job at hand.

Metrics

If you can’t measure, the tired old saying goes, you can’t manage. It ignores Lewis’s Law of Bad Metrics, which states that you get what you measure, so if you mismeasure you mismanage.

Defining metrics to help you understand whether a business function is healthy or needs a tune-up calls for insight and rigor.

What follows is a too-brief synopsis of a complex subject:

Process Optimization Metrics

Managers can optimize a process for no more than three of these six dimensions:

• Fixed cost: The one-time investments required to create the systems and infrastructure that the process needs in order to function.
• Incremental (aka marginal) cost: The additional cost of processing a single transaction. Incremental cost does not include amortized fixed costs.
• Cycle time: The time needed to process a single transaction — to turn inputs into a single output.
• Throughput (aka capacity): The number of outputs the business function can deliver in a given unit of time.
• Quality: Adherence to specifications; alternatively the absence of defects.
• Excellence: Flexibility; the ability to adapt to unusual situations and to tailor or customize.

Defining metrics for a process or practice begins by deciding which two or three of these optimization dimensions matter most. These are the ones to measure. You only get two or three because optimizing for those invariably calls for trade-offs with the remaining dimensions.

Forget service level agreements (SLAs)

SLAs are a popular but misguided way to measure business functions.

Service levels are two-part metrics. They define (1) the minimum threshold of acceptable performance, and (2) the percentage of occurrences that must meet that threshold.

For example, for level-one incidents, the service desk manager might decide that cycle time is the most important optimization dimension for the first part of the metric, establishing a time to initial response of 5 minutes and time to resolve of an hour as the minimum thresholds of acceptable performance. For part two, 95% or more level-one incidents must conform to the thresholds established in part one.

SLAs are a necessary evil in outsourcing contracts because both the contracting company and the outsourcer need to know whether performance adheres to contractual requirements.

But for business function management, the old-school metrics of mean and standard deviation are far more useful.

Trust

IDG / Bob Lewis

In Keep the Joint Running: A Manifesto for 21st Century Information Technology I introduced the “process distrust loop.” It shows, semi-satirically, the practical consequences of distrust: When executing a process, every step of the way, distrust causes the person or group receiving work in progress to assume that it’s defective in some respect. That leads to complaints, rework, delays, waste, and general unpleasantness.

And, as a bonus, additional distrust.

With trust, even poorly designed processes can flow smoothly. Without it, no process has a chance of delivering the intended results.

In conclusion

These four underpinnings — a process culture, recognition of the differences between processes and practices, the ability to define and track appropriate metrics, and, most of all, trust among everyone involved — make the difference between an IT organization that gets the job done and one that never seems to quite deliver the goods.