Damned Lies, and Project Specifications
by Brian Dunning
article | del.icio.us
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
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
J. Hansen, USC Center for Software Engineering):
- The requirements are knowable in advance of implementation.
- The requirements have no unresolved, high-risk implications.
- The nature of the requirements will not change very much.
- The requirements are compatible with all the key system stakeholders'
- The right architecture for implementing the requirements is
- 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
"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
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
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?