Estimating the Impossible

Earlier today, I had a very enjoyable conversation with an Israeli company that works primarily in Africa. They want to hire WritePoint to write a document, one of many, we hope. The person with whom I spoke is new to the company and wants to improve the existing documentation. Amazingly enough, perhaps even close to unique, he isn’t in a rush. There are no firm deadlines – just a lot of documentation that he calls “Hebrew written in English” and “childish.”

We had our initial meeting in which we discussed what the company does, where it works, what it needs. And then, he asked for an estimate. Estimate based on what? I thought to myself.  We spoke for a few more minutes and when we were done, I agreed that I would send him a detailed list of questions and requests. With this, we hope, I’ll be in a better position to give him the estimate he wants so that we can begin.

What happens when you are estimating the impossible? The best advice I can offer is twofold: get more information, and don’t.

Don’t estimate the impossible. You’ll almost always be wrong. Get more information; get a sense of what they want. At least, get a sense of the minimum they expect and commit yourself to do better. With an example in hand, you can probably give a fair estimate of how long it will take to write a similar document and then add extra time to fix it or make it better. The void, the unknown, will always be in what is not yet documented. These are the areas you must identify for yourself and for your client.

In this case, I worked out an outline with a bunch of assumptions and a list of questions and requests. I want to look at their existing documentation to see how much content there is. I need to understand if what is there is technically accurate. Even if it is childish, even if the document needs major reformatting and editing, we’ll be in better shape to deliver a document faster – if we know that we have a chunk of accurate information already completed. On the other hand, if most of what we get is not relevant or worse, inaccurate, we need to factor this information in as well.

Without question, when we give the final estimate, we will add two important sections:

  • Assumptions: based on these items, we have offered a quote. It could be that we are assuming (and trusting) that the company’s promise that the documentation is accurate from a technical point of view will save us time. If it turns out, somewhere in the middle, that there are whole sections that need to be updated, this will cost the company more. By clarifying this upfront, the company accepts their responsibility. We work very hard on the assumptions section – we want the company to know – now before we begin – what we are thinking. We want them to point out inaccuracies in the assumptions and more, we want them to work to verify that our assumptions are correct.
  • Disclaimer: in this section, we explain what would cause us to charge hours above what we estimate, what could delay delivery, what extenuating circumstances could bring. Again, here we would include instances where we might have to fix technical inaccuracies that we were told were correct. But there are many other disclaimers that might appear here as well. It is important for the client to understand that if certain elements of the project change, there may be monetary ramifications. While an assumption would include our estimate for the number of review cycles or how many reviewers are involved, or even which sections a document might contain, the Disclaimer section will include the results as well. We assume there are five components that are included in the solution; each requiring a specified number of meetings and pages. If suddenly there are six components and one of the original five has undergone dramatic reconfiguration after the writing has been done, we cannot guarantee that we will deliver the final document at or below the original estimate.

Finally, in our estimate, we often explain the calculations by using industry standards. More often than not, we beat the industry standard in Israel in terms of hours per page but as we do a calculation, we include estimates based on the complexity of each section, the expected length, etc. Here too, the client is able to see the document we plan to write.

Our recent The Life of a Project series detailed how one project was handled. This was a great example of impossible estimations. Initially, our client estimated 20 hours to complete the job; we estimated at least 40-60 hours. The final project took 120+ hours. By most standards, this would have been considered disastrous and the client could easily have decided never to work with us again. On the contrary, they’ve already been in touch with us about more work and we received phone calls and emails thanking us and praising our hard work.

The estimate is a key first step in communication with the client. If the lines of communication stay open, the client is right there with you as you document their product and they quickly understand where estimates (on both sides), might have been inaccurate. Often, the client will understand the role that misinformation that they inadvertently gave from their side led to an inaccurate assumption on your side. Further, by not identifying that mistaken assumption, they bear some of the responsibility for additional time the project may have taken.

Estimations can often be done to a fairly accurate degree. When estimating is all but impossible given the current information, laying out a clear documentation plan and adding detailed explanations of the things you assume (and the disclaimers), can save a project from disaster.

In life, in love, and definitely in technical writing – communication is critical.