Think about the web
and software projects you’ve completed. How many were delivered on time and on
budget? How many estimates were accurate? IT projects are notorious for
over-running, and here are several reasons why it occurs…
1. The project is
poorly scoped
How can you estimate time on a project when you don’t know what that project
is? It’s rare to find a client who appreciates exactly how their system should
work.
Almost every large
project I’ve undertaken has requested “flexibility”. In other words, the client
wants the system to handle anything they want at any future point in time —
even though they have no idea what those features might be. Flexibility
is not a requirement!
2. Development time
is estimated by non-programmers
If you’re not a programmer, don’t guess at development times. A project is
doomed the moment a manager writes their own fictional estimate. At best,
they’ll be completely incorrect. At worst, the programmers will be tempted to
prove them wrong.
3. Developer
estimates are too optimistic
Developers think in terms of coding hours. Time passes quickly when you’re in
the zone and it’s difficult to assess your own speed. Appreciating the speed of
other developers is impossible.
Many developers are
over-optimistic. They tend to forget the softer side of the development
process, such as project management, collating requirements, discussions with
colleagues, absences, PC problems, etc.
4. The project is not
adequately dissected
Be wary if the development estimate for an individual feature exceeds a week.
That chunk should be sub-divided further so the developer can analyze a complex
problem in more detail.
5. Estimated time is
used
Give a programmer 5 days to complete a task and it’ll take 5 days. Software
development is infinitely variable and any code can be improved. If a developer
takes 3 days to finish the task, they’ll spend the remaining time tweaking it
or doing other activities.
Unfortunately, this
results in a situation where estimates become the minimum number of development
days. The actual delivery time can only get worse.
6. More developers !=
quicker development
A 100-day project will not be completed in 1 day by 100 developers. More people
results in an exponential increase in complexity.
7. The project scope
changes
This is perhaps the most irritating problem for a developer. A feature is
changed or added because customer X has requested it or the CEO thinks it’s a
cool thing to do.
Is the impact of that
new feature documented?…
8. Estimates are
fixed
Estimates should be continually assessed and updated as the system development
progresses. Programmers often believe they can make up lost time — it rarely
happens.
9. Testing time is
forgotten
It’s impossible for a developer to adequately test their own code. They know
how it should work, so they consciously or sub-consciously test in a specific
way. In general, you can expect to spend another 50% of the development time on
testing and debugging.
10. Estimates are
taken too literally
Non-programmers rarely appreciate the complexity of software development yet few
businesses plan for schedule slippages. The project often sits at the bottom of
a huge unstable tower of other activities, such as literature printing,
marketing, distribution, etc.
Development hold-ups
can cause a costly chain reaction of delays. Unfortunately, it becomes easy to
blame the programmer at the bottom of the pile. That’s doesn’t bode well for
future projects — the programmer will either refuse to provide estimates or
inflate them dramatically.
Have you encountered
other reasons why project estimates fail?