by Steven J. Owens (unless otherwise attributed)
Ah, project estimation, the source of the most noise and pain in the software industry.
A friend with a little wage-slave system administration and scripting experience is thinking about tackling a small consulting job, and asked for advice.
You can easily amass a metric ton of books on the topic, not to mention academic papers. The current hot topic is "agile development" methodologies, the most popular being "xp" or "extreme programming." Lots of people swear by it, some people swear at it. You can debate the merits of different approaches endlessly, but I strongly suggest that for your first project, you borrow a simple tactic from the agile world:
Each pass, do the same thing; figure out the simplest thing you can do that will help them out, do it, come back for more. At the end of the each week, have a fully functioning, usable application that will be one step closer to their ideal application.
Essentially, think of the entire project process as a dialog, a process of discovery that you facilitate with functioning software.
Normal people usually need a few trips through the wringer of software development to get a feel for how much assumption, ambiguity and judgement go into their own normal processes. This really is normal and is a big part of the reason for the classic management/engineering dichotomy. Odds are extremely high that:
Discuss this approach up front with them; they're probably new at this too, so start off by telling them the old 90/10 rule. The first 90% of the software takes up the first 90% of the time. The last 10% of the software takes up the second 90% of the time.
Also, there's a report out there that some big company did (google on "The Chaos Report" IRRC) that pretty much lays it out black and white: most software projects come in over budget, behind schedule, and don't really solve the problem.
Point out that you're focusing on:
Having said all this, they're still going to want to ask you questions about total cost. The big misconception here is usually on the technical side - we underestimate just how vastly ignorant they feel (and to some degree are) and what sort of precision they expect. They literally have no idea what the answer is. Your job is not to give them an answer and stand by it, but to rule out the "ridiculous" answer at either end of the spectrum, and maybe point out the major variables.
My favorite tactic for dealing with this in general is to get used to tossing off order-of-magnitude estimates, along with some vague confidence indicator. Whenever they ask any sort of question, think for about three seconds about what's involved in what they asked for, how well you know both the problem and the implementation, and say something like "hm, that'll take either days or possibly weeks, depending on whether they understand their database schema or we have to puzzle it out for ourselves."
Often this is exactly the kind of rough idea they wanted, and it doesn't commit you to a hard estimate.
For doing your own estimates for a full project, sit down and break it down into as fine detail as you can, and come up with your best guess for each detail - each requirement, the steps necessary to implement that requirement, and the time it'll take for each step. Add it all up. Then double the amount, because you underestimated, because everybody underestimates.
For your own good, you may want to write down each of these details and estimates on a 3x5 index card, then as you go through the project, try to record what actually happened on each card as you go. That way you can go back over everything when you're done and figure out what you can learn from the experience. But don't go overboard, you'll have enough to learn this time around (the XP crowd have a whole process based around index cards, called The Planning Game).
As far as doing your own actual pricing estimates, there are generally two options, either fixed price (they're buying the end result) or time & materials (they're buying your hours).
Ideally with fixed price, you estimate how long it should take a normal programmer to do it, multiply that by a normal market rate, then charge that or a little less. Then you get it done much faster and keep the savings. However, this only really works if you know exactly what needs to be done, and exactly how to do it. It goes out the window if there's any ambiguity about the requirements -- and there always is.
Ideally with time & materials, you start the meter, sit down with them, and start working, and keep working until they're done. But, first, nobody's going to do that because they don't have any idea of what the price will add up to, and second, anybody who's qualified to do that will just hire you as a contract employee (e.g. highly paid, highly skilled temp), not as a consultant.
What typically happens in either case is a game of tug-of-war between the consultant trying to reach closure and get paid, and the client trying to reach closure and get the application they need. Ideally it's a friendly, collaborative tug-of-war, but it can too easily turn vicious. For fixed price this usually involves attempting to impose some sort of formalisms on change processes, to control and limit them and keep them from upseting the apple cart. For time & materials in makes every change or feature request a mini tug-of-war over estimates and deadline commitments. This whole mess is why I suggested the approach above.
There's a ton more that can be said on these topics, and there are tons of book about them. Aside from books on software design and project planning, a decent book on the whole 'net consulting bit back in 1997 was The Geek's Guide To Internet Business Success. It's graphic-designer oriented, but I didn't find that intruded significantly on reading the book:
Janet Ruhl's The Computer Consultant's Guide was an excellent nuts&bolts-of-the-consulting-biz book. It was also published in 1997, but should be pretty timeless.
Most of the consulting & computer business books I looked at ended up being about writing your business plan, or marketing your business. Ruhl's book was basically a FAQ compiled from the CompuServe consulting forum. Things like "What the heck is 1099 vs. W-2" and "do I need business insurance" and "what kind of consulting jobs are out there" and stuff like that. Gives you an excellent grounding and orientation. I'm not really familiar with her other books.
There's also Ruhl's website:
http://computerconsultantbusiness.com