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.

 

4 thoughts on “Estimating the Impossible”

    1. Hi Tim – we build a disclaimer for each proposal we make. It isn’t generic, as it must be tailored to the situation, customer, expectations.

  1. Thanks – that is useful. As you say, communication is the key, but how to formalise the estimate up-front is not easy. I have had a case where they would only agree to a certain number of hours, and this was the project price. In the end, it took less because the developers could not supply all the items planned for the release. But I would have felt more comfortable if they had agreed to an estimate, and then paid me for actual hours worked.
    You mention *using industry standards*. Can you point me to them?
    Many thanks, Jacqui

  2. Hi Jacqui – even when a company agrees to a fixed price, an estimate can be very helpful. It can serve as a “check list” to confirm all parts have been delivered, for example. Personally, I create written estimates as often as possible – even if I do it on my time and even if the customer doesn’t respond to it. More than once, even on a fixed project price, I have pulled out the original estimate to show the client that we have reached, are reaching, or have passed some line drawn earlier.

    In more than one case, I have clients allocate more funds because they realize things have changed from the original plan we drew together. As for industry standards, there have been a number of studies done. We are running a similar study now on Techshoret. You can take part in the survey here: https://www.surveymonkey.com/s/FJVV59Z

    We’ll be publishing the results in the coming weeks.

Leave a Reply

Your email address will not be published. Required fields are marked *