A common interview question is, "tell me about a time you failed, and what did you learn from it". I was asked that question several years ago, and I replied with some examples of projects that failed, but I did not have a good answer for what I learned - another failure!
I have several ideas about failure. First, if you never fail, then you're not trying hard enough; or you're not taking on challenges that push the limits of your abilities. An ambitious team does not avoid projects that may fail. A team's portfolio should include high risk projects.
Context is king. Different projects demand different strategies to succeed. A "trail blazing" project must quickly demonstrate its value to stake-holders, and should not spend time on testing, reliability, scalability, or cost efficiency except to ensure that those capabilities can be fleshed out in the future. On the other hand, a project with a mature product with hundreds of users must deliver value, but not break existing functionality or introduce security vulnerabilities or increase operating costs.
A project needs a clear definition of success. Ideally, metrics measure costs and progress toward a project's goals, and incremental releases collect feedback from stake-holders. A good team dispassionately evaluates a project's progress, and takes action (seeks help, changes approach, increases resources, changes the timeline, changes the goals) when a project is failing. A good team kills a project when it becomes clear that the goals cannot be reached with the available time or resources.
A good team celebrates success, but is not punished for failure. A good team fails gracefully without bitterness or blame. A post-mortem reviews the good and bad parts of a project's history whether it succeeds or fails in the end. A project often does not have a clear beginning and end, and it's easy to "declare success" in a project without measurable goals and timeline. For example, when a project successfully delivers a new feature, but users do not adopt the feature, because it does not deliver sufficient value to change behavior; is the project a success or a failure? Should a "phase 2" project refine the feature to realize its imagined potential, or was it a wrong idea, or should ux experiments and iteration have been part of the plan from the beginning? Is the project a success for the dev and operations teams, but a failure for the product and marketing teams, or do all the teams evaluate themselves on the success of the final deliverable? What if a project delivers its goals, but the team leaves the company in disgust?
A good team accepts that it will sometimes fail, because it takes on hard projects. The team clearly defines success for a project with metrics and costs and a bounded timeline, continuously collects feedback from stake-holders, and does a post-game review.
