Stakeholders don’t like suprises, especially when it comes to project costs. It’s worth taking the time to carefully estimate the business analysis phase of the project. Here are five tips.
Estimating the business analysis phase(s) is not easy. It is not hard, but it takes a willingness to think about exactly what work will be produced, and many business analysts do not have the patience. So for those of you who do not have the “stomach” to spend the required time to estimate business analysis, here are five tips:
1. Break the effort into manageable pieces. We can estimate a whole lot better when our business analysis phase(s) are small. For example, it’s easier to estimate a user story than an epic story. Scrum Masters understand that user stories for upcoming sprints must be small enough to be groomed, estimated, and delivered. Using another example, it is easier to estimate how long one specific business process will take than to estimate an entire value chain.
2. Choose your approach. We’ll estimate differently if we’re using a plan-driven approach (Waterfall) than if we’re estimating in a change-driven (Agile) environment. The way we organize, estimate, prioritize, and trace requirements, the way we handle changes, verify and validate requirements, the way we report on the effort all are dependent on this approach. The activities related to organizing, prioritization,, traceability, and handling changes will be different depending on the framework we use to go through business analysis.
3. Use a variety of estimating techniques. There are lots of ways to estimate requirements, most of which can be used for other project phases as well. On many projects we cannot be precise about our estimates when we’re first asked how long business analysis will take. We usually use analogous estimating, or experience with a previous project. If we have good history, we might be able to use parametric estimates. For example, if we know that it takes four hours to model a business process and we have five processes to model, it will take twenty hours to model business processes.
4. Brainstorm with the people who are actually going to do the work. They usually have a more realistic idea of what needs to be done and how long it will take. I also like yellow sticky notes, since they can be easily added, taken away, and moved. Again, these techniques, which have worked well on traditional projects, also transfer to Agile projects.
5. Identify all the deliverables/artifacts, before attempting to identify the tasks needed to produce them. Here are a few examples of deliverables: user stories, agendas and minutes, “as-is” business process model, traceability matrix, to name a few. Once we have the deliverables, we get together to think of as many tasks as we can — tasks that are needed to produce these work products and the hours these tasks will take.
Of course the real, real key is having the courage to communicate bad news. Which brings me back to the president pounding his fist. What I should have done was communicate our status regularly, rather than surprising him after months of effort. What a lesson learned!
Referensi : http://www.projectsatwork.com