Huh? How can that be possible? It is not as strange as it sounds. All three products had functions for tracking the hours worked by each project member, multiply it with the hourly cost, and sum the costs for all project members, like this:
project cost = Σ(cost/hour * hours)
A simple formula, but there is something missing. Try this one instead:
project cost = Σ(cost/hour * hours) - profit
The profit here is what the customer earns from getting frequent partial deliveries during the course of the project. (It's not the total profit from the project. Oh, how I wish for MathML support in more browsers.)
In a waterfall style project, with a single delivery at the end of the project, the profit will be 0, because the software won't be used until the project is over. On the other hand, in an iterative project with frequent deliveries, such as an XP, Scrum, or FDD project, the profit may be substantial. In some cases the profit is higher than the cost of development, which means a project pays for itself even before it is finished. (I won't go into the details of how to do a Cost/Benefit analysis here.)
The problem is that by focusing only on the costs, a project manager, and other stakeholders, get a flawed view of the economic viability of a project. This is bad because it is economics that drive project decisions.
Should we add more people? Should the project be cancelled? Should we reduce the project staff? Where should we focus our efforts? The decisions are all heavily influenced by the economic model of the project.
For example, if a project can make a delivery every two months, it may be worth while, but if the deliveries are every four months, it may not be. With this information at hand, a project manager can take measures to shorten the delivery cycle, for example:
- Reduce the size of use cases (for example by splitting large ones into smaller ones) to reduce batch sizes.
- Make sure to use developers that know how to write unit tests, to ensure that the software is more stable during development.
- Use automated builds and testing.
- Prioritize features so that the most important ones (from the customer's perspective) are tackled during the first iterations.
- Reduce iteration length to get better control of the state of the system.
With a flawed economic model as the basis for decisions, the wrong decisions will be made. If a flawed model is built into the management tools, it becomes very hard to detect it. Most project managers I know just trust the tools.