Skip to main content

Fundamentals of Software Estimating: First see the Elephant in the Room Part 4

By August 21, 2013April 20th, 2022No Comments4 min read

This is the last in a series of four posts (and more to come) on BASIC software estimating concepts that address the “WHAT IS IT?” we plan to estimate.

Upcoming posts will address:

  • Fundamental principles of estimating (micro estimation versus macro estimation; probabilistic estimation, degrees of uncertainty);
  • What can and should an estimate be used for?
  • Pitfalls and missteps in software estimation
  • Do you need a tool for estimation – including a survey of the most popular software estimating tools
  • Does size matter?  Shortcut approaches to software sizing
  • Succeeding with estimation – creating a Software Estimating Center (with or without a Project Management Office PMO)


Whenever I teach project estimating or Project Management 101 (basics) to software developers, we address the fundamental questions about what we plan to do (once called “The Triple Constraint” in project management circles):

What amazes me, is that while these are great questions that need to be answered when we do an estimate, we start out by ignoring the “Elephant in the Room” – that is, what do we mean by the “it” in the questions above.  Sure, for some people “it” may be obvious that “it” is a project, but bear with me for a minute… misunderstandings about terminology and definitions are often the source of major rework when software construction is involved.

What is “it”?

  1. “It” could be the project (and all that the term entails);
  2. “It” could be the resultant product (software and/or hardware);
  3. “It” could be a phase or exploratory R&D effort; or
  4. “It” might be something altogether different...

The question of “what is it?” we are estimating is fundamental to why IMHO (In My Humble Opinion) software projects end up being over budget, late, and out of scope.  If you don’t know definitively WHAT you are estimating, how can any possible estimate be realistic?

This post is Part 4:  “It” is something completely different (i.e., not a project, a product, or an R&D effort)

When the “It” is production systems support (i.e., keep the systems up and running) or help desk (answering calls and troubleshooting) or product installations, the first question remains – how big or how large is the scope?

The following types of questions need to be answered to help size the scope to be estimated:

  • What length of time will the estimate be intended to cover (i.e., a year is typical)
  • What applications are to be supported/included?
  • What level of support is needed (24 x 7 or five days per week or some variation?)
  • What is included in the work (analysis, troubleshooting, training, rework, enhancements, etc.)?
  • How many users use the system(s), how often (daily, weekly, all the time), how many locations are being supported (geographically dispersed?), are there multiple languages that need to be supported?
  • Does support include time for vendor liaison for supported/installed packaged software?
  • Is support variable throughout the period to be estimated or consistent? (i.e., are there critical performance periods (such as yearend) during which the support needs to be increased?)
  • Are there service level agreements that govern the quality and responsiveness of support?

This list is not exhaustive, however, it does outline the major considerations for scoping out support or help desk activities or installations.  Knowing the goal and the scope of such efforts is the first step in being able to realistically estimate support.

The next post…

Takes a basic look at the components beyond figuring out what is to be estimated (the critical first step).  I hope you’ll join me then.