Fundamentals of Software Estimating: First see the Elephant in the Room- part 1

This is the first 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”?

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 1:  “It” is a project

The concept of a “project” is the basis of Project Management 101 (per the Project Management Institute‘s formal PM Body of Knowledge: PMBOK®).

When I taught project management for a major government agency overseeing billions of dollars of software development, it amazed me to find out that many unofficial, self-appointed “project managers” accepted the notion that  a project could be an amorphous concept with a jello-like scope, undefined start/end points (let alone the idea of acceptance criteria that would define when a project is “done”), sketchy objectives, that could go on for years without delivering results.  For many, the end of the project was a often a moving target because new functions were routinely added during construction or “substituted” for things that were no longer needed. Such projects run out of control with schedules that go on forever, a scope that remains ambiguous and ever growing, and budgets that are essentially buckets of money.

Some projects started with an idea (no one could remember why) and as long as it “stayed in the green box”  (meaning that it didn’t raise the ire of management or be outside of acceptable metric limits) it was a “good project.”  The prevailing idea of a project budget was “five people working full time on this stuff until we’re done” and the schedule was “we thought we’d be done by now, but management keeps adding more stuff to the pile of things they want in the system.”

As an engineer, I often compare software development to building construction – with the difference being that software development often starts without “sealed engineering drawings” or the equivalent (formal plans) and either gets canceled along the way or goes on until someone says “stop.”

The Project Management Institute (PMI) defines a project in its PMBOK® 4th Edition as:

A temporary endeavor undertaken to create a Unique product, service or result.

So, if we are estimating a PROJECT, we must minimally be able to define:

• What is the scope of the project:  Will it include a full lifecycle (i.e., from concept definition and requirements through to working installation of software for the first user?) What is the final result (a product, a concept, a service) and what are the functions to be included?
• Who (the stakeholders), what (as above), when (how will we know it is done?), where, and why (what’s the objective?)  Note that HOW the project is to be done is outside the definition of the project.
• What is included (and even more important sometimes – what is NOT included) and what are the start and stop points?  What (explicitly) is outside the boundaries of the project (such as training; corporate rollout; multiple languages; etc.)

Once you’ve defined that “it” is a project that you want to estimate, and have defined what constitutes said project as outlined above, make sure to write them down.  Once you’ve got these minimal things documented, you are ready to at least begin to think about how to estimate the items in the original list I presented at the top of this post (how big, how long, how much, how good.)

For more information and definitions about “Projects” refer to www.pmi.org (The official site of the Project Management Institute.)

Stay tuned for part two: If “it” is a product.