Risk and Buffers
PMI's Pulse of the Profession 2026 reports that 31% of complex projects fail to deliver their intended benefits, up from 12% just two years earlier. The same study found that teams effective at handling complexity succeed 88% of the time, against 14% for teams that are not. Whatever else those numbers say, they say the standard risk toolkit is not keeping up with the projects it is supposed to protect.
VPM treats risk differently than most methods: the buffer and the fever chart are the primary risk instruments, and the familiar risk register plays a supporting role. This page explains why, drawing on chapter 9 of Project Management in Product Development (Ellis, 2016).
Why the register alone fails in development work
Traditional risk management asks the team to identify risks up front, assess likelihood and severity, and provide mitigations before the work starts. That works for project types with few unknowns. Product development and other innovative knowledge work do not qualify. The customer may reject the first value proposition, but you cannot know that until a prototype forces a real decision. A competitor may be granted a patent on technology your design depends on, but you cannot prepare for it until the patent publishes. These are what Loch calls unknown unknowns, and no register row written in week one will contain them.
There is also a cost limit. Past a certain point, more planning is unlikely to surface the issues that matter, the same way nobody plans for a breakdown on the drive to the grocery store. You check the gas, put on the seat belt, and go. Well-prepared projects still start knowing that surprises are coming, which means the team's ability to detect and respond becomes the deciding factor.
Two lines of defense
The 2016 book frames risk management as two lines of defense. The first is preparation: select the right team, use the right processes, and plan the project thoroughly. Done well, preparation quietly eliminates most threats before they ever get a name. The second line is response: identify the risks and issues that survive preparation, track them, react when they touch project goals, and report exposure honestly to the sponsor. No method guarantees success; the goal is the highest practical likelihood of success, with the smallest losses when a project does fail.
A useful distinction inside the second line: a risk is an event that might occur but is not yet likely enough to act on beyond monitoring; an issue is a risk that has matured to the point that the team must respond, for example by changing the design. A test that hints a product might fail certification creates a risk. A second test that makes failure all but certain creates an issue.
The funnel for named threats
For discrete, nameable threats, VPM keeps a simple risks-and-issues funnel: description, likelihood, severity, exposure (likelihood times severity), owner, mitigation, and a due date. Sort it so the items needing attention now sit at the top, and resist precision theater in the scoring. The rankings are subjective; elaborate scales add effort without adding truth. The funnel earns its keep in the standup and the leadership review, where it should read in seconds, like every other VPM view.
The buffer is the register for everything else
Here is the structural difference. A register can only hold risks someone imagined. The buffer absorbs the schedule effect of every risk, imagined or not. When any task on the critical chain slips, for any reason, the buffer burns and the fever chart shows it the same day. The team does not need to have predicted the supplier failure, the surprise patent, or the rejected prototype. The chart registers the consequence and trends it against time remaining, while options to recover still exist.
That is why a VPM project reviews the fever chart daily and the funnel weekly, instead of reviewing a sixty-row register monthly. The register answers "what specific threats are we watching?" The buffer answers the question sponsors actually ask: "is this project still going to make it?" One is a list of suspects; the other is the heartbeat.
See also
- Buffer Methodology
- VPM Buffer in Execution
- Toyota A3 — for working an issue once it has matured