It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So"

This quote is often ascribed to Mark Twain (it's the first scene in the Big Short). I'm actually convinced Mark Twain could have been a Chief Digital Officer.

"It should just take us about 3-6 months" are famous last words for many Enterprise-scale projects that sometimes take 3-6 months just to sign contracts with their first set of vendors, much less finish the project.

What happened?

In short, magical thinking. Before the project begins, you have no frame of reference. In some organizations, the reality is not much can help. You simply don't know what you don't know. (Rumsfeld's "unknown unknowns")

You always want to estimate the size of the revenue or EBIT opportunity (to the extent you can) - especially as you embark on a big project.

But there's another set of buckets I like to make for projects as well:

1 - Things We Have Proven We Know How To Do, and

2 - Things We Don't Know How To Do

Let's take them one at a time:

1 - Things We Have Proven We Know How To Do

These are often things in line with your current business model, small to medium-sized wins. Often all the expertise is in-house, or, if not, you may already have contracts with the vendors you need and have worked with them before (this last part is key).

2 - Things We Don't Know How To Do

The biggest risk, as Mark Twain suggests, is putting something in bucket 1 that should be in bucket 2.

How do you avoid this? Asking yourself a few critical questions will help:

A: Has the organization attempted similar projects in the past, and what was the result?

B: Are the people required to implement the solution to our problems available, unburdened by other projects, and cost-effective to hire and retain?

C: Do we understand what a realistic project timeline is for evaluating, developing, and implementing the solution to our issues?

D: Is management prepared to accept a failed implementation (innovation is messy, after all), and what would the time-to-market cost be in such a situation?

Look, setting detailed project timelines for innovation are somewhat pointless in some sense, despite the constant pressure to do so.

Better to experiment and timebox, and continue iterating in a particular innovation stream. At least until you determine if your approach will work, or if it's a waste of your time. If you aren't doing this, then your innovation process may not be mature enough to produce consistent results in the first place.

And even if you can produce occasional results, your magical thinking could come back to bite you in the end.