Intent

[Ocean West]

The telephone rings and the voice on the other end, tells you they heard about you from 'so-and-so' and you come recommended for your skill, or perhaps you are the closest FileMaker Developer in a 50 mile radius.

During this phone conversation you exchange pleasantries, and outline your services and or solutions, your skills and abilities, and some where in there you interject your modus operandi that you work on a contractual basis and that your hourly rate is $X per hour.

After you've chatted with the prospect for 30 minutes they indicate they wish to utilize your services, and or are inquiring about your solution.

Not knowing them from Adam you feel confident in your FileMaker skills that this is a project you wouldn't mind being a part of , not only for the 'glory" or for the challenge but for most of us its for the $$$, After all that is why we are in business.

The next point in your conversation is to arrange a meeting. With the details of the project to be discussed with perhaps multiple indiviuals.

Upon arriving at your location for the meeting, you discuss many variations on a theme, at this stage you are interviewing your prospective client. Getting feedback about them, face to face meetings gives your gut something to go on.

But it now comes down to the wire. Fish or cut bait. You have already spent about a half an hour on the phone (usually over a hour) then you have gotten in your car and drove to their location to meet, more time. The the meeting itself provides insight to more details of the project that you are to take on.

So when does the cost of doing business (wooing a prospective client) become a paying gig?

You may have personal policy that you give upto an hour on the phone to determine if you want to do the job or not. And then perhaps a maximum of 2 hours in person to meet and interview the client more.

Now that you have a more clearer picture of what they want (which will change many times) You need to propose a price or at least an estimate or better yet "Scope of Work" document. That outlines the time frames and objectives of the project. But what if you can not estimate how long something is going to take? The unknowns?

You may not even have the job, and are now expected to give a price without knowing what your in for. What if you are upgrading someone else's database, You haven't even had the opportunity to look under the hood or kick the tires.

Letter of Intent, a one page letter that simply states that the prospective client intends to contract with you. Pending your review of documents, programs, interview with staff, etc. And that all this takes time, and sence time is money you need to be compensated. Even if this the same rate as your contract, it is still a good idea to outline these items. What if the client is shopping and you spent another 40 hours writting a Scope of Work document and they go with your competitor. Your stuck with an expensive waste of time and resources that you could have contributed to an existing paying client.

So once you have determined your threshold of pain as to how much of your advice you give away for free. You hand your client a letter of intent to be signed. It is quicker and less intimidating for them to sign on the spot in lieu of the 12 page contract. And protects you if they fail to pay you for your services renderd, prior to signing the contract.

This is something I am making more a policy in my practice. What have you found to be effective?

Ideas and thoughts on this topic I am sure would be of intrest to many forum members...

[Ocean West]

Another tool that is utilized by large firms is a Purchase Order. With out an authoriztation to proceed or a PO no invoices will be paid.

The hard part is smaller mom & pop shops may not use PO's. So in your letter of intent include a not to exceed clause for hours and dollars.

[BobWeaver]

One of the things that I use is a standard proposal form. It has aprox. a page of general terms and conditions (in 10 point font, so it could easily be a quarter page in standard contract fine print). The rest is scope of work which depends on the project.

At the very end of the proposal, is a section where the client can indicate his/her authorization to do the work. Something like this:

___________________________________________________

Proposal accepted by ____<Client Business Name>______. Client PO#_____________

The undersigned hereby authorizes XYZ Database Consultants Inc. to commence work on this project according to the terms of the above proposal.

Name___________

Title___________

Signature__________

Date_____________

Please return signed copy to XYZ Database Consultants Inc.

123 AnyStreet,

Somewhereville

___________________________________________________

For small jobs, this is a quick and easy way to get a prospective client to start things going without a lot of paperwork. But, it still protects the consultant by having a signed authorization. Caveat: I'm not a lawyer, so have your own lawyer review your documents before you use them.

[danjacoby]

The odd thing is that I've never used a written contract of any kind. I live in New York City, and had clients as small as a private odd-lot middleman and as large as a major television studio (I won't say which, but if you know what little is filmed in NYC, you can probably figure it out).

I suppose I'm not much of a businessman, but I've never been cheated and I've never missed a meal. I've even had two clients I've never met, because they're nowhere near NYC (amazing what the internet can do for us computer geeks), and not a written agreement in sight.

Just lucky, I guess.

[Fitch]

On larger jobs, I outline the pricing and the general scope of the work to be done in a Proposal, for which I don't charge.

In the Proposal, I separate the Detailed Specification from the Actual Project. I make it clear that I will bill for the Spec. This protects you in the case where you do all the legwork and analysis and then they turn around and hand your Spec to some lowballer to do the programming.

