When it comes to taking risks in IT, the key is to not go into it blindly. The nature of taking a risk means you don't know what the outcome will be. Still, you can't be reckless. You've got to study the risk and realize you're likely to run into some unknown unknowns and some known unknowns along the way.
And, perhaps most importantly, you must have checkpoints throughout the project and know your boundaries. Everyone involved should have agreed to, “If this happens, we fail fast and we will end it.” If you don’t have those “If this happens then...” scenarios built into your project plan, then you just keep going down that rat hole once a project starts failing. That can lead you to a bad place.
By establishing milestones, gates, and questions along the way, you're ensuring that you're being smart about the risks you're taking. And as hard as it is, you’ve got to be ready to say, “We are stopping."
I had to do that on a major project with my business partner. We made agreements that if certain scenarios happened, we would stop. By that point, we had millions of dollars invested, but we knew that because we had reached one of those gates, it was the right thing to do. We didn’t stop completely; we just paused for two years, and then we came back and the solution was delivered, and it saved millions of dollars for the company. It was risky to put the project on pause at the time, but it was a smart risk. It would have been riskier to keep going and ignore the milestones we had previously set for ourselves.
To help encourage smart risk taking, I like to seed innovative thoughts. In our IT organization, we have a Force.com environment that we have put in place for developing new solutions that are built to adapt, as opposed to those that are built to last forever. We'll build apps quickly, use them for a while, and then move on. We also have an internal competition called “Force Fest” where we try to solve business problems in our Force.com environment.
This year we're also creating another internal competition as part of our annual in-house technical conference. We can't afford to send our entire IT organization to technical conferences – it's just too expensive, and there aren't many near our headquarters in Indiana that we can get to. So each fall we sponsor a tech conference and have vendors and suppliers come to us, allowing 500 of my staff members to go to a tech conference.
We've added what we're calling “Spark Tank” to this year's conference to spark some new ideas in innovation. It's similar the show “Shark Tank,” where investors pick the products they want to fund and help grow in the market. Many IT organizations are doing something similar in-house. But I don't want the winners of our competition to just get a blue ribbon and a pat on the back. Instead, I will actually seed money to the winning idea from my budget, give the winners time on their docket and encouragement to go make it happen.
I look forward to seeing what risks they're going to take.
