Unified Communications = Emperor's New Clothes?

I've just come back from a Unified Communications conference, I was speaking. Unfortunately I was speaking last which means I spend the whole conference worrying about my presentation. It's not that I mind presenting, but the last thing I want is to boringly repeat what everyone else has said previously.

This time, I realised that wasn't going to happen. Most of the talks were about what had been done using the big-boy tool-sets from Microsoft and Cisco. My talk was about what I'd done without spending any money or at least very little.

An analyst from Forrester opened proceedings, and at one point he said that unless you had a single unified interface then you hadn't done Unified Communications. I fundamentally disagree with this. It isn't the interface that counts, it's the user experience. At work, we use all the elements of Unified Communications, they're just not wrapped up in a pretty package with a Microsoft or Cisco badge, instead they're mostly free or open-source. The only exception to this is the Telepresence system we use for the board - that was just a JFDI, fair enough.

There was also much talk about how to justify the cost of implementing UC, and how you could demonstrate ROI, but in my view, what's the point? I'm finding it far easier to implement something for free, get take-up in a viral manner and then once its established and a necessary part of the company culture, then if it's really needed go asking for money.

One presenter talked about being more efficient because he could bring a specialist on to a call by using IM or roping him in to the conference call. It may be effective for the presenter, but for the poor specialist who's just been disturbed and drawn in to a conversation he's had no preparation for, it's anything but effective or efficient.

I feel a bit of a heretic, but surely as IT leaders we should be providing a toolset that enables our customers to communicate in the manner they wish in a cost-effective manner rather than worrying about whether it happens to come under a banner of Unified Communications.

Process for Process Sake

I've just come back from a trip to India to see one of my outsourced teams. I always find these experiences very interesting and this trip was no exception. We ended the week with a dashboard containing over 40 actions that would significantly improve the service if they were all completed. In addition, I got a real appreciation for the off-shore skill sets in my team and also the opportunities for utilising other skill-sets in the off-shore company's capabilities, particularly in the process re-engineering space. I hope they got a sense of being part of my company and making a difference.

Many times I've heard that the Indian outsourcers excel at following process, but if needed to go outside that process service dips quickly. Whilst not seeing this slavish following of process within my outsourced company, although the BPO team were definitely process geeks par excelleance, it was very evident in other places.

A great example was in the security checks at the hotel entrance. The security team were required to check every car for bombs. One security guard was equipped with a mirror-on-a-stick for checking under the car whilst the other was charged with checking the car. The security guard equipped with the mirror checked under the front, but not the sides or rear. The security guard who checked the car, just looked in the boot, didn't open or check anything (at one point we had 45 small white boxes all containing mugs - presents for the off-shore team - all about the right size to carry a grenade) but he didn't open and check a single one.

It was clear that the most important thing for the security guards was to complete the car-checking process, not actually be effective in ensuring the car didn't have a bomb on board. Process successfully completed - check, actual likelihood of finding a bomb: zero. All our bags were x-rayed on the way in to the hotel so perhaps it didn't matter that much. What was interesting though was that whichever hotel we went to the process happened in exactly the same way, quite clearly a fantastic, repeatable and quality process, but with very little benefit.

It takes me back to a presentation I gave a while back on incident processes. To emphasis why the process was required I used an example: Nobody ever buys a drill because they want a drill, they buy a drill because they want to make a hole, probably in a wall. Similar having a process for process sake is pointless, the process must properly beneficial otherwise don't bother.

The other thing that struck me about India was the absolute contrasts: Hot (outside)/Cold (inside), High Tech/Low Tech, Throw-Away/Make-do & Mend, Chaos/Order, Quality/Tat...

Must go back, see more.

Being an avid biker made the roads very interesting because there are thousands of motorbikes. Best I saw was 2-up with the pillion carrying a bicycle!!

Just Learn to Type... PLEASE!!!

So, a bit of a hobby-horse this one. Why don't companies make it a pre-requisite to have at least a reasonable level of typing and Office suite capability? Or, at the very least ensure that the new essential recruit has some relevant training.

Eh?

Ok, let me explain myself. I have what I consider the massive fortune of being able to touch-type at 60wpm. PAs shudder when they see me touch type because it's certainly not classical touch-typing, but it's still very effective. I can even do what many men can't - I can type and listen at the same time! I scared my CTO the other day with that one!

I can type an email, review it, cogitate on it, edit it and send it in about 1/3 the time that the majority of senior managers/directors can. This gives me more time to do other things, to think, to lead, gaze at my navel, whatever.

