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.”
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.