A business analyst’s work in eliciting, analyzing and specifying requirements costs the organization, but doesn’t benefit it in a measurable way until it is implemented as part of a solution which is helping to meet stated business objectives.
With that in mind, just as with more tangible types of inventory which don’t provide real business benefit until integrated into an end product or sold, you don’t want to carry any greater “inventory” of unimplemented requirements than you have to.
It’s not a perfect metaphor, but I think there value in drawing the comparison. Think of requirements as inventory or as component materials in a storage bin with a shelf life and a carrying cost. Inventory isn’t free. You have to pay someone to produce (model and document) requirements. You need a supply of good, current (fresh) requirements to produce a quality product.
If requirements sit unused for a while and the market landscape or business need changes, they can become stale and useless. They can become false or misleading. At that point, using them as a basis for design and development can result in production of a sub-par or poor quality product.
Stealing a page from the book on good inventory practices, we, as a solution delivery organization want to make sure we carry sufficient inventory to keep “the factory” busy and a bit of a safety reserve just in case, but we don’t want to carry excess which has a fair chance of turning to waste. Unfortunately, as is sometimes the case with physical inventory, you can’t sell excess requirements or take a write-off for bad requirements inventory!
I understand that in some environments, it is common practice for the business analysts to try to stay several projects ahead of the factory. I suppose the reasoning is so the customer will have the impression that work is being done on his/her project, and to ensure that the developers will have a steady stream of work. This type of scenario is ripe for requirements spoilage.
Ideally, the analysts would stay no more ahead of the factory than they have to be. If you’re working ahead as an analyst, I recommend that you do just enough to get the big picture for the next piece of work – just enough to build a basic framework for the end-solution. Then, you dress the framework with detailed requirements – in full collaboration with the team – just in time for it to be used to create the end product. This ensures that the inventory we’re providing our consumers is fresh, and that you minimize the risk of spoilage associated with carrying too much excess.
As I said, I like the metaphor of requirements as inventory. I’d be grateful for additional angles or suggestions on how the metaphor can be applied in our world of solution development, or for feedback on its weaknesses.
Not a big fan of analogies, but I won’t call the Analogy Police just yet.
You can’t sell off excess requirements, for one thing.
Well, Dave, I love metaphors/analogies! But to appreciate them, I guess you have to acknowledge that they have flaws.
And you’re right, as much as we’d like to sell off those excess requirements, the market has never materialized, has it?
Appreciate the point, though, and I’m going to update the post to include that with notion of not being able to write off excess.
Plus you have to cut me a little slack, I’m just easing back into this blogging thing after a long layoff!