This is Part 3 of our The Life of a Project Series.
There are two very popular starting points for projects – each is very important. Often, our initial meetings with a client generate both an outline and an estimate. There are times when an outline is not necessary (as in the case of this recent project) and there are times when an estimate is not possible because the scope of the project is too undefined.
At another point, I’ll discuss outlines – a pet peeve of mine because too many technical writers skip it and then wonder why the client had different expectations. For now, I’ll explain that while an outline was unnecessary here (the client has already created the outline from the requirements document), an estimate was something they wanted.
There are many factors in estimating how long a project will take. There are many resources on the Internet to assist you if this is your first foray into the concept of estimations. What I will do is offer the following tips:
- Have an SME show you the product. When it comes to learning about the windows and functionality, go to the source. The sales/marketing department is great for giving you a sense of the positioning of the company, but not for an adequate walk-through of the product.
- Take your time. Count the windows and menu options and calculate how much text you need to write for each one.
- Don’t forget the extras. The table of contents, index, appendices, and layout are “extra” sections that need to be added. You may not need an expert to walk you through these sections, but they take time.
- Include a buffer for your project. There are so many unknown factors that can suddenly emerge – additional review cycle, more features, etc.
- Be prepared to walk away. There are clients who do not have reasonable expectations. The “I want it yesterday” is still very common in the industry and rarely do startups, for example, understand how long things will take.
About this project:
When we first sat with this client, we noticed right away that we would be dealing with very pleasant people. That was something we appreciated. We also understood that although they had worked with technical writers in the past, their expectations here were not realistic.
At a first description, I estimated the project would take 40 hours – I wasn’t confident enough to commit to this amount because I felt there were many items left vague and undefined. There were several sections that had not yet been addressed; more that had only partially been considered.
When the main engineer heard 40 hours, he announced it should only take 20. This is where diplomacy comes into play. Rather than express supreme doubt, I simply agreed that were HE to write the document with his knowledge of the product, it is possible (though I highly doubted it) that it could be done in 20 hours. In our case, I explained, I didn’t see it getting done in less than 40.
Even then, I warned the client that it could easily take as much as 60, and I wasn’t even sure about that. We settled on an initial purchase order for 40 hours with the clear understanding that they expected it to take more.
In most cases, WritePoint is able to pin the project down and not only make a realistic estimation, but even work hard enough to beat it. It becomes a challenge for us – one we don’t like to miss. In this case, the final project was delivered in over 120 hours.
It’s important to go back and identify why – for ourselves as well as for our clients. In this case, luckily, it wasn’t hard to identify key fail points. At least 10 hours was lost right at the beginning because we were given the one document (the wrong one) and told to begin. Meanwhile, the company was continuing to work on the right one. They were sending us updates, some of which made sense, and some of which did not. But we were working off the wrong version – doomed from the start.
Once it was discovered, I think we agonized more than the client – who accepted the blame and gave up the new information. In one case, we were given three different sets of instructions. Each time, we changed the information through out the document according to the latest email. When we got the third email, we stopped and wrote to the client asking for clarification. We explained – you told us to do A, you told us to do B, and now you are telling us to do C. What should we do? The answer was to go back to what was…more time wasted.
The sheer volume of information that was included was a surprise to everyone, including the company. As they were still passing us information a few hours before the final deadline, the increased hours came as a surprise to no one.
So, we get to the final lesson. Had the company insisted that job take 20-30 hours, even 40 hours and required us to offer a per project price based on this amount, we were prepared to walk. In the early moments of the meeting, this was discussed. And I explained our simple theory – I do not want to work for free. I do not want our writers to work for free. And, I do not want to charge my client for hours we did not work. On a per project basis – at least one of those three things is most likely going to happen.
We were prepared to walk away rather than risk committing to an estimate that was the epitome of the concept of a moving target. Luckily for all sides, it was clear to everyone that the estimate was a best guess, and only a guess.
Dealing with these engineers and management remained, throughout the project, one of the most pleasant and comfortable experiences I have ever had. They were there with us – on the long and impossible nights we worked on their document. They appreciated the fact that our business hours did not end at 5:00 p.m., or 6:00 p.m., or 2:00 a.m. for that matter.
See Part 4 in the series: Outline the tasks and the contact people