I was recently working with a customer and a number of their business analysts on a specific project, when I asked them what they did around planning for their elicitation efforts.  Imagine my surprise when they said, “Nothing, that is what the project manager does.”  I probed a bit deeper, hoping that they did something around planning for their own efforts, but found that if they did any planning at all, it was minimal at best.  The total planning effort boiled down to the 3 lines on the overall project plan that stated:

• Gather Requirements
• Review Requirements
• Approve Requirements

Chapter 2 in the BABOK, Business Analysis Planning & Monitoring, lists out several different tasks that BAs should engage in order to plan their efforts.  But even more basically, the requirements effort needs to be planned so as business analysts, we approach the effort with thought and we know when we are actually done.

At ArgonDigital, we like to manage the requirements effort as a mini project.  While our activities and tasks can be put into the larger project plan, and I’m always happy to share with the project managers that I’m working with all of my planning artifacts, I find that many project managers do not want to manage and track at the same level.  And that is fine; after all, I’m responsible for this phase of the project, and I’m creating the level of information that I need in order to ensure that project is progressing appropriately.  This is especially important if there are several people working together on an effort.  I want to ensure that all parts of the project are covered, and everyone is progressing on their tasks– and if there are barriers to their progress, I need to remove those barriers.

I do several different things as part of my planning effort. The first task is to define the requirements architecture that I plan to use.  During this step, I learn as much as we can about the project and determine what deliverables are necessary. I also select which models make the most sense.  Different types of projects need different types of visual models, and we want to figure out what is necessary for the particular project at hand.

Next is to figure out who I need to talk to.  Looking at my deliverables and the organizational chart that I have created, I determine who the subject matter experts are who I need to talk to.

Now that I have these various parts, it time to start to put together a plan.  I estimate out how much time each model will take, what scheduling constraints I may have, and start to put this down on paper.  As I think about my estimates, I must remember to include:

• Prep time
• Heads down time to actually work on creating the deliverables
• Meeting time
• Review time

Even little things such as planning a meeting take time.  For instance, think about the last meeting you scheduled, especially a large meeting.  How long did it take you to find a time that works for most people, find a meeting room that is available at the same time, draft the meeting invitation and agenda, etc.?  ArgonDigital’s experience shows that it takes approximately 15 minutes to do all of that per meeting.  If you have several meetings to schedule, that time can add up quickly!

At ArgonDigital, we like to document our plans in a burndown format.  Burndowns show us how much time is left, instead of focusing on how much time we have already spent on our project.  Burndowns should be updated every day, so you have an accurate projection of how much time is left on the requirements effort.  It is important to be honest about how much time is actually left on a task.  If you have learned more about a particular topic, and instead of 4 hours, you now feel that you have 12 hours left to create your process flows, 12 hours is the amount of time that should be reflected.  While no one likes to see estimates go up, it is much better to be honest and transparent about your efforts then to hide them.

This may sound like a lot of work, but I ask you what are the alternatives?  If we don’t plan, how do you know if you are making progress?  How do you know when you will be done?  What answers do you give your project manager?  A bit of preparation can go a long way to answering those questions!