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

This is the third post 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.

Introduction

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):

• How big is it? (Scope management)
• How much will it cost to build? (Cost estimating and budgets)
• How long will it take to build? (Scheduling)
• How good does it need to be? (Quality)

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 3:  “It” is a phase or exploratory R&D effort

When a phase or exploratory effort becomes the “what” we are estimating, a concrete definition can be difficult – especially because at this stage (early, preliminary, before we know what is needed to be built) – it is difficult to figure out the “size” of what we want to estimate.

A key element when we want to estimate how much effort, cost or duration to allocate when estimating and R&D endeavor is to figure out the scope (what is included IN the R&D and what is not!)  One way to look at R&D projects is to look at previous “similar” completed projects as a fog-test, ball park of what your particular project might entail (assuming that there are good records of such projects at hand.)

For an R&D type of effort, consider the following:

• What is the starting point of such an effort (is it purely a concept or wild idea of a software solution or a software and hardware solution or a service?)
• When will you know definitively that the effort is finished (i.e., project completion criteria)?
• How many alternatives are to be explored/presented/documented?
• Has this type of R&D effort been done by the team/company before?
• What is the output of the effort intended to include? (Working model/prototype, mock screens, costing, documentation of results and research approach, interviews, online research, on site visits with prospective solution vendors?)
• Are there related efforts going on (interfacing “systems” work, other software development) that could impact the proposed solutions(?)
• What will constitute success of this effort?

Note that for each type of effort or project identified as the “it” we want to estimate, the “construction” or development equation will be different.  This is similar to having a variety of building construction equations depending on whether one is building a hospital, renovating a school or doing a study of the environmental impact of a project on a neighborhood.

First we need to know WHAT we want to estimate (the elephant in the room), then we can begin to tackle HOW we can estimate.

Best wishes,
Carol

Related articles

• Fundamentals of Software Estimating: First see the Elephant in the Room- part 1 (musingsaboutsoftwaredevelopment.wordpress.com)
• Fundamentals of Software Estimating: First See the Elephant in the Room: Part 2 (musingsaboutsoftwaredevelopment.wordpress.com)