From an SR&ED perspective, project failure is useful. Failure for technical reasons is most useful. This is not to say that failure is “good”, in any sense – companies don’t appreciate failure, or reward it, usually. Most companies do not take failure as a sign of new learning, or in any constructive, positive sense. (I suspect that very few companies could repeat the experience of 3M and the post-it note, for example.) In the world of SR&ED, however, failure for technical reasons is a strong indicator of potential SR&ED-eligible work.
Most companies develop elaborate rituals and routines for suppressing the evidence of failure. They don’t talk about it, and often they don’t learn from it. All too often a “lessons learned” debriefing is a prelude to picking the bones of a soon-to-be-departed project manager or project team. The lessons learning in such circumstances are often more cultural than they are technical – it’s not the content of the lessons learned that matters, but the presence of the ritual and the sub-text: “don’t screw up”. And also, “don’t get blamed”.
When this burial of the facts happens, organizations squander their possible knowledge gains for the marginal advantage of a brief revenge, and the suppression of technical failures and challenges becomes an entrenched aspect of the corporate culture. People also learn never to talk about technical risks (endangering funding). This is kind of funny when you think about it, in a bitterly bleak kind of way, because the failure to examine and discuss and mitigate technical risks would be a contributing factor to – you guessed it – project failure.