Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


How do you deal with management who constantly tries to reduce your estimated analysis hours?

Posted by Chris Adams

Article Rating // 34800 Views // 3 Additional Answers & Comments

Categories: Business Analysis, Systems Analysis, Leadership & Management, Project Management


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.

Chris Adams
LinkedIn Profile



Robert Merrill (uFunctional LLC) posted on Monday, October 5, 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.
Robert Merrill (uFunctional LLC)
Tim Willson posted on 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.
Tim Willson
atanasg posted on Friday, February 19, 2016 3:59 AM
I will politely disagree with Chris Adams methodology.
In 500+ hours analysis projects having to manage 70-100 tasks is nuts.

"My" assumption driven approach allows me to estimate infinitely big projects in less than a day and stay on top of execution at all times.

This is what I do:
1. Come with set of broad assumptions for the scope of the work
10 business groups, 8 major business flows per group in average; 200 requirements average per group; ... etc.

2. Come up with a set of cost assumptions
4 hrs elicitation per group; 4 hours per process; 4 hours per requirement ... etc; 150 senior, 100 intermediate, 70 junior BA; 15% operational contingency; 20% scope contingency ... etc.

3. Put together detailed visuals as how work is done (why 4 hours per process ... etc). This I usually copy paste form my prior estimation cause methodology seldom if ever changes.

4. Put everything in a spreadsheet with the formulas and present.
10 groups x 8 flows x 4 hours = 240 hours. ... so on so forth.

When they challenge me I offer them to select the "right" numbers themselves. It is just a darn assumption after all. "Oh you think only 5 business groups, OK ... ", and I document in the plan "John Smith, changes the proposed business groups number assumption from 10 to 5"

The result of this exercise in the last 10 years my estimates were seldom questioned. :) Nobody gets creative with the assumptions because they want no accountability whatsoever.

Mostly people nag about contingency % which I gladly change to whatever they want. My response is this "Guys, things go south from time to time, I all depends how comfortable you are asking your CFO for more money if things go south .. thats all". You can put 0% you can put 100%. Its contingency and it is not touched unless we have measurable deviation form the plan. Usually everybody is happy.

Then during the execution:
A. We find there are actually 12 business groups. Then I go back and say our business group assumption failed we need resource for two more 2x8x4 = 32 hours. "Did you stay true to the other assumptions so far?" "Yes" "Good, here's the money"

B. We find there is 8 business groups. I go back and say "Gosh we assumed 10, we need 8, we have 32 extra hours, shall we reduce budget or shell we move them to contingency?" So far the answer always was "Move to contingency" ...

Easy estimate, easy execution management, easy change control. :))

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.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC