Analysis Time Creep
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.
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.
posted by Vikram Pai at
10:44 PM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home