This is the second in a sequence of four posts (and more to come) on BASIC software estimating concepts that address “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”?
- “It” could be the project (and all that the term entails);
- “It” could be the resultant product (software and/or hardware);
- “It” could be a phase or exploratory R&D effort; or
- “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 2: “It” is the resultant Product
When the “what” we want to estimate is the time, effort, cost or scope to build a software intensive product, there are different considerations than if we are estimating a project, such as:
- What is the product – a working, full-scale “system” (multiple interlocking pieces of software plus associated hardware, and glue code for linking it all together, and documentation) or a portion thereof?
- Are training modules and online guides to be included as part of the product delivery?
- Does the product include hardware, and peripherals (like printers or scanners)?
- Will the entire product (or service) be delivered in “one fell swoop” or delivered in separate pieces? (This could involve multiple projects that may deliver parts of the software, with later projects having to redo/enhance what was delivered in an earlier release.)
- Do we know what the product will actually be?
- Are there multiple stakeholders (direct users or indirect ones) whose priorities for product functionality may vary or even conflict?
- Has a product like this been done before (i.e., do we know what all is needed such as additional software, hardware, etc.)?
- What else is included as part of the product? (And what is excluded?)
Software intensive systems are often negotiated and estimated as concrete commodities, however, the challenge of deciding “what actually constitutes the software intensive system ” is a key component that needs to be decided before doing any estimating.
Sounds pretty basic doesn’t it: Know what “it” is you are estimating before you begin estimating…
Unfortunately, as Peter Drucker once said
“It is important to state the obvious otherwise it may be overlooked.”
Know what you are estimating BEFORE doing an estimate… pretty fundamental don’t you agree?
Comments, brickbats, responses welcome…
Related articles
- Fundamentals of Software Estimating: First see the Elephant in the Room- part 1 (musingsaboutsoftwaredevelopment.wordpress.com)
One Comment