Live and Learn? Need advice...

[JRepici]

Hi all,

I have a dilemma...

Can anyone help me figure out how to avoid the following?

Polly (name changed to protect the innocent) calls me up and asks me to do some development work for her. It involves RSS and other forms of syndication, which she knows little about (other than all her content clients are clamoring for it).

We begin working together and she tells me she has cancelled her other prospects for the job, including her job request at elance because she has decided to go with me. She says she is looking for a working relationship with someone who will not only build the application for her, but also teach her what she needs to know about RSS and other relevant technologies.

We begin working together in earnest and I spend a great deal of time with her, setting up example applications on my site and explaining what she needs to know to help me nail down her requirements.

She calls me on Saturday (twice) and again on Sunday. During that weekend we work together on requirements acquisition for a number of hours. This work is to give her an understanding of the issues, and to turn that understanding into a real application brief and estimate. All the while, she repeatedly makes a point of telling me how glad she is that she has decided to go with me for the development and that she has made her choice. She shows me the text of an old elance RFP which was meandering at best.

Then, Sunday afternoon she emails to ask if I think my estimate will come in under elance estimates. Along with the email is an attachment of a new, concise, well-written and cogent outline of the project, which she was able to write as a result of our "relationship", and which she will be posting on elance after all.

Now, reading elance comments about her I see that all the kids there like to say how she comes prepared with concise specifications describing exactly what she wants. Not too hard for them to charge $25/hour to code the project when all they're doing is following someone else's requirements and spec work...

Ok, so I probably made a mistake here...

My problem is I'm having trouble coming up with rules-of-thumb and other "lessons" from this that will help me avoid it in the future. The 7.5 hours of time spent on this requirements and spec work would be easier to eat if I could come away with some extra understanding of how to prevent giving away such services going forward. So:

Question: How do I avoid doing this in the future without turning away possible new prospects?

John Repici

[Wassercrats]

she repeatedly makes a point of telling me how glad she is that she has decided to go with me for the development and that she has made her choice.My first thought is SUE THE B..... I stopped thinking after that.

In the future, get stuff in writing after a certain amount of consultation. If someone promises something, they should be willing to put it in writing. Maybe try to speed up the "requirements acquisition" process.

[Rich]

Question: How do I avoid doing this in the future without turning away possible new prospects?
Well, the short answer is you can't. What you should have done is charged her for your time to help develop the requirements document. Some people (and she sounds like one of them) will not give you the job to just define requirements, so this is why my answer says you will turn away some new prospects. However, if you continue to do "free work" you will continue to fall into this trap.

[JRepici]

Thanks for your replies guys.

Wassercrats,

The first thing I did was go back and look at her emails. It seemed clear she had planned to do this because the only time she ever made a commitment was on the phone. She may have made one in IM's but I don't save those so couldn't go back and look (that is one change I have made in response to this).

This was a long requirements phase mainly because she was so clueless about the subject matter her clients were clamoring for. I tend to be what the M3 crowd (XPers) refer to as a Big Design Up Front developer.

Rich,

That is the conclusion I'm coming around to. I have set up my charges based on coding time, with the actual design work usually a (free) loss leader. This works fine for local clients I can drive to, but the phone clients that come in over the internet will need a more realistic approach to cost issues.

Is it better to send a few good prospects away than to do free work for a few bad prospects? That is the crux. Like you I lean to the former because the other way would really just be making good prospects pay for bad prospects...

That's a very distasteful notion.


John Repici

[Andilinks]

We begin working together in earnest and I spend a great deal of time with her, setting up example applications on my site... You might say or imply that you are incorporating "proprietary elements" into the work.

There probably aren't too many people as devious as Polly, so telling a fib like this to test a prospect's sincerity may be too much under most circumstances.

But maybe after being burned once you need some device to reinstill your faith in prospects.

Or better yet, develop some genuine proprietary elements. :)

Andi

[Chipmunk]

John, sorry to hear about your experience!

Have you made any attempt to get paid for your time? If I understand the situation, you did provide some sort of "deliverable", which you solely own. It doesn't hurt to ask, and you could (very) gently mention reputation (you indicated elance has a ranking mechanism). Even if you can negotiate a partial payment, that's better than nothing.

