Thursday, February 09, 2012

   Quick Links:   Articles     MA Blog     Community Blog     Templates     Books     BA Humor     Events     Jobs     Interview Questions         RSS Feeds

Interview Questions for Business Analysts and Systems Analysts

Careers



Business Analyst Interview Questions


Recent Interview Questions | Search | Subscribe (RSS)

How do you keep management from reducing your estimated analysis hours in order to fit their original high level guesstimates?
Question: How do you keep management from reducing your estimated analysis hours in order to fit their original high level guesstimates?

Statistics:Article Rating (9992 Views) (2 Additional Answers/Comments)
Posted by: cadams5
Categories: Business Analysis, Systems Analysis, Project Management


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.

Additional Answers/Comments
By rtmerrill @ Monday, October 05, 2009 2:16 PM
Here's another approach.

"Since I only have 500 h to work with, I don't think I can finish functional/design specs for the whole scope *as presently understood*. So here's what I propose.

"I'll document the as-is flows, and elicit and document requirements. That should put us at around 200-250 h. At that point, we'll all be less ignorant than we are now about what this is all about. I'll organize the requirements into stand-alonge chunks, that could either be implemented, or not, relatively independently. And I'll estimate the effort to finish business and system process flows and functional/design specs for each.

"It may turn out that it will all fit into the 500 h I have to work with. But if it doesn't, I'll look to you to pick which requirements have enough value to you to warrant complete specification while staying within the 500 h. It makes more sense to have 3/4 of the specification completely done than the whole specification 3/4 done, right?

"Or, you might decide to extend the 500 h based on a clearer understanding of what it will really take than we could possibly have now. OK?"

The fact of the matter is, estimates are estimates, regardless of how much detail you put in the WBS. Diminishing returns sets in. What's happening is that your *estimate* is being turned into a *commitment*. More detail in the WBS may help you negotiate, but what's really at stake is the relative importance of:
1. doing quality work
2. staying within the budget
3. not working a bunch of overtime (which certainly impacts #1and may impact #2 if you're an hourly contractor).

What really helps in situations like this is *project history.*

"Well, I can see why you'd want this to take less, but the this feels like Project X, and getting the specs done for that took around a thousand hours, and even then the developers and QA staff said there were too many holes. Do you think this is half the size of Project X?"

The only time I've ever "won" such a negotiation was when I had project history to point to.

By TBWillson @ Thursday, October 29, 2009 12:28 PM
I totally agree with the "granularity" argument. Breaking it down makes it more difficult to question, at the same time revealing some of your thinking about what steps go into the larger activity. Trouble is, it also takes more time and effort. If the initial ballpark (in this case 500) looks significantly less than the first level of decomposition (in this case 730) I would question the scope too and review other premises, like quality. Maybe the message of the 500 is more about what's good enough than it is about the best solution. Maybe we should consider a different work breakdown? I think that there should be an activity called 'review scope' after the first 80 hours as rtmerrill suggests, to make a "real" plan.

Only registered users may post comments.
  

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Select ModernAnalyst Content

Register | Login



 

Privacy Statement  |  Terms Of Use
Copyright 2006-2011 by Modern Analyst Media LLC