A software development project is an endeavour to deliver a specific Scope (features) that customers and stakeholders find valuable before a Release Date, within a Budget, and with good enough Quality.

Specifically, projects provide the following benefits:

• Coordination. The project facilitates coordination between multiple teams, enabling us to build features that no single team could build independently. Coordination cost grows with organisation size. In a startup, it’s low, and you may not even need a project to coordinate. But in most organisations, you need a project to get things done with multiple teams.
• Constraints. The software project puts much-needed constraints on development. Time is the best constraint. With time constraints, solutions are not tweaked forever — there is a sense of urgency. This is essential for software development, as it is for any other creative endeavour.
• Structure. Ideas are cheap, and maintenance of the legacy is never-ending. With abundant ideas and legacy work, it’s easy to get overwhelmed. With projects, we can schedule work and available resources and manage expectations with customers, sales, and marketing regarding what we plan to do soon.

The Iron Triangle constrains projects: Scope, Release Date, Budget, and Quality; pick any three. You can only optimise for three of the four. They are interconnected. If you increase the scope, time, quality, or budgets are affected, too. A project delivered on time, within budget, and with the full scope of features certainly has low quality — or is an illusion.

The Date is set for what we must assume are good business decisions. Black Friday does not move; sales must start at a specific time to meet a business target. The Budget refers to resources, and adding more people to a software project is known for slowing it down. Lowering Quality always results in some variant of a return rate: a delayed cost with bug fixing and customer support.

The best way to manage a software project is to constantly refine The Scope and fix the other at a good enough level.

Continually refining the scope means delaying decisions to the last moment. This is valuable because decisions can be made with as much empirical information as possible. However, it is also challenging to avoid causing project delays, additional costs, or lower quality.

The best way to refine the scope is to develop in small incremental steps and iterate based on feedback. This, known as empirical process control, is the fundamental theory in agile methodologies. It relies on transparency (an accessible backlog of all work), frequent inspections (by customers and stakeholders), and adaptability (project scope can change at any time). Agile processes — such as the SCRUM Framework and Extreme Programming (XP) — are based on this thinking. Making decisions as late as possible is also the cornerstone of lean development pioneered by the revolutionary Toyota Production System (TPS).

However, making decisions late in a project without taking a penalty for delays, quality, or cost is tricky. This is why the first approach to a software development process was to make the right decisions early and avoid changes later — the so-called waterfall model. This, we know today, does not work well because of the many unknowns in software development. And not when a project is part of a product-market-fit discovery phase, where nothing is known before the first customer signs up.

But delaying decisions until the last moment is not the whole story. To make it work without taking penalties, it assumes a rapid development process where the project goal is kept steady in front of every engineer who is doing the work, empowered teams make decisions without a central authority, and flexible software design where the marginal cost of change is low and no decision is irreversible. These things must be in place, or delaying decisions will cause more harm than good. Without speed, you cannot delay decisions.