Estimation, Part 3: The Art and Science of Predicting The Future With 100% Accuracy Using Only Guesswork and Microsoft Excel.

So. After several pages of whinge and a few more pages of groan on the subject of Software Project Estimation, the case has been vehemently made for adopting the following basic axioms and rules of conduct:

  1. If nobody is forcing you at knifepoint to make an estimate, don’t bother.
  2. An estimate is a guess, not a quotation.
  3. Guesses are mostly wrong …
  4. … and generally wrong in the direction of being wildly optimistic and nowhere near enough.
  5. If you have to take a punt, start by figuring out how long you think it will take until It Works On My Machine, hereinafter to be abridged to I.W.O.M.M.
  6. But don’t get cocky. I.W.O.M.M. is not anywhere near finished.
  7. And don’t try to be clever. Double I.W.O.M.M. is not anywhere near finished either.
  8. From I.W.O.M.M. to categorically done and dusted will be a long wearisome uphill slog. Wiser heads than us reckon it at nine times as much effort, at least for commercial shrinkwrapped software.
  9. Nine times is about right (and may not even be quite enough) for gear which ships with tip-top documentation, has no obvious bugs, will install neatly on any machine, is straightforward for idiot consumers to figure out and will then run smoothly and reliably for years.
  10. However, as most of are not writing the Amazon site or Excel, probably the bar is a bit lower.
If you’re setting down a short list of basic guidelines, maxims, commandments or whatever, ten’s a nice round number. Best not go the whole engraving-tablets-of-stone hog though – you don’t want to have to hire a monumental mason every time you need to shift your philosophical position a couple of degrees.

If you’re setting down a short list of basic guidelines, maxims, commandments or whatever, ten’s a nice round number. Best not go the whole engraving-tablets-of-stone hog though – you don’t want to have to hire a monumental mason every time you need to shift your philosophical position a couple of degrees.

So to get from an I.W.O.M.M. estimate to a reasonable guess at finished, you need to apply a factor definitely bigger than two, but maybe not so big as nine. But if it’s worse than double, but not nine times as much, how much should it be in the typical case ? Typical is a dangerous word, but let’s take a hypothetical I.W.O.M.M. estimate of 100 days and see how much might end up having to be done overall to get the whole shebang live, assuming a typical kind of set up where:

(a) it’s a typically on-target I.W.O.M.M estimate i.e. an honourable punt, not far off given favourable conditions, but certain to have overlooked a few choice points.

(b) you are struggling with typical levels of pointless / essential governance and bureaucracy

(c) the end product has to operate at typical levels of reliability, security and load i.e. it has to be pretty well bombproof but not at the level required for air traffic control.

(d) the Gods visit upon you a typical string of cock-ups, surprises and emergencies.

What else must be done before you can safely release your concoction out into the wild ? Well …

  • Before you can even kick off, non-trivial time must be spent on:
  1. the estimation you already did @ 3 days
  2. knocking requirements into shape so that it was clear what you were being asked to estimate @ 5 days
  3. roughing out some excuse for a design, either because you genuinely need to, or simply to keep the architects happy @ 3 days
  4. expanding that design when pressed by said ruddy architects to include Inter-Op Schema, Entity-Relationship Diagram, Data Model (Logical), Data Model (Physical) etc et-bloody-cetera @ 10 days
  5. manufacturing all the blasted forms, risk logs, mandates, generalised bumph and documentation which your Programme Office deems to be indispensable, and then jumping through all the wretched hoops they require for them to be approved so that you are allowed to get cracking for real @ 8 days

totting up to about 30 days pre-preparatory pratting about and you have not even declared a single integer variable yet.

