Eight to Late

The trade media plays a major role in indoctrinating informing corporate IT decision-makers about new idealogies developments in enterprise technologies. In fact, many IT folks first hear of a new technology (or architecture, or whatever) through journals such as Computerworld, and before we know it  a shiny new bandwagon starts to roll. It was therefore refreshing to see this article in CIO Magazine, reminding corporate IT punters to be wary of media (and vendor) generated hyperbole regarding emerging trends in technology. In this post I offer my approach to dealing with this issue.

The questions one should ask when evaluating new technologies are age-old ones:  what, why and how.  I elaborate below.

• What is it about? The first step is to understand what the technology is about. You don’t need to figure out all the nuts and bolts at this point. What’s needed is a high level understanding, untainted by media hype. You may need to consult your in-house experts for this, but beware of distracting them from their ongoing work. Armed with an understanding of the technology, you can move on to the next question which is…
• Why  do you want to use it? Or stated another way, would your business benefit by using it? There could be several good reasons for implementing a new technology. On the other hand, there will be several more bad ones. You need to ensure that your reasons are the former, not the latter. In this context, it helps to focus on business benefits rather than technology.  You’re unlikely to get the go-ahead if there is no demonstrable business rationale for implementing the new technology. If you find there’s none – stop! Else,  proceed to the next question which is…
• How do you implement it?  Before you present your recommendations to the business for approval,  think about how you will proceed if you did get the go-ahead.  Some senior managers may want to see this information before they give their approval, so it is important you have it on hand. Things to consider include:  implementation steps, personnel involved (internal and external),  rough estimates on budgets, schedules etc.

Now you have enough to build a  business case  detailing the benefits of using the technology, and how you intend to implement it.  Your business case should enable senior management to make a well-informed decision on whether to go-ahead with the new technology or not.  If you do get the green light, the work you’ve put in evaluating the technology will also help in developing a project plan.

Trade journals will continue to promote technologies, often uncritically. The responsibility for separating the grain from the chaff lies with those who work at the interface of business and technology. The winnowing begins with the simple questions: what, why and how. 

The well known technology advisors who construct  magic quadrants  tell us that the traditional IT department will disappear in a radical five year transition.  The death of “old IT” , we’re told,  will be accompanied by the birth of a next-generation IT department,  staffed by (what else but) a new breed of technology professional.  These new-look departments will be up to a third smaller in size than the ones they replace, the superfluity of staff being achieved by automation.

But there’s a silver lining: those fortunate to remain employed in these personnel-depleted, automation-enhanced technology departments will have novel (as in new, not fictional) titles like Director of Processes or Innovations Manager. Seriously, I didn’t make these up –  they’re taken straight from the first paragraph of  the article . 

So, here’s a strategy for survival in the new world: rename/redefine your current job using buzzword compliant (but otherwise obscure) terminology.   As an example close to home (and taking a cue from the article),  an IT Development Manager might become a  Director of Process Improvement, the latter being a nice CMMesque title which has the added advantage of not saying much about the work the person does.  Who can argue with it, though? Surely, every company needs some direction in their process improvement  efforts.  Application development, on the other hand, is so passe that its time has almost passed. I give it five years at most.  How can I be so sure? Well, there’s this article I read recently…