Help Desk Support: Outsource or keep in house?

Help Desk IT people are the front line people you call when you first come across a technology problem. When your computer blue screens, flakes out when you hook up a projector, or when Outlook seems to eat your e-mail. If you dig through research from Gartner, business magazines, and IT management magazines, you can find all sorts of statistics on the correct size of the IT staff for a particular type of business – and most of it is contradictory. I’ve come up with simple guide for the small business owner based on my experience:

If you have less than 10 people in a single office, you probably don’t need a help desk at all. Your network is probably not that complicated and the risk of major incident is relatively low.

Until you exceed 125 people in a single office or exceed more than 75 people in two offices, you don’t need an in house help desk. A business with multiple offices now has a serious network to maintain. They are going to need more support and that means more people and that means more situations where an in house help desk in needed.

For offices in between, an outsourced help desk is the best answer. Level One Help Desk Support is a pretty tough job. You get to deal with pissed off people, people who are in a hurry, and people who are ready to spread the pain. It seems like your IT person is bouncing from one crisis to another. Hiring for people skills is almost as important as technical skills and a small company doesn't offer enough challenge.

Also, a company can’t have a single Help Desk person. Since they are running around putting out fires, they are almost guaranteed to be in the wrong place for the next problem. With an outsourced help desk, they will take care of that but if you bring it in house, there has to be at least a person who has partial help desk responsibilities to reduce risk of “missing” a key incident and to avoid staff burn out.

E-mail: Outsource or keep in house?

Back in the 1980s and 1990s, e-mail was just moving from techno-novelty to normal business tool but now everyone just expects to be able to read their e-mail 24x7, anywhere in the world, accessible from any device. It has become like getting dial tone when you pick up a phone – is just there. Even though social media appears to be displacing e-mail in general communication, all businesses will need to maintain e-mail access for their employees for the foreseeable future.

E-mail systems can be pretty messy to maintain, though. Sure, the big companies can afford to have specialists to setup and maintain e-mail systems but what should a smaller company do? How to pick a system for a company of 30 or 150 employees? Do they go open source? Gmail? In house Exchange? Hosted Exchange? Classic POP or IMAP?

I am a bit biased since my experience is with maintaining Microsoft Exchange and Outlook. Outlook’s shared calendar features, invitations, contact management, and all the productivity tricks have just become too standard – almost everyone uses Outlook and you get the best user experience when it is connected to a Microsoft Exchange server. Prior to the recent rise of hosted Exchange providers this was pretty expensive, but things have changed.

In fact, there are so many options that it can get frustrating to find the best option. Here are my guidelines:

Size

• If you have less than 50 people in your company, you should use a hosted service.
• If you have more than 250 people in your company, you should have in-house e-mail systems

If you are between 51 and 249 people then you need to look at these questions:

• If you already have an in-house IT staff, servers at a high-quality data center, and are used to providing 24x7 services, you should probably bring the e-mail system in house
• If you have custom applications on your network that send and receive e-mail, you should probably bring the e-mail system in house
• If all your servers exist in your offices and those offices have only basic batter backup, basic access to the internet, and you do not have IT staff with e-mail experience, you should use a hosted service

Hosted Solutions

For those companies looking at hosted solutions, the character of your employees will likely determine which type of hosted solution you should use.

• If you have employees that are not techies (meaning that they just want Outlook to work and don’t care about anything happening in the back) then you should get a Hosted Exchange service with spam filtering and ActiveSync access for smart phones.
• If you have people who already use Google docs, like experimenting with new things, and are generally self sufficient when they have IT issues, then it generally doesn’t matter what e-mail system you use. However, Gmail seems to offer the best deal for this time of office culture.

Of all the hosting options available, please do everyone a big favor and don’t use POP e-mail. A service with IMAP is acceptable as long as it is the Secure IMAP that uses encryption but please, please, please, stop using POP. IMAP, Gmail, and Exchange all use the idea that there is only one mailbox and that mailbox can be read and copied to multiple locations while still acting as one mailbox. POP is a temporary parking spot for mail and the local software is not really “linked” to the POP server. If you connect to e-mail with multiple devices – which almost everyone does these days – you end up with partial copies of e-mail scattered all over the place. Mail sent from your phone is not visible on your computer, mail deleted on your computer might still exist on your phone, and so on. Better solutions exist, so stop using POP.

In House Solutions

