Jun 07 2014
Business Intelligence Lessons from Star Trek – Part Two
Author Note: This blog post was originally a guest entry at The Decision Factor, a site that appears to have ceased publication. I have reproduced it here. It was fun to write, and I hate to see good content go missing. The original post was published in 2012 but I believe the content is still relevant today.
In my first Star Trek post, I explored two lessons learned from Captain Kirk’s leadership skills and how we could apply them to business intelligence. Today, I’ll cover three more lessons.
Be Part of the Away Team
Captain Picard of Star Trek: The Next Generation rarely joined the away team, leaving that role to his Number One, Commander Riker. Kirk operated with far more freedom. Whenever there was an opportunity to beam down to a new planet, he was there. His leadership style demanded that he lead from the front.
I think the corollary with business intelligence work here is obvious: the success or failure of our systems depends far more on establishing correct requirements than on the actual implementation. By being part of the away team, we can be directly involved. Lack of user involvement and poor requirements gathering are generally two of the top reasons projects of any kind fail, and business intelligence is not immune to this problem.
Play Poker, not Chess
In Star Trek, there were numerous times when Captain Kirk and his crew were in a bad spot. In one episode, The Corbomite Maneuver, the Enterprise and her crew were experiencing first contact with a new alien race and it wasn’t going well. At one point, Spock had to tell Kirk that they were out of options and the alien had backed them into a corner from which there was no escape. In chess terms, checkmate. Spock, as a character, was the very embodiment of chess: cold, logical, and process driven. It was natural that he would see things this way. But Kirk was different.
Capt. Kirk: There must be SOMETHING to do. Something I’ve overlooked.
Mr. Spock: Chess: When one is outmatched the game is over. Checkmate.
Capt. Kirk: Is that your BEST recommendation?
Mr. Spock: I’m s… I regret that I can find no other logical alternative.
Capt. Kirk: Not chess, Mr. Spock. Poker!
Kirk took inspiration from the game of poker and bluffed his way out of the situation. How can this possibly apply to business intelligence? We don’t want to lie to our business partners, do we?
Perhaps we do – but in a good way.
I often come into contact with people or business processes that have been rigidly followed for many years. To the mind of the many, there’s no other way to do that particular process. In order to convince them otherwise, sometimes we have to bluff. I like to call this a demo. 😉 In order to make a difference, we have to get past that initial resistance; and sometimes a well-placed bluff demonstration helps us along that road.
Blow Up the Enterprise
Sometimes there’s no way around it. A system that’s well known, trusted, and loved just isn’t cutting it any more. The original Enterprise made it through several years of TV shows and a couple of movies before ultimately meeting her end. As much it pained Kirk to let her go, he realized that in order to move forward, the Enterprise had to be sacrificed. (I may have shed a tear or two myself.)
Legacy systems can often inspire the same attachment, but at some point we have to blow them up so we can move on. “It’s always been done that way” is a poor reason to keep a system around when there are so many new and exciting technologies that have come to market recently. Don’t be afraid to blow up the Enterprise to move forward.
But I think the overwhelming lesson to be learned from Star Trek is don’t wear a red shirt to work.
“Lack of user involvement and poor requirements gathering are generally two of the top reasons projects of any kind fail, and business intelligence is not immune to this problem.”
Excellent point. People need to learn how to use your new BI system and that involves some kind of learning curve. If you don’t give your staff the time and training they need to learn to love your new system they are never going to get invested in it.
Dave,
I found the missing Decision Factor site as well as your old articles. The hypen in the domain is a bit of a surprise. My guess is that somebody at SAP let the original domain registry expire.
Regards,
Dallas
Thanks, Dallas.