What’s your opinion on "failure being a valid option"?

Failure as an option, according to me is perfectly fine. Like Thomas said, Failure for a project at an early stage is to ensure lessons are learned and new course taken up. Failure is not to be taken as a personal affront but means to ensure timely action is taken when project is not doing well.

While it is unwise to keep investing money in a project that no longer has value, frequently executives do not like to accept defeat and justify continuing or claiming success by some other rationale.

I remember the goal of one major IT project was to eliminate all "legacy" software programs by the end of the year. When it turned out that was completely impossible let alone impractical, legacy software was renamed "classic client" and victory was achieved...sort of.

This reminds me of Kennedy's challenge to land a man on the moon- the classic example we use when discussing constraints and Conditions of Satisfaction. The basic idea is that a project may have defined CoS (man on the moon (scope) / end of decade (schedule) / within budget (budget) / return safely (quality)) that define success, but there's often one primary criteria that must happen even if others fail. In the moonshot, schedule was supreme. Failure was an option when it came to budget and, to a degree, safety, so long as NASA was first to land a man on the moon.

I think your second definition is actually correct.

Maybe changing "failure (to complete delivery)" to "unable to complete delivery" is a truer representation of the option? If the business or project environment (including business needs) changes significantly then the appropriate outcome may be "stop the project". Is that failure? What if the most important benefits were realised?

Also I think the Project Summary or Closure Report is the opportunity to discuss "failure" and "ideally" learn from the experience.

Interesting question George, in my time I've come across this scenario twice. The first time was in a network development area where we trying something new that had never been accomplished before, sending a new protocol over a Satellite link to try and replace data modem connectivity. There were multiple scenarios to test and the sponsor had stated that failure of all of these is acceptable as long as we understood why each one failed. Luckily we found a scenario that worked eventually after many trials and tweaks.

The second one was on a recovery project, the key stakeholder group were all very hot under the collar that the project had failed to deliver so far, the main deadline was looming and they wanted everything delivered as per the original timeframe, scope and quality (the budget was already blown). After a review of the project status and what was left to do we presented the findings to the sponsor and he agreed that failure to meet the original timeframe and spec was impossible so failure to meet the demands of the key stakeholder group was acceptable.

In a lot of other cases where project timeframes have been set by an arbitrary body, not the project team and realistic estimates rejected resulting in a project doomed to failure some sponsors understand this and some don't.

Acceptable failures need to start off with a project that is set up for success, when all the pieces are in place only to find out that it cannot be done technically, or will cost too much, take too long to get to market therefore not meeting the revenue targets, and needs to be stop to reduce the impact then that is acceptable failure.

Interesting question George, in my time I've come across this scenario twice. The first time was in a network development area where we trying something new that had never been accomplished before, sending a new protocol over a Satellite link to try and replace data modem connectivity. There were multiple scenarios to test and the sponsor had stated that failure of all of these is acceptable as long as we understood why each one failed. Luckily we found a scenario that worked eventually after many trials and tweaks.

The second one was on a recovery project, the key stakeholder group were all very hot under the collar that the project had failed to deliver so far, the main deadline was looming and they wanted everything delivered as per the original timeframe, scope and quality (the budget was already blown). After a review of the project status and what was left to do we presented the findings to the sponsor and he agreed that failure to meet the original timeframe and spec was impossible so failure to meet the demands of the key stakeholder group was acceptable.

In a lot of other cases where project timeframes have been set by an arbitrary body, not the project team and realistic estimates rejected resulting in a project doomed to failure some sponsors understand this and some don't.

Acceptable failures need to start off with a project that is set up for success, when all the pieces are in place only to find out that it cannot be done technically, or will cost too much, take too long to get to market therefore not meeting the revenue targets, and needs to be stop to reduce the impact then that is acceptable failure.

Working in government, we sometimes have to accept failure as an outcome because there are too many things that we have no control over. My agency built and maintains a case management system. When we have a long legislative session (which we just had) and new laws are created or existing ones are changed that require modifications to our system, we know they all have to be completed between April and July, regardless of how simple or complex the change is. Additionally, my agency is very small, so we don't have sufficient staff to handle all of the work and we rarely get the funding we desperately need.

For these reasons, we often know going into a project, that there's no way we can complete it on time. Often we don't even have the needed equipment. We do the best we can with what we have because it's really all that we can do.