Elizabeth_Larson_Head_Shot_CroppedElizabeth Larson, PMP, CBAP, CEO of Watermark Learning (www.watermarklearning.com). With over 25 years of project management and business analysis experience, she has presented workshops, seminars, and training classes on 4 continents. Elizabeth is the content lead for Scope Management for the PMBOK® Guide 5th edition, was one of the lead contributors to the PMBOK® Guide 4th edition (Collect Requirements), and was the lead author for the Planning and Monitoring chapter of IIBA's BABOK® Guide v. 2.0. Elizabeth is co-author of the Practitioner's Guide to Requirements Management: Requirements Planning and the CBAP Certification Study Guide 2.0. She can be reached at elizabeth.larson@watermarklearning.com.
AddThis Social Bookmark Button

Estimating the Business Analysis Phase of a Project. Is it Even Possible?

Elizabeth Larson

Years ago I worked on a large effort to reengineer a distribution center for a major retailer. We provided an estimate for both the business analysis work and for the entire project, which would involve the organization's first use of Electronic Data Interchange (EDI), new business processes, many software changes, and the purchase of new barcode scanners. The business analysis effort took far longer than we anticipated, and at the end of it we refined our estimate for the total project. When we reported the new estimate to the president of the company, he literally pounded his fist on the table and asked, "How did we get to this point? Why didn't we know sooner? You've already spent all this time on the project and what do we have to show for it? Nothing! Absolutely nothing!"

I have always thought of business analysis as the most ambiguous and the most fun of the project phases (by phase I mean phase, increment, or iteration). However, for many years it was my least favorite phase to estimate. I felt like I was guessing, simply pulling numbers out of the air. No wonder we were so far off.

Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience. So for those of you who do not have the "stomach" to spend the required time to estimate business analysis, here are some tips.

  1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small.
  2. As we progressively elaborate our requirements, we can progressively elaborate our estimates. We go from Rough Order of Magnitude (ROM) to budgetary (deliverables identified) to definitive (requirements defined to a low level of detail).
  3. It is helpful to use a variety of estimating techniques. When we're first asked how long business analysis will take, we really cannot be precise. We use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes two hours to model a business process and we have five processes to model, it will take ten hours to model business processes. Providing detail on each of these techniques is beyond the scope of this blog, however.
  4. I have found it helpful to brainstorm with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved.
  5. But here's the real key to estimating business analysis. Identify all the deliverables (work products, artifacts) you will produce during the business analysis effort. It is essential to first identify the approach you're going to take, whether plan-or change-driven (Waterfall/Agile). It is also helpful to use the BABOK knowledge areas to identify which work products will be completed. During the course of an Elicitation event, for example, we might send out an agenda (one work product), update our traceability matrix (another deliverable), create an "as-is" process model (another deliverable), and update our list of issues (yet another deliverable). Next we think of the tasks needed to complete each work product, and finally how many hours the task will take.

Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was reported the plan vs. actual of the business analysis effort regularly, rather than surprising him after months of work.

What a lesson learned!

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth's speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide - Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide - 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner's Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at elizabeth.larson@watermarklearning.com

Comments (12)Add Comment
...
written by Douglas Brown, July 07, 2009
I empathize with the experience related. Most failed projects fail before they start; it's only a question of whether you know it or not. But the level of detail in Para 5 may not be available in the expectation-setting phase (i.e up front). Some thoughts as to how to put a ROM onto the requirements phase would be very useful.
...
written by Aaron Gothelf, July 07, 2009
I agree with the lesson learned.
I call it "managing expectations" which means never surprise a manager with bad news!
And regarding the heading: "Is it even possible?" Well, we don't really have a choice: Every project must have a plan!

Thanks for a helpful blog!

Aaron Gothelf
A Real Business Analyst
www.aarongothelf.com/myblog
...
written by May Jim, July 07, 2009
Depending on the nature of the project, the business analysis phase of the project often raises policy questions which require management or the right stakeholders to make difficult decisions. These often eat into the schedule (or if the project decides to take a risk and assumes one direction, it may result in re-work).

To address this oft-encountered problem, I generally add an assumption that business decisions will be made within x days of submission. Business analysis effort and schedule really have a dependency on the timeliness of stakeholders making these decisions on a timely basis. But I agree, this is a difficult phase to estimate.


