Almost all decision problems involve the simultaneous considerations of different objectives that are many times in conflict.
In the software development world this might be characterized by a customer wanting a set of features to be delivered for a budget on a certain date so those features can be put to work earning back their cost.
Since the list of features is likely to needed to be developed in a specific order with varying costs, the question is what features should be done first and what features down next.
The traditional response from an agile developer is the define the value of those features and produce them in that order. What is the unit of measure of value. That's rarely stated. But along with the Value is the cost of that value and other attributes of the development process. Risk, resource demand, inter dependencies between other features, inter dependencies between these features and external processes - the externalities of all complex problems.
The formal discipline is this process is called Multi-Criteria Decision Analysis (MCDA). MCDA has the following elements:
- A goal, objective, or criteria to be achieved
- A need to be fulfilled
- Constraints and requirements associated with and affected by the decision
- Decision options or alternatives
- The Environment in which the decision must be made
- The Experience and background of the decision makers
The methods to solve these types of problems started in the 1950's with Churchman and Ackoff, and were axiomatized by Debreu in 1960, along with Luce and Tukey, Krantz, and Scott.
The principles in these early papers and the continued development of multi-criteria decision making have now moved to nearly every domain where scarce resources, probabilistic outcomes, uncertainty of the impact of the decisions, and value at risk is high enough to ask the question
What will be the outcome of this decision on the future of the processes, cost, technology, environment, or any other external domain?
So when we hear that
- Decision making frameworks for project that don't require estimates.
- Investment models for software project that don't require estimates.
- Project management (risk management, scope management, process reports) approaches that don't require estimates.
We have to wonder if these frameworks, investment models, and project management methods have come in contact with the reality of how business works. As Carl saying in a somewhat harsh manner
Extraordinary claims require extraordinary evidence. Carl Sagan
