Suppose your project will not comply with the expected deliverables, how can you change the expected failure and still have succes?

It all depends on the client you are working for, if they are ready to accept the changed deliverables then there is still some chance of success, otherwise its a complete failure.

What I will say may be out of the project management guidelines, and is more to be a pragmatic approach, but this is what we are sometimes forced to do.
If a project does not achieve all deliverables does not mean we need to stop the work (of course, you were intending to do this for the right reasons, but no one will appreciate this, especially a sponsor who has her/his job on the line of having a successful project).
The first thing we need to think about, is what are the deliverable(s) that could be compromised for the project as is, identify the impact of this (these) deliverable(s) not achieved, evaluate the pros and cons for altering any of the project constraints to get all deliverables done.
Try to separate the activities with issues from the ones that are on track, or could come on track easily, rethink about all activities, what is really a core activity and what is a peripheral (good to have, but not essential), see if you can stay on track if you remove peripheral activities.
If the deliverables that are facing challenges are in the critical path, then we need to really think about it from resources point of view, as fast tracking and crunching techniques require adding people and/or consuming overtime (and add costs subsequently).
Approach project sponsor / steering committee, and present the alternatives you got, if there is something that need to be de-scoped, ask for it, better de-scope than settle with less quality outcome for all deliverables or failing to get the acceptance in the end.

By re-examining the situation and desalination for all the weaknesses of the project and strength, as well as members of the team and their functions and the ability of each individual to carry out his duties entrusted to them and to develop plans to convert weaknesses that increase the risk of failure to positive factors may need to turn or change some roles or people team

First , if your project would not achieve your deliverable, ALL project work should be stopped.
Evaluate if the project should be closed out or you have a change control mechanism to accomodate the changes in the same project.
Work with stakeholders to establish the changes required in the project and come out with the new project plan.
Once the new plan is acceptable to all stakeholders and sponsor and would help in achieving the deleverables , the old project is re-baselined.

In the only event that the client discusses the deliverables with you and is ready to alter the deliverables to suit what you can deliver.
Otherwise it is a failure.

The problem statement: Scope cannot be verified Issue: This is a caused by weekness in Monitoring & Controling processes (Especially Quality Management) How to deal with it: Do Impact analysis, invoke Change Control and negociate between scope, time or cost.
My2 Cents: If any form of formal Project Management methodoily is in place this kind of risk will be highlighted very early in lifecycle, giving time for risk avoidance / mitigation. 
Secondly, normally projects are based on business objective and the end product is serving a larger program.
This means you can almost always find some sort of contengency & Management reserves.
The project will only fail only if the PM is not doing its job and could not identify the issue in time for corrective action.
In this case the only success for this project will be in Lesson learned whitepapers :)

In the Agile world, it is commonly expected to not have clear requirements and this was one of the main reasons why Agile came to light. Thus iterations are meant to quickly deliver a shippable product which will be demonstrated to the client at the end of each iteration and give them a chance to provide feedback whether they would accept it or help them to further define the requirements. Of course, time to deliver can only be estimated because we are more concerned about meeting the scope, which was merely defined when the project started. Agile is the best approach when requirements are not fully defined but if the customer already knows what they want then the traditional PM methods defined by the PMBOK is the right approach and it is the PM's responsibility and obligation to meet that otherwise the PM must admit project's failure and wrap up the contract to stop additional financial losses.

The moment you identify the risk in expected Deliverables, immediately identify the root cause of the risks / issues, work on plan to mitigate them. High light the challenges to the team to get their full support and effort. Also present the current situation to the client and share the plan how you are mitigating the risk (expected failure). If the problem or delay from customer side, high light the same to speed up things like sign off or clarifications from customer side. (if possible  get a minimal  extesion for the impacted modules to avoid rework). List the activites / modules whicha are in track and make sure it is not getting impacted by the unfinished activites / modules. Work on revised plan on war footing basis to ensure successful delivery and keep the customer informed about the progress to get their confidence which will help their internal planning. 

 

Apply the DMAIC six sigma Approach

Thank you for the invitation

A radical study of the causes of failure

Displacement causes failures

Development of logical solutions

Application on the ground

The ruins of what must be lost to avoid the biggest loss

Consider the causes of future failure to avoid it

Develop effective monitoring system and coordination with donor for updating about current progress time by time. if the deliverables were not achived as set required changes in model should be recommened wit the consultation of sponor. supporting data is required for this positive change in model.