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.

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

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/