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.
5 Comments
Barbara What do you think is more important; estimating work time or elapse time? Also a bottom up estimating process is best as it allows for a total quality approach to requirements (the way things should be) but what about when someone hires you and says you have two weeks… By the way we are midway through a series of posts on ime tracking at http://www.betterprojects.net right now. Come and have a look. We’d love to hear your thoughts.
Craig,
I like to estimate work time. Elapse time requires you to know all of the other things that may get in your way and is much less reliable. The important thing about work time is for everyone to understand that it is the amount of time needed if you weren’t working on ANYTHING else! Most project managers ask for work time and then schedule their project resources for 6 work hours per 8 hour day. This allows time for non-project meetings, breaks, other ongoing assignments, etc.
I looked at your discussion on time tracking and enjoyed it. Keep up the good work!
Barb
Thanks
Interesting perspective on which type of time to track. The PM may care about effort, but only so far as you can fiot the work in to available time.
Once they start scheduling various workstream and committing to deadlnes they then get more focused on when you can complete the task, right?
I guess cost management and capability are the priorities at first but once you are underway you have to make deadlines so subsequent tasks can get started.
Barbara, I have a related question on estimations if you could help me out with it. If the BA has the business/functional requirements and is supposed to estimate the effort to create functional specifications, are there estimation methodologies? Also, if the task of creating functional specifications is to be done in a fixed price contract have you used any estimation methodologies that help to identify ‘changes’ during the contract period that should be considered a change request?
Thank you in advance!
Nilesh, there are no “hard and fast” rules for estimating. It’s more of an art form. However, I’ll give you some things to think about as you estimate.
Prior to giving your estimate, do you understand the boundaries of what it is that you are being asked to do? Have you created a scope diagram? Have you done stakeholder analysis? Do you understand where all of your stakeholders are? Do you understand the type of project (maintenance ticket vs. new software development project)? Depending on your answer to these (and others), you will be able to determine some estimate to your part. The BABOK lists eight ways that you can perform estimation:
1. Analogous Estimation, which is basically a Range-of-Magnitude, sometimes called a ROM.
2. Parametric Estimation. If you have enough history, you can multiply the effort by a factor to arrive at an estimate. So, if history shows that eliciting requirements from a specific functional group takes 10 hours, and this project has a factor of 10, then your estimate is (10×10) = 100.
3. Bottom-Up Estimation. The BA collects the tasks from all the functional groups and rolls them up for a total.
4. Rolling Wave, which is an estimation refinement technique. It involves basing estimates for the next iteration (or phase) on the current iteration’s work.
5. Three-Point Estimation, when you estimate the best-case, worst-case, and most-likely scenarios.
6. Historic Analysis. Go back and look at your previous projects for data to see how much time a similar effort took you.
7. Expert Judgement. Talk to those who have done similar work in the past.
8. Dephi Estimation. This is a good technique if you are getting everyone together and have them vote on how long something will take. The participants vote, discuss, vote, discuss, etc., through several rounds until you reach a consensus. The “Planning Poker” technique is similar to this.
Given your question about a fixed-price contract, you still have to go through estimation, but since your price is fixed, you can only bring a limited amount into scope that fits within that contract. You do the best estimation that you can, and then see based on your price, how much work that you can fit into the deliverable.
Finally, learn from your past estimates. If you gave someone a fixed-price contract and it would up being a lot more work than you thought, keep that in the back of your mind when you start your next project estimation.
Cheers!
One Trackback
[...] Estimating the Analysis Process February 27, 2008 12:01 pm — Rob Meyer So it’s clear to me that I’m coming at business analysis from a different place than a lot of people. That is very obvious when I catch articles like this one on Estimating Analysis Time from the Business Analyst Blog. 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. [...]