By "personal" I don't mean that you need to keep your requirements planning to yourself. No secret diary should be used requiring your project manager to snoop around your desk late at night to discover when you will be done with your requirements tasks. Your requirements plan needs to be shared with the project team and all stakeholders involved in the project. What I mean is that no two Business Analysts will have an identical plan and that is OK. There are a variety of skills you need to be an excellent BA and every BA has different strengths and weaknesses. Estimating the tasks to complete should be similar from BA to BA, but the time to complete each task is personal.
Consider this analogy. The requirements tasks are like a person's hand and the BA's time estimate is like a person's finger print. For the most part, we all have the same basic hand structure, but no one has the same finger prints.
BAs work on projects that have many variables impacting the decision of which requirements tasks should be included and determining time estimates for those tasks. They include the type of project, the business and project risks, the time frame allotted for the project, the stakeholders involved, the number of integration points with other systems, etc. Over time a Business Analyst can look over all of those factors and confidently determine the tasks needed to be accomplished for a project. Planning the right tasks can be done with little regard to the BA resource working on the project. The individual Business Analyst needs to be considered to determine the most accurate time estimates.
As an excellent BA you need to track the actual time it takes to complete each requirement task for your projects. The more history you accumulate the better you will be able to estimate how long each task will take to complete. When you are planning the next project refer back to the actual data to better estimate your time.
3 Comments
Hi
There is a good series of artciles on software estimating which I think could be modified to suit business analysts at the Tyner Blain blog.
http://tynerblain.com/blog/2007/02/12/software-cost-estimation-ucp-1/
Great article, Kupe!
And thanks for the shout-out Craig! What a great surprise to come here to comment, and find a link to Tyner Blain.
When I was a developer, lead dev, and project manager, my teams would generate PERT estimates for deliverables, and then track actuals. I would work with my devs after each release (3-week cycles) to review actuals versus estimates. And their ability to estimate got better very quickly. Now that I think about it, the rate of learning was consistent with the theoretical learning curves I recently wrote about.
Craig – I’ve been thinking about how to use UCP to estimate requirements development effort too. I’m currently “gathering data” on invested time with a real project. I’ll have an actual proposal (or at least some incomprehensible data) in a couple months.
Scott
I’d go the other way with this issue of keeping requirements secret. Every stakeholder’s requirements should be kept secret from ALL other stakeholders, including the economic buyer.
The problem with letting the stakeholder’s squabble over the requirements is that you end up with requirements volitility and they end up having to work around the delivered system.
Meaning is not negotiable and neither is practice.
Since the dot bust, code has become a lot cheaper. With cheaper code the focus on programmer efficency needs to be redirected, because production, the user of the delivered application, is ALWAYS more expensive than programmer time.
Current requirements practices go back to the 1950s. The world has changed.
The argument about keeping the economic buyer in dark probably doesn’t make sense given the economic theory that says that the highest paid decision maker makes the best decisions, which can be extended to say that a generalist knows more than the specialist. Unfortunately, the specialist is exactly who we automate out of a job. It is the work of the specialist that we are trying to automate, not the decision making of the generalist economic buyer. The economic buyer should decide whether automating the work is going to be worth it. Then, they need to get out of the way.
The economic buyer is ultimately responsible for requirements volatililty, because they politicize the requirements. This week group A has more power than B, so group A’s requirements get the top priority, next week that will change. Both groups should be getting what they need. Code both, not the priority.