Software Venture Consulting

FileMaker Pro downloads & Resources
FileMaker Custom Functions
FileMaker Web Viewer Examples
FileMaker Pro & Lasso Consulting
Training
FileMaker Books
FileMaker Articles
FileMaker Error Reference

Free Web Tools
Free FileMaker Tools

Personal Pages
Videos
Adventures
Links

Shopping Cart
Shopping Cart

Search:

Free Newsletter
Signup


Contact


Privacy Policy



FileMaker is a registered trademark of FileMaker, Inc. in the U.S. and other countries.


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?

Browse Mode
Jan 10 Solving Performance Emergencies with FileMaker Server
Aug 06 Top Ten Sessions Cut from the 2006 FileMaker Developer Conference
Jul 06 Who's Driving This Thing, Anyway? Or, How Marketing and Engineering Buried the Hatchet (Warning: Contains a Curse Word)
Nov 05 Shingle Grandiloquence
Oct 05 In Celebration of Geek Magnetism
Aug 05 A Rogues' Gallery of Devcon Attendees
Mar 05 Lies, Damned Lies, and Project Specifications
Feb 05 Pick the Right Tool for the Job
Oct 04 Home Media Server Requirements
Jul 04 Leveraging Your FileMaker Lingo
Apr 04 Technical Support Redux
Mar 04 Enforce Seats in FileMaker 7/8/9 Commercial Solutions
Feb 04 Reinventing the Wheel
Oct 03 WAP: The Technology That Wasn't
Aug 03 Brian Dunning's California Governor Election Platform
Jul 03 Sex and the Single Software Developer
May 03 XSLT: Creeping Out of the Closet?
Feb 03 A Consultant's Guide to Traveling
Nov 02 Adventures of Bat Magnum, FileMaker Consultant
Sep 02 FileMaker at Area 51
Aug 02 FileMaker Terminology
Feb 02 Computer Shunts
Dec 01 Aquabase Alpha & the Consultant's Challenge
Aug 01 It IS the Size That Counts
Jun 01 On the Trail of Sasquatch
May 01 Spring Cleaning
Feb 01 FileMaker Mobile Survivor Challenge
Jan 01 Letter from Nürburg
Dec 00 Performance Anxiety
Nov 00 Objection, Your Honor
Oct 00 Leveraging Convergence: Jargon for the 21st Century
Sep 00 Top Ten Things to Do at Devcon
Aug 00 Aesop's FileMaker Fables
Jul 00 Ten Commandments of FileMaker Pro
Jun 00 Explats Cross Examined
May 00 iMac, Therefore iServe
Mar 00 Valley of the Dollars
Jan 00 Are You Up for a Review?
Nov 99 Tales from the Script
Sep 99 Tech Support Revisited
Jul 99 Moderns vs. Classicals
Mar 99 Nashoba, We Hardly Knew Ye