Fog Creek Software
Discussion Board




Bidding

I work for a small web site development company. We do marketing sites and applications. One of the major problems with the company is the back and forth between sales and production. It goes like this: Sales bids fixed rates for jobs, say it's 10,000 for a small site. That amount gets divided by management to equal the number of hours we have to work on a site. Invariably the number of hours that ends up getting spent on a project is more than the number that management decided a site *should* take based on the fixed rate. Does sales need input from development before bidding?

Phillip Harrington
Monday, February 11, 2002

Does sales need input from development before bidding?  Absolutely.  There are so many reasons for this that I can't even begin to list them all. 

Software development is one of the few fields that I can think of where estimation is routinely practiced by people not knowledgeable of the tools and methods.  Would you have have a layman estimate what it would take to build an addition on your house, rebuild a car engine, pour a concrete foundation, etc.?

The only acceptable substitute for development input would be experienced project management input where the project manager is familiar with the members of the development team, their skill levels, and similar types of projects.

r
Monday, February 11, 2002


"Does sales need input from development before bidding?"

It sounds like you're talking about a "waterfall" model of
software development, so I'd say YES.  ("Successful
Software Development" by Donaldson/Siegel is a good text for waterfull.)

  However, I would submit that,  an extreme programming model might work better for you; that way the customer gets to direct how business value is spent.  Check out:

Http://www.xtremeprogramming.com

regards,

Matthew Heusser
Monday, February 11, 2002


Er, Sorry, better URL:

http://www.extremeprogramming.org

dotORG, dotORG, dotORG.

My mistake.

Matthew Heusser
Monday, February 11, 2002

First, fixed price contracts suck - majorly. I've seen small shops (and large) almost go bust because of fixed price contracts. It doesn't matter if it's web work or standard applications development -  fixed price contracts suck.

If you can get away with a fixed rate contract that states you shop is only doing X number of house, then the XP process Matthew Heusser is expousing would be the way to go.  Unfortunately, most fixed price contracts specify that the end product (web site/application) must be finished and accepted before the job is finished.

If you lose an experienced developer 1/2 way through and have to replace him, third party tool specified in the contract doesn't work right, salesman pulling a really bad number out of midair (or somewhere...) - doesn't matter, you've (your company's) agreed to finish the work for the initial price.

One place I worked, my boss contracted for a custom application from an outside vendor and wanted a fixed price. The development company came back with a price; my boss told them to add 50% on to their price - he knew that they couldn't do it for their original rate. They (the developers) lost money even at the higher price, they lost a couple of experienced people (who were replaced) and finished the project 6 months later then even the pessimistic estimate.

Jeff Pleimling
Monday, February 11, 2002

It is kind of intersting how far sales has gone away from tech:

My mom used to work for ADP as a programmer (early 80's), and she told me that no sales people were allowed to go on a sales call without a someone that knows the system and knows what the contract will cost tagging along.

It seems now the sales engineer (at least based on presentations that I have seen from Segue) is there simply to make sales run smoothly

Daniel Shchyokin
Monday, February 11, 2002

Another intersting point is that "give away the store" sales tactics are not limited to contract software developers. I work for a midsized software maker (roughly 120M Annual Sales) and we routinely get last minute feature requests/feature commitments that seem to cost (in terms of engineering hours) more than they should

Daniel Shchyokin
Monday, February 11, 2002

> Does sales need input from development before bidding?

Well, obviously, they do.

Do they ask for it?

Yeah, sometimes, kind off...

Does it help any?

Normally not much.

Here is what happened to me over and over again in a company I used to work for (and I leave it up to you to guess why I do not work for them any longer): One of the bosses (small company, the bosses were the sales department) would come up and ask: "How long would you need to finish this small project?" After considering the details, I would answer something like: "Well, about 40 days" My boss would say: "If you estimate 40 days, let us try to make a contract worth 60 days, just to be on the safe side." Wow, what a sensible approach! I was really content with my boss in those moments. Then he would go negotiating with the customer and that is what we would end up with: "Well, the customer is only willing to pay xxx so we can only afford to spend 20 days on the project and have to see what we can come up with." Sometimes we could come up with something, usually by spending more time than the 20 days paid for, but I do not know of any customer who did two or more projects with this company.

Have fun,

Jutta Jordans
Tuesday, February 12, 2002

I seem to have spent most of my life wondering why, when every project people do runs over, they don't LEARN THE LESSON.

I used to work on hardware products of which a new one we were supposed to run out the door every six weeks.

Why?

Because the team across the hall did that. They were working on completely different products that sold for only 60% of the costs of ours and they knew how to make them. We started out each project with experimental hardware to write drivers for, and regularly went over time budget by 300%. Lo and behold, next project: experimental hardware and a six week timescale.

The fixed price companies I worked for tended to have issues like: customer insisting on using Microsoft Access to do high-availability databases. And they're all bidding in this ficticious world, against other companies that were ALL trying to undercut each other, regardless of the actual acheivability of the project. So you'd get these poorly spec'd things with tiny deadlines.

{True story: I once got a project which said "Document revisioning and tracking system. Delivery in two weeks. Payment on customer acceptance." That was it - that was the whole spec. That one turned into a whole new kind of financial tunnelling machine.}

But basically, the bidding system seems to turn into this competition between two people who both know they can't deliver to see who can pick the lowest price and keep a straight face.

Customers exacerbate this by having the price as the single consideration. Working software appears to be a long way back in the list behind:
    How cheap is it?
    How many managers can get in on the project?
    Are there Powerpoint slides about this?
    Can the corporate logo be animated?
    Is there a facility to import random word documents into
        the database and, you know, just, have them in
        there? Well, no I don't know why but it's ESSENTIAL.
    Can you include technical support for Word in the
        contract?
    Can you deliver this before the next quarterly board
        meeting?
    Even if delivery relies on meeting people who can't make
        meetings because they're in meetings for the next
        six months solid?
    Please don't talk to the potential users. They are all
        currently very busy watching the last version of this
        thing crash.

Katie Lucas
Tuesday, February 12, 2002

Daniel - "sales engineer"? Priceless. Thanks for the best laugh I've had this month.

DB
Tuesday, February 12, 2002

Sorry Imeant to say Demo run smoothly, not sales run smoothly) and this is what Segue (Maker of automated test tools calls them)  my point though was not a joke, it was simply that before the point of this job was to keep salespeople for seeling 2000000 of work for 200000 dollars now it seems to be to help cover the tracks of crappy software

Daniel Shchyokin
Tuesday, February 12, 2002

Sales should _always_ have development as a check on them. One company I used to work for maintained too little control over their sales force.

It got to the point where the engineers were directed not to have _any_ technical discussions (BS session or otherwise) in the company lunchroom.

The reason for this policy was that one salesman had heard some engineers discussing an article from Byte (this was in the early 80's) about some academic research project, and had not only sold the capabilities of that research to a customer, but had committed to an aggressive delivery date!

An extreme case, true, but if you're not going to send a developer out with the sales staff (and there are often reasons not to), you _must_ make certain that the salespeople have guidelines on what they are allowed to sell. I'd argue that Sales can't quote a price for development without input from Development.

If what you do is largely the same thing every time, then you can provide Sales with 'shopping list' guidelines like "web sites with no GCI and no Flash cost $x/page," "CGI/Flash never go fixed-bid" or whatever (I do embedded, not web, development, so I'm just throwing buzzwords around right now).

If your work isn't "stock development," then you may need to require Sales to come back and get estimates before submitting bids. It may be that a particular job isn't worth bidding on because you'd lose money. Don't expect someone in Sales to pass it up, though. Often, their compensation is based on how many dollars they bring in, not on whether or not the job ends up making money for the company.

Steve Wheeler
Tuesday, February 12, 2002

*  Recent Topics

*  Fog Creek Home