Let’s image a pretty common situation. You’ve just found a client who needs you to do a small job. You are pretty happy, because you know that it can be ready on a week or two and you are dazzled with the vision of quick money. So you talk to the client on the phone and send them an email with a short description of the project. It’s a small one and you don’t want to waste a whole day on writing the specification, preparing wireframes and going through the approval process with the client. But…
You agree the project description (not specification) and the costs with the client. Obviously, you both understand what is going to be done and how much is it going to cost. You start noticing some unusual patterns in the project lifecycle when you have the design ready. There are more revisions than usual and you start hearing things like “I expected”, “I thought”, “what I wanted was”. The project is delayed for a few days, but the design got an approval from the client and you are ready for the development. The situation isn’t crucial, but the client is starting having concerns.
The programmer is done in a few days and you are happy, because it’s faster than the plan and you have a chance to deliver on time. You start testing the project and you can’t believe what you see. A half baked product, which you definitely can’t show to the client. So you decide to send the programmer the description once again and add more detailed explanation. He obviously doesn’t like it, because it’s much more work and he considers it out of scope. Obviously, you don’t want to pay for it. You think, that he should think of some details and add them automatically. It takes a day or two to figure this out and another week of programming, because the changes actually take more than the initial work. You test the project again and show it to the client, apologizing for a delay, explaining that you wanted to make the project perfect. The delay is now one to two weeks, what makes the whole production twice as long as agreed.
And then it comes. You get the list of missing features from the unhappy client. You know, that it’s going to take a lot of time (and cost you money). So you start arguing with the client and explaining them that they want out of scope changes. After week of arguing and threatening of not being paid anything, you decide to compare the requests to the original description and look at the situation with client’s eyes. You realize, that the most of the requests really make sense. You know, that you have to finish the project, so you decide to do the most of it. It takes another weeks. So the client approves the project two months later than the original agreed delivery date was. Obviously, they ask for a discount. It makes sense, but you have already lost money on the project. The result?
- Unhappy client who will very unlikely give you another job.
- Unhappy programmer, who will very unlikely work for you on another project.
- Unhappy YOU, because you lost a client, programmer, money and a lot of time which you could spend on getting more clients and earning more money.
All of that happened because you were greedy and lazy to spend one day on preparing the detailed specification of the project and wireframes, which let the client understand the workflow of the application.
Turning two weeks to two months is bad, but you can recover from it. Imagine, what would happen with a bigger project. So what are the lessons learned?
- Talk to the client and write the specification for every project. Even if it’s a one day job.
- Stop the production and review the whole specification with the client when you start hearing “I though”, “I wanted”, “it’s obvious”, etc from the client.
- Don’t expect the programmer doing the work for you and specifying the product. They have valuable ideas and comments, but their main job is to do what the specification says. Nothing less and nothing more (especially when they are contractors paid for the project, not on hourly rate).
Is there anyone who hasn’t gone through such project?