Is it better to send a few good prospects away than to do free work for a few bad prospects? That is the crux.
Personally, I find coding fun (yeah I'm an :) XPer), and mind-reading/extraction-of-specs very not fun, so I always charge full rate for everything. I can see doing initial negotiations (less than an hour total) "off" the clock, but I can not see any legitimate reason why a "good" prospect would not be willing to pay for development of specs. If they want "free" work up front, then I do not consider them a good prospect. Others probably have different opinions and experiences.

After a project is done and paid for, I often do some free phone support, mostly because the time overhead for billing isn't worth the hassle, plus they've :) earned some goodwill.

Good luck!

[JRepici]

Andi,

I was a bit angry about it at first, but even as I was looking through the emails I realized there was nothing to be done to go backward and change what happened (not without throwing good time after bad to paraphrase).

It really very quickly became about debriefing. That is, determining how to best adjust practices so that it would minimize time lost on this going forward. I usually include my own library grade functions and other elements, which I license on a per application basis, but always as a deliverable within the formal contract.

What I find very interesting about yours and Chip's suggestion is to do something up-front, early on in the relationship that insures I get paid for the design work. What might work here is some short, easy-to-follow contract (perhaps a page or two and combined with a mutual NDA) that could be faxed and signed quickly.

Not the entire specification agreement but just something that states there is value associated with the consulting work that must be paid if the resulting development contract is not awarded to me. This would have to be a very discreetly written agreement. Don't know if I've got that in me.

Chip,

At the risk of appearing to practice one-upmanship (the purest form of American culture don't you think?) I have to say I love all aspects of programming. Each facet of the practice has its own rewards and challenges, and its own unique form of flow. Variety is the spice of life!

I'll agree with XPers that coding has the most intense form of flow. Probably because it requires so much time to get into and is the most mentally consuming. Coding was the first time I ever experience flow (as I'm sure is true for most programmers) and its the closest thing to an Out Of Body (OOB) experience you can get. It is such an altered and incredible state, that if I didn't already have a religion, I'd probably end up joining with you in the XP "movement". (:) cheap shot I know)

Requirements acquisition is different than coding. It is a shallower form of flow but makes up for it by being the only form you can experience interactively with other humans. It is probably what people once really meant by brainstorming, but the term brainstorming has been utterly diluted by corporate boardroom lackeys. M3 tries to make up for this by insisting on pair programming, but this is the worst of both worlds IMO. It's like mashed potatoes without the bones; never allowing the complete depth that comes from lone coding, while insisting on maintaining the same bland working consistency all ... day ... long ...

Design work on the other hand can be just as intense as coding and can also be nearly an OOB. It is different than the flow you enter when coding though. It is more forgiving, allowing you to disperse your thoughts more at the expense of some detailed grasp of individual items, while letting you mentally travel back and forth between high and low levels of abstraction. Hacking, is an integral part of design work, but like the worksheets on your tax forms, the stuff you deliver should never include hacked code (IMO, I know you disagree).


User and Developer Doc was the last and most difficult aspect of programming for me to develop a taste for. I've always known it was an essential part of programming but did it grudgingly. I now find the joy in it. In many ways, if programming is a symphony then Docs are still the dissonance, but a symphony isn't a symphony without dissonance.

Got off on a tangent there. My apologies to the topic police :police:




All,

I'm starting to formulate some good rules and suggestions. Thank you for your help.

1. Basic, non-threatening, low-intensity-commitment, starter-contract for quick fax when a phoned-in relationship shows signs of jelling (Wass..., Andi and Chip).

2. Prospects who reject any responsibility for the cost of design are NOT good prospects (from Rich and an XPer!).

3. Save IM's as well as emails and hard-copy correspondence (me).

4. The crux: Trust must be earned. Once some mutual actions have ensued the formalisms can be relaxed, but if you don't know someone... Well, you just don't know them (Andi, and all).

5. One attribute noticed in hindsight about Polly: She always wrote to ask me to get on the phone. Some are just more comfortable speaking voice (I imagine there are differences between genders here). Should I get red flags when someone is constantly asking to "talk"?


Have I missed any actionable items?

John Repici

