Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

How long does software development really take?

I was reading some stats the other day … 85% of all software development projects fail to come in on budget or on time! That is a staggering and sobering statistic. In what other profession would there be such a low hit rate? How is it that so many bright people get it so wrong so often?

Software development is inherently a more risky proposition than many other projects. The reason a client is after bespoke development is because no such products exist in the market that adequately answers their problem. Some clients are better at expressing their requirements than others. In some cases they simply don’t know what they need. They just know that they need something.

Estimating how long a development effort will take is more of an art than a science. There are many factors that influence this. Usually it is some of the most skilled developers that will be asked to perform this task. Their skill level is usually order of magnitude higher than some of the developers who will be asked to implement the actual functionality. Some are inherently more optimistic than others. In many cases developers do get taken away from time to time to either meet schedules for other projects or lend their expertise to other members of the team. This leads to significant productivity losses.

This leads to two estimates that are key. How much effort is required – tells you how much it will cost; and how long it will take to deliver. There have been many attempts to put bit of science into getting a more accurate estimation. During the late 1950s the US Navy Project Operation Centre came up with the Program Evaluation and Review Technique (PERT).

PERT assumes that in most cases your estimates are sound. However, there are occasions when effort taken is less than expected, while other occasions they take more. They came up with the formula Best Estimate = (Most Optimistic + 4 × Likely Estimate + Most Pessimistic) ÷ 6. This formula is not necessarily specific to software development. In my experience, the odds of something finishing early in software development, compared to something finishing late is less than a third. Therefore I’m more inclined to calculate effort based on (½ Optimistic + 4 × Likely + 1½ Pessimistic).

I also tend to use an 80% productivity to plan duration of tasks. This allows for 4 days of productive work and a day of R&D, admin work, other project work or mentoring. The odds are on certain parts of the project, You can have a 2-3 week stretch where 20% slack won’t be taken up. That will allow you to either get slightly ahead of schedule or claw back some time if you’re falling behind.

Developers are good at estimated effort of development, not all the other the other necessary activities that go into producing a successful application – testing, release and deployments etc. The following table reflects my thoughts on actual effort required based on a developers estimate of 100 hours likely effort, 80 hours optimistic and 140 hours pessimistic.

Actual Estimate

Any method is only as good as its input. Garbage in will give you garbage out. There is no substitute for knowing your developers and their tendancies.

One response to “How long does software development really take?

  1. Pingback: Four Ingredients of Successful Software | Technology Asset Recovery

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: