Slashdot Mirror
Why are Businesses Willing to Spend More for Software?
"I recently had a the chance to bid on a contract, which I didn't win because of my estimated project cost. The winner of the bid had an estimated cost of $15,000 whereas my estimated cost was around $5,000 for the same project. The contract was not a complex project: a system comprised of database-generated web pages, with file submission and minor document management features.
I had, in about 8 hours of preliminary work, 50% of the website and associated back-end completed and had the rest of the site roughed out for what they wanted. The work is simple and I think almost anyone who has done similar types of site designs would agree with me.
The reason I got for not winning the project was that my proposed bid was seen as too low.
Does this make any kind of sense to anyone? Why would a company prefer to spend $15,000 on a project instead of $5,000."
It's not that higher prices imply quality, it's that lower prices imply shoddiness.
slashdot!=valid HTML
..and especially this time of the [fiscal] year, people are sometimes looking to spend more money so they use up their whole budget (otherwise they get less money next year).
what do you think the Chiefs talk about when they golf with and have lunch with their friends that are Chiefs at other companies? They one-up each other with how much they spend. A company that can afford to spend more is seen as more powerful. It's the same old pissing contest, just in a different venue.
Businesses assume that the low bidder will do shoddy work, and you get what you pay for. In tangible things like building contractors, the rule of thumb proves true. Cost cutting usually is quality cutting.
The Uncoveror: It's the real news.
Business people don't think in terms of how "hard or easy" a particular project is. It's about gaging what a potential client percieves as the value of that service. I was told by friends who have been running their own business for 20 years you have to give a high bid, but let the client know the price has room for adjustment. If you're quote is much higher, 90% of the time they will contact you to ask "why is your bid so high?". Whereas a substantially lower bid gets tossed out.
So the lesson I learned after having made the mistake is to bid high and then adjust the price later. In the end, it says two things about the service you provide:
1. your time is valuable
2. you take your profession seriously
Having a lower bid most often is precieved as "amatuer".
This question reminds me of the story about 'K Swiss' shoes in Hong Kong.
In the early 90's K Swiss was doing badly in Hong Kong and the sport shoes were pulled from the market. They did some research and relaunched as a premium brand at three times the price - with the same product.... they sold like you would not believe... they sold many times the previous number of shoes.
It is a problem. If something is too cheap - it is under-valued.... if it is priced high then its perceived value is increased. There are implications for Open Source projects here. If the product is free, is its value nothing as well?
In the eyes of a business (or its PHB, at least), cost is seen as directly proportional to the quality of a product.
This isn't just true in terms of software, but extends to all industries and products. Take a regular cup of coffee as an example:
You walk into a shop and pay $3.00 for a cup of coffee. You'd expect it to be a pretty decent cup of coffee, right? What if you bought a cup of coffee for $1.00? Would you expect it to be more or less good than the $3.00 cup of coffee? The majority of people would expect the $3.00 cup of coffee to be nicer than the $1.00 cup of coffee, but until they taste them both, they don't know.
If a business asks for quotes for a project, and someone is outbidding you 3:1, then they are likely to perceive your project as being underdeveloped, whether or not this is true. :-(
If a project needs to be completed within a certain timescale, it stands to reason that the company will pay over the odds, rather than going with the cheaper option and running the risk of having to pay for someone to take over a project if it goes tits-up, along with the added time that situation implies.
I've stopped (mostly) thinking about how much it will cost me to do something, and instead think of what it's worth to the company, and charge THAT rate. I don't do it to companies that I've done a lot of business with, because they already know they will get good work for a fair price.
If I feel really guilty about what I charge, I give them back enough so that I don't feel too guilty, and tell them it's a discount because of unexpected savings doing the work.
It's a fine balance to chage enough so that they know the work will be there, vs. estimating so much that I lose out. Sometimes I want to send two estimates: One for how much I think I need to make, another for how much I think it will take to be considered a player.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
You: I'd like to buy that car.
Cardealer: Ok, excellent choice, that'll be 50 dollar.
You: What? Why is it so cheap? What's wrong with it?
Cardealer: Nothing, it's perfectly ok. Nothing wrong with it. First owner, has had regular checkups, handles like a dream, 50 bucks.
You: Erm thanks, I'll go somewhere else.
Be wary of any facts that confirm your opinion.
Suppose your a manager of some sort.
If you choose the lowest bidder and it doesn't work out, it's your fault.
If you choose the highest bidder and it doesn't work out, it's the contractor's fault.
And remember, it's not your money that your spending. It's budget money. And where do you, Mr. Manager, want to be at the end of the budget year?
Slightly over budget with good results. That way you get a bigger budget next year.
What's a sig?
Yes, you are cheaper, faster, and do the same job...but maybe your solution wasn't really "right".
Perhaps you *needed* to install Win2000, SQL server, and IIS--your technology was "wrong." Or perhaps you needed to have an office address, an answering service, or a listing in the Business Journal--your business status was "wrong". Or perhaps you aren't related to the company president's golf buddy--your social status was "wrong". In any of those situations, you wouldn't be given the job if you paid THEM for the privilege of doing it.
Of course, there might be the notion of perceived value at work here as well. Because you came in SO cheap, you obviously can't bring the same "level of expertise" as the "big guys". Maybe your system would "work"...but it obviously won't be a "quality solution." Maybe they're looking for someone that they can (and this is my favorite term) "partner with"
(Reminds me of the story of the street artist who was selling "bare" watercolors for $10, and starving with only 5-10 sales per week. Some kind person set him up with a small stipend to purchase frames. The story goes that he then began selling 20-50 framed prints per for $50-$100. Same art, cheap-o frames, and 10x the perceived value and appeal.)
Or, perhaps the people involved aren't spending *their own* money, and they're trying to build a little buffer against blame. If a company charging $15,000 for a $5,000 job fails, then obviously the contractor failed to deliver. If an individual charging $5,000 fails to deliver, then obviously the people that chose that individual over a higher-priced but "more capable" company are lacking in business sense.
At any rate, it doesn't matter. You're out of the running, and chances are, due to those "unstated requirements", you never would have been granted the contract. Suck it up, try again, and work on building your reputation as someone worth "partnering with". Then perhaps you'll be on the *right* side of the equation.
At my company [part of a global publishing company] bids are also evaluated against known metrics. They do a function point count, figure the number of hours and then budget accordingly based on staffing and timeline. They have thousands of projects cataloged and they can (based on each developers metrics) come fairly close to what we are telling them. Your bid was probably way too low compared to the # of hours that the project was expected to take. They don't want to give the project to you and have you unable to complete it becaue you bid to low. I don't care who you are the first %80 takes %20 of the time to do the last %20.
If that didn't kill your bid, mabye your elitist attitude did.
Don't get me wrong, I've seen buisness spend more money on internal development than I had ever expected, but they won't pay for simple computer upgrades for the developers..... weird.
They care about how much it will do for them. If an app is going to make a company a million dollars a year, why not pay someone really good $10,000 even if you think you could do it in 16 hours?
Maybe it is easy, but so what? It makes absolutely no difference how easy it is to the overall value they get.
The only thing you'd need to look out for is idiot MCSEs with over-inflated egos, but beyond that, it's probably better to go with someone with more experience, a better presentation, whatever if you've got the money.
autopr0n is like, down and stuff.
To most business people, talking with a developer is like talking with a doctor. They don't understand the other person's black art, and they have no way to judge the person's competence, other than their standing in their professional community. And most business people treat the health of their business at least as seriously as they treat their own personal health.
So... Faced with life-saving surgery, assuming that you have the resources, would you choose the doctor who charges $5,000 or the one who charges $15,000?
To paraphrase George Carlin (?)... Somewhere out there is the world's worst doctor. And somebody has an appointment with him first thing tomorrow morning.
It's not at all uncommon for contractors to provide clients with unrealistic estimates for schedule and cost, either because they're inexperienced at estimating software development project schedules, or, worse, because they know they can provide an unrealistically low bid to win the contract and make up the difference (and some!) with time and material charges when the project inevitably takes longer to deliver than they estimated. Either way, the client is going to avoid options they percieve as risky.
Unfortunately, the poster has a few things working against him in competing for this contract. There are many honest but inexperienced software professionals working today. Also, there are a lot of real creeps out there selling professional services by bidding low and then bleeding the clients dry once they've commited to a project.
The client's gut reaction to the pricing is surely based on its prior experience with software development contractors that have successfully delivered for them (or on what their own team could have done before they laid them all off). It's quite possible that the poster is much more capable than those contractors. Still, convincing the client that his bid is not naively optimistic or an intentional low-ball will be very tough.
I think part of this is the difference between the way geeks view software vs. clients. When a geek gets software with source, he has the finished product, and if it works OK and is reasonably well written, he is satisfied. The non-geek is going to need somebody around who can take care of problems and enhancements, ideally the author.
So, non-geeks like to procure software from people they know are going to be around later. A geek doesn't give a rats ass if you fell off the end of the Earth tommorow, so long as he has source. A non-geek wants to know that you have a sustainable business. It looks like you lost because your lack of business savvy showed too obviously.
Probably the number one problem I've seen is that geeks often don't do a good job of including cost of sales and overhead in their estimates. Look at it this way. Suppose you wanted to tkae home about 60K$ per year out of your business. Suppose you run this out of your home, so your overhead is very low (good for you). Your only expense is say $50 a month for internet connectivity. Suppose your computers, consumables, wear and tear on your car and everything amount to $1500 per year. You need to gross $62100. But, you want to take vacations; say two weeks a year, plus miscellaneous sick time and what not. Figure that you must make $62,100 over 48 weeks, which amounts to very roughly $1300 per week. Furthermore, you can only count on having work for three out of five days, so you need to bill 433 per day. I look at the project and running it through the handwaving machine it looks like about ten days of work, or 4330, so I round it up to an even 5000 or 11 1/2 days. Piece of cake, right?
Except it's taken you a week of meeting with the client, writing, revising, and meeting with the client again. So, while you've estimated for 10 days, quoted for 11 1/2 days, you actually use fifteen days on the project; 1/3 of the time has been spent on sales costs. You have a target of being paid 433 for each day of work, thought you was going to be paid 500 for each day of work, and ended up being paid 333 per day of work, counting the effort to sell. If you bid all your projects this way, you are going to be making less than $46K, rather than the target of $60K. Plus you have all the hassles of having your own business. If you were making less than $46K somebody comes along and offers you $50K to be a clock punching 9-5 employee, just to code with no responsibility for sales or accounting or that other stuff, what would you do?
And, in fact, this assumes you win all your bids like this. The fact is, you have to pay yourself whether you win or lose. If you win half your bids, then you have to essentially double your estimate for how much to include to cover your proposal writing time in every estimate.
Of course the customers don't necessarily go through this, but they can sense when somebody is not making realistic bids. The smaller the project, the higher a fraction cost of sales will be of the total labor costs. This means there are project sizes below which it makes no financial sense to bid, unless you can simply dash off a boilerplate proposal. If you spent more than two or three hours and came up with a bid of $5000, then any sensible businessman realizes you are not going to be paying yourself much. The only people who hire you would be people who are financially unsophisticated or don't care if you decide to close up shop and get a regular job.
The more overhead you have, the higher the minimum practical project becomes. I work with a geek who simply finds it impossible to spend less than three days on any proposal. This means that for him he cannot efficiently bid on a project smaller than $15,000 (we have an office, leased line internet, office manager, accountants, phone lines etc.)
One way to handle this is to try to find ways of making the $5000 project into a $15000 project. You can simply pad the project with $10,000 of fluff, but this goes against most geeks' sensibilities. One thing we do is to offer our clients a "General Services Agreement." We say right up front that it isn't worth our while to bid on a $5000 project, but over the course of the year we know that there will be numerous small jobs that will add up. So, we will bill up to $5000 for the immediate job, and include $10000 of unspecified work to be done in the future. This allows us over the next year to do a day of work here and there, or even the occasional hour, without going through the rigamarole of bidding and contracting. The client just picks up the phone and tells us what needs to be done and we do it, unless it is going to take over a thousand dollars in which case we give him a written estimate. If it turns out that they don't want this service, they only pay $5000 (and we lose out big time). But once they have the contract in hand, and find out they can call us out on a one or two our job, then they always do use it.
This kind of agreement helps because the client knows that (1) we are planning to stick around and (2) they will not only be taken care of, they can get common day to day hassles taken care of quickly without fuss.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
As a software/web/database developer working for a small company, I've done tons of random projects ranging from under 1k up to where I personally billed 6 figures. One interesting tidbit I've noticed is that in some places, due to 'company policy', for any project over a certain dollar amount (for instance, with a county gov't agency, it was 5,000), they were required to go to bid. Our bids typically are higher then some, but lower then others, but of course, all this was a mere formality. We were getting the contract because we'd done work for them in the past, done service and support for free over a period of years, and they felt comfortable with our work.
By the same token, we'd also had to work with other development teams that were completely inept. However, the upper management of the client was practically 'in bed' with the other consulting company, so they billed out close to 400,000 even though I did a majority of the work, and the other developers were learning as they went along (or asking me to explain how to do things!).
Having seen both sides of the spectrum on this, a person has to always keep in mind that business politics can take precedence at the end of the day, regardless of dollar figures.
-- If you can't laugh at yourself, someone else will do it for you.
$200 per hour consultants -- guys on standards committees driving Excursions whose weblogs are actually _READ_ -- are perceived as writing better code than us $20 per hour pissants.
.4 better in the quarter mile, and costs thousands less. But the Audi is perceived by most car buffs, myself included, as the better car. Why? There's less plastic on the inside. The leather is nicer. The engine is quieter while idling and louder at full boost. The doors shut with a delightful muted crunch, rather than the slam effect of the Subaru. And the controls are much more intuitive...
End result? Well, both applications look the same and feature set, but the latter should have fewer bugs, be more reliable, and a cleaner interface. The two are nowhere near the same end product.
Think of the this like a car sale. The Audi S4 quattro is an all wheel drive car burning 240 hp. The Subaru WRX is a lighter all wheel drive car burning 227 hp, gets about
I run into the same thing all the time where I work. I'm the $20 jr, working with some "past their prime" fellas. When I do something, there's a good chance it'll be fast and great, and an equal chance it'll be buggy and not work. I jump for the brass ring and have been known to bit off more than I can chew. My expensive peers always aim low, take their time, overestimate, take lunch rather than caffeine it: and the result is, their stuff passes QA while mine languishes.
Not all the high bidding is "perception of value." Some of it is insurance of value.
Hey freaks: now you're ju
so 5k is around 5 days work at our rates you have to design the site get Signoff develop the site - then re-doing it when the customer says oh but i want it to work like that(usualy in bizare and stupid ways)
you have to cover the cost of moving from your development enbironment to the eval box and then on the the live.
You do have separte dev/eval/live dont you.
Oh and I forget testing/acessability
One day, I was speaking candidly with my boss about the possibilities of using Red Hat for various server tasks. He never took linux seriously, but had been hearing more and more rumors in recent times, that its "getting big".
In our discussion, he still wasn't listening with a serious attitude... until he asked if we could buy it... and when I said "yes", then the lightbulb went off in his simple little mind. He repeated with, "You mean, they have pricing and licenses?" I replied "YES", just to make him happy... and with that freshly learned knowledge, he now takes Red Hat seriously.
Skiers and Riders -- http://www.snowjournal.com
It is frequently true that the company that they want to win the bid is choosen before the bidding process begins. This can be based on many reasons, some quite good, others less laudable. Often it's because this is someone that they've worked with before, and who already knows what they want on the project. Frequently the only reason that there is a bidding process is that administrative proceedures require it, and sole-source justification is made unreasonably difficult. (Multiple layers of management can cause this effect.)
... I have noticed that when buying off the shelf products managers tend to prefer to pay more. I think that to some extent they get a feeling of status from deciding to buy a big ticket item, and something inexpensive just can't give them that. Apache recently had a hard time standing up to IIS for just that reason at a place that I won't specify. It won because the staff just went ahead and installed it before IIS was ever ordered, but until after it was up and running, it wasn't believed in by management.
Still, I'm a bit surprised... I thought that usually in such a case the bid specs were so crafted that only one company could properly fill it. That's the usual technique. OTOH, it's amazing just how many bids are non-responsive. It's as if they didn't read the specifications. (But I can't see why they would hide it from you if they found your bid non-responsive. That's one of the really valid reasons.)
Perhaps what happened was that because they knew who they wanted to win the bid, they were careless with the bid specifications. In that case they could hardly admit the real reason, but they would still have a valid reason to prefer the person who would do what they wanted, rather than what they asked for.
That said
I think we've pushed this "anyone can grow up to be president" thing too far.
cowardly,
-craiger
My finance professor gave us a great quote (I have no idea who said it first):
"Borrow a dollar and the bank owns you. Borrow a million dollars and you own the bank."
Paying a consultant more gives the company more leverage with that company. Anyone can walk away from a $10,000 per year contract since you probably have other contracts, but it is a whole hell of a lot tougher to walk away from a $100,000 per year contract. The company can threaten you with cancelling the contract to get you to do things not in the original deal. I've personally had that happen. I've also worked for a company that finished a project before the contract was signed. The client never knew it was done because we had to get them to pay for it first. It was 80% paid before the contract negotiations were even finished.
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)
- 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 situationThere is nothing so pathetic as seeing a beautiful young theory roughed up by a tough gang of facts.
"Why are people willing to pay $10 for a burger at some fancy restaurant when you can get one from a roach coach for $1.25?"
Looking at it that way, the reasons seem pretty obvious:
- Quality
- Service
- Atmosphere
- Accountability (you know where they'll be if something bad happens)
Cheers
-b
As a consultant working for a software/ hardware consulting firm I handle this kind of question a lot. The problem is it usually has nothing to do with price.
As a firm we regularly advise against hiring individuals or small firms for software projects. Why? They tend to disappear. With a larger firm along with a higher price you usually get: more support and stability. We had a case not to long ago where we advised a client to take a higher bid on a web project than the lowest bidder- and they chose otherwise. They chose a lone developer in North Carolina to develop the system, he got a job offer that was "really good" but promised to keep working. Three months later nothing new had happened and he tells us he is sorry but he is busy with "work"! (To which the client responded "Well what the hell do you consider our project and payments!). Two weeks later we get a single burned CD with some source code and a note saying he had to move, so sorry, thanks for the opportunity. We did get some money back but now we do not know where he is even located! Now we are scrambling to find a group that can finish the project on time and with out too much of a higher cost- more than likely we will have to start over.
Are all individual developers/ programmers like this? No, not at all but the process of finding this out is often difficult and painful. So... most companies go with larger firms that have more stability and offerings. With that comes overhead for the bidder and thus a higher cost. So, often the higher cost bid is chosen not because the other bid is too low but because there is no stability. Also with bigger companies there are multiple developers, better planning (usually, but trust me not always) and more experience. One of the other benefits of the larger deployment/ programming companies is that they usually have lots of references that can be reviewed and checked out in detail. Often with smaller firms or individuals many of the projects they have completed were with another company and they really don't count. When you work for someone else there is a support structure (accounting/ finance, more developers, better equipment & testing) that you do not have on your own.
This is not to say that we have not had good experiences with individual developers (or bad ones with larger programming groups) but on the whole our client feels better when they have a company with assets to make grievances with and not some guy with an computer, car and PlayStation as his primary assets that we sue for.
Just my 2 cents.
Huh?
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 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. 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!
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.
This sig has been temporarily disconnected or is no longer in service
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.
I have my own illustration. I live in a 70 year old house. The main bathroom was fixed up by the previous owners about $10 years ago, but it had problems. Among them, the old wall mounted toilet used a lot of water. It had a short bowl (I like elongated bowls) It was cracked at the base. It oozed unknown stuff around the base and it had started leaking where the pipe from the tank joined the base and the wall wasn't holding the weight from the tank very well.
We could have fixed the wall and installed a new wax seal and we might have fixed the oozing problem (assuming the cracked base wasn't involved), but we thought this was a good time to upgrade to a new water efficient modern toilet with a nice roomy elongated bowl. Sounds simple, right?
Well, first thing, the distance between the center of the drain and the wall was about 15.25" rather than the now standard 12" So, we had to custom order a new toilet. The custom order, even though it was discounted from retail, was still 3x as much as the same toilet at Home Depot for a 12" offset.
For another thing, no one, as far as we could tell makes toilets for a 15" offset, so we had to order a 14" and figure out what to do about the extra large gap between the tank and the wall, because, once we got the new toilet in there, it was obvious that it was too damn big.
We are still going to have to patch the wall, since the new toilet is smaller (but we knew that).
We had to get new studs to hold the toilet to the wall and I had to look around a little more to find ones long enough for our situation.
The old stud hole was too rotted out, so I ended up having to epoxy the stud in, but not until I made another trip to look for more options. Plus, this still may not hold and I might have to try something else.
The toilet sticks out into the room further than I would like. Their solution for 14" offsets is to sell the same base as for other applications and make a tank that is built up at the back so that it comes closer to the wall.
Now, the addage of "If it ain't broke, don't fix it" doesn't quite apply to my situation, but the reasoning is still the same. Seemingly minor changes can be much more involved than they look at first glance.
Some of the problems we ran into could have been mitigated, but they would have required significantly more planning, and some of them would have required exploration which itself would have been disruptive and might have created other problems that needed to be solved.
Changes to ones systems platform can be similarly disruptive.
Your post is in so far interesting that it gives indeed a hint why it is hard to bid.
:\
.... its allways the PERSON who does it. Project usualy fail not beause of technical incompetence. They fail because of organisational incompetence and this one is often paired with personal or communicative incompetence, call it pride and selfishness if you like.
That was the idea.
I have NONE of such certifications you require. And I have a strong disbelieve in specialization, especialy in computer science. It is VERY likely that one of the guys who win a bid by you are trained BY ME. And I learned it by DOING
As a college dropout myself, I can certainly sympathize with your argument, but it won't get you anywhere. This discussion is about people wanting to know how to win bids, and the easiest way to win a bid is to prove that you know your stuff. Portfolios are easily faked, and I don't have time to meet with you, so how am I to determine whether or not you know the technology? By asking an independent and unbiased third party source. That's what degrees and certifications are really all about. When I hold two bids, and one has certified and/or degreed developers while the other has nothing, I'm forced to compare a known minimum to a completely unknown quantity. Given the typical ten minutes per bid that we're given, which would you chose? Now, since 90% of bids are reviewed by MBA's and purchasing departments with little technical background, which do you think they would choose? We're not talking about what's fair or how things SHOULD be, we're talking about how they ARE. This is how things are, and people need to take this into account when bidding projects.
Would you ask Ivar Jacobson wich certifications he has?
You know, I've got one of his UML books floating around my office somewhere, and I seem to recall that his proper title is Dr. Ivar Jacobson. A PhD in programming kinda speaks for itself
Also your rant about XYZ Web Inc versus personal projects
You're missing your own point. First you say it's the person who does it, then you say it's not technical incompetence (i.e. "the person") who causes the project failures. This is my point and it's EXACTLY why I want to see portfolio projects from the company, not the individual developers.
You could, for example, put together 10 of the best web developers, graphic designers, and DBA's on the market and create a new company. On paper, if you list their individual projects, it might look pretty impressive. But what if the new company has bad management? Poor development processes? Unrealistic salesmen? The best developers in the world can't overcome working for a bad company, and their personal histories are no gurantee that projects taken on by this company will succeed. That's why we have to see projects done by the COMPANY. It not only shows us that you have competent developers, but that you can all work together and get things done. That's more important to a company than individual skill...I'm outsourcing to a company, not hiring a programmer.
There is nothing so pathetic as seeing a beautiful young theory roughed up by a tough gang of facts.