[DRAFT] Scoping and Estimating Projects

    I had an exchange with a colleague last night, and it really pushed me back into this gear. Realizing I haven’t published these kinds of thoughts on Codemanship.ca, and indeed it’s been a while since I’ve written about this topic, I figured it was time to write down my current thinking.

Colleague: [discussing potential project, a “quote” from a developer who became unavailable]

Me: “I don’t do quotes anyways… I haven’t done fixed cost fixed scope projects in a long time. IMO it’s what’s driven the custom software industry to hell, it’s a road paved with broken promises and naive expectations

Colleague: “So when you take on new work how do you give an expectation of budget?”

Me: “An educated guess based on past experience, a development process that ensures business value is front end loaded, and helping them understand how to make decisions without the crutch of a comfortable lie.”

So I’m going to unpack this exchange a little. I often get pushback when I’m bidding on work from web development companies that don’t get into a lot of work that I’ll characterize as “hard development” (not that what they do isn’t hard, it’s just different), and it always falls in this direction. If I won’t commit to a budget and scope, how can they cost it out, and then how can they win the business?

Now, let’s set aside a couple things in the lens of the web designer - first that the web design industry is fairly commoditized. Web design projects typically have a well established concept of “finished”, and the market has a lot of churn, arguably acceptable churn, where organizations will regularly toss out a design and build a new one, often with a different designer.

My first point is that custom software development takes a lot more effort than people like to believe. If people believe it’s less work than it actually is, then they’re less inclined to pay for the work that actually needs to be done. Developers will often fall prey to false optimism when estimating, potential clients with no prior experience commissioning custom development work always seem shocked at the effort and costs, and this puts further downward pressure on estimates.

Combine that with the research that indicates estimates are easily biased through suggestion and wording, and you begin to see the recipe for disaster.

My second point is that software is never finished. It’s convenient to think of a project as something you might declare “done” one day. Ask Microsoft if Word is done. Ask anyone if the software they use every day to run their business is “done”. This word sounds authoritative doesn’t it? It’s done! Well, until you find a misunderstanding codified within it, or a deficiency that the business didn’t think of when they “scoped” it, or a genuine mistake made by a developer, or a new operating system or browser or other technology that it won’t work with, or evolving user expectations around user interface design, or or or or. You might think it’s as easy as reading and understanding a scope document, but let’s point out the challenges usually awaiting you there…

• scope documents written in varying conditions, by people with varying understanding of the work that needs doing