In practice, at least for organizations that are not good at estimating, I’ve rarely seen the long pole stay the same throughout the development cycle. This means you can’t rely on the long pole being … the long pole. With each status update, it often looks more like a horse race on who will finish and in what order.

My conclusion is that it is almost never a 1:1 reduction. I’ve seen it where the overhead processes are so great that it takes something like an 80% drop in requirements to get a 20% reduction in schedule. In this actual situation, this turned out to have a hidden but silver lining. While reducing the schedule was near impossible, increasing the requirements by 600% – which was insane in my book – didn’t actually cause that much problem. I likened the company’s development team to a draft horse (a Clydesdale maybe). You probably can’t make it run very fast, but you sure can load a lot more onto it than you would expect and still get to where you are going in the same amount of time.

Thanks

Bruce

I’ve had folks openly “snicker” at me in meetings when I say we can deliver consistently on time. These are exactly the “game is over” organizations that you refer to. The snicker represents to me the real barrier. These are not the same “highly competent, like-minded individuals” you refer to but instead equally highly competent but expert in large corporate politics and survival. Many of these folks are incredibly capable – but need a bit of a hint to realize it can really be done and it is safe to do it.

However, I clearly disagree with the notion that these companies reach a point where they can no longer deliver on time with high quality. My writings specifically chronicle how I’ve been a part of doing just that. From military organizations, to small corporations, to Fortune 50 corporations. I was there. We did it. It really is possible. But, it is not easy. And it is not easy for the reason you suggest, the size and politics of the organization. The talent needed was always right at hand. They just needed a little guidance and a whole lot of guts.

Yes, there is some magic in being objective. Here in part because it helps overcome the politics. But for everyone, yes, you can use basic measurements and handled the large variations. Yes, it will give you a very good probability date. It is done in context however. Where this has worked very well is in organizations that are consistently late. Always late in some cases.

As strange as it sounds, I am often recommending a schedule that has a 50% probability of success. In an organization that is always late, delivering half on time is a tremendous improvement. It is humorous to have folks who tell me we can predict nothing about our ability to deliver on time, for some of the same reasons you mention, tell me that the 50% schedule is not good enough!

These fairly simple techniques have worked on teams as small as 5 developers to efforts that run 12 months and peak at 450 developers a month.
There are more sophisticated tools and techniques, but I find the sophistication is the barrier to proper use. I watched an organization that never delivered on time implement a Monte Carlo technique. Gee, it came out with almost the same schedule. All the products using this new technique all delivered late, as they always had. It was too mystical to too many, very smart, people to realize how ridiculous a result that was. I used a simple average of past product deliveries, we nailed the schedule, and we took no more time than products did in the past.

Thanks for your comments.

Bruce

Ive been around software development efforts a very long time, and while its great that there are somewhat “objective” tools available to help predict completion times, efforts, etc…in the end the “highest order” effect on a projects time comes down to the same single variable everytime: the people working on the project.

Software development is part art, part science, and all brain. Being able to retain “big picture” views, while focusing on minute details of functionality and quality is a gift that is very infrequently visited on the multitude of developers out there. Most coders are “average” (including myself), and that “average value” has a wide variant. The larger the project, and the more developers, the more difficult it is to come up with a single valid estimate of when something will be “done”.

That is why startups usually fair so well in the software market…highly competent, like-minded individuals, with tremendous drive and determination are able to now develop amazing software in a staggering short amount of time. Once the “sanctity of coder purity” is broken as the startup grows and hires more people, the slower development becomes…when you need “Project managers” to manage everything, the game is over.

-avi