More on estimation principles

I saw this comment by Dennis Stevens (Dennis’s blog is here) on Glen Alleman’s post on software estimation practices (here).  His comment hit on two points that stood out.

Effective estimating requires a strong understanding of variance in estimating and how to account for/govern this variance.

Ditto and amen… my experience in implementing logistics optimization (I worked for formerly-independent component of Descartes) helped me get comfortable with the fuzziness of estimation (e.g., variance).  Two b-school courses were also helpful: mathematical modeling for marketing and applied multivariate analysis (I keep the latter’s textbook by my desk). This background may not make me an expert, but I have a decent estimation BS detector.

Politically driven estimates are just irresponsible management. I remember a conversation with an executive where I told him “This is a 46 week effort. If you need to say 32 to get funding, then you can say 32 and deliver 14 weeks late – or we can say 46. It’s up to you.” We presented at 46 weeks, got the funding, and delivered on time. If an organization can’t afford to do a project, it shouldn’t be done based on false estimates – this is malfeasance.

As Dennis suggests in this case, pretending that the earlier delivery target does not compromise the product or mean inevitable delays is foolish, even unethical.  My experience is that this self-sabotaging approach happens because the project can’t or won’t demonstrate the impact of such decisions on the initiative’s business case.

To that point about the business case, I’ll use a future post to lay out how we used a simple illustration of our business case to justify an internal program’s proposed release schedule.

%d bloggers like this: