I wasn’t ever a very good bridge player, and it’s been decades since I played. Hence, using this analogy may be stretching matters, but as is typical, I took away some key metaphors from my time with the game. One is the squeeze play, where you force your opponent to discard a vital card. It’s similar in a way to what’s called Zugzwang in chess, which describes a situation where one player is put at a disadvantage because he has to make a move, and by doing so (any move, in other words) will force himself into a weaker position.
How does all this relate to CTOs and CIOs? Consider the case of having to estimate how long a specific project will take, particularly early on, usually before any kind of detailed requirements are even remotely fathomed. Note that this kind of estimating is among the most critical activities that you and your organization will do, because it feeds into the organization’s whole prioritization and costing process as a whole. Unfortunately, it gets you into exactly this kind of squeeze situation. If you say a project is going to take what’s considered to be “too long”, you’ll get beaten down about why you can’t do it faster. If you blithely “sign up” for doing it too fast (say, as fast as they want it), there’s a huge risk that you won’t be able to deliver.
Part of this dilemma comes from an impedance mismatch between development mentalities and executive mentalities.
Developers, by nature, are usually reluctant to commit to when they’ll be done. After all, there’s a lot of uncertainty out there, isn’t there. At its worst, this uncertainty results in a developer making statements like “I’ll know when I’ll be done when I finish.” (And yes, I’ve heard those very words from a developer).
Managers and executives, by nature, want and need commitment, largely because other projects are stacked up on the railroad tracks behind the development boxcar: marketing campaigns, product shipments, whatever. Managers can’t wait until the very last minute to tee all these things up. They also need to get a sense early on of what a probable time frame for the project is going to be, so that they can juggle the overall priorities they set: allocating resources to two easier projects now as opposed to committing to one more difficult and lengthier project later. (And secretly or sometimes not so secretly, they tend to suspect that developers just don’t want to be on the hook to work hard).
Responding to this dilemma, software estimating regarded from the point of the developer tends to fall into complex consideration of “how do I make my estimates more accurate”: how do I collect data and information that will help ensure that I won’t overcommit. They strive for greater accuracy through such things as careful examination of historical actuals, use of intricate COCOMO software estimating models, function point analysis, and so on. However, regarded from the point of view of the managing CTO/CIO, it’s a lot less theoretical, and falls into “how do I make estimates based on little or no actual data, and avoid getting killed at the end of the day if/when I can’t deliver on that original estimate”. Padding the schedule with copious contingency is of course one answer, but typically, stakeholders are already aghast enough at the initial time frame you mention for completion of a project, and when they then drill into it and hear that n% is so-called “contingency”, they’ll try to compress that out. You can resist, sometimes successfully, but realistically, it’s always a battle.
In short, 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. And (as you’re doubtlessly thinking right now) you can preach to your stakeholders all you want to about things like the “Cone of Uncertainty” and how your estimates now will tend to be inaccurate, but it won’t matter much. Commitments are what they hear, even with caveats, even with the earliest and most ignorant of estimates.
And if you refuse? You’re instantly lumped into the estimate-resistant ilk I mentioned above: “I’ll know when I’ll be done when I finish.” And that simply doesn’t cut it.
So, it’s a squeeze, also known as “damned if you do; damned if you don’t.” Zugzwang: you gotta move, no matter how much you don’t like it. As I’ve quoted here before, turning the famous saying around from WarGames, “the only losing move is not to play the game.”
So, how do you play the game? What’s my answer to this rock-and-a-hard-place situation? Project Portfolio Management is key. Narrow down the overall list to the absolute most key items as soon as you possibly can. Yes, put in contingency, and stand firm against encroachment. And, above all, make sure you’re talking ad nauseum (and it will be to the point of nausea occasionally) to your stakeholders about the uncertainties inherent in what they’re asking for. That’s all you can do. And may you not get killed at the end of the day, at least on balance.
Lagniappe:
- Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)), by Steve McConnell
[…] 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 […]