I hear you struggling with estimating the time required to complete projects. The larger the project, the harder the estimate. This is perhaps the most frustrating aspect of systems projects for business leaders.[1]
The old adage is to double the estimate programmers give you. Why? Because they underestimate by at least a factor of two (but this may only get you half-way to an answer.)[2] There are decades of studies of how to better estimate systems, but the fact of the matter is that most systems miss their time and cost estimates, badly.[3]
I remember the case of the second major release of Lotus 1-2-3, the dominant spreadsheet of the 1980's. The release kept gaining new feature needs and the scope was mushrooming. David, the VP of Development, had to tell the hard-hitting CEO that the product ship date was not going to happen. It was an ugly meeting. To minimize the damage of market expectations, they began trimming features to minimize the latest forecast.
After the launch, they commissioned a study of how to change their development approach. They landed on the fixed interval development approach. A minor release of the product would happen every quarter and major releases annually. Customers and resellers knew what to expect and could plan on regular launches. Features that didn't make the current quarter plan rolled over to the next quarter.[4]
Remember the "iron triangle" of projects, cost, time and scope?[5]. One of the options is to fix the time, and release the amount of project scope you can get done in the time set. In addition to better managing customer expectations, releases are smaller, and more likely to get done. |