Is It Truly OK to Fail? Bridging the Gap Between Project Execution and Financial Management

Why the right failure, failure you can learn and build from, should be supported in the pursuit of progress.

A notion I keep reading about and hearing at IT industry events is that failure, in service of achieving objectives, is OK. In certain cases, such as in the pursuit of innovation, failure is encouraged, because logic and experience tell us we can’t expect to know everything from the start and we will glean valuable insights from failure. Terms such as “fail fast” and “iterate and adapt” in the IT world are almost cliché today.

I agree in the virtue of failure as part of the pursuit of excellence. Because we learn from our failures, it makes sense to include failure as part of the equation for execution on objectives. But here’s the rub – while it’s clearly part of the equation related to project execution, allowing and accounting for failure has not gained a foothold as part of the equation in project finance.

I was recently at a CFO technology roundtable in Boston where the idea of allowing for failures in IT initiative delivery was mentioned more than once. For example, because Big Data is a relatively new competency, experimentation (trial and error) often means that firms start in the wrong place, such as targeting analysis before the data set has been defined and effectively architected. CFOs, for their part, are expected to be efficient and never waste a dollar, if at all possible. Our finance brothers and sisters are working without a net, so to speak. I’m sure they would find it more than a challenge to share the story with their C-suite peers that, “Our discretionary technology budget is 20% over forecast because we failed, and that’s OK.” Colleagues around the table would be shooting daggers with their eyes and may be wondering if the messenger had lost their marbles. Yet, it’s exactly the message that I believe needs to be delivered, assuming there are meaningful learnings and growth in execution that come from that failure.

Over the decades in IT, frameworks and best practices have been developed, countless books have been published and the IT discipline has evolved. Despite all of this, projects in today’s world continue to fail by some serious measures. Why? Because projects are difficult to deliver. Team dynamics, location and individual personalities, along with complex technology, lofty objectives and tight timelines, make project delivery challenging. I’d hazard a guess that most firms live somewhere between “so-so” and “adept” on the Success Spectrum (above) and I’m sure we all fall short of “perfection.” Maybe I’m the only one not in on the joke. But assuming I’m not, I feel that the right to fail is often more words than actions. It sounds righteous in a speech or as part of an event panelist response, but the words are empty because very few who hold leadership roles have built to bridge connecting execution expectations to financial expectations. I submit it’s time to build some measure of failure into projects’ financial expectations.

Of course, every firm’s leadership team is free to chart the course of their organization. My goal is not to say that every firm needs to adopt the notion of allowing for failure in execution. But when it comes to project delivery, since often times we are blind to many variables, the right failure, which you can learn and build from, should continue to be encouraged in the pursuit of progress. This idea needs to be carried throughout the entire organization to reap the real benefits of the virtue of failure. That includes accounting for failure in project finance. Establishing exactly how to account for failure within a firm should be based on some aspects of how the firm operates. But some simple ingredients may include:

  • Performing an upfront, honest assessment of the people, process, and technology aspects being applied for the particular project:
    • Are people over-allocated? Do they have the experience within the project domain? Do they understand the technologies involved?
    • Does the firm do well within certain processes, for example, product management, but not as well with others like compliance initiatives?
    • Is the technology new to the firm? To the industry? Will the firm will be early adopters?

With that, there could be a unique failure quotient established for every project and that could be used as a measure to apply a percentage to quantify how much spend can be reasonably applied in the pursuit of excellence that I mention above.

What do you think?

Resources