You are CEO of a medium to large enterprise and across the table the representative of a well known enterprise IT vendor is pitching to you. He insists your organisation will greatly benefit from investment in a 4 server dynamic cluster, each with a Raid 5 stack, housing a star schema based MDDB with OLAP Cubes for sales, inventory and customers.
Do you have even the faintest idea what he's talking about? No? Do you have to make a decision? Yes! But how?Shall we assume that you are like the vast majority of CEO's and rank IT as a core contributor to strategic outcomes. And shall we assume that you concur with Clemenceau's opinion that war is too important to be left to the generals which, in your terms, means the CEO makes the big IT decisions. Finally, shall we assume that you are not a member of the IT cognoscenti.
So how do you make excellent IT investment decisions? Best practice falls into two areas: how you organise your own thinking and how you deal with the other players in the equation?
First, get your own house in order.
- Identify your motivation. There is enormous pressure on CEO's to lead the charge with IT. If you invest in IT for the sake of appearances you are breaking the fundamental rule that business investment must be driven by business goals
- Differentiate between needs and wants
- Reflect on your business strategy. What do you want to achieve? Then consider how IT can advance the strategy
- Don't use IT development to correct faulty business processes. Get those processes in order first
- Invest in your comprehension of information technology (e.g. read (Data warehouse essentials for business people). You will never match the knowledge of an IT professional but every hard won scrap of understanding will pay dividends.
Typically, a CEO must deal with in house IT staff, development and technology vendors and consultants. All apparently offering some kind of expertise. But is it the right expertise and, really, just how expert are they?
When confronted with a legal issue, who do you talk to? A lawyer - right? In pretty much the same way, you need to have independent technology advisors. Where to find those quality advisors? Sorry, there's no 0800 number that I'm aware of. You'll have to invest a lot of hard work canvassing your networks for recommendations.
And the role of your advisors? They will develop your comprehension of IT, assist in evaluating vendors and technologies and deter said vendors from attempting a snow job. What your advisors can't do is offer truly unbiased opinions and what they should never do is make your decisions for you.
With which of these common vendor stereotypes would you prefer to work?
- Mad enthusiasts who get carried away by the possibilities
- Professionals with proven service delivery levels
- Big brand vendors with a ruthless strategy of upselling
No prizes for choosing the professionals but in reality, vendor type isn't so clear cut so here are some practical techniques for judging vendors:
- Insist on a private face to face meeting with one of their existing clients
- Have them prove they understand the outcomes you require and your business as it currently operates (that is, how it actually operates, not how you think it should operate). They have to reflect back what you have told them in their own words
- Have them demonstrate how they will make you understand what they are doing in the course of the project. Key word here is understand
- Judge their ability to communicate
It's communication, more than anything else, that will decide the success of your IT decision making. You must establish a common language with your own IT staff, advisors and vendors. Don't even think about trying to meet technologists on their linguistic level, force them to communicate on yours. This cuts both ways, of course. Don't assume engineers are conversant with management jargon. One of our clients likes to use analogies or metaphors - he sees data collected in buckets (databases) and then piped around to produce information (reports).
Don't rely on a 400 page specification to communicate your vision. Build a prototype showing how you expect the application to work from an end user point of view. You will learn things from prototyping that are most unlikely to emerge during specification writing. And you will communicate more effectively with your developers.
- MP
