Estimating the Analysis Process

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.

I’m completely unclear as to how such an activity can be considered an important part of getting software out the door. Your stories/requirements/whatever are feeding the whole team; you’re the first person in the assembly line. It should be obvious the time they take and the value, because without them, every downstream team will be idling.My gut feeling is that it’s only in extreme cases of divorcing analysis from construction that anyone would even ask for these estimates. They should be reflected in the total volume of software produced, and I’d say that if your metrics/estimations aren’t based on total volume including all the activities (testing, analysis, development, engineering, etc.) then you have bigger problems.

Context and Software Process

As I start to post more here, some if it may seem like I’m full of rhetorical antipatterns about my beliefs in software development and the analysis process. I want to make my context clear, in advance.

The ideas here are predominantly about building business software in a large organization. That’s the hear of my experience. A lot of the observations will be anecdotal, because it’s very, very, very hard to accurately measure productivity. Not only is it almost impossible to measure in the absolute, even relative measures can be suspect (Robert Austin covers this much better than I could in Measuring and Managing Performance in Organizations.

So I’ll be the first to admit, there’s not a lot of science here. Some would argue it’s sloppiness, some would argue that it’s just inherent to the task. What is there is just my personal experiences, observations, and thoughts after years of building software in this context. When I say something inflammatory like “traditional requirements specifications suck,” I mean in the context of a rapidly changing business environment at a large organization consisting mostly of non-software professionals. I am not claiming that any such assertions then apply equally to other fields, like shrink-wrapped software, or military radar systems. They may apply, but I have no idea.