All Posts in Organizational Effectiveness

|In: Office Politics|Last Updated:

I love golf.

I wandered through a golf show a few weeks ago, looking at gadgets, daydreaming of long, straight drives, and pondering the game as a metaphor for managing IS (not for the first time, either — see my July 8, 1996, column on the subject).

The obsession so many of us have with long tee shots is a good example. Just as most of us would be better off playing a five iron off the tee and practicing our putting, so many CIOs worry about aligning IS strategy with the company’s goals and vision while ignoring the real big-money issue — poor project execution.

So it was that I visited a booth selling custom woods (actually metals, good persimmon being unavailable these days). The purveyors of these fine clubs had a killer sales pitch: Rather than fix my slice-prone swing, they would sell me clubs that compensate for my deficiencies.

For a significant price, of course.

These clubs provide us with a lovely two-sided metaphor. On the one side we have executives who think nothing of spending a sizable fraction of their annual bonuses on these very same custom golf clubs and a supply of titanium balls, but who cheap out when it comes to providing a reasonable set of tools for IS. They believe better tools will help their golf games, but not their businesses.

On the other side we have IS weenies who are convinced that if they just had better tools, they’d suddenly become the ultimate code warriors, able to create magical applications in periods of time so brief that quantum effects predominate.

Examples of the former are easy to find: Data center managers who lack funds to implement network management, developers whose request for source management software is denied, even project managers who aren’t given basic project management software.

Examples of the latter are just as readily found: A friend of mine bought a PC-based Cobol compiler a few years back expecting to develop and unit test mainframe applications on it. A few minor problems cropped up after the money was spent: The systems it was purchased to support ran on top of a proprietary transaction manager and used a proprietary data compression system, neither of which would run on anything other than an MVS mainframe. Oops.

Then there are the fifty-buck tools that solve five-buck problems. In the early days of Unicenter, for example, Computer Associates boasted of its ability to stop batch jobs if available storage filled up, roll off some files to tape, restart the job, and restore the files at the end of the process. The sole design flaw: For the price of the software, you could have bought enough scratch storage to run any batch job you could imagine. Sometimes, brute force can be more appealing than elegance.

Business executives often complain about our buying technology for technology’s sake. The complaints are, for the most part, groundless. The applications IS deploys and manages invariably have a business purpose.

Except for tools, that is. Let’s face it: A lot of us have a yen for the latest and greatest software tools, just like some stereotypical husband with a workshop who wants a table saw or drill press.

How to make sense of requests for expensive tools? The answer is to eschew (gesundheit!) the use of broad principles. They won’t help. The only way you get a handle on this issue is to figure out your core processes first. These usually are (in order of importance): data center operations; applications maintenance; end-user support; system selection, customization, and integration; software testing; and application development. Understand your processes first and you’ll quickly understand which tools you need and which ones may be wonderful, but just don’t fit.

Oh yeah, just one more thing: While you’re busily giving your developers killer workstations with dual overhead cams, fuel injection, and turbochargers, also give them Pentium 133s with 32 MB of RAM to test their works of art. The P-133 is an important developer’s tool.

You’ll be amazed at how much having to use one will improve a typical developer’s code.

Comments

|In: Industry Commentary|Last Updated:

Steven Wright once asked if shaving cream does anything at all beyond helping you keep track.

It’s a good question.

It isn’t just shaving cream whose only role is helping you keep track. Sometimes, that’s the role of the “repeatable, predictable processes” that so many of us high falutin’ consultants promote as the solution to every business problem.

Before we had process redesign we had Taylor’s “scientific management” and its time-and-motion studies, which tried to turn industrial processes into precisely defined repetitive motions. Beginning with the assumption that business works best when human brains aren’t involved in running it, scientific management led inevitably to repetitive stress disorder. Oops.

We’ve replaced scientific management with process redesign. According to the process perspective, “everything is a process,” a phrase I’ve heard often enough to make me want to argue, just out of spite. “My desk isn’t a process,” I hear myself retort cleverly while I watch ’em fold like pawn-shop accordions. “Neither is my car. Or my …”

“No, no!” they sputter, nonplussed. “We meant to say, everything you do is a process, because everything you do is a series of steps that gets you to the end result.”

Which is absolutely, true — everything you do is a process. Everything you do isn’t, however, a Process, a distinction process design consultants often fail to make in their zeal to craft high-quality-producing methods for achieving results. There are three big differences between processes and Processes:

1. Most of the intelligence needed to create the desired results has been built into Processes. In contrast, most of the intelligence needed to successfully follow a process is in the minds of the individuals following it.

2. The products of Processes have well-defined specifications; quality is defined as adherence to those specifications and can be objectively measured. A Process generates either large numbers or a continuous flow of its product. A process also creates an output. That output may be unique or a custom item; often its specifications aren’t known in advance.

3. People fulfill roles in Processes — the Process is at the center. It’s the other way around with processes: People use them to make sure they do things in the right order without forgetting anything. Lower-case processes play a role in employees’ success.

Don’t buy it yet? Think of the difference between the Process of manufacturing a car and the process of creating advertising. You can specify the steps for building a car so precisely that industrial robots can handle it — all of the intelligence is in the Process. Every last detail of the product has exact specifications and tolerances. If you follow the Process exactly, you must end up with a high-quality car.

You can also specify the steps needed to create advertising — you may analyze the marketplace, determine the product’s tangible and emotional benefits for each market segment, and so on. When you’re done, you’ll never end up with a process that can be handled by industrial robots (although many advertisements certainly look as if they were authored by automata). There’s no tight specification for distinguishing good ads from bad ones until you test-market to find out which ones make the cash register ring.

In our quest to make systems development and integration repeatable, predictable, and most important an activity we can reliably budget, we keep trying to turn it into a Process.

Systems development should follow a well-defined process, if for no other reason than to make sure we don’t leave anything out.

But a Process? Nope.

A great system is a work of art, both internally and in use. The processes used to create it help programmers focus on getting the job done instead of figuring out what the job is. Following the methodology facilitates great results. Only talented designers and programmers can cause them.

Here’s the wonderful irony of it all: Process redesign consultants don’t follow a Process. Only a process.

Comments