Whoever said the customer is always right never worked in IT. The person who came up with that catchy little credo has not toiled away countless days, months or even years building systems that he knew were flawed, only to be blamed (or even fired) for the poor outcome. That person has never pleaded, even begged, business partners not to take a certain approach because he knew things would end badly.
Most CIOs know this pain, and know it well. It's a no-win situation. If they build it the way the partner wants, they watch failure in slow motion. If built the way the CIO thinks it should be done, you might as well hand over torches and pitch-forks to an over-tired crowd.
If you have ever played blackjack, you know there is a socially accepted set of rules on how the game should be played. Based upon the book Beat The Dealer, there are certain hands you should "hit" and certain hands you should "stay."
If you have ever heard the dealer say, "Really?" it is a sign you are not making the correct move. It's a subtle hint meant to help people who may not know all the ins and outs of the "system." Ignoring the dealer is done at your own risk (financially), and it's a sure way to get others at the table upset if things don't work out ("You should have stayed, you idiot!"). Most people will follow the dealer's advice.
However, the same people who may listen to that dealer's ever-so-subtle hint will strike up a heated debate with their CIOs about the functionality or design of a system.
CIO: "Based upon my experience, I think you should consider this type of design with this functionality."
Partner: "That may have worked for so-and-so in the past, but that is not what I want. It absolutely must do this."
CIO: "We can do that, but I want to make sure you consider the impact it will have in these other areas."
Partner: "I got it. Consider it 'considered.' I still want what I want."Don't get me wrong, I am not saying the CIO knows best in all situations. Rather, in most cases, the CIO has the most experience when it comes to building new systems. Many business partners have experience using systems but not necessarily building them. Even if they have built systems in the past, it was likely only once or maybe twice.
CIOs, on the other hand, tend to spend 30 percent to 50 percent of their time building new systems. Most experienced CIOs have built various systems (for example: accounting, CRM, sales force automation, etc.) many, many times. They have "been there, done that." If that is the case, why aren't their opinions given more weight in conversations with their business partners?
Think of it this way: If you decided to be daring and finally build your own house, would you want the architect to tell you what the perfect house looks like? No. You'd want to design and build "your" house. Do you want your mother-in-law telling you how you should raise your kids? (After all, look how good your spouse turned out.) No. They are your kids, and you will raise them as you think fit. Do you want your significant other telling you how great her ex was in bed? You get the point.
Most CIOs bring a wealth of experience to the table that is ultimately not wanted. What business partners really want is for the CIO to make them successful. That mandate is different from doing what is "best." Truthfully, I have struggled with that concept for most of my career.
An example of this issue might be a business partner who wants to build an application that meets the needs of his department. The CIO knows that other departments will need the information from this new system to be more effective. Building that functionality to extend the data takes times and money the business partner does not want to spend. And realistically, it is not moving toward that partner's goal. Who is right?
Building the "best" is rarely the best option. A CIO should consider what is important and how to address it. Here are some guidelines that I try to use:
- Does the request make the project "harder" or "doomed"? If just "harder," then do your best to educate the business partner to the impact and move on. If "doomed," then fight tooth and nail to be heard.
- When it comes to the alignment of other projects, departments or future needs, don't inject those requirements if they would cause an increase in scope, time or money of more than 20 percent. If those other requirements can be met for less than a 20 percent increase, make sure your voice is heard. But don't fall on your sword if they are ultimately dropped.
- Make sure your business partners know that you bring up your experience only to provide them with context for your thoughts/opinions, not to say that they are wrong.
Remember, there are thousands of recipes for chicken soup. With so many recipes, there is a good chance your business partner's concoction is as good, or better, than yours. Keep an open mind. Most recipes taste good. And the world won't end if you have a bad bowl of soup.
A recent article in The Wall Street Journal talked about how CIOs are still largely seen as second-class executives. The article was written by several academics who provided thoughts about what causes this perception (or reality) to perpetuate. They looked at things like communication skills, thinking styles and relationship management. Although I did not disagree with the concepts outlined in the article, I think the concepts listed above also contribute to that perception.
What are your thoughts? I'd love to gain some additional perspectives. Leave a comment or E-mail me. You can also follow me on Twitter: @todd_michaud.
And don't forget to follow my Ironman training progress.