Why are Businesses Willing to Spend More for Software?

Lost Canadian Abroad asks: "As a software developer I have always found it strange that large companies are willing to spend obscene amounts of money for software development. Until recently I have shrugged it off as 'the cost of doing business', but something happened not long ago that has caused me to start questioning that practice. The more I talk about it with other people, who are business people themselves, the more irritated I get about the whole thing. Why is it that if you're not charging a company tens of thousands of dollars for a development project that you're not taken seriously?" I've always wondered about this, myself. This practice seems to contradict common sense. Is it that higher prices imply a certain degree of quality and/or assurance to managers? Do you think that businesses might be better off if they took a risk and tried the lower end of the costs spectrum?

"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."

Comments

Price is not the only consideration....

[Anonymous Coward]

When I assess a bid, I look at the bidder's track record and attempt to assess their ability to deliver and support the goods.

The differential in bids for what is in reality a very small dev project ($5k .. $15k) doesn't really add up to much.

Maybe your competition won the business because they have more credibility or experience in that sector. Get over it.

Insurance...?

[nanite2000]

Surely the higher prices the development firms charge act as some sort of insurance policy? If you're producing software for a large company, and it goes wrong, your development company will be sued for ALOT of money. By charging higher rates, you are not only giving across an assurance of quality, but also ensuring your own company can afford to handle it if anything goes wrong.

Re:heh

[Benny Bunny]

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.

Its about CYA

[Isofarro]

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!

Re:And the answer is...

[BlackMesaResearchFac]

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.

Also known as, "cognitive dissonance."

I love it when people pull out the psychology stuff. :)

The Switch

[Winnipenguin]

Occasionally, organizations invite bidders to the table just to keep the incumbent honest or maybe they just liked your competition better.

I have helped companies secure millions of dollars in technology business and based on my experience those purchase decisions tend to follow a similar pattern.

An individual or team responsible for making the decision will pick a solution early in the purchasing process and then go into the "Switch". In this mode they become less rationale and very emotional about promoting their choice. Once they have switched, it can be very difficult to change their minds.

It usually comes down to relationship. Do you have a strong sponsor/inside coach at the client/prospect? Without the right one your batting average will be pretty low. Communication leads to trust and when people trust you, it is easier to get things done, including winning contracts.

Cheers,
Winnipenguin
X-Corporate Soldier

Sweet Sally sullied shameful Sammy's shining sig

Honestly, $15000 was under bid...

[Java Pimp]

I don't care how good you think you are, it cost money to create quality. I highly doubt anyone could create a quality bug-free product like you are describing in less than a month and be fully implemented, FULLY TESTED (everyone forgets about test!) and determined ~bug free and ready for release to consumer(s).

The amount of time spent on testing should be at least as much as the time spent on design and implementation if not more!

If you want to release a product that is ready for consumer consumption you cant just slap some code together and expect a Microsoft quality (subjective) product.

Database design (even simple) and web development (at least what you are describing) should take no less than a month for design work (a week for layout and design/prototyping), implementation (1 week to implement final design), and test (2 weeks... including different environments, browsers, ... let alone just for functionallity). Right there you are in for about $4000.00 in just labor for one person.

And we haven't said anything about the document management piece. Are we talking just file storage? version control? access control?

I would say $15000 is closer to the mark depending on the complexity but in my opinion that's even a little low.

cognitive dissonance..

[eshefer]

I believe that is the term you are looking for..

from what I've seen...

[baine]

You may not be taking into account the 'whole package' your competitor was offering. They may have allocated ~$5k worth of programming, but probably added $5k for 24/7 customer support availability and $5k to install the app on a server farm with redunant systems and uptime guarantees. They probably also had some sort of legal guarantee of having the project completed by X date (make no mistake, these things cost money!). Or, it may be that your competitor is simply a larger company, with more resources (honestly, more people to answer the phone in case the client calls), and therefore has a larger overhead to support than you. From the perspective of a small business, these things don't make much sense; why pay so much more money for guarantees on X, Y, and Z when it's just cheaper to take the risk? The thing is, for larger companies, it isn't cheaper to take the risk. Riding on any one given product or service a larger company buys there could be hundreds or thousands of billable hours or thousands of dollars of product waiting to go out the door. If a software product or custom app doesn't function right, it could easily cost a company thousands upon thousands of dollars in lost sales, lost productivity, or lost efficiency. Therefore, spending an extra $10,000 on an app that comes with some guarantees can be (and is) viewed as cheap insurance. It means a lot to larger companies to have someone they can call 24/7 if the app borks in the middle of the night. This is a large part of the reason why a lot of companies went with M$ and Sun for corporate IT servers, and why Linux is harder for them to adopt (I know RH and the like offer 24/7 tech support, but there's still a perception among some officers that it's a largely 'unsupported' platform). Think about it, as an IT director for a $80M company, how long do you think you'd get to keep your job if the email server stopped routing mail, and you had to tell the board of directors that you'd submitted a question to some newsgroups, and you hope to hear back soon. Ok, that's an exaggerated picture, but not far from what IT directors consider when choosing software. They simply don't want, in the case that something does go wrong, to have to tell their bosses that they don't have anywhere to turn to in order to rectify the situation. Therefore, they tend to favor larger, (hence, more expensive) well established software companies who have a plan for some sort of permanence, and factor that into their costs.

