How to estimate cost with very little information? [closed]

Question

I have a client who wants a web app that will let him do the following (as he told me word for word):

• User registration

• Recurring payments for users

• Online conference room reservation

I am supposed to give him a cost estimate very fast and I don't have any time to do any deeper requirements analysis! How would you deal with that kind of situation? Should I just give a very broad estimate and work out the exact requirements once he has accepted the estimate? At which point do you usually gather requirements, after or before getting a contract?

Answer 1

Here is what I usually do to limit problems:

Define the information yourself, by describing what you are going to do in details.

Bid on that, and only that.

Refer to that document in your official purchase order form you will ask your customer to sign.

As an altenative, I suggest you to sell your customer with iterations instead of fixed features, with the flexibility to stop or continue development at the end of each iteration.

If you don't know how to estimate your own document, try to do some collective estimation using planning poker. You can also split each functionnality into tasks and estimate each. Sum and multiplicate the result by two if you are pretty confident, or three if you are not sure.

If you not confortable with your estimations, it's a pretty good indication that you are not experienced enough to accept the job in a fixed price scheme.

Answer 2

Offer to do the analysis and design in 2 weeks for a fixed price (with obligations on their part to communicate and review in a timely manner); they can take the output from that and bid it to other vendors if they like, but giving them a number based on three bullet points will either be massive sticker shock to them, or serious underpayment for you.

Answer 3

Count individual web pages. For example, "user registration" probably means there's a "sign up" page - is there also an "edit my profile" page? A "look at someone else's profile" page? Can managers edit their people? Is there a "change password" page? A "forgot my password" page? Do they have to provide secret questions and answers, in which case are there also pages for that? Repeat all this for your other bullets. You come up with some number, like 7 or 27 or 93 or whatever, of web pages. (This list will form part of your proposal and show the client you've already started to design the project.)

If you have built web pages before using the tech you plan to use, you should have a rough feel for average effort per page. 1 hour, half a day, 1 day - it depends not only on your tech but on how much time you put into look and feel, validations, accessiblity - but you should know this number already. Multiply the two. Possibly add time to "design database and write procs" or "design report layouts" if it prints fancy stuff. Add a contingency of 10-25% depending on what you think the client will tolerate. Done.

If you haven't used the tech before to make web pages, decline this work. If for some reason you can't, then prepare to lose money because you will not be able to bill for your learning time and you won't be ready to make good estimates. As a desparation approach if you really feel you must take the job, offer to do a "feasibility study" in which you will design the project and estimate a fixed-bid price to implement your design. Either ask to be "on the clock" for the feasibility study, or offer a flat bid like 1 day or 1 week or 2 weeks.

Answer 4

There are some really great answers already. Here are a couple more remarks based on having made my living doing outsourced development like this for most of the last twenty years.

Without an adequate, written, agreed-upon specification, doing fixed price contracts is a fast way to lose tons of money.

My wife and I had a custom software development firm. Around 1998, we were approached to do a port. "We don't really have a spec or even a feature list, we just need a Mac program with the same features as our Windows version." So we looked over the Windows version, proposed a price, dickered a bit, and agreed on a price. And then it turned out that not only did the liars have a feature list, but there were a ton of hidden features we hadn't noticed during our review that were very hard and time-consuming to implement. Our employees' salaries alone to complete that project cost us three times our revenue for it.

My experience has been that people who don't provide a spec, and aren't willing to pay you to write one, are either amateurs or trying to get something for nothing, and both kinds of clients are big trouble.

Don't write a specification and give it to the client for free.

It's very tempting to do that so you can get agreement from the client and protect yourself - but I used to do that, and decided it's a mistake. One time I did that, I included information in the spec about which I had particular expertise. The prospective client switched to a cheaper development team; the info in the spec filled in the missing gaps in their knowledge - and the substantial work I'd put into the spec was in the toilet.

I now consider specifications and design documents to not only be work products, but highly specialized ones for which I charge a much higher hourly rate than I do for simple programming. That way, if the client wants to put them out for bids by cheap code monkeys on eLance, no hard feelings.

Actually, in the last eight years, I've solved the problem very simply: I no longer do fixed-price projects and have an hourly rate floor I won't go below.. Since making that switch, I'm far happier, make way more money, and the skeevy clients go somewhere else.

Answer 5

