Project Delays? Here is Why Your Estimates Don’t Work
Almost every software development project starts with the questions: “How long will this take? How much is this going to cost? How many people do we need to get this done?” These are all variations of the same question: “How much effort will this cost in terms of time and money?”
And the most common replies are either “we don’t know” or “let us estimate first”. The problem is that nobody likes these answers. Stakeholders don’t like the first reply because even though they need an answer, they don’t have the knowledge to give it themselves. Technical teams don’t like the second reply because estimates take a lot of time and are often too rough to be accurate.
Why estimates don’t work
Traditionally, a project manager compiles estimates on a software project and shows them to the boss who looks over and sets the date for delivering the project. Then there is a team meeting where the plan is presented with all honors and celebrations, and everyone comes back to work expecting they’ll meet the stated deadline.
And in most cases, the deadline is missed… Project managers blame lazy developers. Developers blame unrealistic estimates of project managers. In the worst case scenario, most of the team will quit, and the final deliverable will be filled with bugs.
Unfortunately, this happens over and over again. And there are four reasons why estimates fail.
#1. Focusing on a best-case scenario
When a project manager asks developers for estimates, they use their experience, knowledge and depending on how they are familiar with the project, make an estimate. It’s then used by the project manager to determine how long the project will take. And in most cases, these are the best case scenarios. And what if the worst case scenario kicks in?
The problem is that most people are too optimistic when it comes to estimating how long something will take. Another problem is not including “thinking” time in estimates – e.g. developers often estimate the time necessary to write the code and forget about the time needed to think about it. If it takes 30 minutes to write a feature and 3 hours to think about how it will look like, you will be way off schedule if you haven’t included “thinking” time in it.
#2. Shifting the scope
A developer estimates a certain period of time for a certain task. And if the project manager adds new stuff, nobody can hold the developer to the original estimate because any new change means that the estimate will also change.
And though it sounds logical, this concept is often ignored, so no wonder the final date is wrong. The golden rule to remember: adding stuff makes the job take longer. Period.
#3. Not taking into account how features interact within the system
Developers often forget that features don’t exist in a vacuum. They interact with other features and impact the whole system. So adding, replacing, changing or fixing one feature will inevitably result in more work and more time spent than you expected.
#4. Ignoring the artistic nature of programming
Even if you ask 10 developers to implement a certain function, you’ll end up with 10 different approaches. There are certain tips and tricks that vary from person to person. This uniqueness is often ignored as well as the fact that programming is more art than science. And art doesn’t follow the schedule.
1 Comment
MgS
about 6 years agoA couple of other factors that always need to be accounted for: 1) Identifying and integrating appropriate foundation libraries/tools. Project definitions often include implicit assumptions about how easy it will be to identify and integrate third party components that will carry significant parts of the project. (e.g. embedded databases, ORM libraries etc). Selecting tools is often a project in its own right that takes time to do the appropriate comparative analysis and prototyping. (and sometimes, you learn from this that the entire idea of using a "canned component" simply isn't viable). Worse yet is when someone comes along and tries to dictate that their particular toy of the week is what you must use. 2) Human Factors People typically only work at a fraction of their peak productivity, and more senior developers often are dealing with so many interruptions in their day that you're lucky if they are "productive" in terms of creating solution 20-30% of their day (the rest is taken up with meetings, mentoring, conceptual problem solving etc). Additionally, people take vacations, get sick and so on. Seldom have I seen managers account for this in their scheduling. Nor should we ignore interpersonal issues within a team or friction with other teams. All of which are forces which can impede progress. 3) Refactoring Time As pointed out, software is more art than science at times. This means that when an issue is identified, it may trigger a significant cascade of refactoring existing work done in order to fix it (especially true of performance related issues). In short, the schedule has to be a living thing, and senior management that often sets release deadlines etc. needs to understand this. Most people will be willing to live with a few weeks of a grind to wrap things up, but constantly pressuring people to hit the most recent unrealistic deadline will kill motivation. On the other side, developers need to be an active part of the estimating process as the schedule evolves. Revising estimates to reflect deeper understanding of the problem is a legitimate thing to do, and should not be used as a "weapon" against the developer. A change in the estimate is a change. Simple enough.
Reply