On Control...

[ipmcc]

One of the few blogs I keep up with, Coding Horror, recently had an entry referring to an IEEE article by Tom DeMarco, who just so happens to have literally 'written the book' on software project management metrics and estimation. He was the one who famously said, "You can't control what you can't measure." That article contained the following paragraph that, at the risk of hyperbole, changed my life:
To understand control’s real role, you need to distinguish between two drastically different kinds of projects:

• Project A will eventually cost about a million dollars and produce value of around $1.1 million.
• Project B will eventually cost about a million dollars and produce value of more than $50 million.

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.

Jeff Atwood, the author of Coding Horror, chose to focus on some of the more shocking proclamations DeMarco makes, but for me the real winning moment was the paragraph I've excerpted above. The moment I read that paragraph, I immediately realized most of the jobs I've held (for any length of time) in this industry prior to working for my current employer were Project A, and that the situation at my current employer is very much Project B.  DeMarco goes on to draw parallels between the futility of trying to control an adolescent and the futility in trying to control a software project. In case his blanket statements about working on something of minor value didn't hit home, maybe thinking of your job as raising a rebellious teenager will do the trick.

Normally, I would go trundling along; I'm quite happy where I am, and in case it wasn't obvious, after reading this entry so far, I believe this is owing in large part to working on a "Project B." Recently, however, circumstances beyond my control have pressured me to think about the prospect of moving away from Pittsburgh and, collaterally, my wonderful job. It's not for certain, but it's one of the possible outcomes of a current conundrum we're facing. I never thought about it before today, but the implication starting to pop out for me is that the single most important question you could ask at a job interview in this industry might be, "What can you tell me about the gross margin of the project I'd be working on?"  As unlikely as you are to get a straight answer, you'll probably get some indication, and that will hopefully be enough to know whether you're walking into a "Project A" situation or a "Project B" situation.
The very next disturbing conclusion I came to was that a huge proportion of professional software development efforts are inherently "Project As," or worse.  Any consulting houses, and almost any in-house development (think about most bank software, for instance) is bound to suffer this fate, no matter what level of cost-savings it confers to the organization.  When I said, "or worse," I meant it too.  Since very few internal projects are "revenue generating" (as opposed to "cost saving") one might reason that such companies would seem almost preordained to meta-cost-save by being overly controlling of their software processes.

This is an especially dark thought during this time when virtually employed soul in the country is busy being grateful to have a job at all.  I know I'm grateful for mine!