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."
..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).
having evaluated bids like this a lot, i'll have to put "evaluated" in quotes. you don't have time to really go in depth and really check out each bid. if you get five bids, one is for $100,000, one if for $1,000, and the other three are for $10,000, that makes it an easy first cut down to the middle 3, because obviously the 100K people are insanely out of our budget, and the 1K people are obviously missing something.
this is how most government contracts work. ignore the high bidder, ignore the low bidder, and hope for the best when you pick one of the middles at near-random. you just don't have time to be thorough when you evaluate a bunch of bids.
MORTAR COMBAT!
Possible reasons:
1) You appeared amatuerish. Cheap often *does* mean its a little bloke sitting alone in a room hacking out stuff. There no guarantee you might just get bored and fuck off.
2) Did they offer more? Putting in extra features, and charging for them, is commonplace.
3) Are you sure you actually lost on price? Was their bid of a higher quality, and you were fobbed off with the price as an excuse?
4) Did they offer support? Updates? Full IP/Copyright? Training? Sort of comes in with number 2..
Cheaper does not always mean 'the same thing at a lower price'. Theres a reason for the 'cheap and cheerful', and 'you get what you pay for' adages after all.
http://twitter.com/onion2k
Firstly, you assume that the client was honest with you when he told you that you lost the job because your price was too low. A lot of times clients will say that to small contractors in an attempt to avoid hurting their feelings when really, the reason is that they don't think you're good enough to do a good job, and THAT'S why you're charging too little. You have to know your market. If you went shopping for (say) a wedding ring, and some guy offered you a perfectly beautiful ring for 1/3 what they were selling elsewhere, what's the first thing you would do ? Run off and have it appraised, because YOU would be sitting there wondering what was wrong with it. Businesses are no different, except there is no appraiser for software.
There's also psychological data that shows that people tend to hold dear those things that they have invested more in. Social psychologists have demonstrated that an excellent way to increase someone's opinion of you is to get THEM to do something for YOU, and often times the more onerous the task, the higher the resulting opinion. One interpretation is that they internally conclude they must like you more, in order to explain to themselves why they would do something difficult for you. Conversely, if something comes easily, it won't be valued as much, and people know this at some level.
My firm does Landscape Architecture, Land Planning, and Architectural Visualization. We run into the same thing all the time. Because we're much smaller and leaner, we can generally offer better service, better product, at a MUCH lower cost than larger firms.
.
The catch-22 of the whole thing is that the client will bitch about how much money you're costing them . . . then you'll hear through back channels at the end of the project that they aren't happy because they don't think they paid enough for the high quality product they got.
I've got untold colleagues in other professions who have had essentially the same experience. I think it boils down to this - people want to feel violated. There's a mindset of "if it doesn't hurt, it can't be good" . .
just2cents.
anything i tell you will cloud your opinion.
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".
If I go out and charge $20/h to do consulting, I can't get any business, but if I go and charge $200/h, I can get a fair bit of businesness!
This is CRAZY!
What I get from customers is that those who charge more most have something more to deliver because they charge so much. It is the same stupidity that means a person in a three-piece well-fitting suit can open a bank account with obviously bogus ID, while a hippy with lots of good and valid ID gets the runarround.
If things look rich, then people, especially business people tend to trust them more than things that don't look rich. This is a major flaw in the only society I am familar with, North American Society.
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
You'll ruin it for everybody. Just sit back, and bill the extra hours while you play quake, no one will tell, really.
___
Cogito cogito, ergo cogito sum.
It's true... the last thing you want to be when bidding on a project is the lowest bidder. It is actually worse than being the highest. When I was pitching my first real contracted website, I didn't know what the market value was for my work. I gave a price that I felt was fair. The site was a no brainer (pure HTML, no code) so I didn't feel the need to charge a huge amount. After a few days, one of the guys I knew in the IT department told me off the record that when they saw my bid they questioned my ability. Apparently business looks upon the lowest bidder as someone who is either desperate to get started or someone who does not have the skills to charge near the other bidders. I tripled my bid and was accepted without hesitation. My design never changed.
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.
CYA - Cover Your Ass. Its a blame-culture thing.
Business don't see the support structure behind Open Source - without that support structure, there's no-one to lay the blame on when things go wrong (Software is always the root cause of problems from a manager's point of view). So, somehow, just having the option of turning around to IBM and give them a royal bollocking is worth the exorbitant price.
Our company has recently switched from using Netscape's IPlanet to IBM's HTTP server -- on the basis of IBM's product being much cheaper per CPU than IPlanet (and it comes with Websphere 4). Did we mention IBM's HTTP's server is basically a rebadged Apache? Yep. Did we say Apache was Open Source? Yep. "Can't use a free webserver to run a professional website."
A few months earlier we were using an out-of-date copy of JRun on the main webserver. Something didn't work. Called the support line - being a product that Allaire no longer supported, there was no valid support contract. So the co bought a few copies of the supported JRun 3.0 (hence buying a new support contract and licenses). The bug was found, in one of the JSP's - not the servlet engine itself. And we still have shrinkwrapped copies of JRun 3.0 gathering dust in the filing cabinet. And we still run JRun 2.3.2.
How's that for logic!
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.
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?
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.
When shit fucks up, whoever commissioned it wants to be able to use the excuse, "But, I paid good money for this!"
You can't pass the buck when there's no buck. Why do you think CTOs love MS and are scared of OS? Because you can't say that you spent top dollar unless you do spend top dollar. It divests the commissioning employer from having to be held accountable if your work sucks; if they went for your contract, the dude above him could easily say "Well, of course it fucked up, you didn't spend a shitload of money on it."
The fact that theres little correlation between price and quality has little to do with the fact that its way easier to be unaccountable for a project if you pay a premium price. Its totally backwards, but hey, so's this continent, so just think of it as being a neccessary bit of stupidity for consistancy's sake.
(BTW, this is why its so hard to break into new markets using price as a differentiator. Yet another example of how classical free market economics don't exactly model the real world. When you are a newcomer to an industry, its hard to undercut the competition using price because people don't want to be left in a situation where they have to explain to their senior manager that the reason shit fucked up was that they went for a bargain.)
"Old man yells at systemd"
I really doubt that the core problem is you didn't make a high enough bid. To the client, a low bid may be an indication that you don't understand the project well enough. Did you provide a detailed written proposal or was your response "I think that will take a few weeks and cost $5,000"? Did your bid account for the inevitable post-delivery tweaks and fixes for misunderstandings about the requirements? If not, were you planning to try and charge extra for these as they arose? Did you put in time for training them on the operation of your code? If they plan to maintain it with in-house resources, did you account for that time as well?
Bidding is about risk management on both sides. Even the process of giving a bid is a calculated risk. If you spend a day or more to really understand the customer requirements and write up a good proposal, you're already in the hole on a project. Obviously you can reduce the initial cost by using the "two weeks and $5k" approach but that doesn't inspire confidence.
Once you've established a relationship with a client you can often dispense with the detailed written bids, but it's often important for that first foot in the door.
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.
Then, for the second iteration we went to java and built a much more sophisticated, interactve app. The brass loved that even more.
They decided it was really worth doing and therefore they must spend money on it. They initiated the monstrous government procurement process. It took some eight months or more, but finally a coalition team with Oracle and IBM and others won the $35 million contract.
After much hoo-ha, meetings, requirements gathering, countless billable hours, and the generation of untold linear yards of documentation, they finally decided to build something quite similar to our first prototype. And, after several years of work, with a team of dozens of contractors, that's what they have.
It's like the management said, "We love this, therefore we must spend millions of dollars to have it be exactly the same." But surely some assistant director's budget doubled, thus increasing their dominion, and people got to put on their resume that they oversaw a $35M contract. I'm sure everyone got awards and promotions for successfully disposing of all those unwanted taxpayer dollars.
Sigh. No I'm not bitter, I swear. :-)
Light cup, beer drink, thin so chain, neck turtle fat, man I won't say it again
Quite some time ago now a company a friend worked for needed a small system writing. It was a mid-sized company, still 10's of $millions turnover.
:)
I wrote a demo, spec, etc. and put a bid in. They thought it was good so I had a meeting with the IT Director. He was happy with what I was planning but he questioned how much I was charging - at the time I thought it was a bit expensive, however, I was shocked when he said he thought it was too low! In fact I ended up charging 400% of my original estimate! They paid up, I was happy
Why, I don't know. Maybe my outsourced development was making their in house development and IT work seem overly expensive. Happy to take the wonga though.
Bah! Mating has nothing to do with it! It's all of those RPGs we've been playing for the last 30 years! Where the more expensive something is, the better it is. You KNOW that if you step into a shop, and that rusted out helmet costs 25,000gp, but the shining gold and platinum helmet next to it costs 125gp, the rusted Helmet is a mystic artifact that is WAAAAY better than the shiny one! So of course, everyone now knows that the more expensive something is the better it is!
Kintanon
Vide Game Slave
Check out JoshJitsu.info for Brazilian Ji
Paul Everitt (Zope/Digital Creations) spoke in Colorado about 2 years ago at a Linux conference. Zope Corporations was preparing to bid on a large contract for a national news organization, and they ran their proposal past one of the board members who was a VC and familiar with the market and with Zope Corp's abilities. He told them it was all fine but they needed to double their bid price in order to be taken seriously. Paul told him they would be making a nice profit at the bid price they had settled on, and the VC told him that they would never get the contract if they didn't double their bid price, because the client wouldn't take them seriously. They doubled the bid price and still came in under all almost all the other bidders and got the contract.
this is getting old and so are you
blog
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
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