I am a planner. I like to see what’s in front of me and understand what it will take to accomplish my objectives. I’d expect this is true of many business analysts. Our requirements are, in a sense, a plan for solving a business problem. But we also need to plan out how to create this plan.
That’s why it’s no surprise that there is a discrete task in the BABOK for planning business analysis activities. Its purpose is to:
“Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.”
This task is where we determine exactly what it is going to take to develop the requirements for a particular project.
Most often, I have done this by creating a list of deliverables to detail the scope of a project. For example, if requirements were to be detailed in use cases and user interface specifications, I’d create an Excel spreadsheet listing the names and descriptions of each use case and user interface specification along with other important information such as status and, when needed, an estimate. Then, this list was incorporated into the project manager’s schedule, at which point I would assign target start and end dates based on my estimates and the stakeholder resources I had access to. For most projects I’ve worked on, a spreadsheet of deliverables and a project schedule with timelines has been enough to track progress.
The BABOK reminds us that this task typically occurs more than once to address changing business conditions. I agree. In my experience planning, even in a relatively waterfall-like project, is an iterative process. As you develop requirements, you learn more about the scope and often need to revisit what’s possible within the constraints of the project.
I’ve also had shifts in methodology or approach change the plan. On one project, I began with a fairly RUP-based process. I had created a scope document and was part-way through drafting a list of use cases to organize the project requirements. Then we met with the third-part development team who proposed (er, demanded) we use their version of an agile methodology. Over the course of the next week, I reconfigured my plan, learning about how to create a product backlog and create user stories. I readjusted my estimates, although they were even more tentative now that I was working with a new-to-me methodology. Once again, I found myself planning to plan.
Don’t Start Your Plan From Scratch
My Business Analyst Template Toolkit includes a Requirements Development Plan and Use Case List Template that can help kick-start the planning process for your next project (without going overboard and investing more in the plan for the plan than well, the actual plan).
This post is one installment in our Journey Through the BABOK with BA Stories series.
Anyone got a good resource for how we go about “estimating” even the business analyst portion of a project?
Business planning is probably a great time to start and new and valuable ritual as we head into the next year.
Pingback: Stop the project plan crash. You are the expert. | The Agile Radar
Hey Laura, BA Planning has been a hot topic here at Unum on my team. Most project planning is put together by the PM (with the whole project teams help)however, as BA’s we need to plan our work even more to our granular level.
A while back I posted a discussion on LinkedIn about BA Planning to see if anyone had any templates to share and I received a couple of responses. BA Planning is one of my BA skills that I would like to improve on. Looking at the whole picture vs just elicitating requirements and implementing them.
If you or anyone else has any templates to share that would be great. I would like to take the examples that I get, create one specifically to meet our needs, and share it with my team.
These are the topics that I’m looking for in the template:
Types of Meetings
Types of documentation
Which techniques are needed
What tools are needed
Who for stakeholders do we need to involve
Sign-off process
QA and IT support
etc.
Thanks for posting this and thanks in advance to anyone that can help.
Tammy, Sounds like your team is doing a great job of hitting the core issues and the sections you list are the great foundation for a planning document. Many of the items you list are contained as part of the BA approach (as opposed to the BA plan in the BABOK which is specific to the deliverables to be created). For my thoughts and reader comments on the BA Approach task, check out this post: https://www.bridging-the-gap.com/the-babok-might-not-be-a-methodology-but-the-ba-still-needs-one-babok-2-1/
You might also check out this post for some more ideas (and the webinar referenced if you are an IIBA member): https://www.bridging-the-gap.com/leading-through-transparency-the-value-of-a-requirements-management-plan/
For each section you list, you might start by asking, “what decisions do we need to make?”” and “what information do we need?” and “how is that information going to be shared/approved/etc”. Those questions should lead you from a list of sections for your document towards a structure for each section.
This is something a mentor could definitely help you with too. For more information on our mentoring program, check out this page: https://www.bridging-the-gap.com/business-analyst-career-mentor/
A few other thoughts:
-In addition to stakeholders, consider what other sources of requirements-related information are necessary. Are there documents, competitive products, etc that are also sources of requirements? If so, how will you obtain requirements-related information from these sources?
-In lieu of “documentation” you might clarify this as “deliverables.” Often we create documentation such as meeting notes that are not formal deliverables. Your plan may or may not need to lay out non-deliverable documentation that’s created as part of a project.
I look forward to hearing how your initiative goes. Sounds like a great career opportunity! Be sure to check back with us and let us know what you find.
Hi Laura,
I use a combination of tools – the Business Requirements Plan, the PMP, and my Outlook tasks. During weekly project meetings we also discuss our plans for each week and risks or issues to the dates.
As I am balancing three projects – I am switching tactics to an excel form of planning with dates that includes all projects so that I stay on the critical path.
Thanks for sharing Michelle! Great point that as an individual BA we often need not just a plan for a project but some sort of tool to keep all of our projects organized and make sure we stay current on all of them based on priorities and critical path. Sounds like you are planning on multiple levels!