bidding process

[smartfart]

My buddy from school (hey, Champi!) is a construction project manager in Atlanta, and years ago he told me that normally bids were accepted, opened, and the highest and lowest bids were thrown out at the beginning, then the remaining bids were looked at from there. Supposedly it helped weed out the gouger and the guy at the bottom who didn't know his stuff well enough to put in an informed bid.

I don't know if this is incidental to Georgia or to the construction industry, though.

More than cost

[FJ]

There is more to it than just cost of software. Here are just a few.

Supportability: Which one requires more people time to maintain? How much training is needed? People cost adds up quickly.

Vendor Support: A large company will spend more on software if they feel they will get better support. If you can't reach someone at 2:00am and your system is down, being cheap is being stupid.

Life span: They will also look at the long term feasibility of the solution. If a cheaper solution can't be easily upgraded, most companies will shy away from it.

Vendor reputation: A cheaper, smaller vendor can face problems simply because they are smaller. A big business doesn't like the idea of giving a small company money if they won't be in business for the long hall.

Existing contracts: If you deal with a new company, the lawyers will become involved. This is added cost. If you are already dealing with a company, it can be much easier to change an existing contract.

Integration: Which solution fits better into an existing infrastructure?

Return business: Large companies sometimes agree to "return the favor" in exchange for a large contract. For example, a software company bidding for a telecom contract, may agree to switch to that telecom in agreement for winning the contract. I don't know how ethical it is, but it happens. When IBM sold it's Advantis network to AT&T, AT&T agreed to outsource some of it's operations to IBM's Global Services division.

Techie preference: This often is important to the bosses, but a smart business will ask the people using the solution which one they prefer. IMHO, nothing kills a project quicker than having the users say "we hate this."

Re:You need to learn basic software engineering

[BrianH]

First, someone mod this guy up, I may not agree with him 100%, but he makes some good, relevant points that many people here will miss because of the Score:0

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.
As a programmer myself, I agree completely. The debate, however, comes into play when deciding just where that line should be drawn. My personal standard is that there should never be more than 2 developers per use-case, but that it is preferable to limit teams to 1 developer per use-case and "cross-develop" features to ensure that a project stays developer independent. Using that theory, I would have accepted up to ten developers for this website.

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

Fundamentally I agree with you, but a bid is NOT the place to propose architectural changes to a potential client. I once took on a $15,000 project to add several features to a website that was written in Delphi, running on an ancient HTTPd server running on NT4, and connecting to a really old Informix database. I wrote my proposal to the clients specifications, and won the bid. After I won the bid and began developing the new features for the client, I presented them with a list of suggestions to improve their website. These ranged from implementing WCAG-AA design rules, to switching to a Solaris/Apache/Oracle architecture to improve performance. I also didn't argue for these changes "because they're better", but instead made solid business arguments as to why the changes should be made (reduced maintenance costs, improved reliability, better performance, greater expandability). The client eventually OK'd the upgrades, and my $15,000, 30-day project became a $160,000, six month project. So, yes, architectural changes CAN be suggested to the client (and they can often lead to much more lucrative contracts), but they should NOT be placed within the bid itself.

...though I admit to thinking that your choices "leave room for improvement...

I'll actually agree with you there, but that brings up the other half of the "suggesting platform changes" issue: The people evaluating your bid may not have any control over the technologies used. In my position, for instance, I make web decisions daily that directly impact website development for more than 40,000 people. Despite this, I don't get to choose what goes in our datacenter. Decisions about what we run on are made by Datacenter Operations, the Director of IT's office, and the CIO herself. While I can make suggestions regarding what goes on our servers, I can't arbitrarily order them changed. So when I put out an RFP requesting a web-app that will run on IPlanet and Broadvision, and someone gives me a bid suggesting Apache and Slashcode, there just isn't much I can do with it...no matter HOW convincing your four page manifesto on the superiority of Apache might be. I've seen far too many proposals get chucked because development firms don't take this into account.

I pretty much agree with everything else you say :)