A man walks into a car dealership and says, "I want a car. How much will it cost?" The salesman says, "We have all kinds of makes and models. How much are you willing to spend?" The man says, "I dunno. How much do flying cars start at?"
All but the simplest software projects are flying cars. No one has invented one yet, so no one can reliably tell you how long it would take to make and definitely not how much it will cost, unless time and money aren't important. And, time and money are important to everyone.
I can define the problem, and I have a solution.
Every Software Project Is a Flying Car
I picked flying cars because, unlike a transporter, a flying car sounds possible. We know how to build cars already and we know how to make things fly already. How hard could it be?
Software projects are like that. We know what software is, and we know how to create software (sort of). The problem is that the nature of software is, if it already exists we use it. If the software doesn't exist, no matter how much it seems similar to software we have seen or heard about, it's a new invention. No one can reliably tell you how long it takes to invent something that never existed before. (If an entity meets a fixed date and price, they have built thousands just like it—as in home building—or there was some serious padding going on.)
Building software is not building cars, homes, or widgets. A chunk of software is a brand new invention. Worse, tools change frequently, methodologies come and go, and team compositions are as flaky as ever. This means that for all intents and purposes every piece of software is different and every dynamic in the equation is different almost every time.
The remedy to fixed price bids: Don't promise a fixed price for the whole shooting match if you are a software builder, and get another set of bids if you are the customer.
How Do I Build a Flying Car?
If you are a provider, you sell time and materials. Then, who cares how long it takes, you're making money. If you are a customer, insist on time and a fixed price because you know when the check writing stops. The problem with either of these alternatives is that either the vendor doesn't make any money or the customer doesn't get shiny features they forgot to ask for up front. However, if both sides are negotiating in good faith and both want to be satisfied, there is a better way.
The better way is to agree on fixed time and materials—a de facto fixed price—for both sides for every aspect of the project. Suppose you really want to build a flying car. Then, vendor and provider can agree on a specific amount of time and materials to define all of the requirements of the car, vertical takeoff, hovering, top speed, stop distance, color, sound system, and so forth. The vendor gets paid for every hour worked and the customer only pays for the duration agreed upon. This is easy, right?
To ensure that both vendor and customer have a real chance of flying high over traffic is that the agreement must include a decision point at the end of requirements: a) You have enough to go on or b) You need more time. If the answer is that there is enough to go on, proceed to the next phase; otherwise, both parties must agree on a fixed amount of time and materials to sustain a continuance. The problem is, of course, that the customer will get some information wrong, change their minds, or just omit something important. That's okay. Every one of these changes is a time and materials fixed requirements session.
By fixing time and materials—cost—the vendor makes money and the customer is motivated to compromise, focusing on things they are willing to and can afford to pay for.
Next, do some project planning, but before you start make sure you and the customer agree on the amount of time and materials and the level of detail and conditions for a) a continuance or b) proceeding. Again, the vendor makes a fair wage and the customer has a pre-established total cost. (Also, consider incentivizing vendors for finishing early.)
Before you proceed to design and construction, throw out everything that isn't very valuable and very useful. Now, proceed to design. Complete the process with construction, testing, and deployment.
You say, "Paul, this is a waterfall process you are describing." You're right, but here is the difference. You already know a single waterfall doesn't work. Nobody gets all the requirements, analysis, design, construction right the first time; otherwise, you would never have to test and debug code. So, in your process include a phased plan with a fixed price for every phase and plan to repeat the entire cycle as many times as it takes. In between cycles, include a decision point: a) Do you have the criteria met to proceed or should you have a continuance, or b) Do we pull the plug on the whole thing?
Finally, I can't say this enough: Throw out useless frills, focus on the hardest, most complicated and valuable things first, and (vendor and customer) spend your time on constructing those things. If you tackle the tackle high value high priority things up front—those things that make the system worth having—even after the first cycle you have the makings of a valuable system for the customer. Hence, the customer will won't to proceed and the vendor makes a tidy profit. If the customer isn't interested in permitting a fair profit, seek ye elsewhere, vendor.
What Could Possibly Go Wrong?
It all sounds very reasonable and rational, right?! You have very smart people building software, but even Microsoft is perpetually late—how do they make money? Well, Dr. Forsythe from Michigan State's Computer Science department said it best: "building software is the hardest thing that people do."
Software is purely brain stuff. The mind can imagine (and has imagined) almost anything. And, things are often simpler in your heads than they ever can be in the physical, tangible world. Plus, software engineers are very bright (sometimes cocky) and overestimate their own abilities. (So does everybody else, for that matter.) So, what can go wrong? Everything, and everything just about always does. The way you fix this is to offer continual training and on-going education, allow people to specialize and work on team formulations that are more static and not so fluid. The same 10 or 20 people doing the same thing project after project will get better at it.
Because you know things will go wrong, build in schedule tolerances. Perhaps vendor and customer splits overages 50-50. There are few projects where the customer's constipated inadequacies and at least as much at fault as left-brained over-imagineering.
I said I had a solution. I didn't say it would be easy. The truth is that customers goof and engineers goof, but everyone knows that vendors have to make a profit to keep being vendors and customers have to manage their money to continue consuming. The answer is that both sides have to negotiate in good faith and build in tolerances and decision points for all the things that you have learned can and will go awry.
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his upcoming book, LINQ Unleashed for C#, due in Spring 2008. You may contact him for technology questions at email@example.com.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet opened a users group branch in Flint, Michigan in August 2007. If you are interested in attending, check out the www.glugnet.org web site for updates.
Copyright © 2008 by Paul T. Kimmel. All Rights Reserved.