12

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?

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
ndemir
  • 323
  • 1
  • 5
  • 1
    +1 for the link to this article alone. A good read that I hadn't come across before. – Willl Jan 28 '13 at 12:46
  • Project A should never be committed to... – Andrew Clear Jan 28 '13 at 22:36
  • @aclear16: Sometimes these types of products/projects are absolutely necessary though. I have been working on a product/project for the last few years which is not expected to ever make any money but only break even (at best). But you'd be surprised how crucial and important this product is to the company to support and complement our platform and portfolio of products. – Jeach Jan 31 '13 at 03:51
  • If Project A is absolutely necessary, then pure profit is not a good measure of its success/failure. If that is the case, then the provided example does not accurately reflect a value comparison between the two projects. – Andrew Clear Jan 31 '13 at 07:47

2 Answers2

10

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."

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
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.

David Espina
  • 37,143
  • 4
  • 34
  • 91
  • 1
    By "terrible message" I mean the author's, not CodeGnome's! – David Espina Jan 28 '13 at 13:20
  • I don't think the author was promoting "permission for sloppy management". I just think what he's saying is that managers could for example spend 80% of their time/effort on the likes of Project A and spend 20% of their time/effort on Project B. Or for example if the developers of Project B needed to refactor code to make it 'really great' (but not a priority) then to allow it anyway. Or if you have junior project managers, allow 'them' to lead these "big projects" which tend to be monopolized by senior PM's simply because of their great ROI prestige. – Jeach Jan 30 '13 at 17:51
  • With respect, the examples you provide are in my opinion evidence of sloppy management. 80% time on A by expensive leaders with questionable efficacy will only drive costs up, return down, and provide little to no value. Squeeze in extra code simply b/c you have runway sounds like feature creep. Allowing your 3rd string to manage simply b/c you have cushion? Hmmm.... – David Espina Jan 30 '13 at 18:02
  • Especially on a project where you're likely spending someone else's money?? – David Espina Jan 30 '13 at 18:04
  • Per your comment - "evidence of sloppy management", I believe that "sloppy management" is a consequence of real world scenarios for the large majority of us. We're faced with many issues; too few resources, too many projects, too little time, too many features, time-to-market, etc, etc which means 'sloppy management' is a reality and we must do our based to manage it as best we can. I have yet to see 'perfect execution' from any company and any project manager. We strive for academic theory but unfortunately must face reality. My comment is based on the execution of such reality. – Jeach Jan 30 '13 at 22:05
  • While perfection is never achieved, you never stop trying. To say this is our reality and that is academic/theory is giving up and accepting status quo. I cannot tell you how many times as a BPM consultant I go into an environment, make one elementary and academic change, and watch performance sky rocket. – David Espina Jan 30 '13 at 22:44
  • I do agree that we should all try to 'perfect ourselves/process/etc' (which I do) although sometimes it's just not possible due to corporate culture. But I'm not talking about giving up here either! Status quo on the other hand is the reality for many organizations... 'take it or leave it' kind of environment (unfortunately). If you go in as a consultant to these types of places then having you there in the first place is a sign that they want to better themselves. But I think we're getting a bit off topic also :) – Jeach Jan 31 '13 at 03:46