You are happy, because you have just found a client, who wants some small job. You know, that it can be done in 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 a short 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 detailed 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 doing the design and you start noticing some unusual patterns in the project lifecycle. There are more revisions than usual and you start hearing things like “I expected”, “I thought”, “what I wanted was”. The project had delayed for a few days, but the design got an approval from the client and you are ready for the development.
The programmer is done in a few days and you are happy, because it’s faster that the plan and you have a chance to deliver on time. You start testingthe 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, he considers it out of scope, but 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 if 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 threating 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 other project.
- Unhappy YOU, because you lost a client, programmer, money and a lot of time which you can 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?
- 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 specifiyng 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 contactors paid for the project, not on hourly rate).
Is there anyone who hasn’t gone through such project?