To most of us, the problems with fixing cost, scope and time are obvious. How do we know we can deliver all of the scope, in the time we’ve been given, with the people we have to do it?
The short answer, is that in most cases you can’t especially if you want to be able to respond to change and maintain the quality of your product. The concept of the Iron Triangle helps us understand the problem. It tells us that in order to maintain the quality of our product, that we can only ever fix two corners of the triangle.
In a lot of software development projects our cost can be defined as the cost of our people, the development team, which has a fixed size. You may be able to bring more people onto a project, but that can have many negative effects (see The Mythical Man month). Time (or schedule in the diagram above) could be defined by a given deadline, or by estimates provided by the development team that are being used to calculate a delivery date (see my post: To estimate, or not to estimate: That is the question for my views on how to work without estimates). Scope is defined as the project objective broken down into requirements for delivery, plus any change that occurs during the project life cycle.
If we assume a fixed cost, then either the scope or the time has to be flexible. If time is fixed, then we have to work on requirements in priority order until we have run out of time. We then take a decision with our customer as to whether to continue working (thereby adding more cost), based on the value of the scope we haven’t yet delivered. If scope is fixed, then we will continue working on requirements in priority order until we have delivered everything that was requested.
Ultimately, by focussing on the Principles behind the Agile Manifesto, delivering value early and then throughout a project, discussions about fixed time and scope are moot, with requirements evolving based on feedback from customers, and the decision to stop, an easy one to make at any point given the value already delivered.