I had one manager who if you received an email from him any more than 2 lines long meant he had put his heart and soul in to it because it would have been painful and long to create. I never took his emails for granted! But he spent so long typing that it left him very little time for anything else.

However much we like it or hate it, typing and the ability to use the basic office suite effectively and efficiently is critical to a senior manager's success.

Surely if everyone could type fast, everyone would just write more? Possibly, maybe it would generate more emails, but I still believe they would be more effective overall.

As for office suite knowledge, I think I can illustrate that very easily: I had a call from a function the other day demanding Office 2007 because Office 2003 just wasn't letting them edit their documents the way they wanted to. I went and had a look. As I suspected it was a lack of knowledge of their existing toolset that was the problem, not Office 2003 letting them down.

Yes, you can see it bothers me. But if we senior leaders don't sort it out, before long Generation Y or whatever they're called now will come in and trounce all over us because be assured they will be able to type, and type fast and they'll have been using the Office suite since Year 1 at school. You can't survive in the on-line world if you can't type fast and that will come to the office without a doubt.

And no, voice recognition is not an option. Face up to reality, Go and find Mavis Beacon's Typing Tutor and learn to type, you will never regret it.

Oh, this post written and published in about 20 minutes.

Blocker or Enabler?

I was printing off some documents for a meeting the other day when I realised that yes, technology is a fantastic enabler, but it can also be a devastating blocker.

Why did I think this whilst printing out a document? Oddly it was because the printer was making me late for a meeting. Erm, actually, let me re-phrase that: my dependance on technology had made me late for a meeting, no actually, let me try again: my process for ensuring a successful meeting failed because it did not allow for the technology not quite working according to plan.

By this stage you may be wondering what I'm going on about. I needed a presentation printed out, I printed it a few minutes before the meeting expecting the colour laser printer to spit it out in a few seconds and I'd be at my meeting in time. Instead, firstly it ran out of paper, secondly it decided to re-calibrate half way through and then near the end it decided to clean itself. In the end I was 10 minutes late for the meeting. My expectations of technology had led me to be late for the meeting, I needed the print out to do the meeting. Fortunately my team waited patiently for me and I cursed the technology rather than my lack of organisational skills.

Then I thought about this in a larger context. How often do we have expectations of technology far in excess of it's capability and we end up with technology blocking rather than enabling. Is the NHS National Programme for IT a case in point - an assumption that technology was the answer and therefore used to solve a problem that wasn't actually, at its core, a technology issue thus ending up with technology being a blocker to successfully resolving the problem.

So, the question is how often in today's business arena is technology seen as the panacea when the problem should be looked at as a business issue of which the use of technology is just a part rather than the whole solution. When technology is the seen as the panacea, it becomes a blocker to solving the problem and can waste many millions. We as the people running technology in a company must ensure that the company we work for understand this and we help them use technology as an enabler, not a blocker.

Desktop Virtualisation - Fully baked or a damp squib?

Silicon.com had a piece recently about desktop virtualisation, apparently, it's all going to kick off this year. Is it? Is it really?!

In my view, it's a long way off and I'll explain why:

We have off-shore facilities that need access to our main CRM platform and historically another part of the group has provided this functionality using Virtual Desktops. We also have off-shore developer capability that also use Virtual Desktops.

I'm currently looking to take over this functionality, and having looked at the pain that it produces, the last thing I want to do is replicate it. It seems to be continuously unreliable, it is slow, fails at inopportune moments and usually does a great job of over-promising and under-delivering and is staggeringly expensive to expand or upgrade.

When I tell people the price for additional machines, they look at me as though I'm mad and I don't blame them: £600 for a basic virtual machine and £1,200 for a developer standard machine. The usual response I get is that they could go down to the local PC store and buy a machine for a lot less than that. And I wouldn't blame them!

How can virtual desktops get lift-off when the price point still isn't right. Surely a virtual desktop needs to cost less than £50 for a good spec virtual PC before we can really say Virtual Desktops have arrived. Anything else will just not make financial sense.

Also, in general so many things can get delivered by browser nowadays, the need for virtual machines is diminishing anyway. A basic PC with Windows and a browser costs so little nowadays, why would I want a virtual machine and all the hassle associated with them.

As for my remote developers, the best thing I can do for them is use a VPN or MPLS connection out to their office and create a LAN extension giving them direct access to our development boxes. Job done, lots of money saved.

So, why are Virtual Desktops supposed to go big this year. I've no idea, I've really no idea.

Not Management

A friend of mine has a very good idea for an on-line commercial business. He's sold the idea to a number of companies, even got some seed investment, but he can't bring it to fruition himself because doesn't have the technical skills to bring his dream to reality. A year or so on from the original idea, he's still unable to bring his unique proposition to reality.

