The most important book about IT published in 2009*

The best way to discover your ignorance is to try explaining what you think you know.

About a year ago I started turning the KJR Manifesto into a book. Since I’d already published a synopsis in this space (“KJR Manifesto — Core Principles,” Keep the Joint Running, 4/10/2006) and had written columns about most of the ideas, I figured it would be a quick, easy project.

Those of you who manage projects already know what happened. It’s what happens to every quick, easy project — everyone involved rediscovers a basic truth of the universe, which is that there is no such thing as a quick, easy project. Simple and easy projects are complicated and challenging, and things just become more complex and difficult from there.

But I digress.

Twelve months and thirteen chapters after starting the effort, Keep the Joint Running: A manifesto for 21st Century Information Technology is officially in print. Writing took a year because with few exceptions, as I started digging into each of the thirteen principles that will, in my not-all-that-humble opinion, define successful IT organizations this year and for quite awhile to come, I discovered just how shallow my thinking had been.

The chapter on metrics is a good example. If you read KJR on a regular basis, by now you’re probably tired of hearing about the four metrics fallacies: Measuring the right things wrong; measuring the wrong things (right or wrong); not measuring important things; and measuring employees.

It turns out, unsurprisingly enough, that no matter how good someone is at recognizing bad metrics, it doesn’t make them good at crafting good ones.

Creating a formulation for creating useful metrics took much more time. If you’re interested, good metrics are: Connected, consistent, calibrated, complete, communicated and current. I didn’t know that I didn’t know that, until I tried to explain it.

Another surprise: While the list of six process optimization parameters (overhead cost, unit cost, cycle time, throughput, quality, and excellence) has appeared here often enough, its usefulness is broader than I’d realized.

For example: The distinction between processes and practices is one we use in our consulting practice all the time. (I’d thought I’d written about it enough to be tiresome. Turns out only one column in the archives covers it, and that used a different vocabulary.)

It turns out that this two-value spectrum of how to organize work should be described as a three-value space: When the time comes to get work done you can organize it as a process, as a practice, or use invention.

It also turns out that the best way to decide which is the best fit for a situation depends on which combination of the six parameters most requires optimization:

• Processes (well-defined flows of thoroughly specified steps) tend to minimize unit cost, maximize throughput, and improve quality.

• Practices (sequences of broadly defined steps within which personal expertise and judgment play vital roles) tend to minimize cycle time, and also encourage excellence.

• Invention (figuring out how to handle a situation when it arises) has very low overhead costs, but otherwise has little to recommend it, unless you’ve never had to deal with a type of situation before.

One other factor proved challenging. In listing the thirteen principles that make up the Manifesto, I figured each was clear, simple, and practical.

I still do. But I also figured this would mean each would be easy for CIOs to implement in their organizations.

That isn’t necessarily the case. Depending on the principle, the current situation within IT and the company’s political environment, some of these principles could turn out to be very difficult to make happen.

For instance: There are no IT projects. Certainly, every project should be about improving the business in some way, shape or form, or what’s the point? Making the case wasn’t just easy, it was fun (if you’re curious, it starts by describing the experience of buying a guitar, if mainstream IT ran the guitar store).

It turns out, though, that many companies are put together in ways that almost seem calculated to prevent this outlook from ever being included in the practice of IT governance. Beyond that, it invalidates just about every application methodology ever practiced, and calls for a level of collaboration between IT and its business partners that’s far more extensive than the IT-as-a-business-with-internal-customers model that’s so prevalent in the IT punditocracy.

It took a lot longer than I expected. It was a lot … make that a lot … more work, too.

Writing can be quick. Thinking takes time.

* So far.