he-HE said . . . "actionable"
(there's a term Dogbert would be proud of).

[hobbes]

Coming late to this, but in general if what the client is looking for is at all complex or ill-defined and will require more than 1-2 hours of time invested to just develop a proposal, then work out with them that you will charge X/hour. It's not as if they'll end up empty-handed for the $ as they'll have a concise requirements and possibly design document. Up to you whether to waive the fee if the client accepts the proposal.

In this particular case, you may want to consider just invoicing her for your time and see what she does...

Obviously if you're dealing with a very large client and/or responding to a formal RFP, you may have to consider up front costs a loss leader.

[Wassercrats]

If that woman was willing to make a decision based on a per-hour quote, why did you need to get into the requirements aquisition stage before there's a contract? Let her give her bad description of what she wants and if seems like you could handle it, give her your hourly fee, then let her sign, then you could work out the details for no charge, knowing you'll be paid for the programming.

It's more complicated if she also wanted an estimate of how long it will take, but I would just give her the best estimate I could based on what she could tell me. If she ends up wanting something different than what she described, that's her problem.She says she is looking for a working relationship with someone who will not only build the application for her, but also teach her what she needs to know about RSS and other relevant technologies. I spend a great deal of time with her...explaining what she needs to know...I think some of that explaining should have been post-contract. I don't think she expected to be taught much before she hired you, but you were obviously willing.

[Chipmunk]

First the :) business stuff (then some friendly XP stuff):

Excellent postmortem! In cases like this where someone clearly was malicious, the healthiest things are to write off the lost time, and analyze what you can do to prevent a repeat occurrence.

I've been lucky in that most of my solo and group freelance stuff has been thru referrals, so it's been easy to be direct about what things cost, and not do any upfront part "off" the clock. I have had bad luck in some larger projects, but had always taken sane legal precautions, so was able to recover most, though once it took a collection agency (was about 14k$ so was worthwhile).

Perhaps I'm unclear on things, but it does sound like you provided some form of "deliverable", and that it is your expectation that she will be putting that (probably modified) on elance for the purposes of hiring someone cheaper to do the rest of the work. If that is so, then you have a lever (copyright infringement) to negotiate some sort of payment. If she uses something you created without paying, then she is stealing. You may not feel comfortable with that, but I know that the "7.5" billable hours you mentioned probably cost you a lot more total time, and certainly grief. If she refuses to pay for your time, which she initiated, can you put in a warning to others thru elance? I understand if you want to wash your hands of it - that probably is the most time efficient thing to do.

On the phone point, I suspect that was an intentional con on her part. One tip I was given by an oldster many years ago, is to follow up every phonecall with an email summarizing the call. If you're feeling :) particularly paranoid, blind-cc it to a third party email account, such as Yahoo. Once trust has been built (on payment history, etc), you can relax your style.

[Andilinks]

ummm.. I had a chance to think about my earlier answer while working out.

There is one crucial defining moment called "closing the sale," when prospect becomes client.

That is the moment when you should introduce the "short, easy-to-follow contract." call it a pre-contract...

Defining the moment when sales pitch becomes client relationship keeps down the cost of selling and is exactly your dilemma with Polly.

Before you introduce this or any contract during the sales pitch you need to drop subtle hints about it, which are known as a "trial close."

As soon as the prospect is receptive to one of these hints, BAM! pull out the contract, if the prospect appears to balk pull back the contract and continue the sales pitch but make it plain that nothing really valuable passes between you until the contract is signed.

Andi

[Chipmunk]

Now, :) on to XP:

John, I was smiling (positively) throughout your excellent post, and don't worry, I wasn't offended at all - we both put in explicit or :) implied smilies in our postings, and you spoke eloquently and passionately about our craft!

For me, the two biggest thrills of computer programming are :) getting the machine to do exactly what I want, and providing users with tools that do exactly what they want and/or need! When I started out, it was very much a fun joust against and with the machine, but after a few years, that became less and less of a challenge. Gradually I realized that the machine is completely knowable, and thus that challenge is always finite and masterable. Providing the user with the best software for them is never masterable, so is the worthier challenge.

What appeals to me about XP is its emphasis on rapid prototyping, and frequent small customer/user-centric iterations. XP is often portrayed as a gonzo hacking methodology, but what it really is, is a process that puts the user at the center of everything. Yeah, it often means we do a bunch of gonzo hacking, but in a :) disciplined, committed-to-the-user manner! The main truism is acknowledging that neither we nor the enduser can know exactly the final form of the software, so we spend more time with the user, extracting the essence of what they perceive their needs to be, then quickly build something stable that fulfills many of those core needs (and contains many of the developers' ideas), give it to them, let them hammer away productively, then sit down for another discussion (with the current software so we can refer to it), which is much more fruitful because both the developers and users know more than when we started.

Humans grow and learn thru experience. XP acknowledges and embraces that.

I said in my previous post "mind-reading/extraction-of-specs very not fun". With XP, I don't try to mind read, rather I provide a series of working products, with each one being an improvement based on what the users and developers have figured out together. There's less guessing, more communication, and a :) lot more fun. Before XP, I found requirements collection to be stressful, but in a true XP environment, requirements are fun. It's a blast at every iteration as the users see that they've been listened to, trust is earned, and they get braver about making suggestions and discussing the best way to do things.

