What comes first - estimates or requirements?

We’ve seen many advancements of late in process improvement, better software estimating models, introducing flexibility and agility into software development, formal project management, limiting work-in-progress, etc. – all which incrementally advance projects forward and promise to reduce costly rework.  However, none of these methods addresses one of the most fundamental questions in software development:  what comes first estimates or requirements?

Chicken or Egg?If estimates come first… It seems like putting the cart before the horse if estimate precede requirements, but that is precisely how a good number of software projects go.  To begin with, someone has an idea or a business problem that software can solve but before any work even one dollar can be spent, the work has to go into next year’s budget and get funded.  This means figuring out some sort of estimate of work that has yet to be scoped out.  “Is it going to be bigger than a bread box and smaller than a football field?” is one way of saying – we need a “rough ball park” (guesstimate) that we can use in the budgeting process. Unfortunately this guesstimate process is clearly flawed because it is based on invisible and ether-like requirements. As such, the guesstimate is prone to + or – 500% or more variance once the real requirements are known.

This is like saying – how much will it cost to build a house for my family, just give me a rough estimate so I can go to the bank and arrange a mortgage.  This would be an absurd behavior – especially when one usually doesn’t get a mortgage in advance, and especially because the cost will vary depending on where, how big, how custom, and how the house will be built.  If  one secures a $500K mortgage amount – it gives an upper limit but doesn’t guarantee that a suitable house can actually be done for that amount.  Yet, we engage in this behavior in IT all the time – we guess(timate) for the budget cycle, the amount gets slashed during meetings, and ultimately the fixed price (based on little information) becomes the project budget!

If requirements come first… then in many companies nothing will ever get built and problems will remain the same forever.  Analysis paralysis is common (especially with shifting new business requirements) which gives rise to the support of agile and extreme programming approaches to requirements.  Many companies shifted their support from the arduous front end heavy “waterfall” methods of software development in favor of “progressive requirements elaboration” whereby requirements are discovered along the way. As such, requirements are always evolving with new user stories emerging only after the earlier ones are delivered in software.  So what happens when requirements are needed to build a better estimate (and thereby make sure the project has enough budget) yet an estimate is required before one can begin to scope out the requirements that will fit the budget?  It is a circular situation akin to the chicken and egg conundrum that has plagued humankind for years.

Pathway to cooperative results…One method that proves to work well with this dilemma is scope management – whereby a business “project” (more likely a program of work) is divided into sub-projects, scoped out at the highest level, quality requirements are thought about, and traceable estimates ensue.  More to come on this topic in the next post…

To your successful projects!


Carol Dekkers
email: dekkers@qualityplustech.com

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Close Comments

Comment (1)

  1. From my linked-in group – a few comments: #

    T Scott Ankrum ” First come estimates of requirements. ” 4 days ago

    Delete Carol Dekkers ” Good comment Scott! ” 2 days ago

    Delete T Scott Ankrum ” My comment sounds glib, but it’s serious. You can’t start any project but the trivial without a plan, and a plan needs estimates. You only know how big a development project is by its requirements. So, before you can start on requirements development, you must estimate the requirements. ” 2 days ago

    Delete Denis Meredith ” Our customers want estimates of the whole job at the beginning when we don’t know enough. The ideal would be for us to be allowed to estimate the next stage (with perhaps a guess at the rest of the job) at the end of each stage, with a decision as to whether to proceed at each stage. Unlikely to ever happen. ” 10 hours ago

    Delete T Scott Ankrum ” When I took my first course in software project management back in the mid 1980s, we studied what is now called the Waterfall method, because that’s all there was. The instructor emphasized that, in the beginning, only the first phase of the project could be estimated with any confidence. The remainder of the project could be estimated only very roughly. Thereafter, toward the end of any phase, only the next phase could be estimated with any confidence. You can and should give your customer a rough estimate of the full project at the beginning. As the project progresses, you can gradually improve that estimate. ” 9 hours ago

    Delete Carol Dekkers ” While I agree that a project cannot be initiated without any requirements – projects must often be budgeted and planned long before the first solid requirement is written. With waterfall development – the requirements phase IS the first phase – and further estimates should only come after. With agile/iterative requirements are user stories that are fleshed out incrementally as software needs are discovered. Regardless, the approx project size is a necessary pre-requisite to budgeting. This is the crux of the chicken/egg analogy – we need to know how big in order to answer how much, yet we won’t know how big until many months after the budget is approved. Thanks for commenting!”

Leave a Reply

Your email address will not be published. Required fields are marked *