'Risk-Driven' project management

I did a quick read-through of the presentation and am intrigued by a couple concepts. One is the use of trending - brings me back to my earlier days when I relied on S-curves to track project progress and predict outcomes. Second is the idea of success being based on a range of values (optimistic, target and worst case - makes me think of probability analysis) rather than specific scope, costs or dates. I need a more detailed read to fully understand the application/implication of risk analysis. I may have more comments in a couple weeks.
Thanks for the reference

Let's make sure we define risk broadly to include project benefits which in many circles are considered negative risk. So, that being said, all project decisions must be based on either 1) reduction (mitigation) of risk and/or 2) enhancement of benefit. Note that there can be decisions made outside the project without project consideration which can have an influence on the project. Risk or benefit must be identified by the project at that time and analyzed for extent of impact and mitigation measures identified.
You are correct that decisions, without exception, present new risks and benefits which must be analyzed at the time to determine if tolerable or mitigation measures be put in place.Every action has a reaction, some good - some not so good.
Some will argue that the action of risk identification and analysis in itself is one of the best mitigation measures available. The concept is to eliminate as many surprises as possible - surprises are rarely positive.

Vladimir;
In an earlier post you make reference to the "cost of time". This is an important concept however one has to consider the challenge of attaching the appropriate value to time.
1) The cost to the owner of not having the deliverable (operational costs and lost profit). These cost may be variable and could be mitigated depending on specific circumstances. One must also be aware of "drop-dead" dates (at some point the deliverable may have zero value); and
2) The project costs of extending the delivery duration including staffing and contractual commitments (construction claims). These cost can vary based on the phase in which the delay occurs. Also subject to mitigation and critical milestones.
I'm not saying costing time is impossible but it may not be as simple as one would hope.
One also has to consider that the final deliverable may be made up of a number of secondary deliverables (tasks within scope of work). Delays in certain tasks may have different cost impacts. As an example - delay in delivering a parking lot may have significantly less cost impact than delay in delivering the associated manufacturing facility.
All these factors can be accommodated when applying Risk Driven Project Delivery. Properly applied you are always focused on what's best for the project deliverable (minimum risk, maximum benefit).

Yes, Peter, you are right.
Cost of time must be applied not only to the project as a whole but also to intermediate milestones and is different for different project stakeholders.
We model costs of time using hammock activities that start from the optimistic and finish at the expected date of certain milestones in the current schedule. In the portfolio schedule delays in the current project may generate cost of time in the connected projects.
Yes, we use this when create project models and simulate project risks.

But this concept of cost of time is most useful for justifying project decision making,
When project managers need to take decision if it makes sense to use additional resources for project acceleration integrated project success criterion that includes the cost of time shows if this decision is justified.

The models we create and use include these hammock activities with assigned cost of time and help managers with decision making. And yes, costs of time are different for Clients and Contractors and they use different models.