'Risk-Driven' project management

Thanks for the response Steve; Once you have mitigated a risk to the point of no return with further effort (cost of mitigation exceeds the benefit of mitigation) you have to decide: 1) tolerate, 2) transfer or 3) eliminate (find another way or cancel). In many cases 2) and 3) are not available or acceptable and the tolerance level has to be adjusted.
Keeping in mind that the higher the tolerance level (95% confidence level versus 75%) the greater the cost (time, money or both) to get there if it is even possible to get there. From a schedule perspective, you may want to use probability theory to determine the duration for the 95% confidence. (there may be a 75% probability to complete in 90 days whereas 120 days will provide 95% probability. It does not mean the project will take 120 days it just means its more probable.

I think you have to look at this at the macro level - establish a best case, worst case, most likely total project duration - on the overall schedule rather than individual tasks. Unless you have unlimited resources, are not concerned with effective application of effort and can analyze each task independently. Once you have established the 'range' of completion dates you can get into the details to narrow it down as necessary through fine tuning tasks, looking at resource allocations and parallel tasks versus sequential. Make sure that the first impulse to reduce float is resisted. The available experience can narrow the range between worst and best case scenarios.
In cost estimates it is normal and acceptable to recognize inaccuracies thus allowing estimating contingencies as appropriate based on the Class of the estimate. Same concept should be applied to time estimates (schedules).

Thanks for the response Stephane; This brings me to my earlier comment as to recognizing value in project planning. Risk management is part of project planning. the Lean concept does not call for no planning but for just the right amount of planning. Only do what needs to be done to deliver the project. The question is, "How Much planning is just enough?". The project dictates that. Can I refer you to Scott Amblers papers: Planning, When Have We Done Enough and The Efficiency Zone.

In many cases we plan for the wrong reasons, even when we apply significant effort. The project management plans are developed as a result of process and procedural requirements, attached to funding requests, bound in impressive binders and placed on the shelf. Little effort is applied to updating and adjusting plans to reflect the reality of project implementation. When planning is the result of risk and benefit analysis there is a greater probability that that it will be a living document, that the plan will be used as a tool rather than taking up shelf space.
Working backwards in the development of schedule and cost details is not a bad thing. "This is what we want and these are the steps (tasks) necessary for us to get there." versus "These are the steps we are going to take and hopefully it will get us were we want to be."
Another key to establishing a realistic schedule is to apply the calendar only after the duration is agreed. Target dates too early in the process tends to bring in emotions rather than logic.
As a further note, budgets and times are not always solely based on scope and necessary effort, and are sometimes influenced by politics or management preferences - what can be approve. The full financial and time impact of the project may not be authorized - it may be considered more convenient to augment later. "Its easier to beg forgiveness than get approval".

I agree whole hardly with your comments about project plans. Project plans in themselves should only concentrate on the "ground rules" so to speak about how various aspects of project management will be managed. For us, since we have a phased approach, our "phase" plans will speak to what it is we need to achieve to get to the next phase. It is to provide some substantiation for senior management that gives them confidence in what it is you are doing in each of the phases. For myself, the schedule for the most part is the "plan".
I also agree there is nothing wrong with working backwards, however problems arise when one quickly realizes after some detailed planning that those initial dates/ budgets are not achievable. It then gets really bad, when the sponsor refuses to change the dates and/ or the budget. At this point, logic does not apply in its truest sense. The logic being applied is by those, who themselves do not understand the timelines involved, but instead have made commitments (usually finance related) without consulting with those that must execute the projects. It is a lose-lose scenario that I have seem time and time again. This all goes back to proper planning IMHO.
Your last comment is particularly relevant, as for us in the government, this is often the case of much angst.

This is when the risk or probability of achieving the decided result kicks in. You don't tell the client/owner that their objectives can't be achieved - you explain that the probability is low with a high risk of failure. Then you explain what failure may mean in terms of cost and time. You may also wish to advise what can be done to mitigate the failure within the imposed constraints. I know its not easy, and may be hazardous to your job as PM, however nobody said it was going to be easy. In my experience too many PMs accept the impossible task afraid to push back or don't see it as worthwhile. Ultimately it will come to roost and the client/owner will have to pay.
I've seen owner/clients that have suffered numerous project failures and look to change the project delivery process - say from traditional to Lean or Agile - without looking at the root problem. Doesn't really help.
Note, project failure does not mean total collapse, to me it means failure to one key objective, client satisfaction.