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. Is this the case for you as well?
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.
Now it's your turn. Share an example of how you plan your BA activities. Do you use spreadsheets and project schedules or has something else proved a better choice? If so, what was the context?
This post is one installment in our Journey Through the BABOK with BA Stories series.
Related posts:
- BA Stories: The BABOK might not be a methodology, but the BA still needs one (BABOK 2.1) After 4 weeks of meandering our way through the BABOK,...
- BA Stories: Getting Elicitation Right – With Preparation (BABOK 3.1) It’s difficult to even think about being a business analyst...
- Journey Through the BABOK with BA Stories For the last month, we’ve been working our way through...
