Estimation attempts to address the two great unknowns of complex technological systems development:
Q: Why did I write "cost" twice?How much things cost
and
how much things cost!
Because I want to highlight that we're interested in more than monetary cost. Cost can be thought of in terms of the resources available or needed, things like the effort (of knowledgable people), resources we already have or can alter (tools, spatial arrangement, environment), and other things we can acquire (more or newer tools, equipment, space, specialist inputs etc). Linked with this is also the idea of "opportunity cost", the hypothetical cost of not doing something as we pursue one goal over another. However the point of this post is to develop the concepts and understandings needed to perform estimation.
For the moment I'll focus on the first "how much things cost"; the second "how much things cost" is the province of the complex technical sale, value perception and price, an entirely specialised domain, skill and art in its own right.
The question here is "how much will it cost to develop? What is the effort? How long will it take? How many people for how long to produce a nominal deliverable (more or less?)?
Accepted wisdom suggests that you make a guess, double it and hope for the best. Why? Novel valuable high tech requirements are by definition unknowns. And estimating how to produce an as yet unknown, unfinished thing is necessarily an art, not a science. But we don't need to leave it there; there are some approaches and practices, that combined, enable us to make informed 'guesstimates' or scientific wild-ass guesses (SWAG) that help us overcome this bind.
For example, if a requirement is very similar to something we have encountered, resolved or done before then, all things being equal, we use the prior experience as a template to estimate the cost of addressing the new requirement.
But as the new requirement strays into the unknown then risk and uncertainty increases and estimates inexact. Yet even here rigour can be applied, knowledge, expertise and judgement employed to suggest effort, cost and timeframe estimates.
"Estimation as practice" relies on the skill, knowledge, resources and contexts of those involved in a situation. Estimations are 'situated' in the same way that other kinds of knowledge work are situated amongst context, history, place and moments in time.
The methods below offer the rigour of organisational processes, from which estimates can be produced (and refined) for planning.
The Planning Poker method is a Delphi technique, an approach that harnesses the collective knowledge experience, judgement and wisdom of team members.
Constructive Cost Model (COCOMO), currently titled COCOMO II, is a holistic method for estimating software costs and schedules using generalised software design elements as a cost units. In simple terms you start from a figure of one person-month per function point (incorporating specification, design, test, documentation etc), and refine according to the empirical results your team/organisation achieves. COCOMO II provides three models for estimation/planning:
- Application composition; applies complexity-weighted costs for objects like screens (with layout, buttons, input, displays), data tables/schema, reports/outputs, components, objects etc.
- Early design; combines function point numbers and sizes with personnel attributes.
- Post-architecture: includes source lines of code (SLOC), function points, current architecture, code use/reuse, and project history data.
