Archive for the ‘Corporate IT’ Category
Brave new world?
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…
Effective project communication enhances IT/business alignment
The so-called gap between IT and business has led to a surfeit of articles on IT/business alignment in magazines targeted at technology decision makers. Should a CIO want to do something about the disharmony between her (or his) department’s efforts and those of the rest of the business, there are several consulting firms (big and small) who claim to be able to get the two sides singing in tune. Many solutions proposed by these folks focus on technology or processes – such as service oriented architecture or project management processes for example. No surprises there, I guess. But, although technology and process may indeed be a part of the solution, I believe they do not address the fundamental problem which is one of poor communication between the two sides.
About 50 years ago, CP Snow talked about the breakdown in communication between the sciences and the the humanities, in his influential lecture on The Two Cultures. Although Snow was referring to academia, thedivide between IT and the rest of the business can be seen as a part of the same rift. The divide has two aspects to it:
-
Mutual misperception: Many business users see IT as the “folks who fix computers”. The view from the other side is just as one-dimensional, with technical people stereotyping accountants and sales professionals as bean counters and snake-oil salespersons. Clearly, there’s little hope for a genuine partnership between IT and the business while such misperceptions remain.
-
Mutual incomprehension: In keeping with the geeky stereotype, IT people often speak in a jargon-and-TLA laden dialect when communicating with business folks. The other side’s guilty too, but less so – I’ve had a few situations where I’ve had to remind people of my ignorance of accounting arcana (sorry, what’s amortization Jack?).
Improving cross-departmental communication is a first step in bridging the schism between geeks and suits , which in turn is a prerequisite to closing the gap between IT and the business. To have the best chance of taking hold in the organisation, the improvement needs to occur at the grassroots level – i.e. at the level of individual interactions between the two sides. Technology-oriented business projects present excellent opportunities to improve cross-disciplinary communication because they involve frequent interactions between IT and other specialisations in the organisation. Building IT credibility within a business takes time, effort – and yes, technology and process too. But a good place to start is with building individual relationships across departments, through effective person-to-person communication on projects.

