![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
What's Wrong with Fixed-Rate Bids?My working philosophy is that fixed-bid contracts are usually a bad deal for somebody. If I'm smart, I over-bid and they're a bad deal for the client. If I'm not smart, I underbid and they're a bad deal for me. No project is exactly the same as any other project. No two clients are alike. No project specification is ever truly complete at the outset. Those of us with enough professional experience to understand this will, of course, pad to bid to handle the unexpected.But is that "right"? Probably not. The client's initial description is usually fairly general; it's rarely fully thought out or broken down into steps. Is the user interface fully specified? What about a test plan? There will probably be room for incremental improvements, things you didn't think of, places where the general description needs to be filled out. Neither of us can really guess how long the project will take until we truly spec out the project requirements. In addition, many people ask for a flat-rate dollar bid but not a time bid. Let's say someone tells you they can do your project for $1000, then you find it takes them 3 months. Did you save money? Worse, let's say you're in a crunch; you only have a month but you don't want to spend a lot of money. If you make a mistake choosing the "lowest bidder" you may run out of time before you discover that the "low bidder" can't solve your problem. The better deal is for me to do good work (and get paid for it), and for my client to get good work (and know he isn't being taken to the cleaners). I do good work. Some people may charge less; some of them may also do good work. But often, you get what you pay for. What's your budget?I know people who ask "What's your budget for this thing?" and then decide if that sounds like a reasonable payment for the apparent work involved.
My preference when I work is to work in units, usually units of time. I tend to bill dollars per hour, with the rate negotiable within a given range, depending on my interest, the project itself, and the location. One form of negotiation is the "not to exceed" contract, as in "Not to exceed 40 hours". I work in terms of milestones and status reports. My client knows what I'm doing and where the project stands. I prefer the philosophy of "bring each feature to beta". This means that as the project progresses, pieces of it work earlier than others. This provides the client with a feeling of completion along the way and enables the milestones to work better. If things aren't being done at a rate that makes us both happy, we discuss that and solve any problems. Presuming that your basic project description is sufficient for me to believe I can handle the job, and that I would find it interesting (for me, a more important factor), we would next need to turn it into a real specification. Until that happens, a general description is not really sufficient for me to guess how long a project will take or to estimate a realistic bid.
SpecificationIf you decide to work with me, I would suggest the following steps:
I might propose $500 for the Discovery phase; if it takes me less than 10 hours, we might agree to roll some of the balance into phase 2. Once we have a more exact specification, we can more clearly determine how long each step should take (your desires vs. my estimates) and how much each step should reasonably cost, within your budgets (time and $). You know what you're paying forI provide frequent status reports and milestones. You provide feedback and testing. We both agree on any major revisions in the specification after it has been drawn up. I can offer you nearly 20 years of experience, attention to detail, a firm belief in quality and process, clean and maintainable code, clear documentation, and a professional attitude. If you think we could have a basis for discussion, please contact me. Telephone calls accepted by appointment; the best way to reach me is by email: vlb@cfcl.com.
| ||