Time and Cost Estimations. Why do development teams tend to avoid them?
Tags: Estimations, Web Development, Project Management, Mobile App Development, Development

Every business owner knows how planning can be fundamental for project success. And the time/cost estimation is a significant part of it, often without getting them right it’s pretty much impossible to say if the implementation will be worth it/ in time to win the market.

But here is where another problem begins, developers refuse to make an estimation but even the worst scenario — if they make it unrealistic by accident or just to win the project. So in this article, we want to outline the factors that influence the estimation and the ways you can ease up this process.

Let’s start from the beginning.

What we mean by Estimation and why it’s so important.

Estimation is the process/ practice of analyzing and trying to determine (on the basis of it) the amount of effort and time (usually hours) that needs to be dedicated for the developers to implement the idea. This also includes any management and progress tracking and target date commitments made based on these estimations.

The overall project for this can be also broken into many smaller tasks and milestones. In order to achieve a more exact result. It’s the right approach as the bigger the relative size, the more inaccurate the estimate becomes at an exponential rate.

Customers focusing on the estimation for a few quite obvious but fundamental reasons. Sometimes software releases and introduction of new features are sticking to the fixed date. The market will not wait forever for your idea to shine so many startups are trying to release asap. This approach can be pretty dangerous as influencing the overall quality. Another case is to release by upcoming industry conference or big event, so it would be a good marketing opportunity.

One of the popular reasons is — investments. Investors always want all processes to be transparent so demanding a detailed estimation for each stage. They rate efficiency, progress by different metrics. This is also a legitimate reason if the metrics provided are meaningful, valuable, and accurate enough to warrant the time and cost overhead.

Besides the time, budget is what matters a lot too. Many projects are pretty limited budget-wise so estimation is fundamental for them to see how much they can implement.

What factors can influence the final estimation?

Aside from being overly optimistic, development specialists are often under a lot of pressure. Every estimation that turned out as unrealistic they have to take responsibility for. In any way, the estimates, even the “rough” ones, end up being considered commitments in the client’s mind. Problems with it it’s mostly predictions, and in the end, it might take twice as much time. Without proper documentation and detailed project requirements, it’s impossible to make an accurate guess.

Firstly, you need to take an account of factors that can influence its results:

- Unclear requirements at the start of the project, lack of quality documentation;

- Client unpredictably changing the requirements;

- Personal developer’s experience and productivity level particularly if multiple people are involved;

- Sick leaves, communication delays (often from client-side), holidays etc.;

- Overlooking potential issues with 3rd party integrations;

- Additional research time;

- Administrative work and non-engineering related requests;

- Unforeseen issues with maintainability, architectural flaws/imperfections, scalability, performance, testability, etc.

In almost all cases, some of the above or even a few are the results of inaccurate estimates. It’s not always possible to take them into account before the start of the development. So the common practice is adding some padding to estimation, you may say ‘put in the risks’.

Also, you need to take into account one of the interesting phenomenons that can influence the process. Parkinson’s law states that work expands so as to fill the time available for its completion. This certainly applies to software engineers, and more specifically, an engineer will work full time. So there needs to be a healthy balance.

So let’s get back to the point.

Why developers tend to avoid exact estimations and what you can do to help them with the process?

After outlining the factors that influence the process it’s pretty straightforward. In the best-case scenario, the client provides detailed information about the project, and still there many risks and roadblocks. And in the worst, the requirements are unclear and the client needs the estimation ‘yesterday’.

So no wonder developers not very happy to make estimations and take responsibility for them. Yet experienced teams usually have a good flow and predicting most of the risks. But to do so they need a good information base from the client.

Let’s outline what realistic estimate one should generally consider:

+ Detailed specifications — one of the most obvious factors yet many clients skip it. The more information you can provide on the scope of the project, user flow, and the desired outcomes the better.

+ Graphic design/ Wireframes — Ideally to get the most reasonable estimation ready designs are perfect. But in the initial stage, even simple drawn wireframes will do for developers to understand the structure and idea. Keep in mind — Complex UI elements usually require more engineering effort and take longer to implement.

+ Technology stack/Integrations — Depending on project specifics, there are numerous tools and integrations your team can use to solve different problems. Developers can’t know they all so you need to buffer the time for the devs research or the learning curve.

+ The personal experience factor — The experience of the developer can play a significant role especially if the developer implemented similar projects before. Keep in mind — the difference between senior developer efficiency and junior can be really big. Therefore, estimates should be tailored to the team that will work on the project.

There is a good rule for specification — ‘’It can’t be too detailed’’. Even if it seems pretty straight forward there can be more important details. You can document a simple description like — “User can login into the app” but a developer will have a dozen of questions:

- What type of login should be implemented (email and password login or social networks login and if yes, which ones)?

- Should the fields in the registration form have any restrictions (maximum number of characters, type of characters, password strength requirements)?

- How should the input fields detect and handle errors (invalid email, password, etc…)?

- Is the “Remember Me” option needed? If yes, for how long should the information be stored?

- Which password recovery option should we use?

And that’s just the tip of the iceberg. So if you have the opportunity to work on the specification with someone technical or your development partner can assign a project manager to work with you, with no doubt — do that. In the long run, good specification can win you a great amount of time.

OUTLINE

Project estimations never come easy. It requires great analytics skills and experience from the developers and patience, help from the client. Projects often considered being “behind” because of incorrect estimates even without significant development issues.

A healthy balance is fundamental between underestimation and putting in too many risks.

Fixed or target deadline/budget can be very important and valuable for the project but should be handled using appropriate techniques. In any case, it’s better to take the time to do things properly with high-quality standards. It will be a win for the project in the long run.