A cop walking his beat one night finds a drunk on his knees, searching for something on the street. The cop asks the drunk, “What are you doing?” “Looking for my car keys,” says the drunk. The cop asks, “Where did you lose your keys?” “I don’t know,” the man answers. The cop, a bit perplexed, asks, “Then, why are you looking here if you don’t know where you lost your keys?” Responds the drunk, “Because the light is better here, under the street light.”
- Author Unknown
When I think about the story above , I realize that organizations trying to quantify the value of investing in requirements definition often do something similar. They look where it’s easiest. Many vendors (and consequently, now customers) are well aware of the Standish Group’s CHAOS Report. It’s been shining a spotlight on the issue of rework in the context of software development for several years now. Reduction of rework has become the measure of choice for managers looking to defend investments in requirements definition. Rework is what’s under the streetlight. It’s where we look, but it’s just the tip of the iceberg.
What often goes unseen – and has the potential to dwarf the value inherent in reducing “rework” – is the follow-on effect of reducing rework, namely, accelerated time to market. If an application is brought to market even a couple months early it can mean many things:
- Extra months of additional revenue (for revenue generating projects)
- Extra months of productivity gains (for internal productivity-centric projects)
- Extra months of competitive advantage – or “stopping the bleeding” when catching up to a competitor who is already in the lead with a product
When considering the projected ROI for enterprise applications, a couple months represents significant value.
In the same vein, I stumbled upon the following quote from McKinsey: “If a company is later to market with a new product by only six months, 33 percent of the gross profit potential is lost over the product life cycle.” In contrast, “Improving time to market by one month improves profits by 12 percent.”
Who wouldn’t want to avoid losing 33% of their gross profit potential? The benefits from getting to market early (regardless of whether you define “market” as internal or the consumer market at large) are hard to ignore. Yet they very rarely show up in a business case.
Rework isn’t the only place to look for time-to-market advantages. Focusing on requirements definition not only reduces re-work – it also reduces WORK work. At an agile development conference in 2006, Mary Poppendiek (author of Lean Software Development: An Agile Toolkit for Software Development Managers) shared that 45% of code that’s written is NEVER EXECUTED! Another 20% is only rarely executed. It is however coded, documented, tested, trained, supported, maintained, etc. All of which adsorbs resources – and adds time & cost – to projects. Getting the requirements right interactively and up-front with end users helps make sure that unnecessary functionality never gets built. What if your development teams could get 45% additional bandwidth simply by not working on stuff that will never be used? Less stuff to build & test means, you guessed it, shortened time to market.
If you find yourself wondering how to measure time to market, ask your business partners what value having the right application months earlier would mean. I’ll bet they can tell you…
If you find yourself building an ROI calculation in support of focus on requirements definition, I hope you’ll grab a flashlight, wander away from the streetlight, and have a look around the street. If you’re not building an ROI for requirements definition, shouldn’t you be?
Share This
A 
Simulation done
