How Is the Software Selection Process Like the Denver '76 Winter Olympics?
By "Jim Lein, Oracle Midsize-Oracle" on Feb 25, 2014
by Jim Lein | Sr. Principal Product Marketing Director | Oracle Midsize Programs | @JimLein
Spoiler Alert—the answer to the question posed in the title is, "Sometimes well meaning people make really, really bad decisions."
The 2014 Sochi Winter Olympics Are History. For a year now, ever since the media started hyping this Olympic iteration, I've had a tough time not thinking about the Olympics that might have been but wasn't: The Denver '76 Winter Olympics.
In 1970, The Denver Olympic Organizing Committee (DOOC) successfully persuaded the International Olympic Committee (IOC) to award the 1976 Olympics to Colorado. Two years later, sensible Colorado voters rejected the bid and became the only entity to ever turn down the Olympics—Winter or Summer—after having been awarded them.
When it comes to software selection, we all know stories about bad decisions. In the case of Denver '76, the red flags were:
Product: the selected venues—in my adopted home town and ski area—lacked reliable snow
User Adoption: Colorado residents were concerned about the environmental impact and the impending flood of tourists
Cost: (budget estimates soared 300% within two years)
I’ve actually dug through two boxes of DOOC meeting notes, letters, and memorabilia in the archives of the Denver Public Library (I wanted to learn exactly where the events would have been held. I still don’t understand how the IOC awarded the Games to Denver. It was a disaster waiting to happen.
Mercifully, the '76 Games were moved to Innsbruck. Franz Klammer turned in perhaps the greatest Olympic downhill run of all time in front of 66,000 home town fans. Bill Koch became the first (and still only) American to win an Olympic cross country medal with his revolutionary skating style.
Growing companies intent on modernizing IT systems don’t have the option to pass the buck. And disaster is not an acceptable outcome.
As I research this series, it becomes clear that software selection disasters can be averted by following a thorough process. I believe that the RFP—as painful as the process is—is not going away. But perhaps the most important steps are those taken before the RFP is released-to help good people make good decisions. Soon I’ll be publishing what I’ve learned.
Meanwhile…here’s a great article, “9 Tips for Writing a Great RFP”, about RFPs in general, not specific to IT, that echoes much of what the experts are telling me.
The views expressed on this blog are mine and do not necessarily reflect the views of Oracle