Risks can be accepted, controlled, or transferred. Your project plan should certainly include risk analysis and recommended controls, but the risks properly belong to the project stakeholders. As the project manager, you should focus on documenting the risks and providing reasonable project controls for those risks that aren't accepted or transferred.
Targets vs. Estimates
Every project has a target. In most cases, the management targets for projects are unrealistic. For example, a project that is estimated with best-case scheduling and no slack in the process is unfortunately common, and will represent your best-case scenario for the project in question.
An estimate, on the other hand, measures what you think you know and then factors in your cone of uncertainty and other risk analysis figures to arrive at a more realistic estimate. The more you know about the problem domain, and the more you know about the risks you may face, the more accurate your estimates will be.
In general, you may find it helpful to offer your estimates as a range rather than a set of fixed numbers. The size of the range inherently implies uncertainty, which is really the point: you're making an educated guess based on a set of assumptions.
An alternate method is to apply a "fudge factor" to your estimates. This can be based on historical measures (e.g. your projects typically come in +/- 20% of the realistic estimate) or on risk tolerance (e.g. your project can tolerate schedule slippage <= 10%).
I'm a big proponent of transparency in planning, so if you go this route I'd certainly make a point of acknowledging that this figure is a fudge factor, rather than the result of a quantitative analysis. In Scrum, I typically apply a fudge factor of 0.6 for new teams, and 0.8 to established teams, but your mileage may definitely vary.
Explicitly Document Assumptions
Risk is never zero, and estimates are not guarantees. In general, I've found that the best way to handle this reality is to simply document them as part of your project assumptions.
For example, your project documentation may include a formal or informal risk analysis, as well as a target schedule or set of estimates. By documenting the assumptions that underpin your project plan, you improve communications and provide for contingencies at the same time.
Consider an imaginary project where you assume:
- a schedule variance of plus/minus ten percent,
- a budget variance of plus/minus ten percent, and
- a supply chain that will not deviate outside of your schedule or budget variance.
If any one of these assumptions turns out to be false at some point during the project, then stakeholders can re-evaluate. The organization may decide to take any number of actions if the project is out of tolerance, including changing the plan or canceling the project.
Your Role: Not a Guarantor
If you're selling fixed-price services, then you need to bake that risk into your estimates, too. Sometimes your organization comes out ahead, and sometimes it doesn't. If your organization can't tolerate that risk, then don't do fixed-price contracts.
Remember that your role as a project manager is primarily to apply reasonable controls to the project, and to routinely communicate the status of the project to stakeholders. Politically, project managers may get blamed if a project slides off the rails, but try to keep in mind that your role is to track the project and apply project controls. You can't actually guarantee an end result, nor should you try.
If you want to sell customers a pig in a poke, switch to the sales department. Otherwise, use your position to educate stakeholders about the scope and assumptions contained in your project plan, and be prepared to explain how you came up with the planning numbers that management and clients must approve to move the project forward.