In my line of work, there isn't a single simple deliverable that is so labour-intensive that I can't complete it in one day.

I define a simple deliverable here as one for which the goal is well-defined, all the necessary materials and tools are present and accounted for, and all the techniques for operating over them are well-understood and there is data on the time it takes to execute. It's like assembling IKEA furniture: It may look daunting, but if you follow the instructions, you'll get what you expect, when you expect it.

A complex deliverable, on the other hand, is missing at least one of the criteria of a simple deliverable. Put another way, a complex deliverable depends on the completion of one or more other simple—or complex—deliverables. To use another domestic metaphor: How long would it take and how much would it cost, do you think, to build a toaster from scratch? The answer is you'll have to try it to find out.

The complexity I'm talking about has nothing to do with how hard a given task is, or its artfulness or even how many steps it takes to complete. It has everything to do with whether or not all the inputs are ready to go. To go domestic again: If you have all the ingredients and equipment you need to cook a meal at home, there's nothing impeding on your ability to do so. If you discover that you have to go to the store, then you're already eating late. If the store doesn't have your missing ingredient, you have to go to a different store. If all the stores are closed, then I guess you're ordering a pizza.

What makes deliverables complex is that tiny perturbations in the time and money it takes to get all the precursors together, to turn a complex deliverable into a simple one, have non-linear effects on the total cost of achieving the goal the deliverable is supposed to address. Non-linear—as in exponential! If I told you your goal was going to cost somewhere between $1,000 and $1,000,000, how useful would that information be? If I told you it would cost $10,000, or even between $10,000 and $50,000, a fivefold gamut, I would be lying—to you and to myself. And this is why I've chosen to abstain from uttering estimates on complex deliverables: if I'm going to stand by a figure, I want it to be both useful and true.

Now, critics might harp that I just need to get better at estimating. I say bullshit. I say this because I came to this decision after years of careful research and contemplation on top of a decade of watching the pitiful clown act that is software and Web development. I also say this because the only people I've met that provide accurate estimates are doing a very specific trick: they are either only offering simple deliverables, or they are coercing complex deliverables into simple ones. That is, they take the problem and frame it in terms of a formula, then they execute that formula, irrespective of whether or not it actually solves their client's problem. The people who actually solve their clients' problems, under that Procrustean constraint, are up all night—often on their own dime—until they do.

People pay me to solve problems, not execute formulae. Complex deliverables are therefore my reality. If I'm not going to tell you how much I think it's going to cost to acquire one, we might seem to be at an impasse. Fortunately, as a lifelong student of problem-solving, I have solution, which I paraphrase from George Pólya's aptly-titled How to Solve It:

If you can't, at this moment, solve the problem at hand, then for goodness's sake solve a different problem.

One more metaphor and then I'm done: If you're missing an ingredient to cook a specific meal, then cook a different one. It'll still taste good, and you'll still get fed. In the meantime, if you go shopping every day, or make batches of sauces and whatnot and freeze them, you'll find yourself rarely wanting for ingredients. In my line of work, that translates to simple deliverables: collecting precursor material, creating tools, experimenting with new techniques, breeding serendipitous concoctions, and of course, keeping an exhaustive inventory. Every. Day. And every day I make something that can at least be applied to the real business problems of the clients I work with, if not something they can use right away.

⁂

I arrived at this method of production because it's the best way I know to create real, ongoing value and mitigate risk in a situation full of unknowns. If you have questions, I entreat you to contact me, either by email, Twitter or Skype.