the burden of "failure is not an option" makes people fearful and reluctant to take risks or make decisions.

That's where the prototype comes in.

Sodestrom pointed out to me that the very act of calling something a prototype means that you're going to give it a try, then throw it away. How liberating and non-threatening is that? You're going to try something, and the default is that you're NOT going to live with it. You're going to learn, and then figure out what's next.

In the IT business, we pooh-pooh language and nomenclature, but in the human business, language and what we call something matter very much. Think carefully when calling something a pilot versus a prototype. Staff members may have a reptile's brain's reaction to a pilot, but they won't have one when you're talking about a prototype, because it's going to get thrown away. It is not contemplated to be in production. At least, not until people learn from the prototype and then decide on their own to implement whatever good stuff they learned from the prototype.

2. Spend money on experiential learning instead of slideware.

We easily spend $5,000 on the following experience:

Here is my question to you: How is this better than actually buying something to mess around with in the lab or signing up for some new service, paying $10K, and seeing if it is beneficial to the organization?

That's the problem. In many cases, we are freaked out about paying $10K or $20K for new stuff that could potentially benefit the experience level of many employees, but we are totally fine with paying $5K for EACH individual employee to go to a slideware training that provides technical education, but that may (or may not) impact the business's ultimate results.

[Learn the three practices of the "Cloud Whisperer."]

My advice: Pay for new stuff versus paying for slideware. It can be a freak-out moment to pay for something that you're not sure will pay off, but do anyway. Our early days of cloud computing were all about this: We bought some hardware and software to play around with, which led to many mistakes and learnings about cloud in a safe environment. In Sodestrom's case, he invested in 3D printers and ended up with ideas for printing spare parts for robots to install on Mars missions.

We paid for one cloud service that seemed promising, but it ended up as a super-complicated, unsuccessful project. The money that we put into it might have equated to the slideware experience of one or two staffers, but the experience and the learning that we took away from that enabled us to better target an effort that was 10x the dollar amount.

We can get to a more innovative IT. But we need to stop focusing on the word innovation as if it were a result in itself, and stop looking at new project and management frameworks as if they're silver bullets.

The key: Understand that, although change is the enemy of operations, staff members don't consider something a change once they truly understand it. That understanding allows us to take simple steps to create process changes and experiential learning that inevitably will lead to the results that we want.