Please login or join to subscribe to this thread
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 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.
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.
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.
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.
Please login or join to reply