In other words, :) come over and feel The Awesome Power of The XP Force!

More seriously, I've seen a lot of "big shops" try to do XP, and they tackle it as a rigid set of unbending rules. They tend to fail. XP is often misused as an excuse to justify bad coding practices. It requires well above average programmers who can build very simple yet flexible class structures in the early stages (because we acknowledge that we do not know what we're :) going to need). Too often I see faux-XPers building convoluted top-heavy monstrosities, that then can only be hacked & kludged. That is not XP! My favorite XP coding idiom is "ya ain't gonna need it".

XP works best with a talented, enthusiastic, smallish development team. It does not require "continuous" pair programming, just acknowledges that portions of projects are better done by two, and that some form of continuous peer review is vital. Most of my group's work is done solo (we're a virtual software creation coop), and we're very productive that way, but we do frequent project reviews, and when we do get a chance to do in person pair work, it's about the most fun one can have programming!

[JRepici]

Hobbes

Agree.

On an RFP we can give them the sizzle without the steak (as it were). So it is a case of having to spend the time to do the design, but without giving it away. Also, if someone has taken the time to prepare a formal RFP, they've already done much of the requirements work and they are much more ready to pay for a delivery.

Andi,

Spot on! Can you recommend any good reading on this?

Wassercrats,

Ya, I screwed up. Almost ALL of that explaining should have been post contract. I chased the prospect to the exclusion of common sense. Dumb, dumb, dumb...

By way of explanation, not excuse: I was caught off guard by this one because she had committed (repeatedly) to going with me for the project verbally. I was taken in by a misguided presumption of innocence.

Also, I had no well thought out plan in place to deal with it. That is being corrected as we speak (thanks) :)



Chip,

I did a lot of stuff, including setting up demonstration stuff at my site, but she wrote the final design brief. If it were 14K (or even 3 or 4 k) I'd be all over it. It really isn't worth the aggravation at this point though. There is some Ralph Nadir in me that wants to chase her down and make sure she doesn't do this to others, but that kind of thing takes an obsessive level of commitment and, well ... it's not me.

Didn't mean to spark the XP vs BDUF religious wars... Ok, I'm lying, yes I did ;)

All: Thank you thank you thank you ...

John Repici

[Andilinks]

Spot on! Can you recommend any good reading on this? Not offhand...

This is Sales 101, literally. I don't have any specific recommendations, but sifting through Amazon reviews of sales texts would be a good start.

Andi

[JRepici]

Andi,

Thanks, I'll go take a look. I've had a Dilbertesque aversion to anything having to do with salesmen and sales departments for a good part of my programming life. That needs to change, since the Sales 101 stuff you presented made a lot of sense and was clearly stuff I need to learn.

John

...like a light shining down while a chorus is singing :)

[hobbes]

John (or anyone seeking business advice) -

If you're US-based, you may want to contact your local SCORE (www.score.org) Chapter. You can usually find someone knowledgeable and the advice is free. You can also get business counseling via email if you prefer. Many chapters will also put on workshops covering business/sales/marketing/etc. basics.

[JRepici]

1. Basic, non-threatening, low-intensity-commitment, starter-contract for quick fax when a phoned-in relationship shows signs of jelling (Wass..., Andi and Chip).

2. Prospects who reject any responsibility for the cost of design are NOT good prospects (from Rich and an XPer!).

3. Save IM's as well as emails and hard-copy correspondence (me).

4. Follow up every phone call with an email. (Chip) Should we follow up a days worth of phone calls with a hard-mail?

5. The crux: Trust must be earned (in the mean time use contracts). Once some mutual actions have ensued the formalisms can be relaxed, but if you don't know someone... Well, you just don't know them (Andi, and all).

