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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
0 Comment to "10 Reasons Why Software Project Estimates Fail "
Post a Comment