Project Management Central

Please login or join to subscribe to this thread

Topics: Benefits Realization, Leadership, Risk Management
What’s your opinion on "failure being a valid option"?
Network:5170



Over the years, I have found an interesting dynamic wherein the "definition of success becomes amazingly versatile when failure is NOT an option." The other side of this equation states that "success as originally defined is possible when failure IS an option." Although we all know that failure can and does occur (of course, not on our projects), it is rare to here a sponsor make a statement that failure is an acceptable outcome.

What are your thoughts on “failure being a valid option”?
Sort By:
Page: 1 2 3 next>
Network:63



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.
...
2 replies by George Freeman and John Tieso
Apr 08, 2019 11:55 AM
George Freeman
...
I agree. Objectives by their nature are statements related to a future state and as such, require refinement when project knowledge recognizes they are unattainable in their stated form. However, many projects hold their objectives as immutable and in essence end up "holding themselves hostage". Adapting or closing out objectives based on new knowledge gained in a project is NOT failure, however, "not adapting" your objectives and holding your project hostage (in my opinion) will increase your opportunity for failure.
Apr 08, 2019 3:14 PM
John Tieso
...
There is nothing more embarrassing or difficult than explaining to a customer that the project is failure and should be stopped. The real question is "Why the failure?" is it the fault of incorrect or imperfect, unattainable specs? Inadequate budget estimating? Environmental conditions not anticipated? Excessive risk originally identified at a lower risk level?

Any of a number of conditions can arise that prevent successful completion of a project. better to see the problem(s), describe how they inhibit or prevent success, and then go to the customer to discuss. The time to do that is as early as possible, not at the end. The customer may have insights you do not have. They also might be willing to adjust scope, timelines, or help to alleviate or eliminate risk. They cannot do that when they are in the dark.

One caveat though: Make sure the problem(s) are inherent in the tasks, not because of your own failures to comprehend or execute the project in its intended form.
Network:1476



George -

interesting take on this challenge. It is fairly common to ask sponsors and other key stakeholders what does success look like to them at the onset of a project, but perhaps it is equally beneficial to have them articulate what failure would be so that a team has a sense of the range of outcomes between these extremes.

It is common for a sponsor to expect that all key constraints will be achieved and so their initial take on failure might be a material variance in any one of those. The reality is that usually one constraint has the highest priority and there's likely to be wiggle room on the others so long as that one is met. In such cases, failure (as originally defined) is an option.

Kiron
...
1 reply by George Freeman
Apr 08, 2019 11:55 AM
George Freeman
...
Your first point is a challenging one. When the project is being defined, etiquette normally dictates that we focus on the positives (e.g. success factors) as it would be considered common sense to understand that failure is the lack of meeting the stated positives. But as you alluded to, the range of outcomes can be extreme, so there is value in being direct and challenging out (ahead of time) the definition of failure.
Network:21840



It can be an option, specifically when you can learn a lot from your failure. This concept can be applied to a lot of research projects.
Network:2323



George

think it depends on the project type and product . For a software on 737 Max, I would say one of the key requirements is 'failure is not an option' while on an experimental startup software, the mantra is fail fast and learn a lot.

Stopping a project for a cause is the right thing to do. It is not a failure for the company but may be a failure for the project manager. Failure and success are subjective measures for certain stakeholders.

The project summary in my view is too late to learn, this should be done regularily during the project, also to improve the project, and the summary just document the highlights.
...
1 reply by George Freeman
Apr 08, 2019 11:56 AM
George Freeman
...
Very good points. Failure is subjective and you can have both success and failure on a project at the same time. My general rule for success (from the PM perspective) is "Adoption" as you can meet every objective on a project and still not have adoption – which for me is a form of failure.
Network:1656



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.
...
1 reply by George Freeman
Apr 08, 2019 11:58 AM
George Freeman
...
Deepa, I like the way you phrased this! If Sponsors, Project Managers and Teams accept this as a truth then failure is not final and would be instead considered a transitory event – a stepping stone to ultimate success.
Network:273



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.
...
1 reply by George Freeman
Apr 08, 2019 11:59 AM
George Freeman
...
Great example of the power of "corporate will" - Rescind failure through clarification of that which defines success. Is this reality our friend or foe?
Network:263



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.
...
1 reply by George Freeman
Apr 08, 2019 11:59 AM
George Freeman
...
That is the perfect example Wade. If a leader sets a vision and everyone gets on board, then failures are our compass to success.
Network:5170



Apr 07, 2019 9:47 PM
Replying to Ashleigh Kennett-Smith
...
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.
I agree. Objectives by their nature are statements related to a future state and as such, require refinement when project knowledge recognizes they are unattainable in their stated form. However, many projects hold their objectives as immutable and in essence end up "holding themselves hostage". Adapting or closing out objectives based on new knowledge gained in a project is NOT failure, however, "not adapting" your objectives and holding your project hostage (in my opinion) will increase your opportunity for failure.
Network:5170



Apr 08, 2019 7:36 AM
Replying to Kiron Bondale
...
George -

interesting take on this challenge. It is fairly common to ask sponsors and other key stakeholders what does success look like to them at the onset of a project, but perhaps it is equally beneficial to have them articulate what failure would be so that a team has a sense of the range of outcomes between these extremes.

It is common for a sponsor to expect that all key constraints will be achieved and so their initial take on failure might be a material variance in any one of those. The reality is that usually one constraint has the highest priority and there's likely to be wiggle room on the others so long as that one is met. In such cases, failure (as originally defined) is an option.

Kiron
Your first point is a challenging one. When the project is being defined, etiquette normally dictates that we focus on the positives (e.g. success factors) as it would be considered common sense to understand that failure is the lack of meeting the stated positives. But as you alluded to, the range of outcomes can be extreme, so there is value in being direct and challenging out (ahead of time) the definition of failure.
Network:5170



Apr 08, 2019 8:27 AM
Replying to Thomas Walenta
...
George

think it depends on the project type and product . For a software on 737 Max, I would say one of the key requirements is 'failure is not an option' while on an experimental startup software, the mantra is fail fast and learn a lot.

Stopping a project for a cause is the right thing to do. It is not a failure for the company but may be a failure for the project manager. Failure and success are subjective measures for certain stakeholders.

The project summary in my view is too late to learn, this should be done regularily during the project, also to improve the project, and the summary just document the highlights.
Very good points. Failure is subjective and you can have both success and failure on a project at the same time. My general rule for success (from the PM perspective) is "Adoption" as you can meet every objective on a project and still not have adoption – which for me is a form of failure.
Page: 1 2 3 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The golden rule is that there are no golden rules."

- George Bernard Shaw

ADVERTISEMENT

Sponsors