Simeon Franklin

Why I Don't Do Quotes on "Big" Projects

I don't do quotes on "big" projects. That includes guaranteed prices and guaranteed launch dates. The reason for this is that on most large projects the requirements are undefined and there is no way of defining them better than actually doing the project!

Let me illustrate what I mean by example. First consider the small, well-defined project: a client asks for a Google Map on an existing html page that shows the location of a half a dozen points of interest whose addresses are contained in a spreadsheet. This is a job I can give a fixed estimate for: I can have this done next Wednesday for $200 (to randomly pull figures out of the air).

The point is, small jobs with few unknowns are easy to quote - If I've done the exact same thing before I know how long it will take... On the other hand I've had people ask for dollar/time quotes based on two sentence descriptions of complex projects. Consider:

We'd like a website that allows people to schedule their session with their personal trainer at our gym. We'd also like to be able to manage their membership payments online.

Just count the number of variables: do personal trainers have a way to manage their information? Are we actually accepting Credit Card payments online? Or just showing outstanding balances? Are we sending notifications when payments are due? Can they pay arbitrary amounts or only the comlete outstanding balance? Can members edit their profiles online? Can the Gym manually enter payments or schedule appointments? What happens when a trainer cancels an appointment... I could go on and on...

When pressed for a fixed quote based on almost no information my only response is to throw out a figure high enough to let me do whatever the client wants for as long as they need me. Sure, I can build www.MyGymSchedule.com for $100,000 in 6 months.

Unfortunately nobody's ever taken me up on my "Crazy Money" proposals. The traditional software engineering approach to solving this problem would be to spend time with the client formulating a requirements document that details an answer to every question I've asked (20 pages instead of 2 sentences). Once the document is completed I would create an estimate with fixed costs and timelines based on the requirements document. This is popularly called the "Waterfall" method of software design or, more pejoratively, the Big Design Up Front (BDUF).

What's Wrong With BDUF

So what's wrong with the traditional model? First there is the problem that creating the 20 page document will probably require a significant investment from me, the technical lead on the project if the client has not been able to create it on their own. So now I'm either donating my efforts in hopes of getting the job or convincing the client to go through a process they didn't think would be needed. More seriously, however, is the problem that all specs are incomplete and all requirements are subject to change.

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Dwight D. Eisenhower

This is key so I'll just repeat it - All requirements change. This realisation is what has driven the software industry towards more agile methods and is responsible for the general increase in software project success in the last decade. Planning is still valuable when it consists of refining expectations and more clearly defining goals. But planning is an ongoing part of software development, not a prerequisite or a prelude.

Realising that for large projects attempting to completely specify all requirements before hand is ultimately a fruitless aim sends us off in search of ways of managing change instead of ignoring it. Consider the case study I've been describing: www.MyGymSchedule.com.

Iteration

A better approach than BDUF for both programmer and client is to start an iterative process that aims to find out what the client really needs and what the financial tradeoffs are while delivering a usable product all along the way.

For instance - I can build a site that shows the total balance for a member and lets them see the available slots for all the personal trainers for perhaps $2000 dollars. When the site is complete let's decide what features we actually need - maybe the next thing to do is let the member actually schedule the appointment online - we can hash out exactly how that works (email notification, cancellation protocols, and so forth) as we develop it. I can also tell you about how much that feature will cost and how long it will take to complete. Rinse and repeat until the cost of new features outweighs their benefits.

This sort of iterative process requires trust on the part of the client - that I'm not going anywhere, that at each stage of the project we will have a product that justifies the investment so far. But in another way it minimizes catastrophic risk for all parties: the risk that I'll complete a project that conforms to a requirements document but doesn't actually meet the clients needs. This is where failures hurt! - and I've been on projects where money (from the client) and effort (from the technology provider) have been spent but nobody is happy...

Iterative development aims at failing earlier rather than later, at discovering the insufficiency of the requirements as early as possible, at keeping a tight cycle of communication between developer and client, and at keeping deliverables in small, bite-sized chunks. I am committed to this style of development because I honestly believe it stands the best chance of allowing me to sucessfully complete projects to everyone's mutual satisfaction.

Technology

It helps of course, to not only be using processes that provide the ability to agilely respond to the evolving requirements of the customer, it's important to be using technology that is agile as well. That's why, while I've built web applications that included code written in PHP, C++, Perl and VBScript, today I prefer the Python programming language and the Django web framework. Django is "the web framework for perfectionists with deadlines" and fits exceptionally well into the iterative process I've described. Be sure to read my technology page for the details. If I sound like the kind of web professional you've been looking for, head on over to my contact page and tell me about your project!