Why Software Projects Drift Away From Their Original Goal

A team is building a customer portal to reduce repeated status enquiries. During development, it adds a reporting dashboard, new account fields and a more elaborate notification centre. Each request sounds reasonable. The first release still cannot show customers a dependable status because the source information has not been resolved.

This illustrative project is active, but its original constraint remains. Progress measured only through completed features can make that difficult to see.

Write the goal in terms of a user and an outcome. For the portal, customers should be able to understand the current state of their request and know when action is needed. The application’s features are means of achieving that result.

The GOV.UK discovery guidance starts with understanding the problem and constraints. Preserve that understanding after discovery. The brief should remain a reference for delivery, rather than disappear once a design or estimate is approved.

The goal may change when evidence warrants it. What matters is that the change is deliberate and visible. Quietly accumulating requests can produce a different product without anyone deciding that the original objective should be replaced.

A development team needs input from different parts of the business. It also needs a way to resolve conflicting requests.

Name a client role with authority to order the work and make trade-offs. That person should understand the intended outcome and have access to the colleagues whose knowledge is required. They do not need to invent every answer personally, but they must be able to obtain a decision.

The Scrum Guide formalises product ownership and an ordered backlog. The underlying responsibility is useful even when a project does not use Scrum: someone must maintain a coherent order of work.

Avoid confusing ownership with a meeting schedule. A weekly meeting can still end with unresolved questions, contradictory instructions or decisions deferred indefinitely. Record what needs deciding, who can decide it and when the answer affects delivery.

The technical team should explain consequences in business terms. A requested feature may delay a critical integration, create a new permission requirement or increase operating cost. The owner needs that information to choose responsibly.

Give the owner a backup route during absence. A project that depends on one unavailable executive can lose direction through delay as easily as through too many requests.

Also define who can accept completed work. Demonstrations are useful opportunities to compare the product with the intended task, not only to gather more ideas for the backlog.

Agree how conflicting feedback is resolved after a demonstration. Capture the disagreement, identify the business consequence and give the owner the information needed to choose. Sending contradictory comments directly to developers can leave them making an unintended commercial decision while believing they are simply following instructions.

Change is part of software development. The objective is to make its effect understandable before the team commits to it.

For a significant request, record the problem it addresses, the expected value, the evidence and the effect on the current plan. Keep the record short enough to maintain.

This example is illustrative. The value lies in showing the trade-off, rather than treating a new feature as a free addition to an unchanged commitment.

Some requests can be resolved by clarification, configuration or a process change. Others belong outside the product’s current scope. Assess the need before assuming the answer is development.

Do not let estimates become the only deciding factor. A small feature can distract from an important unresolved dependency. A larger task may be necessary to make the first release usable.

A project stays coherent when each important addition has a reason and an acknowledged cost.

Keep rejected or deferred decisions briefly recorded too. Otherwise the same request may return repeatedly because nobody remembers why it was not pursued.

A milestone should show progress towards the business outcome. “Five screens completed” says little about whether a customer can finish the task.

Choose a small end-to-end capability. For the portal, that might be viewing a current request with an accurate status and a clear next action. It should include the underlying data path, permissions and important exception states.

This exposes dependencies earlier. If the source system cannot provide a reliable status, the project needs to resolve that issue before investing heavily in the interface around it.

Agree acceptance criteria using realistic cases. Include an ordinary request, a missing-information case and a change after submission where relevant. The business should see how the service behaves under the conditions it will actually face.

Review benefits alongside delivery. GOV.UK’s service-benefits guidance links expected improvement with a baseline. Keep the original measure visible so the team can distinguish shipping from achieving the intended effect.

A first release may provide learning rather than the full expected benefit. State that clearly in the decision record. If the purpose is to test customer understanding, the review should examine that evidence rather than imply the whole operating problem has been solved.

Avoid using milestone reviews to approve an ever-expanding set of unrelated changes. Capture new ideas, assess their importance and decide where they belong relative to the current goal.

If the team cannot explain what the next release is meant to accomplish, pause the addition of new commitments and review the current position.

Restate the business problem using the evidence now available. Identify the work already completed, the remaining blockers and the features that no longer support the priority. Separate unfinished necessities from optional improvements.

Then define a credible next release. It may be narrower than the original plan, but it should deliver or test something complete enough to matter. Preserve useful components where they fit, and avoid continuing low-value work solely because effort has already been spent on it.

Reconfirm roles and decision timing. A revised plan will not hold if the original ownership gap remains. Make dependencies on client information, supplier access and commercial decisions explicit.

Use a short decision summary after each material review: what changed, why, who agreed and what it means for the next milestone. This gives new participants a way to understand the project without replaying every conversation.

For a software development project, direction is an ongoing responsibility shared through clear roles. The business owns the intended value; the delivery team makes the implementation choices and trade-offs visible. Together, they can keep the next release connected to a result worth completing.