ANSWER

As seasoned business analysts, we are often asked to provide estimates for how long a particular set of tasks might take.  If you’re working in an environment that is constantly trying to get more done with less, then you probably have also experienced the difficult task of having to rationalize your estimates for a large portion of analysis effort. 

Consider the scenario where you provided the following estimates:
80 hrs – Documenting the AS-IS Business Process Flows
150 hrs – Eliciting and Documenting Requirements
100 hrs – Documenting the TO-BE Business and System Process Flows
400 hrs – Writing Functional/Design Specifications
Total 730 hours

Later you find out that while management was developing high level guesstimates for planning purposes they ball-parked 500 hrs.

This is when the business analyst is now asked questions like…
Will it really take 150 hours to elicit and document requirements?  Can you do it in 100 hrs?  What about Writing Functional and Design Specs? Can you do that in 350?  Typically, the business analyst responds with an “I guess so” only to find out later that the work is behind schedule and they needed the full 730 hours, or more!

It can be difficult to defend the need for 400 hrs compared to 350 hrs when estimates are at such a high level.  For this reason, the business analyst should get into the habit of providing more detailed work breakdown structures and estimates.  By breaking each task down into more granular sub-tasks a number of benefits can be realized.

1. The level of error resulting from estimates tends to be smaller when more granular tasks are estimated.  Business analysts have a fairly strong sense of how long a 6 or 8 hour task will take to complete.  This is far different than estimating a 400 hour task.  How do you really know if it will take 400 hrs, or 360hrs, or 440 hrs? 
   
2. Management almost never questions estimates on very granular tasks.  Have you ever heard a manager look at a work breakdown structure with 50 or more tasks and say, will this task really take 8 hours, or can you do it in 6?  There are several reasons for this.  First, they have a greater level of confidence in your ability to estimate a small task.  Second, all they will save is two hours.  That’s nothing.  By contrast, they see a 400 hour task and think they might be able to say 40 or 60 hours.  Now that’s something.
3. Having a more granular work breakdown structure gets everyone on the same page as to the steps involved to complete the work.  This may uncover dependencies that the team would not have noticed if they were only looking at the high level tasks.

A good rule of thumb is that no single task should be greater than 40 hours when estimating.  And if you know that your management has a habit of pushing back hard on estimates make sure that no single task is greater than 20 hours, with most being less than 8-12 hours.

Of course, estimates can and should be re-evaluated as work is completed and you move from one stage of the analysis process to another.  Much more will be known once the AS-IS process flows are documented and the elicitation and documenting of requirements is complete.  At that time the remaining work can be re-estimated and decisions made as to whether all requirements will be implemented or whether work on low-priority requirements will be postponed.