Like Michael, you may very well Wanna Be Starting Something, but you sure as shite won’t be until you have submitted all the necessary and pre-authorised pre-requisites for Project Tollgate One. You may think that is Bad, but the twats in the PMO will tell you in Black and White to Beat It. Ahem.

  • Once you are actually coding, there is much toil to be toiled which as it isn’t coding per se, your I.W.O.M.M number will not have accounted for. For example:
  1. kit and tools to be set up, beginning with servers and databases and continuing with version control, build automation et al, and all of this gubbins to be continuously trimmed and fettled as you go along @ 10 days
  2. more testing during development than you ever expected, be it unit, manual or automated, which will throw up gaffes which then have to be sorted @ 25 days
  3. peer reviews and associated rework @ 5 days
  4. wrangling with random interventions from customers, architects, PMO, senior management and any other old git that wants to stick their oar in @ 5 days
  5. meetings, timesheets, multifarious general admin @ 5 days
  6. documentation, governance, form-filling, reports, risk logging, 3+9 budget look-aheads, Gantt charts and any other project management chicanery required on pain of death by Programme Office trolls @ God Knows, could be trans-finite, but let us posit 30 days.

With the 100 days you had at the off, and the 30 days beforehand, this 80 day sized lump brings your running total up to 210 days. So we’re on double, and counting, and we haven’t even given the testers a sniff of it yet.

  • Testing beyond the bare minimum obviously never gets taken into account in an I.W.O.M.M. estimate. Generally the I.W.O.M.M figure will stretch to basic checking of the order of I-ran-it-some-guff-appeared-on-the-screen-right-sort-of-colour-no-immediately-apparent-gotchas-nothing-exploded. Sometimes we dip even below this and the estimate doesn’t extend even to compilation let alone trying to use the program. “I will create it; it will work; I am perfection” seems to be the mantra. But let us not be unkind and let us take it as read that when the code hits test it has been thrashed by its originators to a respectable standard. Even so, proper system testing will span far more use cases in greater depth and so take an awful lot longer but thereby unearth subtler problems and less conspicuous omissions. So it will be a sizable endeavour, even when the labours that preceded it were solid. Maybe:
  1. Test prep. Establishing what to test, and how @ 5 days
  2. Environment set up. As for development, but harder. You need the test kit to match live as closely as possible, and that means the boxes themselves, their configuration, data and databases, and connectivity. Not simple @ 15 days
  3. Testing. The nuts and bolts: functional, system, integration, whatever you call it @ 30 days
  4. Regression testing, to make sure that in producing new gubbins you haven’t bust any of the old gubbins @ 10 days
  5. Load testing, performance testing, penetration(*) testing. Some of these might not be necessary in your particular milieu but then again all might and they can take frigging eons but let us be hopeful @ 10 days
  6. Bug fixing, including fixing bugs introduced when other bugs are being fixed, is always chunky @ 40 days
  7. Re-testing and seventeenth-pass-cross-fingers-all-fine-now regression @ 10 days
  8. User Acceptance Testing. Obviously the users will do this themselves, but they will need their tiny little business hands holding @ 10 days
  9. More bug fixing, from howlers that emerge during UAT @ 20 days
  10. Non-bug fixing. You can’t pick your users. They’re not always the brightest stars in the firmament. Many of the “concerns” they bring to you will not in truth be errors at all. For example you may receive incident reports which read “banner has a horrible lilac background” or “when I push the button the letters go funny” or even “screen is black”. It doesn’t generally pay to ask customers if they are f**king kidding, so one must instead be diplomatic, sincere and helpful and look into even the most spurious non-issues with painstaking thoroughness. Often well over half of UAT “concerns” will be misunderstandings of how the thing is meant to operate (both legitimate and silly), requests for extra changes, random opinions, unreproducible glitches, and plain unadulterated unvarnished idiocy. All of which make work for the working man to do @ 20 days
  11. General admin, meetings, governance and documentation. Everything you had to do during build, and much, much more. Test Progress Summaries, Outline Test Plans, Test Completion Reports, Requirement Test Coverage Matrices and so on, how much and how far depending on your employer’s specific level of organisational psychosis @ 30 days

Giving an overall Score on the Door for testing in all its shapes and sizes of 200 days. We are up to 410 days now, and we haven’t put so much as a batch file live.

“So Isla, what are the Scores on the Doors ?” “Well Larry, the names in the frames are Bob and Cheryl with a 68% overspend, and Graham and Tina with a 23 week delay against baseline.”

