From a slashdot thread: Re:bid evaluation (Score:5, Insightful) by BrianH on Tuesday August 27, @12:27PM (#4149265) (User #13460 Info) I'm not sure that this is particularly true. I've sat on a half dozen bid evaluations in the past, and I recently chaired the bid committee for a government website and had this same discussion with a couple disgruntled bidders. Our project was for an educational website with about 10 processes and 45 screens. we received 17 bids on the project, with prices ranging from $8,000 to $325,000. The bid we selected was somewhat in the middle at $74,000. When some of the lower bidders called asking why they'd been overlooked, I had to explain a few points: Price is often the last thing bid evaluators look at. While it is true that stupidly high and stupidly low bids get tossed without evaluation, price usually doesn't have any effect early in the evaluation process. Company size really does matter. The point of view is that the more developers work on the project, the more likely it is to be completed and delivered on-time. In the project I recently awarded, we had two proposals that were even in every way, except that the $55,000 proposal had four developers (one graphic designer, a DBA, and two programmers), and the $74,000 proposal had seven developers (one graphic designer, a DBA, and five programmers). Guess which one we chose? Company history is VERY important. Gaming and personal sites don't count, and neither do projects you completed while employed for someone else. If you are approaching me as XYZ Web Inc., then I want to see an impressive portfolio of websites that were actually built by XYZ Web Inc. I personally don't care if you've worked at Yahoo, Amazon, or Ebay, because I'm not hiring them to do the job. I'm hiring your company, so I need to see your companies credentials. It's amazing that such a simple concept can be so consistently forgotten by bidders. You need specialists, or you need to go out of your way to show that your general developers have specific training in multiple fields. If I put out a bid for a website that requires graphics work and a database, then you had BETTER show me that there will be a professional graphic designer and a DBA working on the project, in addition to the web developers. If that's not possible, I need to know the certifications and training that your general developers have had in those fields. "Self Taught" earns your bid a short trip to my circular file. Did you submit a proposal, or just a price? You cannot write a good bid that is less than 20 pages long...period. We need your company portfolio, your developer histories, the list of the technologies you plan to use, timelines as well as a quick development plan and at least one use-case scenario to prove that you really understand what the project is all about. I've seen far too many bids that basically said "We're XYZ Web Inc., and we can build your website for $5,000". Maybe you can, maybe you can't, but either way you have to give me enough information to base my decision on. Never ever argue technology with the client. Our datacenter is pretty standardized: We run IPlanet on the webservers, Oracle on the databases, and Solaris as the OS for everything. When we put things out for bid, we make it clear that our websites/software must run on this platform, and that our web sites MUST be written in JSP. Given that, I've never understood why so many bidders see fit to argue the point; "PERL is better!", "Linux is cheaper", "Apache is more stable", "IIS is the web standard", and other pitches may or may not be true, but I really don't care. If my RFP says that you must use technologies A, B, & C, then that bid had better use those technologies. Anything else gets you dumped. What about goodies? Maintentance? Most good bids (read:expensive) include statements that the developer will train internal staff to maintain the webpages, construct the site so that a secretary or merketing lackey can edit it, or otherwise pile on peripheral site features that aren't neccesarily included in the bid request. Showing the client that you're willing to go above and beyond what they asked for is a good way to get their attention. See any room for improvement? Suggest it! The bidders who won the last eval I chaired partially did so because they improved our own requirements. When the developers saw our RFP and saw the requirments and features, they realized a better way to solve one of our problems and suggested it. We were so impressed with the improved suggestion that they got the project. Be professional. Bids will often have bidder meetings where some of the top proposers get called in to answer questions or clarify their proposals. If you get called to one of these, you need to remember this: These are not your friends, or your bosses, or your co-workers, they are your potential clients and you need to treat them as such. This means no bluejeans and t-shirts with Google logos on them. Put on some slacks and a tie (and a coat if it's a large or formal institution), and toss that big pile of papers in a briefcase. If you can't present yourself properly, how can we expect you to rpesent us properly? Price gets weighed in AFTER all of these factors are considered. If we evaluate our bids and find that two companies offer equally outstanding proposals, make equally compelling sales pitches, and have equal backgrounds and development staff, then we might weigh price in as the deciding factor. But that's actually a pretty rare situation :\ [ Reply to This | Parent ] Re:bid evaluation by BrianH (Score:5) Moderation Totals: Insightful=2, Informative=1, Total=3. Re:bid evaluation (Score:2) by ebyrob on Tuesday August 27, @01:38PM (#4149988) (User #165903 Info | http://slashdot.org/) In the project I recently awarded, we had two proposals that were even in every way, except that the $55,000 proposal had four developers (one graphic designer, a DBA, and two programmers) Why do I get the feeling you would have gotten a much better website if you'd awarded the 4 developer bid instead? Of course, I haven't seen portfolios or paperwork. It's just a gut reaction. 4 developers (1 DBA,1 Graphic Artist, 2 coders) sounds like a good size for such a project. 7 developers, by contrast, seems like over kill for a project that doesn't have clearly defined sub-sections... [ Reply to This | Parent ] Re:bid evaluation by BrianH (Score:2) Tuesday August 27, @02:16PM Re:bid evaluation by Neverrtfm (Score:1) Tuesday August 27, @03:32PM 1 reply beneath your current threshold. Re:bid evaluation (Score:1) by yusing on Tuesday August 27, @02:02PM (#4150266) (User #216625 Info) Wow, what an insanely great explanation of bidding. I may not agree with some of the reasoning, but after Brian's explanation I finally understand bidding for the first time. I do have a problem with the idea that some lower bidders are losing jobs JUST because there isn't time to evaluate more closely. If a bid runs 40 percent higher than another in a price range where that involves significant dollars (74K v 55K) that "saved time" is costing a lot of money. In many cases TWO crackerjack programmers may be way more productive than FIVE run-of-the-mill programmers. Not only might they meet the deadline, but the code will be better and easier to maintain. The potential savings in such a case ($20K), it seems to me, warrants closer evaluation. Brian? How'd you *know* it was worth the extra $20K? [ Reply to This | Parent ] Re:bid evaluation by BrianH (Score:2) Tuesday August 27, @02:42PM too many cooks spoil the broth. by oliverthered (Score:2) Tuesday August 27, @03:29PM Re:too many cooks spoil the broth. by Webmoth (Score:2) Tuesday August 27, @03:56PM You need to learn basic software engineering (Score:1, Insightful) by Anonymous Coward on Tuesday August 27, @02:35PM (#4150564) Several of your items sound reasonable, but are actually foolish. For instance number 2 on your list is that the more developers that you have working on a project, the more likely it is to be completed and delivered on time. In fact software engineering literature from The Mythical Man-Month on comes to exactly the opposite conclusion. Adding bodies to software development creates basic infrastructure problems that make the project more difficult to accomplish, let alone to accomplish in a timely manner. Real world project data supports that. Most large projects fail. Larger projects fail worse, more often. At one point Sun had an internal rule that no project would be accepted that was supposed to take more than 6 months or cost over $1,000,000. The odds of failure were just too high. Now of course a given project has minimum realistic needs in terms of how many skills are required, and how much work will be needed. There is a minimum team size for a given project. But for the optimal productivity and probability of successful completion, you really want a team that is close to that minimum. And that gets us into your technology decisions. Agreed that when you are trying to bid on a contract for a client, you do what the client wants. If the client wants a series of unproductive technologies, you have to increase your development costs because of your projected unproductivity, but that isn't the time to sell them on the benefits of their letting you work more productively. However at this moment we are not dealing with an RFP. So I am going to point out to you that if there are real software engineering reasons to want development teams that are as small as feasible, then there is good reason to want a development environment that makes developers more productive and therefore reduces the minimum size of development team that you need for your projects. I won't say which tools and what environment that is because the answer depends on a lot of hard to evaluate factors (though I admit to thinking that your choices "leave room for improvement"), but I can point to Beating The Averages [paulgraham.com] for a sample essay showing how much of a difference it can make. And I cannot emphasize enough that it is a very powerful experience for a developer when they see first hand what kind of difference it makes for them to be in a productive environment. That said, there is a good business case for not experimenting with your development environment. It is one that puzzles most techies, so it is worth explaining. If you start making changes in areas that your company does not personally have a lot of experience in, then some of your decisions will be good and some will be bad. The problem is that the bad ones will cost you far more than the good ones win you - you are essentially gambling on your ability to pick correctly in an area that you know nothing about. Therefore outside of areas of strong company expertise there is a lot of pressure to try to make similar decisions to your competitor. Those are no more likely to be good or bad than trying to make your own choices would be, but they have the decided advantage that you won't accidentally choose badly where your opponent chose well, in an area that turns out to be the deciding factor. Incidentally this is a principle that explains the advice offered by Paul Graham in Revenge of the Nerds [paulgraham.com]. In that special case Paul is talking about how a nerd should take advantage of their area of expertise. And the answer is to pick a line of business to which your special knowledge applies, go into that business, and let your correct decisions tell. But when you do that, do not simultaneously attempt to rethink every other area of business that you must deal with, because you will get a lot of that wrong! [ Reply to This | Parent ] Re:You need to learn basic software engineering by BrianH (Score:3) Tuesday August 27, @03:37PM Why you shouldn't be hot to tinker by Gumber (Score:2) Tuesday August 27, @04:03PM Self taught (Score:2) by sterno (sterno at bigbrother dot net) on Tuesday August 27, @03:32PM (#4151034) (User #16320 Info | http://www.bigbrother.net/sterno/) "Self Taught" earns your bid a short trip to my circular file. Eliminating the "self taught" out of hand seems like a bit of throwing the baby out with the bath water. I've seen many a person who had a number of certifications and couldn't program their way out of a paper bag. Certificiations, depending on the type, can be almost completely meaningless. Personally the only certificiation I have is as a Java programmer and I will tell you right now that all this means is I read the book. If you want a good measure of skill, get a sample of some of the developers and what their real-world experience is. Most of the good developers I know have few if any certifications. [ Reply to This | Parent ] Re:bid evaluation (Score:1) by carbon_guy on Tuesday August 27, @04:02PM (#4151425) (User #604375 Info) BrianH's was the best post I have read so far. Before I can offer any advice, I need to know more about your situation. Are you a one-man team trying eagerly to get your first contract, or are you working for a larger company with dozens of websites under their belt. I have personally done websites as an individual where I knew the client well enough to get the job with little or no interview process. I have also been part of a company bidding 6 and 7 digits contracts. There are MAJOR differences between the two situations. BrianH was right on track for the later situation, but let me add to his wisdom. Here's the typical story... Company A invites several companies to bid for a contract. They send a RFP (request for proposal) to the various bidders. Those bidders explain how they will get the job done, and WHY company A should choose them. They list key personel assigned to the project, and similar projects they have done. My company includes screenshots from our previous work, and letters of recommendation from previous clients. We give a brief paragraph or two about each person assigned to the project. We also get paid a small fee (compared to contract price) just to submit a proposal. It's not uncommon with larger contracts, considering the work (research) that goes into the project. However, I believe your situation is different. You are probably an individual, competing with small companies. So here are a few pointers to help you get started. 1. Spend some time doing research on what other people are charging, it is not uncommon (at the low end of contract sizes) to get turned down because a bid is too low. 2. You are most likely to get turned down because you did not impress your client. Take some time to put together a proposal that impresses people. Be sure to understand your client. If they are not tech-savy, don't overload them with tech-jargon. 3. Make your company look bigger. Clients love the idea of a small army of talented people working on their project. After all that's why they are hiring someone else, rather than doing it themselves. If neccessary, ask friends to join you when ever you meet the client. One person alone gives a bad impression of either not caring, or being understaffed. 4. Consider a worst case scenario and possible problems when bidding. Does that website need to look absolutely perfect on all browser, all platforms, all vesion of each OS ? 5. (stolen from BrianH) Make suggestions. Show you understand the request, and understand what needs to get done. It's hard to build a reputation. It will be tough in the beginning, but learn as much as you can about how other people are going about it. The most important thing you can do when you start out is to make your company stand out. In you proposal, make suggestions (suggest, not tell), talk about follow-on work, but don't get too techincal or complex. No one with a MBA wants to read why you have chosen Apache, PERL, mySQL, PHP or whatever. Just explain how it is going to work to the user, how easy it will be to use, not how your going to write some code. The only part I have been uncertain about is how to handle clients who can't explain what they want in any detail. When a client asks for a website with "forums", but doesn't explain how they want them to work, you can't submit a proposal asking them to clarify, and determing a fair bid is nothing more than guesswork.