4-Task Solution for Estimating and Defending Your Analysis Plan-EN

How many times have you been told that you have two days to “get requirements done” when you know you need two weeks or even two months? Or maybe you’ve even been told that the analysis can be done “during the sprint” (or worse, not at all!) while the developers are designing and developing? We KNOW analysis can’t be skipped, but how do you justify the time you need to really get good requirements nailed down? Why do we even care?

In this article, I’ll give you my take on why estimating and having an analysis plan are important, some tips on how you might do it, and differences between traditional and agile approaches when estimating.

Business analysis is complex work. If you are in the business analysis role, whether you have the title of Business Analyst, System Analyst, Product Owner, or something else, you need to understand what has to get done in order to deliver business value and how long it will take to gain that shared understanding. Why? To accurately estimate your work in order to justify the time it really takes to get good requirements.

The payback of getting good requirements ahead of technical design and development has been proven over and over. If you look at studies from Standish, IBM, and other groups published over the past ten years, the cost of missing or bad requirements is huge. I’ve seen figures between 100 and 2900 times the cost to have found on the front end or in analysis. In other words, the cost of even one hour spent on analysis can pay back an organization between 100 and 2900 times! Wow! Even at the low estimate, that pretty amazing.

Why All the Push Back?

Business analysts and product owners are rarely allowed enough time to elicit, analyze, and confirm requirements. Why? One reason may be that we don’t ask for it, or maybe we don’t know HOW to ask for it.

I remember waaaay back when I was first working on projects (my kids would say in the caveman days), we had one long task on the work breakdown structure that was named something like “Gather Requirements”. To me, there are at least two things wrong with this task. First, requirements aren’t just lying around to be gathered up like leaves in your yard. There’s a lot that goes into analysis, as we all know. It’s not just an easy “pick those things up”. The word “gather” makes it sound easy!

Sidebar: if you need help with your gathering requirements, see our Quick Tip!

Second, we need to break tasks down to levels that are low enough so that we can estimate with relative accuracy. One large ‘lumpy’ task is very hard to estimate. An important business analysis skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to our project managers and sponsors.

Making a Case with an Analysis Plan

The best way to request and receive enough time is to build your case quantitatively. You must be able to explain to the sponsor or your team (or both!) what you will be doing during that time and why this work is important. My suggestion is that you develop estimates by breaking tasks down into small pieces. The smaller the task, the easier and more accurate the estimate for your analysis plan will be. This detail also helps justify your time.

How you break down the work depends, like everything in business analysis, on you, your stakeholders from whom you get requirements and with whom you build solutions, the project approach, and the nature of the project itself. Let’s study those factors and find some examples.

On a traditional project, I often build my analysis plan by breaking my work down by the capabilities, a.k.a. business processes, that I will be affecting on the project. In other words, what processes, functions, or tasks in the business am I going to help make better, faster, stronger, more correct, less costly, or easier? For example, if I were on a project for an online retailer, I might be working on a new solution for checkout. I would take that high-level capability, maybe called “Complete Customer Order” and break it down just a bit more. One of the lower-level processes or tasks involved in completing the order might be “Capture Order Item”. Now, I’m at a level that is relatively easy to start to estimate the effort for good business analysis for that process.

I start planning and estimating how I will elicit and communicate the requirements for “Capture Order Item”. In general, there are at least four tasks I will need to estimate:

1. Research the Problems and the Processes Involved

This could mean reviewing scoping, business case, or other previous documentation, creating a current state workflow, or interviewing stakeholders. Any or all of these might be appropriate. I need to estimate research time based on my elicitation technique, the stakeholders from whom I need to elicit, the availability of good information, and the time I think it will take to get the information I need from them. Let’s assume for this effort, that we plan and run a facilitated workshop with the subject matter experts. I might estimate 2 hours for this task.

2. “Think About” Each Process

I need to take all the information I learned in my research and put it together. Typically for me, this means modeling sub-processes, data, and/or business rules. In other words, this is where I do the true analysis needed to ensure we fully understand the current problem(s) and what we are trying to incorporate into a solution. “Thinking about” the process is where a lot of my good, deep analysis comes in. And this probably generates more questions! Remember that all of these steps are usually iterative in some way. I might estimate 3 hours for this task.

3. Get Approval on Direction

Based on the analysis that comes out of the second step above, I start to work with the business and maybe the technical team (if the solution involves IT) on evaluating the options we have for the solution. I might be asked to help with feasibility and/or cost-benefit of options. Once we pick an option, I need to ensure that the appropriate agreements or approvals are in place. If I’m on an agile team, this takes place within the team, but still needs to happen. All of this means gaining a shared understanding of what it will take to provide the business value needed. I might estimate 1 hour for this task.

4. Elicit the Detail Necessary for Functional and Non-Functional Requirements

This task is done once the direction is known and agreed-upon, based on the decision made in the third task above. The level of detail depends mostly on the people involved. I want to produce the details necessary for the:

1. business to understand what the solution entails and how it will function from the business perspective.
2. technical team involved to be able to design and develop the solution in a way that provides the business value expected.
3. quality or testing team involved to be able to ensure that the solution achieves the desired result and delivers the expected business value.

I might estimate 3 hours for this task.

For the tasks listed above, I have estimated 9 hours of work. If I do this for all of the processes we are affecting on this project and break it down to this task level, I now have some good ammunition to defend my time! In this simplified example, if asked to “do it in two days” and I have 5 similar processes to analyze, I am at 45 hours of work in my analysis plan. Now I can show all of the processes and the tasks involved and make that person who asked for just two days to tell me what to cut out of what has now been shown to require at least one week.

I recommend using our Estimating Analysis Time Template to track the tasks involved in each item, the stakeholders involved and their responsibilities, the estimated time needed and any dependencies.

Be sure to save this work from project to project too so when someone springs an unrealistic time frame on you, you have a basis for justifying your time on hand. This is especially helpful for like projects.

What is Different for an Agile Project?

Nothing! The timing may be different. The capabilities for your analysis plan would be broken down into user stories. The deliverables may vary. But do you still need to research and understand those user stories and the problem we are trying to solve? Yes! Do you still need to analyze user stories and ensure that we can handle the data and business rules (or acceptance criteria) required for that user story? Yes! Do you still need to make sure we have a shared understanding within the team? Yes! Do you still need to provide functionality expectations to the developers so that they can develop something of value to the business? Yes! Do you still need to get the stories ready for effective technical development? Yes! I may call the tasks and deliverables by different names, but it all still needs to get done.

Yes. It’s Worth the Effort!

Like any kind of planning, the effort to create an analysis plan itself takes time, but if you are constantly crunched and pushed to get your analysis done too quickly, think about breaking down your work into chunks so that you can estimate the work and have the quantitative ammunition to defend your work. It’s usually well worth the effort!

I also recommend checking out our Developing a Business Analysis Work Plan course for an in-depth approach and to practice building your plan!

To planning,

Ali