Anticipation takes many forms and covers many areas of software development:

• Anticipating Questions:
  • Have you described your software in terms the customer can understand?
  • Do they still want the software now they understand what you are proposing?
  • Have you been precise with your description?  Vague descriptions can lead to confusion and user disinterest or down right resistance to your software (if they think it is something it is not).
  • Do you have design documentation you can show the customer?
  • Is your design documentation actually understandable (by the user) and is it user focused e.g. work flows, user interfaces etc?  High quality, readable and concise design documents are an excellent way of allowing the customer to soak in the design in their own time.
• Anticipating deployment:
  • How is the user going to run your software?
  • Have you test run your software on the customer’s platform with a similar environment configuration before you attempt to roll it out?
  • What other dependencies will need to be installed to support your software?
  • How do you plan to push out those dependencies?
  • What sort of configuration management (CM) system is your customer using and can you harness it?
  • How will you install and configure your software?
• Anticipating integration:
  • How will your software integrate with the customers current work flow and application stack?
  • Does your software have dependencies are shared with other applications that could require those other applications to be upgraded too?  What extra cost would this introduce?
  • Does your application have specific operating system configuration requirements that could cause side effects for other application?
• Anticipating support:
  • How will you support your software post roll out?
  • How will diagnose problems on customers computers when you don’t have your development environment available?
  • Have you built any logging, metrics or error reporting tools built into your software?
  • Is there a help system integrated into the software and is that help system’s content usable and understandable by the target users?
  • How do you intend to upgrade your software or its dependencies in the future?
  • What sort of testing do you have in place to prevent upgrades breaking existing functionality?
• Anticipating retirement:
  • How easy would it be to remove your software from the customers application stack?
  • Do you have some sort of uninstallation script?
  • What about your applications dependencies: will any dependencies be orphaned and how will you remove them?
  • How tightly coupled is your software to the other systems it interacts with?  Can it be easily and gracefully decoupled?

You don’t need to answer all of the above questions but spending some time thinking about them and jotting down even single senence answer will help you anticipate potential problems.  It is never fun to have to tell a customer “I hadn’t thought about that.” after some show stopping problem emerges…

1. Write down your initial off the cuff estimation, without thinking about the estimation in any detail.
2. Think some more about the task and how long it could take if everything went wrong (within reason e.g, discounting riots, natural disasters, coups etc) then write down your new worst case estimation.
3. Think about how long it could take to do if everything went right and write down your best case estimation.

Since I first started performing the exercise on myself and team members when estimating I have noticed the following:

• That answer one and three are almost always nearly identical and that answer two is usually significantly different on average from answers one or three.
• Those planning based on estimates prefer accurate estimates to an immediate answer: especially as the immediate answer is usually significantly inaccurate.
• I don’t like causing myself massive stress by making inaccurate estimates that I then have to try and meet and I’ve met few people who enjoy self inflicted stress.
• It is acceptable to ask for some time to think about estimates, even if it feels awkward at first.
• Thinking about similar tasks you have done in the past can be a very useful tool to help contextualise your estimation, if you don’t think about previous experiences you can walk into the same miscalculation again and again…