I still strongly recommend Microsoft Exchange – the features are just too comprehensive and too useful.

Due to recent changes in how the software works, Microsoft Exchange 2007 and 2010 can run on much cheaper hardware than Exchange 2003 could. You still want to make sure you get good quality, redundant hardware with plenty of RAM and disk space but this will no longer break your budget quite as much as it used to. The exact details of what you need is impossible to describe in a single blog post but if you are in Seattle, Portland, or anywhere along the west coast of the US, my old company ISOutsource.com can give you practical advice and help you set it up. They've been working with Exchange since Exchange 5.5 and have consultants that have done more installations than you’ve done oil changes.

You will still want a hosted anti-spam service. By hosting it outside your network, none of that spam will travel down your internet connection and free up bandwidth for real business. Also, you won't have to worry about updating the system or maintaining the anti-spam definitions.

Things that you should insist that your programmers NEVER do

I am not a real developer – I only play around the edges and keep up with the basics – but I think I’ve found a few “truths” that project managers should use when managing development projects. I pull a lot of advice from two authors: Jeff Atwood and Joel Spolsky who work together on a project called Stack Exchange. Their opinions are not universally loved but I’ve seen internal development projects that could have been much more successful if our developers had followed these rough guidelines:

• Functional Specs are Useful: Quite a few developers hate specifications – hard to write, hard to read, hard to use, and rarely useful. For many technical specifications, these developers are extremely well justified. Joel Sploksy offers an alternate view of specifications that is far more useful. By creating a written description of what a program is supposed to do (a functional specification) instead of how a program is supposed to be built (a technical specification) you get the chance to provide useful information to your developers. Read Joel’s multi-part description how to do that, then read The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper, and start writing documents that actually help your development projects
• Internationalization from the Beginning: Over the past two decades, every business article, magazine, web site, and book has been talking about how the world is flat and every business is competing on an international playing field. So why do I keep finding software that won’t install in a Japanese-language Windows PC? Why do websites turn 日本語 into ??????? Even though you don’t see need to support international languages now, you can make sure that your developers don’t shut the door early. I recommend that you start your development effort with a requirement to support multiple languages and force them to explain why they shouldn’t. I’m sure there are legitimate reasons for English only but make them justify it.
• Real Testing Hurts: When developing on your own laptop and connecting to a server that is down the hall, you are sitting in an almost perfect environment. Don’t let your developers test in a perfect environment – you won’t learn anything. For example, if you want this new application to work over the internet, you had better test it over the worst connection you can find. As Jeff Atwood points out, performance of your application in the real world is a make-or-break moment. You should make sure your developers run things in high-latency, low-bandwidth, sub-optimal environment or you may be in for a big surprise later. The internet is not new and the internet is not an optimal network.
• ASCII Text is NOT Enough: I think all developers need to read this article from 2003 about how to handle text. Even though the internet enabled, international business era is old news, it is surprising how many different systems mange non-ASCII text. Even my iPhone 4 occasionally takes a Japanese language website and renders it as some odd collection of wingding symbols. In addition to the point about internationalization of installation, make sure that your custom development doesn't manage non-English input. After all 田中一路様 is unlikely read mail addressed to ????????
• Things Break – Handle It: When you are working with complex systems, you have many different points of failure. It is a given that during the life a particular system that some key part will fail and it is up to your developers to handle it. To quote the Netflix developers “Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.” That particular team took it to extremes but since they were designing a massively mission critical system, it was worth it. When starting your development project you need to explain to your developers how much robustness you need for this project. If you let the developers pick you may not be happy with the results since they are likely to look at it from the “how hard is that to program” level and not the “how important is that to the business” level.
• Size Matters in Development: Test data is more dangerous than you might think. It is common for developers to use a very small set of test data in the database and run all tests against that smaller database. However, if your final system is going to massive, multi-server, multi-site, thousands of users then you had better make sure the pre-deployment testing is performed on a larger system. Jeff Atwood has a great explanation of the risks and how to avoid them that you can probably just hand directly to your development team.

Please post your own comments and feedback here. I'm interested if developers disagree with me on this.

Project Management Across Time Zones

Even though I haven’t been working for a global company for all that long, I’ve noticed that a lot of people have difficulties with what seems like a trivial issue: time zones.

My company has offices in the majority of countries, with people in almost every time zone, and it has been that way for years. Even so, most people seem to have difficulty – at least occasionally – correctly accounting for how business is impacted by time zones. Sure, some teams may never care about differences in a work day, especially if the groups are only loosely coupled, but if you have a global team, your project coordination can really suffer if you don’t pay attention.

