11

I was talking with a co-developer.

He has a client that wanted to make sure that he delivers on time. The client wants repercussions for missed deadlines.

While I do not do freelance work, I couldn't give an answer.

So, my question is:

What repercussions do you (freelancers) agree upon with your client if you miss deadlines on your deliverables (aside from being fired)?

gnat
  • 21,442
  • 29
  • 112
  • 288
Teej
  • 221
  • 2
  • 6
  • 2
    He would be foolish to accept any penalties, at least without a get-out clause based around changing requirements. Task estimation is hideously inaccurate at the best of times, before taking into account change management. Basically. Run – Matt D Aug 20 '13 at 06:18
  • 4
    So the client would have a financial interest in having you to miss the deadline? Does not sound like a really good idea. This will only make sense if the client has also a hard financial loss when you are late (like in the example of MainMa). – Doc Brown Aug 20 '13 at 06:23
  • 2
    This seem perfectly acceptable to me. I am quite surprised by the comments. You expect people to pay for work, with either no deadline and no incentive to meet the deadline ? "Task estimation is hideously inaccurate" - it doesn't have to be. – NimChimpsky Aug 20 '13 at 06:28
  • @DocBrown the client presumably has a much larger finacial interest in meeting the deadline, hence paying for the work with a deadline. I find programmers dislike of deadlines and structure amazing sometimes. Imagine getting a new kitchen fitted and the shop says oooooo no we can't tell you when it will be finished, will just charge you by the hour. I'd run a mile from that. Programming is not qualitatively different to any other project. – NimChimpsky Aug 20 '13 at 06:29
  • 5
    If you're getting a new kitchen fitted, you will be quoted for the build as spec'd. If you start changing the cutting surface, the tiles, the faucets and the sink materials you'll be charged extra for both materials wasted, and time spent. It's easy to understand why you're charged in this instance, there's a physical relationship. Changing software requirements often doesn't come with this same understanding, and any contract which requires you to deliver X by Y where X is not nailed down exactly is asking for trouble. Things will change, being unable to account for that is foolish. – Matt D Aug 20 '13 at 06:48
  • This is more about business than programming. – Blrfl Aug 20 '13 at 11:15
  • none. ever. for two hopefully obvious reasons: it gives the client an incentive to sabotage the project, and it inevitably results in pointless he-said/she-said arguments. I generally do flat-bid work, in iterations, with signed-off test specifications. If for some reason I don't deliver on time (which is rare but happens to everyone eventually), I have to eat the extra cost - which is penalty and incentive enough! As an aside, the biggest risk is not changes, it's missed details and unstated assumptions that turn out to be important. – Steven A. Lowe Aug 20 '13 at 20:56

1 Answers1

25

One of the most effective ones: penalty by day of delay. This is also what is done for large projects, the penalty being sometimes thousands of dollars per day.

If a precise deadline matters (for example if one develops for Olympic Games a web app which will handle the broadcast of the event in 2014, the deadline would be the beginning of the Olympic Games in 2014), then the effective measure could be that in a case when the project is late, the company is not paid at all, and should also pay a penalty.

If such drastic measures are not appropriate, then the sole fact that a well-paying customer will leave if the project is late can do the trick.

Note for the customer:

  1. Many delays are the fault of the customers themselves. Causes can be multiple:

    • No SRS, but instead two paragraphs describing losely what the customer imagines being his needs (and of course, the customer don't want to pay for requirements gathering, considering this step a loss of time).

    • Coming two weeks before the final deadline and telling that it doesn't matter that the project was done in Java until now and used Oracle: it is imperative for it to be rewritten in Python and use MySQL, because the customer have read a magazine yesterday telling that those technologies are the future.

    • Coming with a fresh set of requirements at every meeting. Bonus points when those requirements contradict nearly every requirement given until now.

  2. Good communication is essential for a good project.

    Many other delays are due to the lack of communication. Practices where the customer has no communication whatsoever for months with the company and expects to be contacted only once the product is finished and polished invite a disaster.

  3. You get what you pay for.

    There are specific procedures which help keep the project organized, and actually, programming should take only 10 to 15% of time for large projects and 15% to 20% of time for medium projects. Those projects should also be done by people who know what they are doing.

    In practice, customers are not willing to pay $800/day an analyst who will create architecture and software design, and they don't want to pay for other steps neither. A newbie Albanian programmer who is happy to work for $50/day seems much more advantageous.

    Don't complain that the project is a disaster when you're only ready to pay for disastrous projects.

  4. Don't negotiate time required to do the job.

    I often encounter the discussions like that:

    Developer: given the requirements, I can deliver that in four months.
    Customer: it is impossible. The project should be done in two months.
    Developer: well, unless you cut out some features...
    Customer: I can't! All features are needed. Why can't you do the job in two months? I contacted an Indian programmer, a friend of mine, he can deliver that in one month and a half, and asks only half of the price!

    Negotiating time is a recipe for disaster.

  5. Know your priorities.

    Take in account the 90%-done rule. When the project is managed incorrectly, it is not unusual to see developers telling that they have done 90% of the project a month after starting the project. Then, a month later, it's still 90%. And a month later.

    This can have two causes:

    • When the project is not done correctly, i.e. 100% of the time is dedicated to programming, which leaves 0% for requirements gathering, architecture, design and testing, what happens is that programmers have no idea about the work to do, and they discover new tasks during the whole life of the project. Preparing the project would help having a larger understanding of all the tasks which should be accomplished.

    • When the customer is in hurry, it is not unusual for some companies to deliver fast some crap, then spend an enormous amount of time solving bugs. Some companies work only like that, which helps them staying competitive and say that they accomplished a given project in three weeks, even if later, they spent three years solving the mess.

    By putting priorities straight and requiring the project to be done correctly helps eliminating those companies from the list of candidates.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 3
    "Don't complain that the project is a disaster when you're only ready to pay for disastrous projects." Can I use that? This is a great post btw, and nicely sums up the risks from both sides. – Matt D Aug 20 '13 at 07:01
  • +1 Very good points. Also, a pleasure to read :) – Radu Murzea Aug 20 '13 at 07:02
  • 5
    @MattD: answers on Stack Exchange are licensed under Creative Commons Attribution-ShareAlike 3.0 Unported, so yes, you can. Also, feel free to read a related post on my blog: [Quantifying time and cost: Why do we always get it wrong?](http://pelicandd.com/Resources/Blog/QuantifyingTimeAndCostIntro), as well as the answers to my question here: http://programmers.stackexchange.com/q/158640/6605 – Arseni Mourzenko Aug 20 '13 at 07:04
  • Why isn't there a part 4, 5, 6 etc. to that blog post ? – Radu Murzea Aug 20 '13 at 11:58