Here's a really good article by Timothy Olson on quantifying requirements. In very few words, he pins down the essentials.
11 August 2010
Parkinson's Law: Work expands so as to fill the time available for its completion.
It's been shown to apply to government bureaucracies and it surely applies to software development. One bit of lore that I've been carrying around for decades and seen repeatedly validated is that work is at best a little early and at worst a lot late, with a ratio of about 4 in either direction. How do we express this in our calculations if historical data is not available to sample?
I've come up with the following algorithm for a time-to-complete distribution expressing Parkinson's Law:
09 August 2010
This stage of the planning process comes under different names: Strategy, Project Proposal, Business Case, Project Charter, ... The names tend to reflect the degree of approval obtained or being sought, and the kind of detail expected. In any case, this is the first place in the planning process that the planned activities, projected costs, and timelines come together for stakeholder inspection and decision-making. It includes a plan, but probably not at the level of detail used for managing the project.
"How long will it take?" doesn't have just one answer. It has a bunch of them, each with its own probability of being right. Which of the many values we commit to is a risk management choice, not a discovery.