How to Avoid Common Project Estimation Mistakes

One of the biggest project management challenges starts before the main work, namely at the estimation stage. No matter how well a tech vendor does the assessment, the client will most likely have complaints during the development phase because something will not go as planned. 

Experienced project managers know it takes time and practice to learn how to estimate software development. And even when you think you’ve reached a mastery level, that one project will show you new horizons of the unknown. Agile estimation challenges and risks (if not calculated right) can ruin the most promising projects. As phase zero provides only a preliminary assessment, it often leads to the client’s false expectations. There are, however, ways to minimize misunderstanding and start the project on the right note.

How to Do Agile Estimations Wrong

Although Scrum and the agile approach to software development are widely adopted globally, many companies practice framework variations and skip some stages. It leads to ScrumBut, ScrumAnd, or similar techniques. And such deviation from the rules starts already at the project estimation stage. 

Let’s imagine planning a Sprint. The Scrum Master (SM) has an Excel spreadsheet with a list of elements for assessment and planning. Going from top to bottom, the SM is telling the developers what each item implies. If the Product Owner (PO) is also present at the meeting, they give comments and answer questions.

After reading through the requirements, the assessment begins. The SM asks each developer and the analyst how long it will take them to finish each element — in hours. The answers go to respective spreadsheet columns like “analytics”, “frontend”, “QA”, etc.

The Scrum Master’s only goal in this approach is to “utilize” the hours assigned to each team member for the upcoming Sprint rather than calculate risks and encourage a constructive discussion. The estimation process is completed when the spreadsheet is filled in.

Although this way of doing things may seem familiar to many, it raises critical project estimation challenges and leads to multiple mistakes that affect the entire project at later stages.

Common Project Estimation Mistakes

The point of project estimation is clear — to tell the client how long it will take to bring the idea to life and how much it will cost. There are different project estimation techniques you can choose from depending on the project type, size, and complexity. However, due to many internal and external factors, it’s impossible to provide the final numbers in the early stages. And just a few strategic planning mistakes are enough to significantly complicate an already tough task.

#1 Estimating Without Understanding the Requirements

Before answering the question “How much will it cost?” the development team should understand what exactly needs to be done. Broad, ambiguous requirements end up in much bigger budgets in most cases. The same applies to brand-new technologies the team has never used before. Even if the project manager is sure it’ll work fine because it did for another team, most likely, it won’t.

#2 Relying Solely on the Client’s Requirements

The team’s goal is to realize the client’s vision. However, many founders and project managers come from non-tech industries and don’t have enough experience with development nuances. If the project doesn’t have a skilled PO “translating” the idea into the developers’ language, it may end in a much bigger project. An insignificant detail for the client may turn into two months of work for developers.

#3 Not Controlling Requirements Change

If the company doesn’t manage changes at the implementation stage, any estimation will be initially wrong. In the end, project estimation is about assessing limits. Without requirements change management process, projects typically go beyond agreed budgets and timeframes.

#4 Assuming an “Ideal” Working Day

A typical mistake made by both clients and vendors is to base estimation on an “ideal” 8-hour working day. There are always forced breaks for coordination and approval of interim stages, other meetings, and emergencies. First of all, developers are people — nobody can code or test for eight hours straight. Besides, people quit or get sick.

#5 Not Having an Established Estimation Process

To properly evaluate a project, there must be a set-up process for it. Whether relatively simple or complex, it must be a dedicated assessment procedure with documented steps and follow-up reports. Without creating a proper system and a knowledge base of past projects, businesses end up in a situation where different people chaotically evaluate future work following various approaches and standards.

Why You Need Risk Assessment

Risk assessment certainly helps provide the client with more accurate and realistic estimates. However, it’s also an effective way to accumulate a base of potential risks that may arise in the future. In other words, the more you analyze the problems of completed projects, the more troubles you can predict for upcoming ones.

Simply put, this knowledge base is a list of possible problems that may occur. And when you take on a new project, you look at the list of likely risks and analyze which of them may be relevant specifically to this project. Did you have to find a way to bypass iOS blocking the app from launching the alarm from external software? Did you spend more time than initially planned testing an integrated voice call system? To name a few examples, now you can estimate similar risks more accurately.

Why Discovery Phase Is Crucial

No successful project comes out of the blue. The very first stage enables the executives and other stakeholders to draw up a plan according to the current market situation, available resources, and the client’s goals.

If done right, a discovery phase speeds up the process for the development team and introduces significant benefits for the client. Here are some insights from the Rocketech business analysts’ community of practice.

• A better understanding of how the team works

At Rocketech, we present the client with a discovery demo showing how the development process will go.

• Evaluating the project’s prospects

When presenting the Discovery results, the team offers the client several options for the project development, describes the cost of each step, and explains what the results will be. Moreover, we replace single feature estimation with epic estimation. All functions are grouped in blocks to create epics. One epic can include one or more features.

The evaluation process is based on the company’s experience with similar projects. This approach gives a more comprehensive overview of the project and the team’s direction.

Oleksii Zherebnykh, Business Analyst, Rocketech

• Avoiding unrealistic expectations and misunderstandings

Our approach to a discovery phase increases the transparency of each development stage and its cost to the client.

Saying “We’ll need from 80 hours” instead of “We’ll need up to 80 hours” helps minimize the negative response in case of delays.

Oleksii Zherebnykh, Business Analyst, Rocketech

Established Process

Software development project estimation is often the first point of communication between a client and a service provider. Any misunderstanding and inaccurate estimates can have fatal consequences. On the other hand, it’s another step towards improving the service quality and a perfect way to demonstrate the vendor’s expertise and maturity.

Everybody understands why project estimation is important, but not every developer can do it accurately and efficiently. At Rocketech, we strive to become a trustworthy tech partner to all our clients. And an established project evaluation process helps us form the right expectations and build effective communication with our customers.