Executive questions, IT answers, pizza parlors, and speed chess

Let’s mix some metaphors today, and attempt to relate them all to the world of information technology and project management.

I have a good friend and colleague, one of the top IT consultants I know.  He’s able to execute crisply at the detail level while keeping the big picture in mind; he’s especially good at balancing on the fine line separating necessary diplomacy and straight-shooting directness.

For reasons I find simultaneously admirable and unfathomable, this indefatigable person, whom I’ll call Gunner here, is planning on opening a pizza parlor as a sidelight, and is currently embroiled in the process of threading the various bureaucracies and logistics to make his vision happen.  We talk about this regularly, since I am a great pizza fan.  In a recent conversation, he reported that he had just gotten city approval to use a specific lower-cost piece of equipment, news that greatly increases the chances of the pizza parlor actually becoming a reality.  So I, of course, immediately asked when opening day would be.

His answer to me was to detail all the next steps, including negotiating the lease, hiring a staff, and so on.  He never mentioned a target date.

I pointed out to him that I’d asked him an executive question, and he’d given me an IT answer. This actually wasn’t meant as a criticism, just an observation, and I had suddenly realized that this pattern of interaction is fairly common in the IT world.  Hey, I realized, I’ve even done that myself, on both the asking and answering sides.

In other words, in this case I wanted a high-level estimate, a “when”, and I really wasn’t at all interested in the steps. IT people are trained to focus on the “how”s of a project, by necessity, and they tend to dive down quickly into determining the specific steps to get from point A to point B.  And they know that especially early on in a project, the “when” is basically unknown, since it’s so dependent on the particulars that have yet to be unearthed.  There’s such a wide range of possibility in the conceivable “when”s that to them it seems pointless to speculate.  Moreover, IT people aren’t stupid: they’ve also learned that this form of executive question frequently comes from people with an elephantine memory and a deaf ear for caveats, plus a high tendency towards great disappointment and surprise if, down the road, it turns out that the tossed-off rough estimate wasn’t accurate.  Thus, IT folks retreat into the world of the “how”s, deferring the clarification of “when” as long as they can.  And both sides end up very frustrated with the other.

So, after that prelude, there are a couple of major takeaways from this pizza parlor conversation:

  1. Gunner didn’t know the opening day.  In fact, he doesn’t have any idea yet about a possible opening day.  It could be months, or it could easily be more than a year.  Gunner knows instinctively, without having to put any thought whatsoever into the matter, that there are loads of important issues to resolve before he will be able to zero in on a plausible target date.
  2. It was thus kind of a stupid question on my part — but exactly how stupid it really was depends on my attitude towards the exactness of the answer I get.  I need to be utterly aware that any answer I get, this early on, is going to be a wild stab, at best an approximation, and that it may indeed be completely wrong.  In essence, I’m asking a question akin to “how long is a piece of string?”  But it’s actually only an unreasonable question if I have unreasonably lofty expectations as to the accuracy of the answer.

As we all know, CEOs and other executives do ask those kinds of questions; in fact, they need to, unless they want to just operate day-to-day and see what happens.  One can’t completely avoid answering them, and moreover, one shouldn’t.  I’ve written before about this, something I call the “impedance mismatch” between IT mentalities and executive mentalities.  It leads to the situation I’ve described where “you don’t really know anywhere near enough to estimate early on (say, during annual budget season, thinking about what you’ll do in the second half of next year), but you have to estimate anyway.”


What’s the answer?  Play speed chess. This is my frequently cited metaphor for pushing IT people into making judgments and estimates without full information and in-depth analysis.  Speed chess is where you aren’t given a lot of time to think through your moves and their implications.  And if you don’t move fast enough, you lose the game.  Equally, a group of knowledgeable, experienced IT middle-level managers can, relatively quickly, give you “SWAG” estimates on even high-level descriptions of projects, if you push them into it.  They’ll naturally be reluctant to do so, but the way to overcome that reluctance is to insist that the basic rule of the game is that these are “estimates without penalties”. They’ll do their professional best to come up with reasonable estimates (neither padded nor overly optimistic), but everyone in the game, executives and technologists alike, has to clearly understand that these estimates will be wildly wrong at least 30% of the time, because they’re based on limited information and a lot of implicit assumptions.  “Play speed chess”, intoned repeatedly as a slogan, can help both the executives and the technologists remember that, now and down the road.

So, maybe I can get Gunner to put some chess boards and time clocks into his new pizza parlor.  I’ll have to ask him for an estimate on when that’ll happen.

Lagniappe:

Update:

Gunner opened his pizza parlor!  About two and a half years after I wrote this post.  And so far, it’s a smashing success.  As I expected.

Comments

  1. One of the key elements of success that jumps out at me in your article is having an organizational culture that can support/accept/tolerate the element of playing speed chess: that “estimates will be wildly wrong at least 30% of the time”. Based on an IT work estimate, the business starts forming plans to roll-out marketing campaigns, train call center staff/customers, change business processes and mostly likely, string these together to form their post-IT implementation master plan. The business needs to be cognizant that their master plan needs to account for late (and even sometimes early) IT delivery dates. Thus, IT work estimation continues to be part art and science. I’ve written previously at the art side, here: http://bit.ly/90xVMk. More recently, I’ve written about the science side here: http://bit.ly/9BFf18.

    Great post Peter!

Speak Your Mind

*