Here’s a look at where you’re running: You’ve received a brief request from a stakeholder about a new project. This has been given top priority by your manager and so this is the next project that you will start to see.
Before you schedule your first meeting with the business sponsor to get some more information so you can start estimating requirements, and create a business analyst timeline, your project manager will walk over to your desk and ask you how long it will take. Not sure? He thinks 40 hours sounds like enough time, so shall we go ahead with that assumption?
Your blood pressure has risen a bit. You take a deep breath. You re-read the stakeholder request.
You have no idea how long it would take you to leave it alone to define the detailed requirements documentation for this project. In fact, it’s a new stakeholder group and a new system you’re not familiar with, and the last time you heard that, the developers of that group expected business analysts to get quite technical with their requirements.
The headache starts.
What do you do What? To be able to Do you In 40 hours?!?!
You cannot provide a requirement estimate and timeline unless …
What I will do in this situation is first clear to the project manager that I will not be able to provide a reasonable estimate and timeline until I understand a few more things about the project – especially the opportunity for stakeholder requests and some expectations about my role for this new team. Will. I will then give a set of steps and a target date for obtaining this information and providing a plan.
This is not an answer, but it is a reasonable suspension. There is still a lot of work to be done.
Following the business analysis framework we teach at Bridging the Gap, I will schedule a meeting with the initial business stakeholder to ask a few questions about the request, identify who the stakeholder is, and measure how he or she has previously worked with business analysts. I would like to ask the main developer of the system to have lunch and discuss its relationship with the previous BA and share some of my concerns about being technically necessary.
I will confirm my stakeholder list with the project manager, also take the time to update him on my progress and if my target date is still reasonable for actual estimates, and then schedule a meeting to discuss the initial business objectives. I will confirm what I have heard from stakeholders about the project with the Prime Minister to make sure I am not closing the track.
But I still wouldn’t make my guess. That 40 hours could still hang over my head and, in fact, it could be a quarter of the path used at this time.
But I’m getting closer.
Start to get closer to estimating a reasonable need
After discussing business objectives, it is clear that there is a pressure and a narrow need. I’m feeling good about the project. Everyone seems to be on the same page. I met with the main developer to discuss the problem and he came up with some possible solutions. I am sure which requirements package will work best for the developer and how he wants to proceed. It turns out that as long as I find the functional requirements clearly less, he can accept the technical specification.
We’re cranking.
The next meeting is to discuss the advantages and disadvantages of each solution approach with business stakeholders. They are motivated and choose the least complex option. I have everything I need to draft an opportunity statement. Since time is of the essence, I start working a little further and draft a BA plan. A guess and timeline is starting to emerge, but I’m not ready to promise until business stakeholders confirm the opportunity documents. This will happen at the next meeting and.
We’re off!
And indeed a business analyst is turning the need estimates into a timeline
Of course, the project manager doesn’t like my guess, which is about 100 hours to define the detailed requirements above the 25 hours I have invested to get to this point. Prioritizing my other projects and promising stakeholders, it will take me about 5-6 weeks to complete.
(Be sure to watch the video above for a walk-through of our Business Analysis Planning template that helps you combine the necessary estimates and the Business Analyst timeline.)
Although my project manager may not like my guesses, now we can have a real conversation about deliverables, expectations and my availability and adjust from the place of information, not guesses.
My headache is gone. I have low blood pressure. I’m still breathing.
>> Start your fast for success
If you want to define a credible timeline for your business analytics work and plan what you need to do to go against unreasonable timelines, you’ll want to learn more about the business analysis process structure.
In our free Quick Start to Success Workshop, you’ll learn how to avoid the most common problems new business analysts face and the step-by-step business analysis process to build predictable, consistent project success.
>> Click here to register for the free workshop today <
