Problems begin much earlier: when the goal is understood differently, project scope expands without control, and critical decisions are postponed to "later".
The larger the project, the more dangerous it is to assume that all participants think alike.
The most common reasons why projects start to lag, become more expensive, or lose direction.
1. Different people envision different outcomes
At the beginning of a project, it may seem that everyone is talking about the same thing.
The manager expects a faster process.
The sales team – more convenient work with clients.
The IT team – clean architecture.
Users – as few additional steps as possible.
Programmers – clear rules and decisions.
During project planning, at the beginning it seems that all parties equally understand the future solution. The problem becomes apparent when a concrete result starts to be demonstrated.
Vienam „paprasta savitarna“ reiškia prisijungimą ir dokumentų peržiūrą. Kitam – visą užsakymų, kainodaros, mokėjimų ir komunikacijos aplinką.
How to solve this
Before programming, it's necessary to agree not only on the list of functions, but also on what the final solution will look like.
This is helped by:
clearly defined core user journey scenario
high-quality system prototype
predefined risk list
detailed solution description
stage and work plan
project participant approval and commitment to responsibilities
If decisions are made based solely on assumptions or hasty agreements, different understanding emerges too late and becomes one of the main causes of project problems.
2. It's unclear what is essential and what is simply „would be good“
In many projects, features are compiled into one comprehensive list.
Login, order history, reports, notifications, exports, complex roles, additional filters, personalization – everything seems important.
However, not everything is equally important for launch.
Kai nėra aiškios ribos tarp būtino funkcionalumo ir pageidavimų, projektas pradeda augti dar neprasidėjęs. Programavimo komanda negali planuoti, nes kiekviena nauja idėja tampa „dar vienu mažu dalyku“.
How to solve this
Each function must be assigned to one of three groups:
Required for launch
Without this function, the solution cannot fulfill its core purpose.Important, but can wait
The feature is useful, but doesn't prevent launching the first working version.It would be good
The idea has value, but is not yet important enough to make it into the first stage.
This is not a formality. This separation directly determines the project's cost, timeline, and the likelihood that it will be completed and achieve its intended goals.
3. Decisions are made too late
Developers can move fast only when it's clear what needs to be built.
A project starts to stall when questions remain unanswered:
who can see specific data;
which system is the primary source of information;
how the price is calculated;
what happens in exceptional cases;
who approves a particular action;
what data needs to be migrated.
Until a decision is made, the team either waits or builds based on assumptions. Both options are costly.
How to solve this
A project needs a clear decision-making model.
It must be known:
who is responsible for business decisions;
who approves the design;
who is responsible for information required for integrations;
who makes the final decision when opinions differ;
within what timeframe a response must be provided.
One of the most common project blockers is not the project's complexity, but improper distribution of responsibilities.
4. The process is being adapted to the system, rather than the system to the process
Sometimes a project starts with features, without understanding how people actually work.
The process looks clear in the document. In reality, employees have exceptions, workarounds, additional checks, and information that no one had documented.
If the system is built according to an idealized version of the process, it becomes clear upon launch that it doesn't fit day-to-day work.
Then additional fields, exceptions, new states, and "temporary" solutions appear, which gradually become permanent.
How to solve this
Before designing the system, you need to understand not only the official process, but also the actual work.
It's worth finding out:
how the process works today;
where employees deviate from the official procedure;
which exceptions occur most frequently;
which information is received too late;
which actions are duplicated;
what people solve outside the system.
Only then can you decide what's worth automating, what to simplify, and what doesn't need to be transferred to the new system at all.
5. A deadline is set that doesn't match the project scope
An ambitious deadline isn't a problem in itself. The problem arises when the date is set before assessing the scope of work, dependencies, and decisions that will need to be made during the project.
Sometimes the deadline is chosen based on an internal event, marketing campaign, management expectation, or the desire to complete the project by a specific date. However, a date alone doesn't reduce the amount of work required.
When there's pressure to meet the deadline but the project scope isn't reduced, several things usually happen:
insufficient time allocated for planning and prototyping
development begins before important decisions are made
testing is left until the end of the project
bugs are fixed hastily
short-term technical solutions are chosen
the team tries to complete too many features at once
At first glance, it seems that such pressure accelerates the project. In practice, it often creates the opposite result: more fixes, poorer quality, unpredictable launch, and additional work after it.
In the worst case, the system is launched on the scheduled date, but is not yet ready to reliably fulfill its purpose.
How to solve this
The deadline must be aligned with the project scope, not simply passed to the team as a fixed condition.
If the date is truly important, one of several paths must be chosen:
reduce the functionality of the first phase
split the project into multiple launches
first implement one fully functional process
postpone less important integrations and additional features
allocate sufficient time for testing and corrections
clearly identify what risk is being accepted due to the shortened timeline
When date, budget, and full functionality are all fixed at once, the project usually has no room for rational decisions.
The real timeline is not a team's safety margin. It's an estimate of how much time is needed not only to write code, but also to make decisions, test the system, and prepare it for use.
6. The project is treated as one big launch
The longer the team builds the project without demonstrating working results, the greater the risk of going in the wrong direction.
Large projects often stall because the 'entire system' is built for months, while actual use only begins at the end.
Then everything becomes clear at once:
some features are unclear to users;
some processes are designed incorrectly;
missing critical exceptions;
integrations work differently than expected;
some features weren't needed at all.
How to solve this
The project needs to be broken down into smaller working stages.
Each stage must have a clear result that can be demonstrated, tested, and evaluated.
For example:
Login and user permissions
Core process
Integrations
Documents and notifications
Reports
Additional features
This allows you to identify incorrect assumptions earlier and avoid investing too much in a solution that hasn't been validated in real work yet.
How to reduce project stagnation risk
A programming project doesn't need a perfect plan where everything is predetermined.
However, several things are essential:
a shared understanding of what outcome we're building;
a clear boundary between essential and additional functionality;
a unified decision-making model;
a managed change process;
analysis of the actual process;
development in stages and regular evaluation of achieved goals.
A good project is not one where nothing changes.
A good project is one where changes are noticed early, evaluated consciously, and don't cause the main direction to be lost.
Clarity must come before code
Most project problems are caused not by programming itself, but by decisions not made before it.
Therefore, before starting, it's important to agree on:
what we're actually solving;
who the system is being built for;
what should be included in the first stage;
who makes the decisions;
how we'll evaluate whether the result is successful.
When these questions are answered, programming becomes predictable, uncertainty decreases, it's easier to plan time and budget, and the team can focus on quality implementation rather than constant direction changes.