There are several project management "errors" to be found in PMBOK. One is the concept of performing math on the risk matrix. Figure 11-8. Probability and Impact Matrix in PMBOK 2003 describes how the probability of occurrence and impact on the project once this occurrence appears is computed. They are multiplied together to produce a "risk rank." Turning to Department of Defense Risk Management Guide for DoD Acquisition, Fifth Edition, June 2003, §18.104.22.168.1 - Risk Ranking and Prioritization Ranking, pp.18-21. Quoting from the Guide...
Risk rankings are an indication of the potential impact of risks on a program
In most cases risk scales are actually just raw (uncalibrated) ordinal scales, reflecting only relative standing between scale levels and not actual numerical differences
Any mathematical operations performed on results from uncalibrated ordinal scales, or a combination of uncalibrated ordinal scales, can provide information that will be misleading, if not completely meaninglessly, resulting in erroneous risk rankings. Hence mathematical operations should generally not be performed on scores derived from uncalibrated ordinal scales.
Strong language from a competent source
One approach is to show each risk's probability of occurrence and its impact separately, with no calculations between them. This is usually done in a matrix that colors the intersection of the probability of occurrence and the impact Green, Yellow, or Red For a better source (and a free source) of this topic and all other topics in PMBOK, see the Department of Defense version of PMBOK. You can ignore the gory DoD parts and read through the concepts of how to manage a program or project
The aerospace and defense (A&D) project we work are different from IT projects for several reasons:
Mission - there is usually a clear cut mission? Fly to Mars, build and fly some kind of machine, build some kind of software that flies or works on the ground processing data from flying machines. This "Concept of Operations" approach to defining the mission, along with the Statement of Objectives, the Mission Description and other "descriptions" of what done looks like are the shared communications between user and supplier.
Firm Fixed Price Plus Fee (FFPPF) - many contracts today are semi-fixed price. The control of funds is a critical success factor. Incentives for performance is common. Technical Performance Measures along with Testable Requirements are the starting points for a conversation about "what are the units of measure of success?"
Safety and Mission Assurance - with expensive machines comes expensive failures. At worst people die. At best they almost die. The concept that a separate, independent, informed observer that asks the question - "will this thing actually work when it's done?" is the starting point of Mission Assurance.
Systems Engineering - the systems engineering paradigm is the basis of A&D projects. It starts with requirements allocation and ends with end-to-end integration testing. Along the way is interface management, trade studies and lots and lots of conversations about the behavior of the "system."
Accountability to the end customer - the war fighter, astronaut, ship's captain, ... are all customers. The providers are accountable to the users.
So what's missing from the typical IT "train wreck" we see in enterprise development? Ask if any of the above are present in any form? They don't have to be full DoD compliant. Just some form, any form.
What's the role of Planning? Planning of any sort? Full on DoD 5000.2 Program Life Cycle planning? Or XP planning game played every other week with the small group of developers and the customer in the same room? Planning looks forward, in to the future. Planning looks at what needs to happen, what could happen, and what actions need to take place if any of those two things were to happen. One concept missing from many discussions about planning is what does done look like? The agilest will tell us that "done" emerges from the development process. This of course is not true nor actually possible - event in the simplest of projects. Unless you're spending your own money doing artistic work would an unplanned expenditure of time and money be possible. Even the greatest artist has a "vision" of what "done" looked like. So why all the resistance to Planning? This is not just resistance from those claiming project management is not necessary in their special methodology. I encounter this resistance on large complex programs as well. "We're too busy doing real work to work on plans and schedules," is a common response. Some times it actually is a matter of "not enough time." But there is something else here. A natural resistance to defining outcomes, committing to the actions needed to make those outcomes appear - in some form, and the accountability to those commitments. Ask one of our 18 year olds, "when are you coming home from the movies?" "Gee Dad I don't know yet, it depends on what we do after the movie." The teenagers in our house have a planning horizon of about 2 hours. That's how they view the world at times. At other times the horizon is much longer. The college application essay has been worked on for several months now. Cross Country practices are planned a month ahead with specific training intervals. The concept of a planning horizon can be used to guide the planning need:
How long are you willing to wait before you discover that the current activities are not producing what you wanted in terms of desirable outcomes?
By the way, what are those desirable outcomes? Be they "fun" on the Pearl Street Mall, better climbing muscles for the upcoming Century ride, a software feature requested by the customer, or "being there, on time, on budget, and on spec" for the launch of the spacecraft? (Probably only the Pearl Street Mall "fun" is emergent.)
How long are you willing to wait before you discover you are behind schedule and over budget or off spec for any of these things?
These type of questions need to be asked when someone pushes back on the planning - and the supporting scheduling - processes.