In freelance software development, what kind of penalties should firms have when they miss deadlines? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

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)?

Answer 1

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.