The problem
Projects are full of decision making moments. Some of the most important ones are actually before the project has even started, in the preliminary stages when the outlines are being defined. This is often the time when scope and high-level requirements are defined, and a budget is being set. I’m thinking of the ‘cone of uncertainty’ – the horizontal V-shaped curve that describes how estimates of budget and/or time become more accurate as more information becomes available. When the project is finished, one usually knows exactly what it costs. But how to deal with the inevitable margin of error in early / original estimates?
How not to solve it
Based on experience, and knowledge of the industry or subject matter, and rules of thumb, we often make an ‘educated guess’ about the probable budget that would be needed to implement some initial list of (usually high level) requirements. And I’ve been in situations where power play was used to “force an agreement” on quite vague requirements and an all too limited budget (with enthousiastic ROI expectations to top it off). Everyone knew it, but there was no way to open a conversation about uncertainty in that corporate culture.
And then of course, after a few weeks, or maybe months, all kinds of nasty details and difficulties are surfacing as the team starts to refine the requirements and works hard to implement them. Slippage of costs and schedule are the logical next things to happen.
Why it does not work like you think it would
When taking decisions, people are overly optimistic and tend to take risks because of the expection of returns. We overestimate benefits, and underestimate risks. The underestimation of risks comes from the ‘What You See Is All There Is’ phallacy (WYSIATI): the innate tendency to assume that what we don’t see, just does not exist. And “to see” also means: what comes to mind easily. So we all tend to look mainly at the “known knowns”, we quite easily overlook the “known unknowns”, and we rarely even consider the existence of “unknown unknowns” – that’s why we call them “surprises”.
This WYSIATI phallacy also applies to the requirements in projects: in the early stages of a project, the wording and concepts we use for our project’s requirements are sufficiently generic and high-level that all the details and complexities are hidden. So we might describe a software feature in a phrase like “a calendar pop-up for selecting working days”.
This sounds straightforward, but hides a lot of detail: like the various types of calendar (western, Jewish, Islamic, astronomical; and then within the western calendars there is Julian, Gregorian and Ethiopian) and the various sets of non-working days (Sabbath on Saturday, Jum’ah on Friday; and then of course the different sets of national holidays).
There is no escaping the WYSIATI phallacy. Here is a press release snippet from September 30, 1999: “(CNN) — NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency’s team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday.” They must have had a requirement to “measure distance from Earth to the orbiter”, hiding the detail that various systems of measurement exist. When you use inches and yards every day, then that is all there is…
What you should do
Doing a project is essentially a process of ‘reducing the cone of uncertainty’, first of all with respect to the requirements and what it takes to implement them; and as a consequence with respect to the budget that’s needed to do all the work. So make sure to take an approach that acknowledges our WYSIATI brain bias and consciously puts a focus to the “known unknowns” and even has provisions to deal with the inevitable “unknown unknowns”.
All the agile approaches have coherent sets of practices to do just that.