For me, the most common issue is the lag time for back-and-forth communications. If a group in Tokyo asks a question to a person in Paris and that person responds after lunch (Paris time), that is close to the end of typical work day in Tokyo. All it takes is one or two people coming in late or leaving early – dropping off children, stuck in a meeting, or a doctor’s appointment – and the communication loop will be delayed at least 24 hours. In this more connected world, blackberries, web mail, and iPhones help with after-hours communication but that is not a panacea.

Since time zone lag is unavoidable, clear and complete communication is essential. Wherever possible, you need to “close the loop” to avoid multiple back-and-forth exchanges since each loop might have a delay. What I try to do is:

• Clarity in references: When assigning a task for “end of the day, Tuesday” make sure you explicitly say what end of who's day you mean. “Due to the telephone call with Atlanta, please send me that document before 8pm Tokyo time (1pm Paris time)” is more likely to be understood than “before lunch”. Referencing the other person’s time zone is probably best but if there are multiple locations, using UTC or GMT time is better. When using UTC / GMT time, I tend to use 24-hour / military time for additional clarity. That may just be me, though.
• Clarity with schedule constraints: If there is something that needs be done before an Asia office opens for the day, it should be made clear to people in later time zones. Especially in the IT world, people think that midnight on Sunday is an excellent time for routine maintenance and may not realize that your Asia offices is already open for business on their Monday morning. Combining this with the previous tip, “Make sure that this patch installation is complete at all sites before 23:00 UTC on Sunday, October 23rd, to avoid conflicts with the Tokyo office” would be a good way to tell team members of a schedule constraint.
• Clarity with dependencies: The time lag affects decisions as well. If an office needs to receive a decision from a manager the “early” office in order to work, the “late” office could waste a day, have people sitting idle, or miss deadlines if the manager didn’t know that people are waiting.

No matter how you manage risk, things happen. In a global team, after-hours contact procedures must be included somewhere in your risk response planning. This is even more important in those European countries where after-hours work is strictly controlled and after-hours contact information (phone numbers, pagers, etc.) is strictly controlled by employment law. The last thing you need is to have a major office down for several hours because no one had a phone number for a service provider in Stockholm.

Even the most routine activity - scheduling meetings - is made more difficult. Knowing that Tokyo is in UTC+9 and Seattle is in UTC-8 should just mean some simple math to pick a time, right? Unfortunately, over the past decade, there have been many changes in daylight savings time rules. It can be hard to tell when things change and how that affects your regular meetings. Your calendar scheduling application probably has the correct settings but I think that every global project manager should regularly check with www.timeanddate.com. They have an excellent meeting planner and pretty clear explanations of other time and date related topics.

Even with all the challenges, you can leverage the power of time zones for a project. Having other people working while you sleep can really speed things along and reduce total durations. The key to this, like many project related efforts, depends on communications and collaboration. As long as the work is broken down to easy to manage work packages, there should be a way to hand-off task between teams. If your WBS is really detailed, the hand-off can probably happen with just simple e-mails or status reports but it is likely that some sort of hand-off meeting will be necessary. The time commitment, attendees, and frequency of the hand off meetings will vary a lot but I find that IT related projects need meetings between project managers on a daily or three-per week basis for 15 minutes over the phone at a minimum.

Global project teams can really accomplish a lot if well coordinated. Multiple time zones add complexity but by paying attention to schedule details, you can come out ahead.

Dear Web Programmers: Not everyone has a ZIP code

I've been living in Japan for almost four years now. As an American citizen, I still have to do business with companies in America (bank accounts, IRS forms, etc.). I'm pretty sure that I speak for every ex-pat living outside of the US when I say:

STOP MAKING ME SELECT A STATE AND TYPE A FIVE DIGIT ZIP CODE!

I don't have a state... I live in Chiba. My postal code is 261-0013. What can I possibly put in the ZIP field that passes your ZIP validation code. Should I put all zeros? Put in the address for the White House?

Look, I know that coding for international characters and international addresses is more difficult. But, it is 2011 and the internet is getting kind of old. You have had time to realize that companies can do business in Korea, Thailand, or Japan almost as easy as doing business across state lines. Please do us all a big favor and copy the user interface of companies like Amazon. They actually understand....