“So Isla, what are the Scores on the Doors ?” “Well Larry, the names in the frames are Bob and Cheryl with a 68% overspend, and Graham and Tina with a 23 week delay against baseline.”

  • It’s committed, it’s tested, it’s bundled, it’s been accepted by the users, it’s been signed off by the Steering Group, and the PMO have even inked all the pages in your project passport with a big blue FIT FOR PRODUCTION stamp. Which means you’re all done, right ? Just give the big red launch button a hefty thump and Bob’s your uncle. Would that it were so but as ever for reasons both sound and ridiculous, there is a little more footslogging to be done:
  1. Change Management, Application Support and Infrastructure will compel you to participate in their traditional religious ceremonies, typically referred to in their primitive native dialects as “go-live meetings”, “deployment workshops” and “production change boards”. During these hallowed rites, sacred scrolls known as “requests for change”, “release notes”, “schedules of events” and “deployment instructions” will be penned, ruminated upon, redrafted, illuminated, annotated and, after many moons have passed, finally blessed as being fit for reverent submission to the Gods of ITIL @ 6 days
  2. Rolling a new release out is rarely a one-click operation. There’s umpteen servers, nobody has rights to update the stored procedures, somebody forgot to copy a config file somewhere. It can take a few blokes a few hours so @ 2 days.
  3. Even after assiduous testing of well-structured software, there will still be faults that slip through the net. These have to be found, mended, patched live, and their regrettable consequences tidied up. As we have conscientiously tempered the code through several rounds of QA, these should be small, of limited impact, and fairly easy to resolve. Still @ 7 days
  4. Yet more governance, admin and bureaucracy. The closing instalments of reports and paper-pushing and meetings that you had before, plus an Overall Budget Statement, a Post Implementation Review, a Post Project Review, a Lessons Learned Log and a Project Closure Report @ 5 days if you’re lucky.

And then you are at last utterly finished and done with, at a grand total of 430 days or 4.3 times your initial guess at how long it would take to get I.W.O.M.M.

Finished and done with. Over. Completely finished. Period. No more. Full stop. The end. Full period.

Or almost. A multiplier of 4.3 is by my reckoning completely sensible, believable, justifiable, and even a touch on the sunny side. Many different factors could push it up or down, though I would be very wary of making it much lower. The scenario above assumes no major disasters on the one hand, but a medium-to-high level of tedious fussy red tape on the other – in essence it proposes capable people putting in a good show with the main drag on their time being the bureaucracy. The circumstances that can throw it out wildly are:

  • Rubbish people. Or to be precise, rubbish people picking up the ticket after clever (and perhaps slightly cavalier) people have estimated how long it would take for them to do it themselves, rather than their idiot colleagues.
  • Wildly deranged estimation. If your I.W.O.M.M figure was way out on day one, you’re bolloxed.
  • Omissions. Minor tweaks can probably be mopped up along the way. But if the customer forgets to tell you something they need, or worse, they tell you and you forget to quote for it, ¡Ay, caramba!
  • Technical sinkholes. Some 3rd party library you rely on doesn’t behave and has to be replaced, some class you did write limps like a beaten dog and it takes ages to puzzle out why, a bit of keyhole surgery on some venerable old module turns into a quintuple bypass combined with a liver transplant, God knows what else. There are a thousand ways that the ground can open up beneath your feet and you would be very fortunate indeed if you got through an engagement without having to fill at least a couple of large potholes.
  • Fussy and/or stupid customers. Good users are rare and valuable. Bad ones are common, and will consume time and money like a fat kid gets through sausage rolls. It will take forever to establish what their requirements are, they will be revised whimsically and erratically, and UAT will take forever. They will insist that extras they’ve dreamed up minutes ago were in the original scope, even though there is substantially less physical evidence for that than for the Lost City of Atlantis. You can pour out your oily charm to flannel them into compliance, you can cuff them hard round the ears with the specification they signed off, or you can fold and deliver a truck load of extra features free, gratis and for nothing. Without doubt you will judiciously employ a combination of all three tactics (i.e. soft soap, stonewalling and presents), all of which soak up time and energy. As you want repeat business and to minimise moaning complaints to your superiors, you will almost certainly end up giving stuff away buckshee one way or another for the sake of a quiet life.
  • Supernumerary people and superfluous nonsense. You may have to carry and account for a few idiots doing pointless jobs badly. Perhaps you are required to support a Business Content Subject Matter Expert, or a couple of Enterprise Architects, or a Programme Administration Officer. Alternatively, there are vital ancillary duties to be done, but the morons assigned to doing them aren’t, can’t or won’t. You are landed with a technical author who is borderline illiterate, or are forced to provide a home to an analyst who would flounder putting together the user stories for Pong. The engineers plug the holes the gormless oafs ought to be filling with little fuss, but the parasitic cretins still send in timesheets and submit invoices and inevitably waste dollops of other, more useful people’s time as well.
