IT and Project Selection

I’ve just read an article from Harvard Business Review called Mastering the Three Worlds of Information Technology. I’m not familiar with Andrew McAfee’s work, but according to his biography he has a background in mechanical engineering and management. I’m not sure what level of involvement he has had with implementing IT projects beyond talking to managers about projects they’ve been involved in. I suspect that he has dealt mostly with more senior management when researching the topic for this article.

I say this because although he makes some good points, his article pushes the same “Manager as General” metaphor so beloved by American management theory. In this metaphor, a manager is a courageous leader who commands an army of employees. The manager determines strategy and tactics, issues orders to his employees who then dutifully do his bidding, capturing market share from the Enemy, er, competition. He suggests that the ‘top down’ approach of executives hearing about CRM 2.0 with Enterprise WikiWidgets from one of their golf buddies is possibly not the best strategy for technology selection. No, really? His solution is that these same executives should maybe think about what they need IT to do for them before buying a multi-million dollar SAP implementation.

That would be a good start.

Right off the bat I’d suggest that if you have executives who are selecting technologies because they’ve read about it in a business mag, you have the wrong executives. Presumably, somewhere in your organisation you have a whole bunch of IT specialists who run the IT for your organisation. Just as you’re told not to start any sort of radical diet regime without first consulting a doctor, I would suggest that maybe, just maybe, you should ask your IT specialists what they think before you spend $20 million changing from Oracle to SQL Server. Better yet, leave the technology details to the experts within your organisation and concentrate on what you want to achieve. I’ve seen plenty of examples of upper management deciding on a technology and then telling their troops to make it work, only to have the project limp along haemorrhaging cash before finally being cancelled after the manager who ordered the whole mess has moved on to another role. You’d think an organisation would only do this once, right? Guess again.

Executives around the CIO level shouldn’t be deciding on implementation details for IT projects. They should be specifying the requirements they need met. It is possible that existing technology within the organisation can be used to meet these new requirements. If new technology needs to be acquired, leave the selection of it to the experts within your organisation. If you don’t trust the people you’ve hired to do this job and make these decisions, and whom you pay significant amounts of money to do so, technology selection is the least of your problems. Your job is to understand what you need to achieve, why, and how you can determine if you’re making progress towards that goal. Yes, this is harder than just decreeing that JavaBeans with Stateful Tagging is the New Black. You don’t get paid the big bucks just for having nice hair.

Every organisation I have worked with that has embarked on a major technology project has been riddled with inefficient work habits and processes. They aren’t using the technology they already have well, and in some cases, at all. Rather than fix the internal issues, it is deemed easier to try to fix everything with a Silver Bullet in the form of some new technology. Worse, some of these companies have had awesome people working for them, only to lose them as they become frustrated with the pointless battles against the status quo. They move on to pastures that are, at least, new and interesting, if not greener.

I believe there is a convincing argument for giving your existing IT folks permission to improve the systems you already use. Find the experienced senior technicians who know the value of restraint from using the latest fad technology. Ask them about the things they’d love to fix if they had the chance. They work with your IT every day, all year. Chances are they may know a thing or two about what should be done to improve things.

50% of IT projects fail. Do you feel lucky?

Bookmark the permalink.

Comments are closed