Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In my experience as a freelance developper, I've had some difficulties with clients, whom insist on getting an estimate over flimsy requirements. They then expect me to deal with requirements changes, sometimes late in the project, and stick to that estimate.

Since I've never come up myself with some T.O.S. tailored for this situation, I ended up bound by a contract of a more general nature, which inevitably became unsasatisfactory...

Legal lingo not being my forte, I've been lookin for some publicly released T.O.S. to try to remedy this situation. Ideally these would be from an agile shop, under a licensing scheme allowing derivatives. This would help me lay out the contractual groundwork for a sane customer relationship, especially when dealing with changes.

share|improve this question
    
I don't think I quite understand what you're asking. Can you reword/edit your question or add examples to be a bit more clear? –  Ryan Hayes Oct 7 '10 at 18:07
    
I think he is touching on how to incorporate requirement creep / regular specification changes into contracts for a freelance developer working with clients. –  Chris Oct 7 '10 at 18:51
    
@Chris: indeed, sorry if my question is poorly worded, I'll try to rewrite it. –  julien Oct 7 '10 at 19:03

3 Answers 3

up vote 3 down vote accepted

Clients wanting you to be agile sounds more like clients that just want to change their mind (which is fine).

It seems like instead of:

  1. Get requirements
  2. Sign the contract with Julien to deliver X for $Y.
  3. Julien delivers X
  4. Julien gets paid Y

They want:

  1. Get very, very vague requirements
  2. Sign the contract with julien to deliver whatever they want (X? Y? X+Y? Z??), which is undetermined, and pay Julien $Y.
  3. Julien works toward ever-changing requirements.
  4. Requirements are never met.
  5. Julien never gets paid because they are never satisfied.

In this case I would simply charge per-hour.

Don't worry about fixed price or an "agile" contract. If you try to re-contract for every change, it will eventually become more pain than it is worth. Your best bet here would be to have a per-hour charge, and have them sign off on timesheets you provide on a per-week or something similar basis. This way both you and they can be as agile as needed while you have a better guarantee of getting paid. Just do great work and any good client will see your value. If not, you're better off just passing on the particular client if you have the opportunity.

For a more Agile approach..

You could, essentially, have a shorter estimate contract per-iteration. Each 2-week (or whatever time) iteration that you plan, have a shorter contract/amendment that outlines the requirements and estimates just for that iteration. Let the client change requirements, but only give them that luxury at the end of each iteration when you do the planning for the next iteration.

share|improve this answer
    
You pinpointed what's happened a couple of times, except I got paid, by working long hours on those requirements changes. The hourly fee seems indeed logical in these situations, but since the clients insist on getting estimates, I still need some contractual basis to reflect the fact that the estimate will not reflect the actual cost of the project due to flimsy requirements. –  julien Oct 7 '10 at 19:02
1  
Have you tried giving an estimate of X dollars, plus or minus something like 15%? That way, if the project takes longer, you get paid an additional amount. –  Jon Oct 7 '10 at 22:15
    
@Jon That's a good idea. –  Ryan Hayes Oct 8 '10 at 0:51
    
While this answer is very sound, I'm still hoping for something more akin to legal terms which you could actually base a contract on. –  julien Oct 8 '10 at 17:08

At a previous company that I worked for, we ran into this issue when delivering websites with lots of custom functionality. It sounds to me like you're suffering from client based scope-creep.

To handle this, we started aligning our own personal development benchmark with sample deliverable benchmarks to make sure that the client was satisfied with the way things were progressing. In addition, as Chris mentions in his post, contracts / T.O.S documents were written up and signed in person that explicitly stated what was included with each project and divided up into a per-benchmark basis. Each item was listed out with what it did and did not do, to the best of our abilities without being clairvoyant.

Be upfront about your charges and let them know what an initial estimate would be (which is your responsibility) but also give them the "additional rate", whether you determine it to be hourly or contract additions. When they start scope-creeping you, you can fall back to the initial contract which has that laid out and simply state your new estimate.

To summarize: All functionality described in contract, supply benchmark samples when applicable and get sign-offs on those too, be up front about additional rates for scope creep items.

share|improve this answer

Agile Team & Fixed Price Contract: http://www.infoq.com/articles/agile-team-fixed-price-contract

Fixed price contracts are evil - this is what can often be heard from agilists. On the other hand those contracts are reality which many agile teams have to face. But what if we try to tame it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.