Bad Decisions? Yea, That's the Problem

On the current PMI site there are several Blog's. Greg Balestrero, the PMI President points to a McKinsey Survey on IT and Michael Hatfield speaks about the core problem of failed projects.
    Michael states

So, what is the main causal factor? (After listing several causes that are not the problem) The project manager and/or project team made bad decisions.

    But what does this means really. How can we make good decisions? Yes we know the ability to make good decision is critical to a project's success. Michael states the delivery of cost and schedule information is important. Yes, that is important. But I have been directly involved in several ERP projects where cost and schedule information was available and the projects were still 100% overrun in time and cost.
    The problem is not that the information is not available. If it is not available there are serious other problems. The problem is there is not actionable outcomes from having this information. Management decisions are uninformed. Management decisions are driving in the dark. Maybe driving in the rear view mirror at best. Having cost and schedule information from last months numbers is just that - driving in the rear view mirror.
    Here's what's really needed:

1. A description of what "done" looks like for every deliverable and every incremental progress measure that moves the project forward to that deliverable. Here in defense this is called "describing the increasing maturity of the program."
2. Having some measure of physical percent complete. These means having tangible, physical evidence that something has been accomplished. Like the previous post, these means testing the system against the requirements. Testing the code in the absence of this approach is nonsense.
3. Making informed forecasts using probabilistic models of cost, schedule, and techncial performance. Techncial performance is "product performance," in some unit of measure traceable to the products quality or ability to perform. The simple example in defense is the mass of the space craft. Does the mass fall within the boundaries of error at this point in its design maturity? If not, it's going to cost more, or take longer, or both to get that issue under control.

    So Cost and Schedule data is necessary. But it is not sufficient. Techncial Performance data is needed. And then actionable decisions based on future performance estimates - using some form of probabilistic modeling (Monte Carlo is mandated by DoD) - for what is going to happen in the future if we kepping doing what we did in the past. This is how to make use of the "driving in the rear view mirror" data.