Pong. Three moving parts, two dimensions, one colour, and yet still way beyond the ken of many Senior Vice Presidents of Product Management.

Pong. Three moving parts, two dimensions, one colour, and yet still way beyond the ken of many Senior Vice Presidents of Product Management.

One or more of these demons will manifest itself in your case, and will chew up days, weeks and months. Therefore you need another 15-20% on top to allow for what we in the trade call “random crap”. So, using maths, the alpha-to-omega-that’s-it-no-more-all-in-soup-to-nuts-breakfast-dinner-and-tea quote is:

100 days                                I.W.O.M.M

x          4.3                               Testing, bug-fixing, design, cutover, admin, form-filling etc

+          15-20% (or so)         Unforeseen disasters

=          500 days                  Near as dammit.

So five times as much as your opening I.W.O.M.M. gambit.

The Number Five, cultural, mystical and scientific significance thereof. Clockwise from top left: The Famous Five; Pentagram; Take Five; Five Fingers Has The Hand; Starfish; The MC5.

The Number Five, cultural, mystical and scientific significance thereof. Clockwise from top left: The Famous Five; Pentagram; Take Five; Five Fingers Has The Hand; Starfish; The MC5.

 

This is no more than a guideline and I cannot claim the number 5 as a new universal constant. But I have had a look back through a few old projects a few times with a semi-forensic eye and it seems to tally with the actuality, close enough for jazz anyway.

Whatever multiplier you come up with, your estimate will provoke an orgy of whinging and griping. Be firm when challenged, remember how badly things have turned out with earlier projects, and stick to your guns. Remind the sponsors of the many many overruns they have beaten you up about in the past, show them your calculations, or, if feeling bold, ask them if they fancy having a crack at hacking the bleeding code together themselves. Lastly, remind them of the many concrete physical icons of the modern age, outside of the dreary and intangible world of software, which began with wildly gung-ho and over-optimistic vision statements, and ended in recrimination and monumental budget increases. The Panama Canal. The Channel Tunnel. The Sydney Opera House. Soften them up with all this historical collateral, cuz when they ask how long it’s going to take, they’re going to be even more pissed off.

Budget at outset in 1957: A$7m, with a very definitive completion date of 26th January 1963. Australia Day, see. Ultimately spent A$102m , or a tad over 14 times as much, when eventually completed in 1973. Yes, iconic, yes global landmark, but, even compared with the dismal standards of software project forecasting, a bit late and a bit pricey.

Budget at outset in 1957: A$7m, with a very definitive completion date of 26th January 1963. Australia Day, see. Ultimately spent A$102m , or a tad over 14 times as much, when eventually completed in 1973. Yes, iconic, yes global landmark, but, even compared with the dismal standards of software project forecasting, a bit late and a bit pricey.

 

(*) Fnarr fnarr.

Kyuk kyuk.

Kyuk kyuk.

Advertisements
This entry was posted in Uncategorized and tagged , , , , , , , , , , . Bookmark the permalink.

One Response to Estimation, Part 3: The Art and Science of Predicting The Future With 100% Accuracy Using Only Guesswork and Microsoft Excel.

  1. Pingback: Estimation, Part 4: Are We Nearly There Yet ? | IT Shambles

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s