When is "control of a software project" less important?

Question

In the article titled Software Engineering: An Idea Whose Time Has Come and Gone?, Tom DeMarco says that:

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.

It is not "immediately apparent" to me. Can anyone explain?

Answer 1

TL; DR

The author's leading premise is that cost containment is more important for Project A than for Project B. This is almost axiomatic if you do the math.

Purpose of Project Controls

Project controls are the processes and procedures used to keep a project within acceptable variance of the project's goals, especially in the area of projected cost vs. expected return on investment (ROI).

Project Controls and the Article

• 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 this tells you is that Project A has an expected return of $0.1 million after accounting for project expenses. On the other hand, Project B has an expected return of $49 million, earning out more than 50 times its total budget. As one of the stars of Breaking Bad might say, "That's a lot of cheddar!"

What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B.

Project A has a profit margin of only $100,000. The planned budget will eat up almost all of the profits, so it will not tolerate much in the way of schedule slippage or cost overruns before the project is in the red.

Project B, on the other hand, has a much bigger profit margin, and therefore a bigger margin for error. In fact, the cost of the project is only 2% of the expected profits, so the project could theoretically balloon out of control (for example, it might have labor estimates running 300% over budget) and still make the guys from Breaking Bad plenty of "fat stacks."

Answer 2

I think CodeGnome nailed it as the thinking the author had as he drafted that language; however, I also think this is a terrible message. I sort of gives permission for sloppy management if you have a high degree of likelihood of an obscene return. It also gives permission to exert a heavy hand on controls if your return is predicted to be small. If my inferences are on target here, then the author's take-a-way should be avoided.

From the latter's perspective, where the return is low, you need to be very careful with the controls deployed. They're expensive and, if you study organizations carefully, what you will likely find is a set of controls that get deployed to solve some an immediate and discreet problem, but will never go away despite the problem being long extinct. In other words, we have a tendency to maintain expensive controls that offer little to no value.

I think, no matter the expected return, the consistent deployment of the right controls is the way to go.