What Constitutes a Change of Scope? by Bruce Nielson
In a previous post I used Robert Glass’ advice from his excellent book, Facts and Fallacies of Software Engineering to come up with what I see as the industries standard advice on how to do good software estimates:
To summarize, the standard advice is to:
- Not make estimates until requirements have been defined
- Always let the programming team make the estimate, not management or marketing
- Use change control on the estimate as requirements change
While I believe the above advice is good advice, it’s no where near sufficient to address the very real problems of software estimation. However, if you aren’t doing at least the above, your estimates are doomed. So Glass’ points are at least a good starting point.
Now one objection I anticipate from the audience is that if #3, if understood in a certain way, would make it impossible to ever miss an estimate. If you can always change the estimate to match reality, how can it ever be missed?
I actually think this is a good point that starts up down the road to understanding the real problems of software estimation.
First of all, if we take that point of view to its logical conclusion, this is really just the same as saying that the estimate isn’t worth the paper it’s printed on. Imagine going into a car shop (or when buying a house, or whatever you want to imagine) and being told “well, it will probably cost $1,000, but we’ll let you know if it’s going to cost more.”
Then a couple of hours later you receive a phone call. “Yeah, it’s like I thought. The problem is bigger than anticipated. I’m projecting $2,000 now.”
Then the next day you receive another call. “Well, it’s taking longer than expected, so I’d say probably $3,000 now.”
By this point, you’d a) break into a cold sweat every time the phone rang, wondering how much more you owe now, and b) you’d probably have pulled the car out of the shop and taken it to a “reputable” place.
So the first thing we need to understand, is that if you take #3 above to mean “I get to correct the estimate any time I realize it’s going to take more” that we’ve fundamentally misunderstood both human nature and the purpose of an estimate.
The Meaning of “Scope”
Now I anticipate another objection might be: “Well, you’re giving an example of where nothing changed. It’s still the same scope at that car shop, they are just charging more because it took longer. That’s unfair and immoral. I’d never advocate that. I only advocate changes of scope that are obvious and clear.”
Ah, very good. So there is an emotional difference between asking for more money when there is a clear change of scope vs. when the change of scope is vague.
But what exactly is a “clear change of scope”? Are all legitimate changes of scope “obvious” and thus “clear?”
For example, if you brought your car into the shop because there is a knock in it and the shop looks it over and says “well, it’s probably the carburetor, so I know it will cost $1,000 to fix” and then they start work on the car and they don’t find a problem with the carburetor, is it really the same scope still?
There are two ways to think of this, both are fair in my opinion. The first is, the customer’s point of view:
The scope of work that was estimated was to remove the knock. They are the experts, so they should have diagnosed it correctly. If it wasn’t really the carburetor that was causing the problem, that’s their problem, not mine. The scope of work has not changed so the price should not change!
The second point of view is the car shops point of view:
I did my honest best to diagnose the problem. Every time in the past I’ve heard a knock like this, it’s been the carburetor. Any competent mechanic would have diagnosed it the same. When I made my ‘bid’ it was to fix the carburetor, not to remove a vague knock. If I later find out there is a much more extensive problem, that constitutes a change of scope, and thus I have the right to ask for more money!
So who is right? I think most of us impulsively believe the customer is right in this circumstance, mainly because it would make us really mad to be treated the way this hypothetical car shop is treating us. So we “go with our gut” on it and declare the car shop both wrong and immoral.
But think about this problem from the point of view of being a programmer. Really, give it some thought. I have never know a programmer that didn’t take the “car shop’s view” when the shoe was on their foot.
“Scope” is Inherently Vague in Software
I’d submit that actually both are right. Or more to the point, there is no actual “right or wrong” here. We’re making a moral issue where no moral issue exists.
In reality, whether the car shop should take the first or second point of view is entirely based on what is right for their business long term. If they want to ask for more money, this is completely fair and moral, but it’s very likely to end the relationship with the customer and that is as it should be. So they get to decide for themselves if they want to take a loss on this one to keep the customer or if they want to exert their right to declare this a change of scope and ask for more money before proceeding.
But the key point I want to make is that most of the time, it’s not clear what a “clear change of requirements” is. For it to be clear, the “requirements” would have had to have been very detailed, in this case, specifying what they were estimating based on their plan to inspect the carburetor.
But in the case of software, how detailed would you have to be with your ‘requirements’ to avoid debate over if something was a change of scope or not? Likely it would require you to write your ‘requirements’ in pseudo code. (More on this in later posts.)
If the requirements were more abstract and general then pseudo code, then I submit that there will usually be some wiggle room for both sides and for both points of view to declare a cost overrun as either “in” or “out” of scope for the requirements, just like our car shop example.
So my point is simply this: ‘Clear changes of scope’ are rare indeed. You’ll mostly have to live with muddy ones. Turning it into a moral issue is a mistake. (“Those crummy customers always changing the requirements on the project! What immoral cretins!”) It’s just a business decision about what will be in your best interest long term.