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. See Why Larger Teams Do Not Result in Faster Development…
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?
Related Posts
- How To Estimate Time For A Project
- Has project management gone out the window?
- Windows 7 Launch Marred by Software Pirates