May Jim, CBAP
...
written by Chris Jack, July 07, 2009
This is a great article and really validates what our BA team does in my workplace. Whenever we are approached by a Project Manager and we get asked for an estimate the first question to them is always "What do you want in terms of deliverables?" Once we know the deliverable (whether its a Requirements Spec with or without use cases, a Traceability Matrix etc) we can then break down the deliverable into manageable and tangible activities.
...
written by Annie McGlade, July 07, 2009
I agree that understanding the deliverables is part of the key to successful estimation however if you estimate on the deliverables you will stil be out. As at the time of estimation you only have (probably) a 5-20% knowledge of the requirements, chances of accuracy are not good. If you estimate on the tasks you need to perform in order to arrive at the deliverables (your work plan - of which you have much greater knowledge and BABOK can help) you are likely to be significantly more accurate. Understanding your level of confidence and control (as per Cecilie Hofman's prevoious article) to apply your contingencies will get you a lot closer.
...
written by Neela Sagar, July 08, 2009
My grandfather was a decent architect, I used to hear him repeating these words while advising his juniors “Please waste as many papers you want before constructing but don’t create reworks for the constructed. Investing time on a Business Analyst will always add value to the product and give better results. The estimates given by a qualified business analyst should be taken as a minimum time for analysis and if extends the better. It’s the stakeholder responsibility to provide sufficient time to the business analyst to give better product. Time is directly proportional to Product’s Efficiency, Scalability, Reliability, Integrity, Security and Effectiveness. A business analyst improvises product with time and if the stakeholder limits then they need to be satisfied with the limited product.
...
written by Doug Goldberg, July 08, 2009
I've been struggling with this issue for some time. I've been able to obtain a general estimate through the process of use case inventorying and/or high-level needs and features extrapolation. By having either of these items, I can calculate approximately how many hours it would take to achieve desired objectives. Factors such as documentation, audits, resources, reusable content and SME availability can also be factored in to adjust the total.

I developed a spreadsheet to capture all this and have been toying with fine-tuning it for a while. It's based largely on analyst experience with knowing the number of hours to estimate and some other project estimated variables. In other words, it's truly an estimate...not a solid answer, but it can be continually updated as more information is attained.

All this is my attempt to get a handle on the fact that the projects are often decided upon and funded based on incorrect data before they ever reach my area. So, the sooner I have an idea that something is askew in the numbers, the sooner I can alert the PM and senior mgmt.
...
written by Naeemah Steward, July 16, 2009
This is a difficult task to estimating the business analysis phase, However I found it easier to estimate when the project was very familiar to old projects I've completed in the past. This is also based on resources available from the SME and Stakeholder and if there are any unforeseen obstacles involved in the process that might further delay the project.
...
written by cihan uslu, July 31, 2009
Hey Doug, can you spare the excel spreadsheet that you prepared if you dont mind, thnx.

...
written by Jennifer Smith, August 10, 2009
I have been asked to put general guidelines together for estimating (like for every hour in a worksession you can expect to have 1 hour outside the worksession documenting and following up on issues). Is there anywhere I can go that has these general guidelines? I too have put together a spreadsheet similar to what was mentiond by DougGtheBA but have never had the confidence that it is based on the right guidelines. Are you able to share the spreadsheet?
...
written by Colin MEGSON, September 08, 2009
An interesting article. In addition to the 5 tips I would add:
"Work with the stakeholders to identify each different business area impacted and the name of a representative for each area. Then contact each representative to find out how many people you need to meet in each area and whether they would prefer one-on-one interviews or prefer to take part in a larger meeting/workshop".
This gives you an idea of the number of interviews / meetings / workshops required. You are then in a position to work out how much time you need for each one, including preparation, travel time, writing-up your notes and general follow-up activites.

However, after reading many articles and reviewing various spreadsheets, I find that it boils down to personal experience gained from (many) previous projects.
...
written by Deb Turturici, May 18, 2011
How can I find out if there is any research in the area of BA % of time in project and BA staffing models?

Write comment
We love to see comments! However, please do not market or sell any products. Your comment will be removed immediately!
smaller | bigger

busy