Fog Creek Software
Discussion Board




Responding to an RFP. How?  When to charge?

Hi,

I've never done a larger (>$4000) project.
I write commercial software, and someone wants to reuse a piece of our software in a different (non-competing) product.

Customer has asked for an estimate based on a rough list of features.  I'm going to have the programmer provide customer with a range (estimate between $A and $B)
So, we'll have spent a few hours looking at this, at no charge.  (I know, it's part of the cost of doing business.  Not a problem as long at the business actually materializes ;-)

AT WHAT POINT DO WE START CHARGING?

Customer also wants a schedule and some tax info from use and a formal response to the RFP.
(Again, not something I've ever done).
But they have pointed out that they will probably have updates to the spec, etc.

WHAT SHOULD GO IN OUR RFP REPLY besides:
1.  Addressing thier requests ("we will provide A, B , C, etc.")
2. Delivery and payment schedule
3. Addressing charges for excessive feature creep.

HOW DO YOU HANDLE FEATURE CREEP?
Client writes: "I assume that we have not defined sufficiently all of the requirements and we will
>>  need to get these defined for you either in subsequent iterations or
>>  before
>>  starting.
"
That seems to leave a gapping hole to let in a lot of feature creep.

Clay N.
Wednesday, June 25, 2003

Also... what level of detail do you typically provide in an RFP response (when providing that response free of charge) ?

Clay N.
Wednesday, June 25, 2003

More info...


The customer wants us to turn part of a program into a component so they can resuse it in training materials.

Clay N.
Wednesday, June 25, 2003

Three quick pieces of advice,

(1) WHEN DO YOU CHARGE... Depends what you can get away with.  Think about charging from the customer's perspective.  Is there value in the response to the customer, even without implementation?  If not, you'll have a hard time charging.  Gauge the amount of time you spend based on your judgement of the size of the contract and the probability of success. 

(2) WHAT SHOULD GO IN THE REPLY... In any proposal/RFP/response, etc, the most important thing to include at the start is a summary of the customer's requirements and/or business need.  Clearly summarizing this (even if it seems obvious) shows that you understand the problem and will propose a solution to his exact needs.

(3) As an aside, avoid formal RFP's whenever possible.  They're a lot of work, often involve meaningless checkoffs of features, and have a low payoff.  Typically, an RFP is offered in a formal bidding process, to three firms.  One of the firms is the preferred choice.  The other two are included as benchmarks against the first firm, and "to be fair".  You'll never win an RFP unless you become that first firm (which is a whole sales strategy in itself), or prevent the RFP process long before it begins by becoming the sole choice.

There's some good books out there about making complex technology sales, sometimes called "solution sales".  One I've liked is

The New Strategic Selling: The Unique Sales System Proven Successful by the World's Best Companies
Stephan Heiman, etc.

Voice of Rationality
Wednesday, June 25, 2003

- Remember, it is business.  If they will not put it in a contract it is non-binding. [Don't let people mislead you with "verbal" contracts.  They are meaningless without  large $$$ for lawyers]

- Hire a contract lawyer, someone familiar with Intellectual property rights and limited partnerships.  Do this now.  They cannot help retroactively. (IANAL)  You need someone to review what you have written and ensure you have your rights protected.  A well executed contract keeps you out of court.

- No open requirements.  If there are additions,  they are billed at "X" dollars/euros per hour until completion.  State anything not defined in scope is out of scope and billed per hour or bid by piece.  Determine how you will know the project is complete, how enhancements are to be addressed and how defects are to be resolved.  This is especially true in interface projects.  Consider that they make a change to their side of the interface, is this covered under the project or is this billable hours?  Is it an enhancement, requirement or defect?  You want to spell out as much as possible to avoid confusion later. 

- Only provide tax info, P&L, etc. if they are willing to reciprocate.  This is a yellow flag.  Some companies look to ensure you have the resources to do what you promise.  Others look to see what it would take to bankrupt you, or just take what you have.  With $20,000 in the bank how long could you fight a company with a full-time lawyer?

- ALWAYS have them sign a non-disclosure agreement before sending anything or discussing business, such as the interface. 
http://allbusiness.findlaw.com/agreements/glasser/onewaynondisclosure.html

- All RFPs are free of charge and billing cannot in most cases occur until a contract is signed. .  Plan to make your money if you win.  By definition an RFP is usually in place to allow for competitive bidding.  Usually a statement of work is supplied for work you are merely pricing.

- Form and substance: (standard - assumes you do not mean government work)

Provide an overview of your organization, experience, etc.
Provide a detail of every item they have in their RFP, item by item, describing how you will meet the requirement.  You can price each item individually, or a price line item at the end, along with duration, time-lines, and a project plan  will often work.  The more you know about the client the better you know which method to use.  Some RFPs will tell you.

Include billing information so they are aware they must pay on a schedule, up front, back end, what ever you wish or the require. 

Include an offer expiration date.  You may be willing to do it for $100,000 today, but would you be willing to in 13 months?

Ask.  Yes, ask.  If they have a format, standard, or template, use that.  That is what they are used to and often it will eliminate the issue with the financial department "not understanding" what you mean by "XYZ"

That is my quick list...

Mike Gamerland
Wednesday, June 25, 2003

Just a quick note-

"Don't let people mislead you with "verbal" contracts.  They are meaningless without  large $$$ for lawyers"

Verbal contracts *are* (with some exceptions) binding. Just wanted to point that out.

Philo

Philo
Wednesday, June 25, 2003

Hi Clay N.,

The people who have already responded to your post have provided you with some excellent pointers.

I would like to add my two cents to this discussion, however, this forum really isn't conducive to answering your post in the manner that it deserves. You might want to consider posting your questions on Usenet. Here are a few URLs that might be appropriate:

* http://groups.google.com/groups?hl=en&group=comp.software-eng

* http://groups.google.com/groups?hl=en&group=misc.business.consulting

* http://groups.google.com/groups?hl=en&group=alt.computer.consultants.moderated

* http://groups.google.com/groups?hl=en&group=alt.comp.project-management


Other places to check out

* Janet Ruhl's Computer Consultant's message board  http://www.realrates.com/

* Open IT forum  http://pub21.ezboard.com/bopenitforum

One Programmer's Opinion
Wednesday, June 25, 2003

Philo,
While binding, you get into the question of semantics and what was meant by supplying, etc.  You can win.  You just need the legal/cash resources to maintain the fight.

Mike Gamerland
Wednesday, June 25, 2003

You should not normally need to provide tax info.

Since they have told you they want you should start charging after the first consultation. Your responses after that time are part of the process of them acquiring and customising your component.

In your response, specify that further discussion will require the signing of NDA's and work contracts. This includes specifying the features you will provide, specifying the criteria for successful completion and so on.

From the minute they sign, charge them at, say, $150 per hour. Make sure you retain all rights to the IP.

Always remember that the people you deal with are getting paid, and they charge other people for their company's time and/or product.


Wednesday, June 25, 2003

Should have been ...

Since they have told you they want your product, you should start charging after the first consultation.

If they indicate further interest, start charging them for specifying the features, specifying the criteria for successful completion and the other aspects of working with them. Don't do all that for free.


Wednesday, June 25, 2003

Everyone in this thread is going to give you good advice, mostly I imagine from angles that they have been burned on in the past.

Here's one from Downtown.  Always put an expiration date on any quote for services you submit.  30, 45, 60 days, whatever fits your business model.

The last thing you want is for some screwball outfit to come back 9 months later and hold your feet to the fire for a quote you provided when you weren't really busy that called for quick delivery and a low price because you really needed the loot.  Then you got busy ...

Mitch & Murray (from downtown)
Wednesday, June 25, 2003

It seems to me that: if you're really in the software resale business and that you are not in the services business, and so you are not really set up from past experience to do accurate estimations of project scope for use in a fixed price setting. Don't take that as a slam... hardly anyone really is, even most service vendors.


Soooo... If I possessed source code that someone wanted to license subject to modifications to do "X", I would probably just list the features currently contained in that code and then tell them that additional features would be per purchase order at $NN per hour.

It sounds to me like preparation of a bid in this instance is a huge distraction from your main line of business and is a large pain in the posterior.  So, I do agree with the person who wrote that formal RFP preparation is a low-probability, high risk exercise. The only way I would get involved  in a situation like this would be for a project that represented a *substantial* amount of new billings.  Which probably does not correspond to a prospective client who wants an existing piece of component code with modifications.

Bored Bystander
Wednesday, June 25, 2003

It is a bit of a distraction, but I was interested in doing a bit of this work, even if it's only to find out that I HATE doing this kind of work ;-).  All  experience is useful.  That which does not kill me makes me stronger, right?

I'm fairly certain we'll get the bid.  We have a unique program and we'll be charging them enough to cover all of our costs plus a bit of a bonus for the intellectual property.

And they'll save money vs. starting from scratch.

Clay N.
Thursday, June 26, 2003

>>  I'm fairly certain we'll get the bid.  We have a unique program and we'll be charging them enough to cover all of our costs plus a bit of a bonus for the intellectual property.

On one hand, I agree that this will be an excellent learning exercize for you. I've always learned something from going through a bidding process.


On the other hand... the way you describe it, customization will be the lion's share of the value delivered, and the standard part you already have in hand will be a minor part of the total package.


And you originally posted a question about preparing such bids that had to do with attaining closure on the specs and nailing down the specifics. Therefore, I am thinking that you should approach this exercize with a GREAT amount of caution because you're admitting that you are inexperienced with this type of work. Fixed price work can eat you alive, especially if you had no experience with it before.


One tip I do want to give you on this subject: write your bid such that you specify an acceptance test and acceptance criteria that your code must meet in order to trigger payment. You *must* have an excruciatingly clear criteria that will be readily recognized by your client.  One problem that so many small timers I've known (myself included) have had is that the client runs amok with new requirements because the project definition and the acceptance were ambiguous. If they default or renege, your satisfied acceptance criteria can become the basis of legal action. 


And if you cannot  formulate an acceptance criteria, you should consider passing on the work. This includes the case in which you feel that the work in preparing the acceptance criteria is larger than the work itself is worth. Especially "if".


Good luck. I do mean that.

Bored Bystander
Thursday, June 26, 2003

"You *must* have an excruciatingly clear criteria that will be readily recognized by your client. "

EXCELLENT point.  The criteria is actually quite clear. For example : display screen #1 without the buttons.  Return existing values A,B,C as parameters.

Clay N.
Thursday, June 26, 2003

*  Recent Topics

*  Fog Creek Home