|
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, 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 fox them. The commercial world, company politics and ‘management’ as a whole are completely unfathomable and are usually shunned.
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 always expect 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 bridging really works:
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 'them and us' comments can cause intense friction and inefficient working practices to evolve. IT staff 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 political games. Endless committee meetings to agree (actually to discuss) the final specifications can tie up valuable IT and management resources indefinitely in pointless argument. Creative approaches such as system prototyping can help improve mutual understanding, but the truth is that good teamworking demands better communications, trust and respect; Systems testing: how many development project teams make any attempt to train users in how to test IT systems? We've met countless users 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 gets, well, forgotten. They duplicate tests already done by the systems team. The developers 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 when the system will go live... 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: they still measure performance but using criteria that mean something to the business. They accept that failure to satisfy legitimate business demands is not acceptable in the long run. 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 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 such as eBusiness and CRM again 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 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.
|
