Here’s a scenario you may have run into: You receive a short request from a stakeholder about a new project. It’s been given top priority by your manager and so it’s the next project you’ll begin looking into.
Before you can even schedule the first meeting with the business sponsor to get some more information so you can start requirements estimation, and building a business analyst timeline, your project manager swings by your desk and asks you how long you think this will take. Not sure? He thinks that 40 hours sounds like about enough time, so shall we move forward with that estimate?
Your blood pressure rises slightly. You take a deep breath. You re-read the stakeholder request.
You have no idea what it even means let alone how long it might take you to define the detailed requirements documentation for this project. In fact, this is a new stakeholder group and a new system you aren’t familiar with, and the last time you heard, the developers on that team expected the business analysts to get pretty technical with their requirements.
A headache begins to emerge.
What do you do? What can you do? In 40 hours?!?!
You can’t provide a requirements estimate and timeline until…
What I would do in this situation is first be clear with the project manager that I can’t provide a reasonable estimate and timeline until I understand a few more things about the project – most notably the scope of the stakeholder request and some expectations about what my role will be for this new team. Then I’d give a set of steps and a target date for obtaining this information and providing a plan.
This isn’t an answer, but it’s a reasonable deferral. There is still a lot of work to do.
Following the business analysis process framework that we teach at Bridging the Gap, I’d schedule a meeting with the primary business stakeholder to ask a few questions about the request, identify who the stakeholders are, and gauge how he’s worked with business analysts before. I’d also ask the lead developer on the system to lunch and discuss his relationships with previous BAs and share some of my concerns about getting technical with the requirements.
I’d confirm my stakeholder list with the project manager, taking time to also update him on my progress and if my target date for a real estimate was still reasonable, and then schedule a meeting to discuss the primary business objectives. I’d confirm what I heard from the stakeholder about the project with the PM to make sure I wasn’t getting off track.
But I still wouldn’t have my estimate. That 40 hours might be hanging over my head still and in fact, it might be a quarter of the way used up at this point.
But I am getting closer.
Starting to get closer to a reasonable requirements estimate
After the business objectives discussion, it’s clear there is a pressing and narrow need. I’m feeling better about the project. Everyone seems to be on the same page. I meet with the lead developer to discuss the problem and he comes up with a few possible solution approaches. I also confirm what requirements package will work best for the developer and how he’d like to be involved going forward. It turns out he’s fine taking on the technical specification as long as I get the functional requirements down clearly.
We’re cranking.
The next meeting is to discuss the pros and cons of each solution approach with the business stakeholders. They are motivated and choose the least complex option. I have everything I need to draft a scope statement. Since time is of the essence, I start working ahead a little and drafting a BA plan. An estimate and timeline begin to emerge, but I’m not ready to make a commitment until the business stakeholders confirm the scope document. That happens in the next meeting and…
We’re off!
And actually turning the requirements estimate into a business analyst timeline
Of course, the project manager doesn’t like my estimate, which is about 100 hours to define the detailed requirements on top of the 25 hours I’ve invested to get to this point. Given my other project priorities and stakeholder commitments, that 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 put together a requirements estimate and business analyst timeline.)
While my project manager might not like my estimate, now we can have an actual conversation about deliverables, expectations, and my availability and make adjustments from a place of information, not assumption.
My headache is gone. My blood pressure is down. I’m still breathing.
>> Get Your Quick Start to Success
If you are looking to define credible timelines for your business analysis work, and do the planning you need to do to push back against unreasonable timelines, you’ll want to learn more about the business analysis process framework.
In our free Quick Start to Success workshop, you’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.
>> Click here to register for the free workshop today <<
