A couple of years ago, I stumbled across this fascinating quote from Tom DeMarco (one of the pioneers of software architecture. I just saw him reuse the same logic in a new article, and this time, I thought differently of it (now I think he is even more right than he gives himself credit for). First, here’s a quote from Tom’s article. He’s talking about making decisions on how to manage projects and he asks us to envision two hypothetical 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 that $50 million.What is 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.”
– Project B will eventually cost about a million dollars and produce value of more that $50 million.What is 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.”
Project A. Project B. We’d all like to have more Project Bs. In the two years since I originally saw Tom make this argument, I’ve found no flaw in it. I’ve also discussed it with many people who manage IT over the last couple of years and while they universally agree with the logic, they also say that it doesn’t really matter. In their organizations, every project must be managed tightly. Tight management of projects is required culturally. It is required by their processes (ie, monthly and weekly reporting). It is required by their HR department (ie, project reviews). What it took me a long time to realize is that this is because in most of our organizations, all we really ever deal with are Project As.
It is built into the DNA of the modern organization to focus strongly on tight management of projects. And this frustrates most of the people in the organization. Not because they want to goof off, but because they know that when you focus on metrics, tight management and detailed project management, you get at best what you originally designed, sliced up and managed. You cannot possibly get anything better than that because any deviation from that plan and those metrics will be squashed specifically because it doesn’t get you to the original goal. In almost every project run in modern companies today, you can never get any better than the original plan. You can only be worse. And as we know, most of the projects are worse.
But, all of that could have been said (and probably has been said) by Tom DeMarco. When I read his most recent article, I was stuck with the horrible realization that in most businesses today, control really is the right answer. After the argument in the previous paragraph, you may think this conclusion is insane. Unfortunately, in most organizations today, the majority of projects are in fact “relatively useless.” In most organizations, the number of truly creative, innovative, new ideas are either nonexistent or very very limited. Most projects in most businesses look like Project A. In fact, our IT departments are generally designed to manage lots of Project As.
The problem, of course, is that in an organization, in a culture, that manages itself to Project A type projects: controls, processes, structures, metrics, etc., it is almost impossible to envision Project B. Project B will never even be imagined because the processes and structures of the organization are designed for controlling Project As. Control, structure, and management are antithetical to creativity, innovation, and experimentation. You see this problem in yearly budget processes, yearly and project review processes and all of the various metrics and metric collection tools in our organizations.
The problem, at least as I see it Mr. DeMarco, isn’t simply that Project A requires more control than Project B, but that the simple presence of the management structure for managing project A ensures that you will have very very few Project Bs.
