These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.
I've written previously on the ROI of Estimates:
An additional thought occurs to me however - is our expectation on estimates due to language. When we talk about software development (or any project), I think that every individual involved will have their own definition of the word estimate.
Introducing the Estimate Spectrum
Let's draw a line between Guess and Commitment. This gives us the Estimate Spectrum:
From experience, I know that every individual would put themselves somewhere differently along that line.
It maybe a gross over simplification, but most people giving the estimate would be towards the "Guess" end, while those receiving the estimate would be towards the "Commitment" end.
Thus it isn't too surprising that different individuals can walk away from the same conversation with different expectations.
Definition of Estimate
As I've said in Part 1, an Estimate is not a Commitment ... it should never be.
Let's take another look at the definition of the word Estimate:
You see terms like "roughly calculate", "judge", "approximate" - these are all closer to the "Guess" end of scale.
Even the work "Guess" is in the synonyms.
Nothing in the definition of Estimate does it suggest Commitment.
... and yet
We have developed a culture (especially in project delivery) that an Estimate = Commitment.
Why?
Unfortunately this still comes back to a belief that absolutes are possible with Software Development. There is still an expectation that Software Development can be planned ahead of time with absolute accuracy.
Once you realise that that is a dangerous fallacy, then the idea of an Estimate being a Commitment quickly disappears.
As an industry however a are still struggling to get everyone to that place.
And unfortunately, I see a lot of this stemming from "traditional" project management processes.
Traditionally, we have celebrated project managers that bring their project in "on time" & "on budget". I've seen countless job spec's specifically listing this as a desirable.
An aside; personally I find any project manager who claims that they are always "on time" & "on budget" have either never been given a challenging project or are self-deluding themselves (and no I don't count a project that has been re-scoped as being "on time" & "on budget"). Ok, enough of that rabbit hole.
So, personal opinion aside, we celebrate a project manager who will get stuff done when they say they will.
And this is the impossible situation. As I've talked about in my previous articles, it is impossible to accurately predict any software project.
So the project manager is expected to provide a Commitment - so they look to everyone else on the team to provide Commitment.
This however comes across as the word "Estimate".
And the end of the meeting
So at the end of the meeting, the project manager comes out with "Commitments", software developers leave having given "Guesses".
And unfortunately, too may projects are then judges based on those "Commitments" - which of cause then just drives dysfunction after dysfunction.
While this is technically the wrong thing to do - by this point is is emotional and a source of disagreement.
Be clear
So for any Estimate, we should be clear what meaning we are associating with it.
I'm generally very explicit that any Estimate I give is a "Guess" ... and should not be used as a "Commitment". It still doesn't stop them being used incorrectly, but at least I'm being as clear as I can be in my language.
If asked to provide a "Commitment", then I will go through the reasons I cannot provide one (assuming that is the case).
This may upset people - but better to do this at the start of a project.