Business Analyst Blog

Business analysts are rarely allowed enough time to elicit, analyze, and confirm requirements. Why? One reason may be that we don't ask for it. An important BA skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to project managers and sponsors. Often they don't know why requirements take so long to "gather" because the word "gather" implies a BA with an Easter basket walking along the grass scooping up brightly colored eggs! It looks so easy!!

The best way to request and receive enough time is to build your case. You must be able to explain to the sponsor what you will be doing during that time and why your work is important. My suggestion is that you develop estimates by breaking tasks down into very small pieces. The smaller the task, the easier and more accurate the estimate. This detail also helps you justify the time. Let me give a small example - if one of my requirements deliverables is a Use Case diagram my task list might be:

Review project initiation documentation and draft UC Diagram   3 hours

Schedule stakeholder meeting (find room, call participants, prepare agenda)   1 hour

Conduct stakeholder meeting (present draft UC, get revisions)  2 hours

Revise UC diagram based on meeting  1 hour

Consult with IT architect to confirm feasibility   1 hour

Schedule review meetings with key stakeholders  2 hours

Conduct review meetings and ask for approval of UC Diagram  4 hours

By listing everything that you will have to do (including setting up meetings, etc) you will get an accurate picture of the time required. Remember these are work times - not lapse time. This is the amount of time that you would need if you were not working on ANYTHING else. Be sure to built in reviews and revisions as they will always be necessary. The less confident you are about the expected outcome of elicitation meetings, the more reviews/revisions cycles you should build it. Once you estimate, keep track of your actual work time so that you can learn and estimate even more accurately in the future. Take a look at our new course: Developing a Business Analysis Work Plan for more information. 

I presented a webinar for Catalyze (www.mycatalyze.org) on February 14th entitled Designing a Sure-Fire Stakeholder Strategy. The presentation touched on the importance of business analysis planning, specifically planning for stakeholder communications. We had 150 attendees and I was not able to answer all of the questions that were submitted. I will answer the remaining questions in upcoming blog posts.

How do I manage a stakeholder that changes his mind and these changes cause large amounts of re-work. Any rules of thumb such as an extra 20% longer?

Great question. When we are planning and thinking about how best to communicate with our stakeholders we need to consider each stakeholder's ability to provide requirements in a timely fashion. This includes considering stakeholders who may tell us one thing one day and something different the next. If you are fortunate enough to have personal experience with your stakeholders than you can plan for their individual idiosyncrasies (this is not a judgemental statement, we all have some percular ways of thinking and communicating!). If you don't personally know a stakeholder, try to find someone who does. Ask questions informally to get a feel for the person's style.

When building your task list and estimates, you should not explicitly say that you need more time with John because he changes his mind frequently, but you might build in more formal reviews and re-reviews with that particular stakeholder because you know this issue will come up. You also should alert the project manager that when dependencies are built into the project plan - beware that dependencies on John may be risky. The PM can also plan better with this knowledge.

We don't always get the dream stakeholders - the people who are always availabile when you need them, always patient when explaining their needs, and always sure about what they want. We have to learn to plan for and work with whoever our stakeholders are and remember than variety is the spice of life. If all stakeholers could clearly articulate their needs, there would be no need for a business analyst!