In the immortal words of Clint Eastwood's Dirty Harry, "Are you feeling lucky?"
These mid-project discoveries often mean that initial requirements must be recast or re-prioritized. In other words, the team will need to place different bets than what was contemplated in the document.
Since the initial requirements tome will have to be rewritten anyway, the agile solution is to do discovery at the outset of each sprint - typically, every two to four weeks - to deeply understand the tactical requirement at the instant the implementation begins. In many agile methodologies, these up-to-the-minute detailed requirements are even called "cards."
See the parallels with Texas Hold'em?
You Only Think You Know Your Budget
Classic software budgeting is done almost entirely on the basis of cost models: Requirements > Statement of work > Work breakdown structure > Estimates. Thanks to the effects discussed above, the cost estimates are going to be out of whack. Count on it.
There's an additional twist. In business software projects, some of the biggest cost elements are internal staff time, meetings and other sunk costs. All are often ignored in the budgeting process, with twin nasty consequences.
First, the "invisible, free resources" (often, sleep-deprived employees) are over-allocated, over-consumed and cause big project delays. Second, when things get serious, the explicit, costly resources (often, sleep-deprived consultants) come in and cause big budgetary surprises.
So there's a significant chance you'll underestimate the costs. However, the smart business case doesn't focus as much on costs as on business value. Who cares what you think it will cost as long as the final cost is outweighed by the value achieved?
In the course of the project, one squeaky wheel or another will pull rank on priorities and resource allocations. When push comes to shove, the business will discover all kinds of business value that wasn't properly included in the original business case.
Since the entire business case is at best a model - which may well be overcome by new facts - the agile solution is highly incremental budgeting. Each sprint gets its own time-boxed "not to exceed." As the team gets better, the estimation errors start to cancel out. Essentially, the agile model is to make a series of small bets, not an initial "all in" bet.
Of course your finance department wants a fixed price - but in custom software, that's an illusion based on fallacious assumptions. Just in case there's any doubt, any serious CRM effort is going to involve custom software.
Sign up for CIO Asia eNewsletters.