6. Learn the subtle art of the close (Andi). Get help and information from SCORE (http://www.score.org/) (hobbes).

7. Include preemptive copyright notices at the bottom of all emails? (Chip)

8. Large G2000 or F500 companies may be exceptions. If high profile, widely recognized corporations don't come through with the contract we can at least get some mileage from any kudos they may utter while we work together. (Hobbes/me)

"oldster": I resemble that remark!

BAM! yeah!

resources:

TechRepublic
More about web page design and content consultants than software developers but might be useful.

Five tips to find and close deals with clients (http://techrepublic.com.com/5100-6333-5029770.html?tag=viewfull)
Client payment structures that get the check (http://techrepublic.com.com/5100-6333-1054789.html?tag=viewfull)
Five often-overlooked details to include in your project proposal (http://techrepublic.com.com/5100-6331-1051294.html?tag=viewfull)
Nurturing the freelance network (http://techrepublic.com.com/5100-6330-1051292.html?tag=viewfull)
Easing clients into your payment structure (http://techrepublic.com.com/5100-6333-1054790.html?tag=viewfull)

[Matt]

Wow, there are a lot of good ideas here. I find the pre-contract ideas presented by Andi intriguing and lots of other good recommendations are floating around as well. Andi, if you'd like to expand on what a "pre-contract" consists of, I'm all ears. The only thing I can think of is something like the "pre-contract" that a real estate agent may try to get you to sign saying that if you buy a house within the next x months, you'll use that agent. Are you talking about something like this?

I'd like to offer a bit of advice as well. First, it is difficult to tell whether the work you're doing to get a new client is going to pay off. You have to be careful about deciding where that cutoff point is. Some "prospects" are really smooth talkers who will try to trap you into doing a lot of the investigative work for them (at no cost before a legal committment is made)-- but I don't have to tell you that.

Here's a good example: "I have several detailed proposals from other firms, but I'd really want to use your firm. Can you get a detailed proposal to me within the next week outlining how you will accomplish xyz?" The other, more basic variant is simply asking a LOT of questions (more than is needed to get started on the project) and expect you to devote a lot of your time to them before any commitment has been made.

In both cases, it's relatively easy to nip in the bud. Detailed proposals and/ or prototypes shouldn't be created until after a contract has been signed. Explaining how things will work and what solutions you have in mind is part of the initial (free) consultation and you will have to exercise judgment on what is excessive (likely to vary based on a project's proposed budget). In my opinion, a contract isn't enough. I also recommend an up-front fee of some kind (we charge as assessment fee which covers the initial work that goes into getting a project started). This fee should be reasonable (not ridiculously low or high) and will serve as an excellent indicator of whether your prospect has any intention of becoming a paying client. That is, if your new client (just signed a contract) balks at paying an up-front $50.00 fee, I wouldn't bet on receiving payment for $500 or $5,000 worth of work. You must establish up-front that you're not doing this as charity work (some people really have trouble grasping that idea :dunno: ).

Regarding item #5 on your list, you shouldn't stop using contracts just because you "trust" a client. Contracts should be an important component of all transactions. A contract should be an indication that you are a trustworthy firm, not that you don't trust your clients.

Finally, here's a notice for e-mails that I like:
Confidentiality Notice: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it from your computer. Thank you.

[Andilinks]

Andi, if you'd like to expand on what a "pre-contract" consists of, I'm all ears. The only thing I can think of is something like the "pre-contract" that a real estate agent may try to get you to sign saying that if you buy a house within the next x months, you'll use that agent. Are you talking about something like this? They are similar only in that both are sales tools.

A pre-contract in this instance would be a "dry run" or a trial contract in that it would only cover the period leading up to actually finalizing the deal. It would be legally binding but its main purpose would be a psychological binding, a sales tool. The parties get accustomed to agreeing amicably, in writing and just working together. You could put anything you like into it, but off the top of my head I could think of things like out-of-pocket expenses, good faith, etc. The up-front proposal fee that you (Matt) mention could be detailed there. Like I said it's a sales tool, so put things into it that will promote the business and instill confidence.

edit, add: The up-front proposal fee requires a receipt, what better vehicle for binding other understandings but to use the pre-contract form as a receipt for the fee?

Speaking of good faith, the only contracts that I ever want to enter into are those that never go to litigation. But having a contract serves as a reminder of what was agreed. Memories about even the simplest of deals can change and disappear, what's written remains more permanent.

And of course in the worst case of bad faith, having the contract can give you the leverage to keep the other party honest and performing because it can be litigated.

Andi

[Andilinks]

Well the pre-contract would be a closing tool, like when a sales person asks, "will that be cash or charge?" You really hadn't planned on buying but the sales person is telling you it's deal-time. If the customer says, "oh I wasn't planning on buying," it is an opportunity for the seller to ask why and address the objections. If the objections can't be overcome the seller at least knows that it's a lost cause and that the customer is just jerking you around.

Pulling out the pre-contract is a trial close, it gives you some idea of how serious the client realy is. It is the sales interview equivalent of "wiil that be cash or charge?"

Andi

[JRepici]

Everyone,

Thank you for all these great suggestions and comments. I really appreciate your help with this guys.

-djr