How I Hired Freelancers Who Went Way Over The Deadline

Not so long ago I hired a team of freelancers to work on a project of mine.

Everything started as it usually starts. I found several teams, some through friends and some – through a website. I met with team leaders, we discussed my requirements, we agreed on time and on a budget. I picked the team that looked the most reliable to me, they rolled up their sleeves and started to work.

Beginning of work

On the first day we discussed the requirements again. I listed the requirements again and added a couple of new small ones. The freelancers agreed with everything. Even with the new requirements, said they, it was still plenty of time.

Great, thought I.

They started briskly, did quite a portion of work the very first day, and didn’t require much handholding. I went home pretty reassured that day.

Time passed by. I let them work in their own pace. Some days I didn’t see what they were working on. Some days they didn’t show up at all. More often than not, I saw them walking around drinking coffee and enjoying the view. Still, they kept telling me they’ll be on time, and I trusted them.

I didn’t care how exactly they were working, I only cared about the work being done.

First bug

Then the trouble started. Looking through the half-finished project, I noticed a huge bug. It was very visible, hugely annoying, and prevented the project to work.

I pointed it out to them. They were immensely surprised. Apparently, they didn’t see it before. Couldn’t I live with that? No, I couldn’t. Okay, they said, it’s a shame, but it’s quite some work to fix it. But we’re still on schedule.

First bugfix

Okay, how are you going to fix it, asked I. We don’t know, they told me. What did I think?

I didn’t think much, because I wasn’t very familiar with the details, and also I wasn’t an expert in that area. We brainstormed together. Then they brainstormed on their own. A couple of days the work wasn’t moving forward – everyone was thinking on the solution. Finally, the solution emerged, and the work continued.

Are we still on time, asked I? Yes, very much on time.

More bugs

Of course, bugs like that one happened not once and not twice. Features got forgotten. Features were done badly. Sometimes, I had to ask to fix the same problem several times.

Deadline is approaching

The deadline was approaching quickly. But the end of work seemed far away to me. Are we still on time? Yes, we are. I asked every day and got this answer every time.

I started to get more nervous and checked on them more often. More and more bugs appeared and features got forgotten.

Deadline

The deadline was on Friday. You might have already guessed: they didn’t finish on Friday. But they promised to work during the weekend, and they would finish 99.9% of the job by Monday.

After the deadline

You might have already guessed: they haven’t finished before Monday, on Monday or after Monday. Many features were incomplete, new bugs were appearing, and old bugs were being reopened.

The team leader was saying they have other projects to work on, and they couldn’t work with me full-time anymore. I was exhausted. They were tired. They worked weekends. I didn’t have the finished project. Our arguments were more and more heated. Everyone was nervous. When people are nervous and work overtime, they make more mistakes. When they make more mistakes, it’s more work to fix them.

They were defensive. I was angry. Every morning they told me it’s the last day. Every evening they said: goodbye, we’ll see you tomorrow.

Way after the deadline

Long story short. The project took almost three times longer to finish than originally estimated.

The budget was almost two times higher than originally estimated.

What a twist!

Sounds very familiar, doesn’t it? Those developers, you think. Never on time. Never good quality. Never without handholding. Always have to check on them. Can’t work by themselves.

Now, it’s time for a confession. The project was to renovate an apartment, the team consisted of renovation workers, and the original time was three weeks.

The real time was 8 weeks and 5 days.

What does this all have to do with software developers?

You have probably heard phrases like: “software developers are never on time”, “don’t trust a developer to estimate a task”, and many more.  Developers are being sneered at for not complying with time estimates, including the ones they made themselves.

But my theory is – everyone messes up with their time estimates. This renovation project is a very good example. And there’re many more. Projects go overtime and over budget all the time.

My point is – it’s not software developers – it’s humanity.

---

In my next article – “What is common between Opera houses and software projects” – I give more examples of delayed projects in different spheres. I also list the reasons why the projects get delayed and give advice on how to overcome this problem.