You can't. Tell the customer it is similar to building a bridge or a house, and require the same amount of preparation to give an accurate estimate.

Answer 6

Welcome to the real world.

I would advise your customer that you use a daily rate of £x per day to calculate your prices, and could produce something that met that specification in a few hours by reconfiguring Outlook - but that you are not confident that its what your customer is actually after. Suggest that you meet up and spend around an hour going through the details.

If your customer is not prepared to put the time in to actually define what their needs are when they are looking for an implementer, its only going to deteriorate as the project progresses.

Answer 7

You're saying the client refuses to give you enough time for deeper requirements analysis. That by itself is a red flag. Maybe they've already gotten an estimate from someone else and don't like it, and think if they can just trick you into accepting this for a lowball price, they'll be able to force you to deliver.

There's three ways I've seen to deal with this:

1. Do a gut estimate anyway, without deeper analysis
2. Automatically estimating it as 150 man days, and pointing the client to solution 3 if that shocks them.
3. Selling the client on an analysis project

I cannot recommend solution 1. The risk that you end up committed to an impossible estimate is too big.

Solution 2 is still risky. 150 man days is big enough that if they bite usually afterwards you can define a scope that fits inside that estimate. But, depending on what your client means by conference room reservation, this could still not be enough.

Specifically on that topic, how well do you know the problem space? Have you thought about all of the aspects involved?

• Will the system have to integrate with outlook?
• Will it have to support catering and equipment (e.g. beamers)?
• Will it have to support tracking participants, with reception desk integration?
• Will it have to support automatic billing of booked rooms and related catering? What sort of pricing models will it have to allow for?
• Will you have to track room keys, with check-out / check-in?
• Will everyone be able to book anything, or do you need room-level security?
• ...

I've just spent a year redesigning the front-end of a mature conference room reservation system, and the design specs ended up filling several hundred pages. Do not underestimate the complexity of a competitive conference room reservation system.

Of course, you can keep it simple. But if your client wants a system that's competitive with what's already out there, simple won't cut it. Unless this client agrees ahead of time on exactly what it is that you will build, it's pretty much guaranteed you'll end up in rough negotiation once the time comes to deliver and get paid.

Answer 8

Pick a random amount, double it, then tell the customer that number, plus or minus 200%. That should get the point across.

Answer 9

There are a couple of estimating systems out there, and they aren't particularly new.

Function Points
The idea of "function points" is basically all programs have the same 5 features: outputs, inquiries, inputs, internal files, and external interfaces. You have already used a "user registration" scheme, so you have a good idea how one of those looks. As for the "recurring payment system" this is going to be more complicated and you'll probably want to look into an existing API (many folks go with PayPal until paypal screws them, so have a "Plan B" in mind when you go that route).

There are a number of "for money" function point tools, but one free one is here.

COCOMO
COnstructive COst MOdel uses historical data for estimating, but I guess you lack historical data to figure out how much time and effort this project will entail.

Weasel words: COCOMO is not related to the city in Indiana named Kokomo. When the Beach Boys were doing commercials for Delco Electronics (a division of GM now spun off and called Delphi Electronics), they said they liked the name of the town so much they wanted to put it into a song.

These estimating methods need historical data, which most developers won't collect by themselves. One method to do so, for a sole practitioner would be PSP. While that won't help you to put out this particular fire, it will help with your future estimating. Part of the reason that estimating is so hard for people is that they don't keep track of their estimations (thus can't tell where they went wrong, or need to adjust in future projects). And another significant part of why estimating is so hard is that folks have been badly burned by mismanagers playing political games with the developers. Off the cuff estimations are always horribly wrong with the sole exceptions of "we did that one before and it took exactly X to complete."

Answer 10

Chances are that your client has seen a similar app at a competitor's website, so ask him to point you to that website (if I'm right); then examine said webapp and estimate the time to build something similar.

Answer 11

1. Get up on Google, find a similar application (I've no idea about web development, so can't give you any more practical advice than this), a company or a private developer which makes those, and ask them for a quotation. Preferably, ask two.
2. Based on your experience, see how it fits into your plan of development, and think whether you can do it for less (usually lone developers (assuming) have less costs in some areas than companies devoted to those kind of development.)
3. Give him an approximation, strongly emphasizing that the exact price will depend on his requirements (of the client, that is).