Why? Two simple reasons:
- A lack of leadership & people management and
- A lack of detailed requirements.

Without these fundamentals his project will not succeed.

To keep costs down, my friend decided to rely on volunteer developers, working in their spare time inspired by both the idea and the promise of shares in the company. He also handed all responsibility for website development to the developers and left them to it having given them only a high-level idea of what the website was supposed to achieve.

Unsurprisingly deadline after deadline was missed. My friend was getting more and more frustrated. He had to persuade his seed investors not to demand their money back, very embarrassing. Finally on the way home from the golf course one day, we talked about the situation and managed to make him realise why his vision was failing to appear.

Simply, he had never given the poor developers sufficient detail in the requirements, had not controlled or managed them and had never controlled the direction the project was going at the hands of the developers. He listened and nodded, hoped it would all work out and got madder and madder, but would not acknowledge it was a management issue, simply put, he told me that "I don't believe in management".

I persuaded my friend to allow me to take control of the development. Up front, I told him there were only two possible results now:
1) Our developers would be reined back in and would follow detailed requirements we would provide. Or
2) The developers would entrench and then throw in the towel.

Either was acceptable. With the first result we got the website my friend wanted. The second result meant we could move on to pastures new using the newly detailed requirements that my friend had produced.

So, my friend and I took time out to develop the full requirements and logical map of how the website should work. We quickly had a far better idea of what the website was going to do than at any previous time. This logical diagram was given to the developers and openly discussed - many further requirements were formed. By the end of the session we had a decent set of documents that described the website and what needed to be achieved to make it a reality.

Now the developers had the detailed requirements, we had them constrained sufficiently to drive delivery. Initially we broke the whole thing down in to smaller portions, prioritising the work and agreed delivery dates. Every workpackage content and delivery date was decided by the developers - there was no chance that we could be blamed for setting unrealistic deadlines or deliverables.

The developers got going, time past, but instead of ignoring them as my friend had in the past, we did daily update calls and dug in to the detail every time. In the end and very much as I suspected, the developers threw in the towel. My friend saw this as a disaster at first, he thought we'd failed, but then he began to realise how far the relationship had fallen apart. My intervention brought about a dramatic conclusion, but helped bring issues out in to the open and mutually they discovered they were un-solvable.

Having seen the management in action my friend has acknowledged the need and he's also improving his ability to provide detailed requirements. We've found some professional developers who are better equipped to deliver specific work packages to deadlines and will be working full time, not part-time. Yes, the website has been delayed, but now it's far more likely to be delivered rather than never see the light of day.

I guess the point is, however small your dream or business is, never forget that to deliver that dream, you're going to need other people. Fundamentally that means leadership, people management and project management as a minimum. If you're not good at it, find someone who is. Don't bumble along believing that it'll all be fine. My friend learnt the hard way, please don't do the same thing.

Leadership and the Technician

Why does the best technician still frequently end up as the person promoted to run the team? I really would have thought we, as an industry, would have worked this one out by now and stopped this automatic process because the best techie is frequently by far the worst candidate for the job.

Most typically this can be seen in teams that are populated by uber-techies: network teams, Linux sysadmin teams, etc. The techies look upon the uber of uber-techies in the team as their silver-back gorilla. The senior management team spot it and reward that uberuber-techie by following the Peter Principle and promoting to incompetence. Indeed it's a double wammy because the promotion also reduces team productivity: the uberuber-techie is no longer doing uberuber-techie things, instead they are stuck in a world of people management and task allocation, sitting in management meetings bored out of their brains and generally not very happy with the result.

How wrong can it get, literally brimming with wrongability.

If I've not seen a spark of leadership capability, and frequently I don't, bringing in an outsider to manage the team is by far the best option. The only problem with this method is that the techie team usually fails to realise what's good for them and resent the imposition of someone with a management/leadership skill-set having had mis-guided expectations of promotion from within. So, if you do bring in an outsider, you MUST have methods in place to recognise the silver-back in your organisation and use techniques other than promotion to leadership to give them their continued growth outlet.

I've got one chap who's very happy being an uberuber-techie and just wanted to choose his own job title and get good salary increase each year. Well, that's an easy one - done and done! Others have aspiration to leadership, but have yet to demonstrate the skills, again that's not a problem. Provide them with opportunities to see if they really do have those latent skills - this can be done in minor, reasonably safe ways, for instance by providing project management opportunities or sending them on a leadership course or whatever. Finally if a non-management route to increased responsibilities is available then many will recognise that uberuber-tech is what they're good at and give up on the idea of leadership.

Simples!