March 2005

Lies, Damned Lies, and Project Specifications
by Brian Dunning

digg this article | del.icio.us this article

When I do consulting work, I work on an hourly rate. Period. No project price. No estimate. No quotes. No guarantees. I work hourly until they want me to stop. Don't like it? Don't hire me. Sound callous?

New clients - those who have never before worked with a consultant - are rarely impressed by this model. They want a firm price, they want it to be adhered to, and they expect delivery of their finished software on schedule and on budget. Sounds reasonable. Anything less is not professional.

Many, many moons ago I was a project manager at what was then the largest FileMaker consulting company, and we did our best to please this type of client. We spent weeks putting together a detailed project specification that described, in detail, everything the finished project would do. It summed up with a detailed price estimate. Numerous versions of this document would go back and forth until the client was satisifed that it did indeed cover every tiny piece of what they wanted. Again, sounds reasonable, and sounds like a client should expect nothing less.

So how do you predict the price of a project? Since custom development is, by definition, work that nobody has ever done before, how does one magically predict how long it takes? Well, you can, sort of. While a product manager in Silicon Valley I learned the VP Engineering's secret weapon for pleasing the CEO: the Super Duper Magical Project Prediction Formula. You ask the developer (a) what's the shortest amount of time the project might take; (b) how much time he thinks it probably will take; and (c) what's the longest amount of time it might take. You take these three variables and you plug them into your secret formula:

And hey, wow! Presto! It actually works, a surprising percentage of the time. When you break down a project into all of its components, apply the formula, and total everything up, you truly can have a reasonable prediction of how long a known, finite, well specified development project is going to take. So what's the problem?

The problem is that none of the above takes into account the variable that has, by far, the largest impact on the project, and which is completely out of the consultant's control. And anyone who's done this before already knows what I'm talking about: that variable is the client, their needs, their feedback, their company, their coworkers, their management, and the billion changes needed to handle all of this over your average year or two of development. It's clearly not remotely possible to know any of this in advance, let alone all of it. And it is by far the most important driver of the scope and cost of a project.

Hearing this, a new client invariably asks "How about if we agree not to make any changes unless they are separately quoted?" The consultant fakes a smile and agrees. The handshake happens. Eighteen months and a hundred thousand dollars later, the project is completely out of control, the client is frustrated and angry, there's no budget left, and there's no light visible at the end of the tunnel.

Want to know why this fails? It is because we, as FileMaker project managers and consultants, are applying exactly the wrong methodology. The process above (that of writing a detailed project specification and following it through to completion) is known as waterfall development, aka the Systems Development Lifecycle Model (see? it actually has a name!). In short, this is the process of breaking a project down into known, finite steps, completing each step in succession, and finally arriving at the finished product. Well, as described above, this simply does not, and cannot, work in the world of consulting. The waterfall model is wonderful for commercial product development where there is no client in the mix, but unfortunately that's not the case here.

Here are the six assumptions that the waterfall model makes (Wilfred J. Hansen, USC Center for Software Engineering):

1. The requirements are knowable in advance of implementation.
2. The requirements have no unresolved, high-risk implications.
3. The nature of the requirements will not change very much.
4. The requirements are compatible with all the key system stakeholders' expectations.
5. The right architecture for implementing the requirements is well understood.
6. There is enough calendar time to proceed sequentially.

Clearly the above assumptions do not apply for most client-based custom FileMaker development projects, for the reasons I've just described. Embark upon the project specifications method with a client, and you are coming as near to guaranteeing failure as possible.

The alternative - that which I so eloquently described in my opening paragraph - is called spiral development, first formally described by Barry Boehm at TRW in the mid 1980's. This is the process of gradually, carefully, "spiraling in" on the right solution. I like to describe it as "baby steps." When I start a custom project, I do a little bit of work at a time. There are always many changes and bits of feedback to accommodate at each baby step. As a result, there is never an opportunity for the project to get offtrack, and it's always clear exactly where it stands at the current level of expenditure. When a client asks how much more money to get the project done, I simply point to how much they've spent so far, and to where the project is now, and I advise them to draw their own conclusion. The future of the project is, after all, up to them, not up to me.

Now, the obvious point that a client is going to hear when you describe this process, is that there is no specifications document, no price quote, and no timeline. Try selling a project on that basis! It definitely goes against the grain of what most of us are accustomed to. And yet the spiral development methodology, I argue, is the only way to arrive at a satisfactory end result for an appropriate cost, in the world of client-based custom development.

Going back to our new client, for whom this is a first consulting project, it's going to be a tough sell. They have no patience for learning about development methodologies: they want to put up their hand and simply ask "How long, and how much?" Well, I usually let these clients go elsewhere. Many times I've had them come back to me a year or two later, after spending six figures, and this time they're more than ready to learn about development methodologies. It is interesting to note the volume of client work that is available for spiral development practitioners.

No quotes, no specifications document, hourly rate until it's done - does it still sound as callous?