Hi all,
This has been a good month with what I think are some solid posts and some great and much appreciated feedback. I’ve got a lot on over the next couple of weeks so I’m having a little break. In the meantime, please feel free to suggest any topic within the ICT field that you want me to cover. If it’s something that I have strong knowledge (or opinion) of, I’m more than happy to have a crack at it.
Regards,
Michael
The Dancing Bear
Hi again,
The feedback from my last post was great thank you. I also got a nice request from New Zealand to cover the perils of introducing VoIP on the LAN, since I gave so much coverage to implementing VoIP on a traditional LAN. Thank you, IT Manager in New Zealand, and here goes.
I’m going to start with a few definitions and clarifications (Warning: Technical Content).VoIP is made up of two components: Signalling/Control traffic and CODEC. The first establishes the call whilst the CODEC (or COder/DECoder) converts speech to digital media and vice-versa.
<start very technical bit – skip if you want to>
When I say VoIP, I mean SIP and G.711/G.729. Originally, VoIP meant either proprietary technology or a very loose standard called H.323. Proprietary technologies obviously meant that you needed a homogenous telephony environment (unless you implemented digital bridging with DPNSS or QSIG but that’s far deeper than I intend to go with this post); H.323 was designed to bring some conformity to VoIP but it was such a loose standard that vendors still often couldn’t interact. Tech example (thanks again Andrew): Cisco H.323 used short preamble for call establishment, Ericsson used long preamble and neither were configurable so they could never call each other.
SIP (for Session Initiated Protocol) is a signalling protocol; it’s job is to establish a call between point “a” and point “b”; it is deliberately rigid in order to prevent the issues with H.323. Virtually every IP-PABX supports SIP, and virtually every IP-PABX can talk SIP to every other IP.PABX. This solved the interoperability problem but created a new one: features. Most of the “cooler” features on PABXs (IP or otherwise) are somewhat proprietary to its vendor. SIP is the lowest common denominator, and designed to mimic the features of the carrier-facing end of a traditional digital PABX. This means that things like call-camping, conference calls, multi-party calls (beyond 3 parties for the purists) aren’t part of the protocol. Vendors had two ways of dealing with this: Server-based control (e.g. IPFX, Asterisk, etc.) or proprietary signalling (e.g. Mitel, Avaya, etc.). Both still use SIP, but they use other technology in order to extend beyond what SIP offers. My personal preference is for proprietary signalling as this doesn’t require a dependency on a File Server (that’s another topic). Both work very well though.
G.711 is a CODEC (or audio COMPANDing protocol for the purist COMPress/expAND protocol) which actually carries voice or “the media”. G.711 is not new, it’s been around as long as I have (i.e. since 1972) and has been ubiquitous for telephony since the introduction of Digital voice. Pretty much all IP (and digital for that matter) PABXs support G.711. G.711 utilises 64Kbps of bandwidth. G.729 is a compression technology designed to reduce the network load of G.711 ; it can drop the bandwidth cost down to 8Kbps but at a cost of voice quality; it’s still available but largely irrelevant in these days of fat WAN links.
<end very technical bit – read on>
When you choose to implement VoIP, there are two key considerations: Quality and Security; if you are implementing SIP carriage or connecting to a WAN, there are two more that are equally important: Routing and Bandwidth. I’m going to leave the challenges of VoIP over WANs to another post.
Quality of Service (QoS) is probably the biggest issue I have encountered with VoIP is QoS. The problem with VoIP is that in some ways it sounds too easy. A typical VoIP session (comprising of signalling + CODEC) is around 100Kbps (each vendor is slightly different here) which seems insignificant when you have a 100Mbps or GbE. Even 20 concurrent calls still only needs about 2Mbps! That thinking – along with network (or voice) engineers that just don’t understand VoIP (see my post http://dancingbear.com.au/2012/02/10/if-you-want-to-succeed-with-microsoft-lync-learn-telephony/ for more on this) – is why so many VoIP projects fail and to my mind is unforgivable since QoS on a LAN is a trivial task. I won’t go all technical again but to use an analogy: common Ethernet without QoS means that he who has the biggest hammer (i.e. demands the most bandwidth) wins the fight. A 200MB File Copy is a Jackhammer vs. the tack-hammer that a VoIP session wields. The file copy will completely lock a network segment for just a few seconds which may be irrelevant to most other programs but is an extremely long interruption for a VoIP call (acceptable delay for VoIP is only 150ms).
I’m only going to cover QoS for IP handsets in this post, which is what most people expect when they talk about commercial VoIP. QoS for soft-phones (including MS Lync, Skype or those supplied by various vendors) will be covered when I talk about VoIP over WAN since the requirements are similar.
Setting up QoS for IP handsets is generally quite straightforward; it mainly requires that you have the right network switches (i.e. switches that support 802.1q VLANs and 802.1p QoS). All that it really takes is to separate your voice and data traffic into different VLANs and to prioritise the Voice VLAN. That’s it, you’ve implemented VoIP successfully and you will have clear calls! Well, that’s not quite it, there are other things to configure like discovery protocols, dhcp and routing but they are either trivial (switchport voice vlan <x> on Cisco, equally straightforward for other switch vendors, routine (most data people can set up DHCP in their sleep) or both (unless you have a massive campus with thousands of nodes, LAN routing is trivial and routine).
The next consideration for VoIP is security. On older Digital PABXs, security was ensured through it being a closed system. Each handset connected directly to the PABX and unless you could get access to the wiring cabinets (IDFs and MDFs) or the carriage in the street, there was little you could do to listen in on a phone call. VoIP exists on a network, which can be accessed from virtually anywhere, and neither SIP nor G.711 support encryption. This makes VoIP far either to listen into (or snoop), given the right tools and technology which makes it vulnerable. This is where your choice of PABX vendor is very important, and is another reason why I endorse the use of proprietary signalling over server-based systems. Most of these systems support encryption of VoIP calls (generally using a very strong encryption like AES) which makes snooping virtually impossible. I give props to Mitel here for being the first vendor to have strong encryption turned on by default. If you care at all about the confidentiality of your voice traffic, then implementing a system that supports encryption is a must. A side-note here, Microsoft Lync (and its predecessor OCS) require encryption to be deployed, using certificates. This makes them a bit more complex to install but ensures that they are rock-solid secure (which gets my vote for a good architecture).
That’s all there really is to it. Get decent switches, set up VLANs and QoS and make sure you have the right security and your VoIP will be pretty much perfect. I realise this post is a bit shorter than typical for me but I’m a little tired tonight. I might revise or expand it in the future (as well as cover some of the other topics I’ve mentioned above) and of course I’m happy to field any questions anyone might have but that’s all for now.
Hi all,
I’ll get back to The Cloud soon, I have my next post mostly written but it’s a very complicated topic; and what’s not too hard to deliver as a presentation is proving far more difficult to put into a blog post. I’m going to start seeding these with diagrams soon, which should make things easier for me. For now, I’m going to write another post based again on a request – this time from the IT Manager of a major Sydney school (I’ll ask his permission before I publish his name) which is to explain how to get his VoIP working better over his Wireless network.
The short answer is that VoIP will never be ideal over WiFi (for the techies and purist out there, I know that it’s 802.11 networking and not WiFi but that’s what most people think of, and what most labels say). There are several reasons for this that I am going to cover in this post.
The main issue with VoIP over WiFi is that Wireless Networking (the 802.1<abgn> standard for the techies out there) is a half-duplex standard which means that a device can either transmit or receive at any given time (see http://en.wikipedia.org/wiki/Half-duplex#Half-duplex for a fuller explanation/definition). This provides a direct conflict with Voice conversations which tend to be bi-directional. The technology is kind of like trying to use a phone as a walky-talky where you have to hold the button down to talk and let go of it to listen. Wifi has sufficient bandwidth to cope with this somewhat, but it is far from an ideal medium (whereas all wired Ethernet networks other than the original 10Mbps are Full Duplex and hence better suited to Voice (even Wired networking has some issues with VoIP but that’s an easier topic I will cover in a future post).
Another issue is that the majority of Wireless telephony devices operate using legacy protocols that operate at very low data rates (as of 2009, commercial-grade 802.1g (54Mpbs) handsets were only starting to be introduced just as the 802.1n (up to 600Mbps) standard was approaching ratification). There are a few reasons for this. Firstly, VoIP needs very little bandwidth to operate. Most VoIP systems utilise SIP (Session Initiated Protocol) with G.711 as a streaming CODEC which consumes between 97-105Kbps depending on which VoIP vendor you are talking to. This is far less than the 1Mbps that the lowest level of 802.11b Wireless allows for an the rule for Wireless is that the lower the speed, the greater the range so WiFi phones tend to request/demand very low bandwidth from your Wireless Network. Far from being a good thing, this is a major problem as Wireless is a shared medium which means that bandwidth available (22MHz per channel) is all you get amongst everyone connected to that Access Point. That means that a WiFi phone connecting a 1Mbps consumes just as much of your Wireless Network as a laptop connected at 150Mbps with 802.11n. A Wireless Radio (NB: a Wireless Access Point can contain one or more radios; most APs contain only one radio although 2 or more radios in an AP is becoming more common) can only operate at a single channel or frequency at any given time. This means that most WiFi IP phone will not only starve your network of performance whilst they are connected, but they will also cause constant contention (since they are likely the only low-speed devices on the network).
Our next issue is frequency contention. Wireless Networks run at divisions of either the 2.4GHz or 5GHz spectra. Virtually every VoIP phone (and most other WiFi devices) use 2.4GhZ. There are three main reasons for this: Range, Price and Power. Lower frequency signals carry further than higher frequencies (which is why mobile phones tend to operate at as low as 850MHz since Cellular towers are kind of expensive) which makes 2.4GHz far less expensive to deploy (less radios/access points needed) than 5GHz. In order to achieve any decent range, 5GHz devices need to consume a lot more power which can take a rough toll on a WiFi Phone (or Laptop)’s battery. There are two big problems with the 2.4GHz spectrum. Firstly, the allowed spectrum goes only from 2.401 to 2.483MHz (Japan allows a bit more). Since Wifi consumes 22MHz per channel, that means that there are only 3 non-overlapping channels in the 2.4GHz band (or only 1 non-overlapping channel if you use 802.11n which consumes twice the bandwidth)! In other words, if you are running 802.11b Wireless phones, the maximum data rate you can provide to any given area is only 33Mbps (11Mbps x 3 channels) or actually half that once Wireless overheads are taken into account. That’s the bad news, here’s the worse news: since 2.4GHz is an unregulated band, anyone can use it and everyone does. Microwave ovens, baby monitors, cordless phones, cordless computer mice, wireless headphones and dozens of other devices all gleefully use this area of the spectrum and there’s nothing you can do about it. I once did a Wireless Survey at a University where the PIR sensors that turned the lights on in the lecture theaters were operating (and absolutely blasting) at 2.450GHz, completely locking out a big chunk of their Wireless just so someone doesn’t have to flick a light switch when they walk into the room. It doesn’t matter where you go, you will always get frequency contention with 2.4GHz. The 5GHz band is far less utilised but for reasons mentioned above is less suitable
Now we move on to the biggest bugbear of all VoIP (not just Wireless) which is Quality of Service. Nothing you run on your network demands more “real time” bandwidth than voice. Voice quality can be horribly distorted if any packet loss, delay or jitter is present on your network and that’s particularly bad news for WiFi (which is a slow, shared, contended media as described above). To deal with these issues, VoIP traffic needs to be granted absolute precedence on your Wireless network over any other type of traffic or it will be very poor. This is one of the reasons that VoIP over Wireless tends to starve your network’s performance (as described above). Until around 2007 (when the WME extensions to 802.11e were released) there was no standards-based method of providing QoS for Wifi which made deployments very problematic. One company – Spectralink – released a method of providing QoS for Voice over WiFi called SVP (Spectralink Voice Protocol) which depended on a dedicated appliance to govern the traffic in conjunction with compatible access points which many vendors (including Cisco, HP, Motorola, Proxim, etc.) subscribed to. Whilst Spectralink worked reasonably well, it was expensive, difficult to configure and allowed only the most basic (and easily hacked) encryption to be used on the network. With the release of standards for Wireless Media Extensions (or WMM for Wireless MultiMedia as its more commonly referred to), SVP became obsolete but many AP vendors still support it as there are still many older SVP-based IP handsets in use (mainly due to their high cost of replacement).
Those are the main issues with VoIP over WiFi, there are others but those are enough for you to see that it can be a challenging solution to deploy.
I’m sure that by now the gist of this post must seem to be don’t deploy VoIP over WiFi but nothing can be further from the truth. This technology is very useful and can be successfully deployed if the right strategies are used.
Before I get into how to do it right, I’m going to digress into the single biggest issue I encounter with not just VoIP over WiFi but Wireless Networking in general: More is better. I’m going use use bold, underline, italics and caps for the following: NEVER EVER BELIEVE SOMEONE THAT TELLS YOU THAT YOU CAN OVERCOME YOUR WIRELESS ISSUES BY FLOODING YOUR SITE WITH ACCESS POINTS OR RADIOS!!!
I use so much emphasis because I encounter this so often and it is upsetting to see organisations being ripped off by forcing them to buy needless amounts of equipment and spend huge amounts of money (it’s not just the APs, it’s the cabling and the data ports they consume along with their licensing and management that really costs money) with the result being an environment that’s worse than they started with. Yes, worse! As detailed above, there is very limited spectra available for use and the more APs you have in any given area, the more that spectrum gets carved up and the less efficient the overall network becomes. This is a particularly big problem for VoIP over WiFi since people tend to be moving when they are on the phone; not only does a site “flooded” with APs tend to cause the phone to “radio-hop” (i.e. jump from radio to radio or AP to AP) excessively, the results of that hopping can cause havoc on the rest of the network (also as detailed above). Each WiFi phone will be like a little ghost roaming around the premises causing all sorts of issues wherever it goes. It doesn’t even need to have a call active since the phone (like any other Wireless device) is always “on” the network (how else could it receive a call?) unless it is switched off. If you aren’t sure if you have too many radios or APs, download a program like Netstumbler (http://www.netstumbler.com/) and run it at several locations around your site. If you see full coverage of the three non-overlapping channels (i.e. 1,6 and 11) from 3 distinct radios and maybe a small amount of signal in those ranges from other radios then you probably have the right number of devices. If you see the same channels being strongly presented by multiple devices then you have a problem.
What can you do about it?
OK, enough with the doom and gloom. Let’s move on to steps you can take to ensure decent VoIP over WiFi coverage. These are only rough guidelines to help you; doing this right really needs a trained Wireless Networking professional with the right tools and knowledge but a lot of people claiming to be that really don’t know what they are doing so see if they are following these steps and if not, you might want to consider how qualified they really are.
Do a Wireless Survey. Whether you are planning a new deployment or are having issue with your existing environment, a proper Wireless Survey is a must to work out optimal radio placement and potential blackspots. Top of the line survey tools (like “AirMagnet”) can run to over $10k but they will provide very exacting information regarding what you need to do to get your Wireless Network deployed right. Note that a Wireless Survey of a large campus can take a week or longer so expect this to be a fairly expensive exercise but if you have a lot of problems, or if you can afford it, it is worth it when done properly.
A follow-on to a Wireless Survey is investing in decent Wireless Management tools for your environment. Most major vendors offer pretty decent self-branded tools that will allow you to easily prepare “heat maps” of your Wireless Network as well as to detect “rogue” devices (i.e. APs that don’t belong to you but are transmitting in your space) as well as blackspots (where there is no coverage), hotspots (where there is heavy congestion) or areas where there is too much congestion. These same tools can often also help you “tune” your network (see below). If your vendor doesn’t offer the right tools or you are running a multi-vendor environment (more on this below as well), there are excellent 3rd party solutions (like Aeroscout http://www.aeroscout.com/) you can use.
Tune your Wireless Network properly. I made strong mention of the issues of too many APs above, but how many is too many? The answer is based on the amount of channel overlap you have. A lot of environments (most notably secondary and tertiary schools, where every student has a Wireless laptop or similar) really do need a lot of coverage. It is not uncommon to even see two radios per classroom in some schools and this is fine, as long as they are tuned right. Avoid the temptation to turn the gain right up on the antennas. If anything – in high-density environments – you need to turn them right down in order to make sure their coverage is as localised as possible. Some vendors’ APs are “self-tuning” but my experience is that this is usually less effective than taking the time to set the antennas properly and lock them that way. Use the tools I mention above to do this and review it at least once a year (or whenever there is a problem, or the Wireless Network is being expanded).
Move high-bandwidth devices to the 5GHz band only. These days, most laptop and tablet vendors offer 5GHz WiFi in all but their cheapest models. Not only is the 5GHz band less cluttered, it also has many more channels to use for overlapping coverage. The number of channels differs by country (due to local regulations) but Australia – which is where I live and allows an average number of channels – has 21 non-overlapping 20MHz channels (or 10 for 802.11n). This firstly allows you to deploy far more APs/Radios than 2.4GHz (which allows you to provide far more data) but will also pull most of your contentious data off that spectrum leaving far more available for Voice. The only devices that should be on your 2.4GHz network should be Smartphones (which still mostly use 2.4GHz due to power constraints) and VoIP WiFi phones. This may mean investing in 5GHz dongles for some legacy laptops but these can be obtained for under $50 each. This will also mean getting rid of any 2.4GHz wireless printers (or print servers) you may have deployed. Given how much data is consumed by printing, these are likely causing issues anyway!
Consider reserving a channel just for VoIP. This is a fairly draconian but effective measure for maximum VoIP over WiFi performance. Choose one of the three non-overlapping 2.4GHz channels and use it exclusively for VoIP, allowing data devices to use only the other two channels. This will guarantee that your VoIP usually has decent bandwidth available (subject to interference from non WiFi devices as detailed above; use the cleanest of the three channels for VoIP). If the previous strategy is employed, this will only reduce the amount of data available to Smartphone devices.
Go with a single-vendor, managed WiFi solution. Wireless Networks come in two general flavors: un-managed and managed. Un-managed networks are where each Access Point is configured (and runs) individually. Managed networks use a central controller to administer and propagate policies to all the APs. Managed networks allow technologies like fast-roaming (i.e. quick handover from one AP to another during times of movement or congestion) and Layer 3 roaming (roaming between different network subnets) as well as better overall network management and congestion mitigation. But…
Avoid “Captive-Portal”-based managed WiFi solutions. There are two ways that managed Wireless Networks function. One way (and still the most common) is to tunnel all the traffic from the AP through the controller before sending it to its ultimate destination. The other way is for the AP to receive policy from the controller but to send the traffic is receives directly to its destination. The former solution is a major reason for poor VoIP over WiFi since the controller itself becomes a major bottleneck point. If you already have a Captive-Portal System…
Consider a dedicated Wireless Network just for VoIP. This isn’t as expensive as it may seem. Remember that the lower the data rate, the greater the range. Whereas 11Mbps 802.11b has a nominal transmission range of around 30m (indoors with typical walls), 1Mbps 802.11b has a range of around 90m! This means you can deploy far fewer APs to attain the same coverage for VoIP as you ordinarily would need to use for data. Further, performance could be greatly optimised since not only could you reserve a channel for VoIP, you could also lock the data-rate of the AP to match that of phones. This should be a last resort but if VoIP over WiFi is really important to your organisation it may be the only solution.
There you have it, my view of what issues you can expect to encounter with VoIP over WiFi and some of the ways you can deal with them. I must again stress that this is an area where good expert assistance will make all the difference to a successful deployment.
I would like to make one final note, and this is more around security than performance. Remember that many WiFi handsets only support very basic WiFi encryption which is very easy to hack so make sure that you isolate your “Voice” network from everything else using appropriate security policies on your APs, switches and routers/firewalls. If you consider the confidentiality of your VoIP traffic to be important then make sure that you invest in devices that support strong encryption (such as WPA2) if you don’t want people listening in on your conversations.
Kudos to James Vickery http://jamesvickery.com.au for inspiring this post.
My readers will have certainly picked up by now that I am an IT consultant. It’s what I do, and it’s who I am. Over the last 19 years I have been:
No I don’t carry an encyclopaedia of IT in my brain and I hate it when I get introduced as “The Master” or “The Guru”. That’s not me; there are people far better than me in every field that I’ve listed above (and many more). What I really consider myself to be is a Customer Specialist. My real role and strength is getting to know and understand my clients and their ICT goals and – perhaps more important – bringing them understanding of how they can achieve those goals. This post is all about that, and it’s probably what I am most passionate about in my industry because I think it’s something that is done far too rarely which is why there are so many fundamental disconnects between “ICT” and “The Rest of the Business World” even today, despite the fact that ICT is fundamental to the success of virtually every business in the world larger than the local sandwich shop.
I’m going to go through some principles that I apply when I meet new customers, and how I work to develop my relationship with them. This is what I do every time I am in front of a client (or for that matter, a colleague since to me colleagues are just clients of another sort; the difference being that we are each other’s clients trying to work together).
BE OBSERVANT
Use your senses; not just your eyes but your ears and even your nose. If at all possible, meet your clients (particularly for the first time) at their offices. You would be amazed at what you can pick up through some basic observation even before they come out to greet you. Some examples:
What is their building like? If it’s in a good location and is well kept then they are probably paying a premium rent, and are the sort of client willing to spend good money for good service. If it’s in a bad part of town or badly looked after, then they might be the sort of organisation that tries to economise on “inconsequentials”. The latter is always a bit of a warning sign for me.
What is their reception area like? I can sometimes make my best judgements about a client solely from their reception area. This is the “first impression area” of any business; and is what their clients see when they walk in. How they present themselves here speaks loudly about how they conduct business. Is the area clean and well set out? Does the receptionist greet and deal with you professionally and courteously? A receptionist that treats you coldly because you aren’t a “customer” might well set the tone for how you can be expected to be treated once you go in. A receptionist who is overly chatty might indicate a general lack of professionalism. Look at the reception desk. First impressions again. Is there a modern PC and good equipment neatly set out or is there a 3rd generation clone that’s been handed down over the years? Are their current newspapers available to read or magazines older than the ones at your Doctor’s surgery? The information you get from this first impression will help you to gauge the mood and tone of the meeting.
When you walk in, what do you observe? Is the office area cheerful? Cluttered? Overly-neat? Don’t eavesdrop but do listen for the tone of any conversations that happen to be going on. Do people sound nervous? Relaxed? Tense? What does the place smell like? This might sound silly but if you smell any type of food other than coffee or tea, this might indicate that this is the sort of place where they expect to eat lunch at their desks whilst they work. Again, this will help set your expectations.
What’s the meeting room like? To my mind, the single most important tool in any meeting is the Whiteboard. Is there one? (If there isn’t I always ask if one can be brought in; I feel hamstrung without this necessary tool). Is it nice and large? Is there a good supply of markers? Is there a decent projector available? Have they put water on the table or – if this is to be a long meeting – juices and snacks; and taken coffee orders? Even before you start, by observing the conditions in which you will have to meet them, you can better tailor your presentation to the client’s business’ attitudes.
The point of being observant goes on throughout the meeting, you always have to watch your client and look for both verbal and non-verbal clues that you aren’t winning them over. This leads to the next point:
BE FLEXIBLE
The difference between a consultant and a salesperson is that the former is expected to know what they are talking about whereas the latter is mainly there to spruik a product or service. This means that if you see that what you are presenting isn’t holding their interest, be fully prepared to shift gears or even entire directions mid-presentation. This is why I believe that the Whiteboard is the consultant’s greatest friend whilst PowerPoint is their greatest enemy. The former allows everything up to any given point to be erased so you can start afresh whilst the latter forces you to follow a path that may be the completely wrong direction to what your client’s expectations are. I may well put together a PowerPoint presentation but not until I am deep within a paid engagement where the client and I have established strong mutual understanding and trust. Until that point, I do everything possible face-to-face using collaborative whiteboard sessions so that we can build that relationship. Flexibility also means not being afraid to go beyond your own field of expertise. If you go in to discuss networks and a storage issue comes up, don’t be afraid to take this on board; just be sure not to claim expertise in an area where you only have passing knowledge. Being caught out not knowing something is a way that a weakness can be turned into a strength by committing to the client to bring an appropriate subject matter expert to the next meeting. This shows not only the flexibility to branch the solution out wherever it needs to go but also the strength of character to be willing to admit a lack of expertise in a subject. This leads to the next point:
BE AWARE OF ASSOCIATED FIELDS
No-one can know everything about everything; that’s axiomatic. What is also axiomatic is that you need to build the strongest possible expertise is your own field. What is more subtle – and often rarer – is the need to build at least passing knowledge of fields associated to your own. I so often encounter so-called experts who are completely focussed on their own field with nearly complete (and obstinate) ignorance of any other area of technology. I find this to not only be a completely obnoxious trait but also one which shows that their own expertise is seriously lacking. No ICT system exists in a vacuum. What good is a DBA that doesn’t understand how different storage arrays will affect database performance? What good is a VoIP specialist that doesn’t understand the concepts of network QoS or VLANs? You don’t need to be an expert but you still need to maintain rudimentary knowledge of fields that link with yours. I mentioned earlier in this post that at a certain level, I treat colleagues like clients and I meant it. For example: in my current role, I have no consulting responsibility for anything around Servers and Storage. This doesn’t stop me from routine chatting to our Server and Storage specialists, occasionally attending their tech meetings and reading their papers. This also certainly doesn’t stop me from keeping my eyes and ears open when theypresent to clients. I certainly can’t learn everything they know but if I can pick up on the high points and key-words, I can listen for them at my own meetings and recognise an opportunity to introduce them into a client. You can’t know everything but you should try to know everything you can. This leads to the next point:
LEARN TO UNDERSTAND YOUR CLIENT
This next part is so critical that I will put it in bold italics: Your client knows their own business far better than you do! The reason I emphasise this point is this probably the single biggest mistake I encounter in our industry; primarily amongst newcomers to the industry who still haven’t learned that being an IT genius that doesn’t make them a genius in all fields (I call this young doctor’s syndrome). Before you visit a client, take the time to visit their website and look them up in a search engine. Learn all you can about them so that you can understand or recognise key points when they are made within the meeting. If you try and tell the customer how to run their business, you will fairly quickly get a sore backside from doors that hit you on the way out of the building. The client knows their business and you know your technology. It is your job to help make your business assist their business. This leads to the next point:
YOUR CLIENT PROBABLY DOESN’T UNDERSTAND YOU
We are now moving to the second part of this article heading. If the client knew all about the services you are there to offer, they wouldn’t need you in the first place. You should obviously have a wealth of knowledge around your subject but your ability to communicate this knowledge is far more important to your client. This is why top scientists are rarely asked to present directly to their sponsors; their work is just too technical for the people who pay them to understand it. It instead needs to be “filtered” a few times, converting it from “techno-babble” back into “human”. As a consultant, you don’t have this luxury of filtering; you are the filter. This is the most important thing that you do; you achieve technical solutions to business problems. This is the key to your role and what differentiates the “consultant” from the “technical specialist”. Your job is primarily business, not technical. If you don’t understand the client’s business needs you have no chance of putting together a decent technical solution for them. If you can’t address the technical solution to the specific business needs that you have learned then you have little chance of getting them to understand why you are proposing to do whatever it is you are suggesting. This leads to the next point:
YOUR TECHNICAL TEAM PROBABLY DOESN’T UNDERSTAND YOUR CLIENT
Just as your client is more focussed on their business then they are on the technology that facilitates it, your technical team is usually focussed on the technology and doesn’t know (or often doesn’t care) about the relevant business environment. Your job now is the clearly translate the business needs into something the technical people can work with. For example:
The last two are the exact same statement, just put in ways that the relevant parties will best understand them.
You need to become a Babel Fish (from Hitchhiker’s Guide to the Galaxy; props to Tess Collins from Apple for coining the phrase for me) where your just is to act a real-time interpreter between the relevant parties.
Customer Service (which after all is what this all boils down to) is both an art and a science. You can’t learn to recognise all the nuances of a customer’s attitude (art) but you can learn to look for them and recognise the most obvious signs (science). This is a topic that could fill a whole book but I hope these points I have presented might help you in your business relationships.
