Project Evaluation: Approaches and Mistakes

Why project estimation is a management process, not a number in the budget01

Estimating an IT project is one of the most sensitive stages of interaction between business and contractor. It is here that expectations regarding timelines, budget, and results are formed. A mistake at the estimation stage almost always leads to problems later: missed deadlines, budget overruns, conflicts, and disappointment for both parties.

It is important to understand: project estimation is not a promise or exact mathematics, but a managed hypothesis based on data, experience, and assumptions. By 2026, mature teams have long moved away from the approach of "estimating once and forgetting" — estimation has become part of continuous project management.

In this article, we will cover:

• the main approaches to estimating IT projects,
• where and why mistakes occur,
• how businesses and teams can work with estimates consciously.

Why is project evaluation necessary02

Project evaluation is needed not only for budget formation. Its key function is managing uncertainty.

A competent evaluation helps:

• understand the scale of the task;
• compare implementation scenarios;
• identify risks before starting;
• make a decision on the feasibility of the project;
• establish correct communication between the business and the team.

Without evaluation, the project turns into either a «black hole» or a source of constant revisions of agreements.

Basic Approaches to Evaluating IT Projects03

There are several common approaches to evaluation. Each has its strengths and weaknesses, and none is universal.

1. Expert Evaluation

The project is evaluated based on the experience of specialists: PM, tech lead, analyst.

Pros:

• quick;
• takes context into account;
• suitable for early stages.

Cons:

• subjective;
• heavily depends on the experience of specific individuals.

2. Evaluation through decomposition

The project is broken down into features, scenarios, and tasks, each of which is evaluated separately.

Pros:

• high accuracy;
• transparency for the client;
• easier to manage changes.

Disadvantages:

• requires time;
• impossible without well-developed requirements.

3. Analogous Assessment

The assessment is based on a comparison with already implemented projects.

Advantages:

• based on real data;
• works well in familiar domains.

Disadvantages:

• poorly applicable to unique products;
• requires a quality case base.

Table 1. Comparison of Assessment Approaches

Approach	Accuracy	When to Apply	Main Risk
Expert	Average	Early stages	Subjectivity
Decomposition	High	Before the start of development	Time costs
Analogous	Average	Recurring projects	Erroneous comparisons

Why estimates "break" during the project04

In practice, the problem is rarely in the methodology itself. Estimates cease to correspond to reality due to changes in context.

Main reasons:

• change of requirements;
• emergence of new scenarios;
• underestimation of integrations;
• hidden technical debt;
• dependency on external systems;
• delays from the client.

Important: changing the estimate — is a normal process, if it occurs transparently and is managed.

The estimate is not a fixed price05

One of the key mistakes businesses make — is to perceive the estimate as a guarantee.

The estimate is:

• a range,
• assumptions,
• a set of conditions.

A fixed price is only possible under:

• fully fixed requirements;
• in the absence of changes;
• clear architecture.

In all other cases, it is more accurate to speak of flexible assessment with phased review.

The role of analytics in accurate assessment06

Without analytics, the assessment will almost always be optimistic. It is analytics that:

• reveals hidden scenarios;
• helps decompose requirements;
• reduces the number of "unaccounted" tasks.

Our team in most projects considers analytics not as a separate stage, but as an investment in the manageability of the assessment.

Typical Mistakes in Project Evaluation07

Mistake 1. Estimation "by eye"

Occurs when deadlines and budgets are stated without delving into the task.

Mistake 2. Pressure on the estimation

When the team is forced to "fit" the numbers to business expectations.

Mistake 3. Ignoring risks

The absence of buffers almost always leads to failures.

Mistake 4. Mixing estimation and planning

Estimation answers the question "how much", planning answers "how and when".

Table 2. Mistakes and their consequences

Error	Consequence
No decomposition	Volume increase
No buffers	Deadline disruption
No recording of assumptions	Conflicts
No review	Loss of control

How to properly work with estimation in a project08

A mature approach to estimation includes several principles:

1. Transparency
   The client understands what the estimation is based on.
2. Ranges, not a single number
   This reduces the illusion of accuracy.
3. Regular Review
   The assessment is refined as new data becomes available.
4. Recording Assumptions
   What is considered the input conditions for the assessment.
5. Connection to Priorities
   Change in priorities = change in assessment.

Who is responsible for the project assessment09

Assessment is not the task of one person. In mature teams, the following are involved:

• analyst,
• project manager,
• technical leader,
• designer (in UX-sensitive projects).

The RUSO team in complex projects considers estimation as collective responsibility, not a formality.

Conclusions10

Project estimation is a management tool, not a fixed number once and for all. The more complex the product, the more important:

• transparency,
• flexibility,
• honesty in assumptions,
• regular updating of estimates.

Projects where estimates are used consciously develop predictably and sustainably.