There's some decent discussion of this in The Computer Consultant's Guide. (I'm sure there are newer, better books on the subject.)

[sneddens]

I am only now about to get my second client so I don't have insight except from a purchaser's perspective.

I was once shopping for a programmer and came across a fellow who said: "I will design the solution in three or four stages; at each stage you will have functioning code. You will commit to paying for one stage at a time. If at any time you are unhappy with how things are going you can take the code you have paid for elsewhere." The project fell through but he would have gotten the job eventhough his hourly rates were very high.

[agraham999]

I have a policy...of what my time is worth...and what is the minimum I am willing to do a project for...both in time and money. I am an author and write columns full-time...so if the project is enough to pull me from writing for at least a month...I'll consider it. So start with your own policy of what your time and effort are worth. There is always another gig out there...so don't sell yourself short...stick to your guns.

I have a few other policies...

I never get into a bidding war with another developer...once I get that vibe I back off. If a company is going to make a big deal over a couple of grand...it isn't worth fighting over...because cheap clients are the most trouble...wanting something for nothing.

I try to take clients who also charge by the hour...like large consulting firms, architecture firms and so on...because they understand the value of "time." An architecture firm that charges $100 an hour for their designers...won't bat an eye at your $110 an hour. Small clients with very little understanding on the value of IT will balk at a $10,000+ bid.

I will give a prospective client about 30 minutes on the phone...and then I move right to a meeting. I'll give a company two hours of my face time for nothing...in one sitting...I don't let them pick my brain...what I really do is pick theirs...then I go back and give them a proposal...which I'll spend about an hour on. My rates aren't negotiable and my quotes are firm. I will have another face to face if they want me to justify why my work is better than another developers.

I really try to communicate one message to prospective clients...and that is I am all about value. I'll give them a complete balanced solution and build it so that it can grow with them as their needs grow. I like to foster long relationships.

When they hire me...I meet with them to develop three plans...rev 1, 2 & 3. Rev 1 is their basic needs with a few "wows" thrown in so that they can see the beauty and power of FMP. I love it when they go "I'd never thought I could do that." Rev 2 comes 30 days after rev 1 is installed...it is the revised 1 with zero bugs. Rev 3 is the "possibility" version that is only on paper. I give them a plan of where they could be in the next version.

I've never done a letter of intent...because I give them a proposal that mentions a retainer of "x" amount must be paid before work will begin. Their retainer seals the deal...in any court. NEVER call it a deposit...use the word retainer.

Don't set your fees too low...or they will always expect it...and it doesn't give you any room for error. For example...perhaps you need to have someone do part of the work for you because you are swamped...well if you only charge $30 an hour...good luck finding a freelancer for $30 or less.

Good point Ocean West about taking someone elses work...you can get burned here very easily. I just did...I took over a project that was 6 months in the making...and when I took over...I thought it would be an easy case of fixing their work...and then I learned the clients needs exceeded the abilities of this work. And this work was baaaad. I had to rebuild 6 months of work in three weeks. In this case I didn't get burned financially...just in time...an impossible deadline. The funny part of the gig was that the previous developer was a Filemaker instructor. It made me feel that FMP instruction could be quite dubious.

Know your buzzwords and what they mean...clients often don't know what ODBC, JDBC, XML, SQL, and other tech goop mean...bu tthey love to drop it in a meeting...and you need to be ready to fire right back. Also...a lot of companies have a "tech guy" who keeps the server running...but knows nothing about relational db. These guys often appear in meetings and like to grill ya...give you a hard time...gives them some type of superiority complex or something. Don't get into a spar with them...just talk data...the data is what is important...and if you aren't sure of the answer...just say you aren't sure...you have to see what they have...and keep the topic on the db.

Demo files...keep a good one and a bad one. Keep a sample of your work to show in a meeting...and a bad sample even if you have to make it. This way you can show WHY you do things a certain way. I have seen some severe portal abuse and other design mistakes...so it serves as a good example of why you have a certain development philosophy. And never send the demo file...always do it in person...because if they don't understand what they are looking at or are doing...they may assume their mistakes...are your bad design.

One last thing...I express that I am excited and interested in doign the project...but I also try to give the vibe that I don't need their work...you don't want to appear too hungry...or they'll take advantage.

One last thing for real...be sure in your proposal...that you outline how many meetings you will have (I do 3) and charge after that...or they will bring you in for stupid stuff all the time. And never include installation into the job as a freebie. Good lord...I've seen installs that take 3 days because of THEIR network problems, THEIR computer guy, etc. I once told an Admin guy I needed the Exchange address book data ASAP...he said he would have it the next day...I waited three weeks...all that time not making a penny because I couldn't take another gig...because today could be the day.

Do good work...with reasonable rates...and always deliver on time...and you'll stay busy.

[Geeksharka]

I've been doing professional FMP (Web & Enterprise) work for a long time now (since v.2), and have gone through all the stages of proposing/bidding. Many many good experiences, a few bad ones. Here are my rules of thumb now:

- Free consultation, usually one hour via phone or face-to-face (most of my clients are far away). During this initial contact key elements need to be discussed/discovered, them being: general scope, timeframe, rapport with client, client budget, your rates, your billing method.

- The billing method boils down to this: It's all hourly.

Billed monthly, after the fact with complete list of hours worked with descriptions. New clients sometimes (but rarely) are required to pay an initial retainer upfront against which hours are booked, depending on the project size, and client rapport.

- They need help planning the job? (Their 'outline' is too vague?) Well, that's where your expertise and experience comes in. Explain to them the importance of a solid blueprint, and charge them for assembling it. I inform the client of the estimated cost for developing the blueprint, and then let them decide if they wish to have the blueprint developed.

Around 10 years ago (with nothing better to do anyway) I spent way too much time creating entire blueprints, describing in detail how to make their plan work from a technical/DB point of view -- and then see the client take the blueprint and bid it out again!

Nowadays I charge them for the blueprint (1/2 up front, 1/2 upon delivery), and expressly let them know that they can then (after they've bought it from me) take that blueprint and use it to let others bid on the job. That way they are not locked into using me just because I made the blueprint. It has yet to happen that they choose someone else at that stage, but it's good for the client to know that the money they're spending on developing the blueprint provides them with something that is theirs -- regardless of whether they continue to work with the blueprint developer.

Without the blueprint, I will not estimate time, money, or hours on any project.

The blueprints are detailed, but clear. They are (of course) generated in FMP, complete with Budget, Specs, Elements, Phases, Timelines, Costs, Billing Methods, Payment Due Dates, Sign Here, and here, and here, etc. etc.

All proposals are different, but contain the same basic elements. Using FMP allows me to literally spend time on the important stuff (research/planning), and then create and spit out a customized bid within minutes. I don't care about this too much anymore, but with my old firm we'd send out 2 to 3 full 10-20 page bids a week on this system and never had a problem.

Finally, with a detailed, clearly written, and signed blueprint, all parties can move forward with confidence -- and you don't feel jipped for spending so much time developing the plan, because they already paid for that part.

HTH

[Kurt Knippel]

Sharka,

This bidding solution in Filemaker...is this something that you would be willing to share?

[Geeksharka]

I'd be happy to.

It's been awhile since I've used it, so let me see if I can dig it up first. If I find it, I'll place a open copy on my site for anyone to download and tweak as needed (logos, etc. etc.). I'll provide a direct link on my next post.

[Geeksharka]

Hmm, just looked about... but no nada. I hate it when that happens. I'll compile a similar proposal assembler and post it soon.

[Geeksharka]

I placed it online.

Click here to go get it.

[kenneth2k1]

Hello.

Perhaps Kurt means to communicate that this sample file bid could be used by a competitor once you have given it to the client.

Ken

[Geeksharka]

Perhaps Kurt means to communicate that this sample file bid could be used by a competitor once you have given it to the client.

That's OK. That's why the bid is kept pretty simple. It has enough sections in it to convey knowledge and professionalism, but not enough to tell them how to do the job. The point is to convey to the (potential) client that you A) understand what they're talking about, know how to realize their wishes, and C) clearly inform the client of your (general) cost -- so nobody's wasting anyone's time.

The real nitty-gritty of planning the job in detail (what I call creating the blueprint) is something the client pays for. and always the first part of any job. If they expect me to do that for free, well, it won't happen. Creating a detailed, professional blueprint outlining the system's architecture, detailed tech specs, etc. etc. involves my experience and expertise, so if they need help creating a qualified RFP, then they should have an expert do it.

After they've paid for the blueprint, it is indeed theirs to use as needed -- which may include offering it to the competition and having them bid on it. I actually point this out to my clients. Some of them even do that. I've never lost a bid this way though. Clients by and large care about their rapport with you, your proven ability, and of course price. If they have those three areas covered, chances are they'll pick you for the job (in my experience).

[Kurt Knippel]

I just wanted to check it out so that we could make use of it. Propsal generation templates that are actually in use are good things to have.

[Ugo DI LUCA]

Know your buzzwords and what they mean...clients often don't know what ODBC, JDBC, XML, SQL, and other tech goop mean...bu tthey love to drop it in a meeting...and you need to be ready to fire right back. Also...a lot of companies have a "tech guy" who keeps the server running...but knows nothing about relational db. These guys often appear in meetings and like to grill ya...give you a hard time...gives them some type of superiority complex or something. Don't get into a spar with them...just talk data...the data is what is important...and if you aren't sure of the answer...just say you aren't sure...you have to see what they have...and keep the topic on the db.

I observed these 2 phenomenoms a few months ago.

Seemed they had downloaded the newly issued FM7 specs and read it more than I had myself at that time, speaking about the relationship graph advantages...

The "Tech guy" was the funniest of all of them, speaking about XXL all over the meeting. May be I'd buy him a T-shirt at the end did I thought.

I didn't get the job, and the Tech guy no longer works there, so no fear they might show up here for some lurking (I'm sure they did actually pick a few ideas from here).

Really, it seemed as if you were in this meeting too. Just so funny afterwards to read these few lines. So true.

Thanks for the rest of the ideas guys anyway, as they migh help in the short run. By curiosity, has anybody kept Sharka's file as the link doesn't work anymore ?

You can use my mail adress if so [email protected]

Thanks.

[bruceR]

" This bidding solution in Filemaker...is this something that you would be willing to share?"

Here's a product I like: Doc_Builder:

http://www.thedatabasefactory.com/web/pre_fab_software/doc_builder/about.html