|
Have you ever noticed how some IT professionals seem to speak a different language to ‘ordinary people’? They use complex, technical, jargon-ridden phrases and just love obscure acronyms. They speak of methodologies and models, of specifications and exceptions. The differences often go much deeper than just their language, though. Some focus on incredibly narrow specialisms and become so skilled they may lose the ability or desire to explain how things actually work to mere mortals. It is well known (to Hollywood directors, at least) that true computer nerds have no social skills or normal friends, but pizza faces and B.O. They inhabit an ordered, logical, Spock-like totally rational and predictable cause-and-effect world where clear, precise instructions always lead to repeatable results. Real-world practical situations involving ambiguity and variety can unnerve if not totally fox them. The commercial world, company politics and ‘management’ as a whole are completely unfathomable and consequently are usually shunned by true geeks.
Of course, from the other point of view, business people are hopeless at telling you what they want in the way of IT systems. They are happy to criticise whatever you show them but can't say how it should look. They keep changing their minds and, worst of all, expect everything to work first time according to the original schedule, even though everybody knew it was hopelessly unrealistic. They don't understand the problems caused by intermittent bugs and systems interfaces. They demand miracles.
IsecT's consultants have developed the advanced linguistic abilities (*) and understanding to forge more productive links between these two camps. We call it bridging. Here are some situations where the bridging approach shines:
-
Specification of a new system: business people sometimes say “We don't know what we want, but we'll know when we see it”. IT professionals, meanwhile, say “How can we deliver something if they don’t even know what they want?”. The polarisation characterised by such 'them and us' comments can cause intense friction and inefficient working practices evolve. IT pros who insist on delivering only to formal specifications, and then argue that it doesn't matter whether the product actually helps the business so long as it meets the specification, are playing their own version of corporate power politics. Endless committee meetings to agree (or rather to argue about) the final specifications can tie up valuable IT and management resources indefinitely in largely pointless argument. More creative approaches such as system prototyping and brainstorming can break the mould and improve mutual understanding, but the truth is that good teamworking demands better communications, trust and respect all the time, not just for away-days;
-
Systems testing: how many development project teams make any attempt to train users in how to test IT systems? We've met countless “users” (sorry, we hate to even use such a denigrating term for business people, but it’s what IT calls them) who have been designated as testers but have no real idea what they are meant to do, nor how to do it. They sometimes waste so much time planning ‘complete testing’ (which, by the way, is totally impossible on any practical program) that actually doing the testing is essentially forgotten. They duplicate tests already done by the systems team. The developers attempt to persuade them to test only against the formal specifications, deliberately ignoring all their unwritten assumptions about how the system would actually work. Their managers just want to know whether the system will go live on the announced date ...
-
IT service management: a Service Level Agreement (SLA) that says a system will be available to users for 99.9% of the time is not exactly helpful if the remaining 0.1% of downtime happens to coincide with a critical business deadline, or consists of numerous brief interruptions during the normal working day (we've experienced both situations!). And have you seen SLAs with more small-print than a software license agreement, so written that planned maintenance, backups, upgrades, weekends, evenings, lunchtimes etc. are specifically excluded from the service window used to measure and report uptime? Truly business-focused departments take an entirely different approach to service management: they still measure their performance but apply criteria that mean something to the business, and most importantly they actually use the metrics to drive process improvement, not just as a reporting formality. They accept that consistent failure to satisfy any legitimate business demands is simply not acceptable in the long run, and even sporadic failures can be very costly both to the organization and to their relationship with the rest of the business. They realise that being customer-focused means not simply doing everything the customer asks but reaching agreement on delivering the essentials well, and not accepting poor quality services as 'just how it is'. Effective, forward-looking customer relationship management is not something that comes in a tin.
-
IT strategy development: unless your business actually sells IT services and goods at a profit, IT is not an end in itself but a means to an end, a tool to support the real business. But, extending the tool analogy, there's a world of difference between basic hand tools and modern machine tools. In just about every situation we've seen, IT can be used creatively to extend the business into new markets and products, and can help deliver existing products more efficiently and effectively. Finding the appropriate balance between sticking to IT basics and implementing cutting-edge IT systems for eBusiness requires high quality interaction between IT and The Business. IsecT's bridgers can help by creating a framework supporting the constructive dialogue necessary to develop, refine and review IT strategies that integrate seamlessly with business strategies.
To IsecT consultants, bridging is just one manifestation of the much wider field of customer relationship management with a wealth of tools and proactive relationship management techniques on hand.
(*) We ask people to tell us in plain English what they really mean ... usually more than once.
|
