I think it was Tom DeMarco who described “Death March” IT projects as those that are “Impossible, but not demonstrably so.”
That many of the IT projects we take on are not “demonstrably” impossible seems to be the only explanation for why we continue to take them on in the dumb ways we always have.
Sure, lots (most?) of ’em get done in the end, but at what cost? Health? Relationships? Personal integrity? Unless our project involves life and death and/or national security, we’d have to be pretty dumb to compromise any of those three just to get it finished within an artificial and ridiculous set of constraints.
So we’re pretty dumb – for all the advancement in hardware and software over the years, the wetware between our ears still leads us to do some dumb stuff.
Committing ourselves to fixed end dates and fixed budgets for projects before we have a clear idea of what it is that we’re doing exactly. Dumb.
Thinking that we’re protecting ourselves by contractually passing all of our schedule and budget risk on to someone else – can you say liquidated damages for late delivery? Also dumb.
Laying out a careful project plan with schedules and budgets that adequately reflect risk and uncertainty, then buckling under on both the minute management pushes back: “You mean you can’t do it faster/cheaper than that? Maybe we’ll just have to find someone who can,” they say. “OK, we’ll do it faster and cheaper if you want us to,” we say, without batting an eyelash. We might as well say “You guys caught us red-handed (yuk yuk), You’re right, our original estimates really were padded. Silly us.”
The classical definition of insanity is doing the same things over and over again and expecting different results. Insanity seems be an extreme definition for project practices that are simply dumb, dumb and damnably dumb.
Let’s take the whole RFP process in our business (please) as managed by a dumb client and a dumb vendor: in the very best RFP documentation (even dumb clients sometimes do good documentation) clients do everything they possibly can to communicate what it is they know about what they want, which sometimes isn’t very much.
Since we’re talking IT projects, we may be dealing with something the client has never done before: it’s not as if they can point to an example: “Build one of these here warehouses or a battle tank or gas plant”.
And because the dumb client has been burned so many times in the past, they defend themselves against uncertainty by – guess what? By being dumb: insisting on a fixed price for something highly uncertain, and then giving the business to the lowest bidder. Granted, some RFP processes have improved in the last while, and communication of the criteria used to evaluate RFP responses is improving. But you’ve got to agree there’s still a lot of dumb out there.
Ask yourself – if you were a vendor and all you had to work from was a dumb client’s RFP, would you bid a fixed price?
Of course you would if you were a dumb vendor.
Even dumb vendors know that responding to a major RFP is an expensive and time-consuming proposition, and they swallow hard before they commit. And they ask all the questions they can of the client to clarify. And then they do the estimate of what it will really take to get the project done, given their limited knowledge. And then they never like the first answer (“This is far too long/too expensive – they’ll never buy it!”). And then they ask themselves what it would really take to win the business.
And it too often comes down to simply the dumb answer: the lowest price, and the earliest finish date.
And now the dumb vendor is in a quandary – does he bid low to get the work and hope the scope grows to a point where he can leverage some profits? Does he think we can he can change order the client into profitability if he’s under-priced or underestimated badly?
No wonder we have so many dumb projects that people kill themselves to complete. Taking on projects that are “impossible, but not demonstrably so”. Just dumb.
Enough dumb clients. Enough dumb vendors. Let’s just do it differently next time and stop being so damned dumb.
Hanley is an IS professional in Calgary. He can be reached at firstname.lastname@example.org.