As of 2014, 98% of businesses in BC are considered small businesses. 53% of those are self-employed individuals, while 45% have less than 50 employees (source). McLean IT specializes in small businesses, so this is written for the 98%.

What is an MSP?

The term MSP is most often applied to the IT Industry. A Managed IT Service Provider is someone who assumes responsibility for the management and support of IT systems as selected by their clients or as dictated by their requirements. They are typically used by small to medium-sized businesses without the luxury of a dedicated IT staff.

Why Do I Need an MSP?

As I mentioned in the beginning, the overwhelming majority of businesses in BC are Small Business. Therefore it can be especially difficult for them to maintain their own IT systems as well as larger enterprises that traditionally employ an entire department of IT personnel. There might be a tech-savvy person who becomes the de-facto “IT guy”, but as technology evolves, they can quickly get in over their head. The tech industry changes fast. It can be exceedingly difficult to stay current even among professionals.

Working with an MSP offloads the responsibility of management and support to a third-party who is experienced in maintaining systems just like yours, and are dedicated to keeping on the cutting edge of technology so that they can adapt along with you.

A medical clinic, for example, will use computers to maintain appointment scheduling and billing, faxes to communicate with other physicians and pharmacies, printers and even a server, all of which operate on a network. They would be hard-pressed to keep an full-time IT professional to support their systems, but on the other hand, if something breaks, they need it fixed now. That same clinic might decide one day to move away from paper records to a paperless EMR (Electronic Medical Records system), but have no idea where to begin or what is involved. This is exactly the scenario where an MSP excels.

This sounds expensive

Not at all. Staff turnover, training, experience (or lack thereof), downtime, and of course wages all apply to in-house staff. The cost of an MSP can be regulated by a contract or on an as-needed basis, also called a “break-fix contract” which is exactly what it sounds like: it breaks, the MSP comes and fixes it.

Take the medical clinic example above. Let’s say a single computer has broken. How much productivity is lost both by the lack of computer, and the employee tasked with bringing it to a computer shop to fix — often with a turnaround time of a day or two — then picking it up again? MSPs will most often respond within the hour with a prompt visit on-site to resolve the issue.

In fact, one study in 2013 cited both “lower costs” and “higher quality of service” as reasons businesses were turning to MSPs to outsource their IT management, predicting 70% of IT infrastructure will be outsourced to MSPs by 2017.

Where Do I Start?

Call us today to discuss what we can do to help your business — 250-412-5050

A large part of what we do here at McLean IT is manage client infrastructure — or put in plainer terms, the servers and networks that support their respective businesses. No two networks are exactly the same, and that’s by design. There are some foundational similarities between them, but as they say, “form follows function”. The exact architecture of any given system of computers dictates unique needs of the business.

[Read more…]

I spent half of today trying to track down the server hosting one of my clients websites. The business and website have been around for so long, and the site maintenance and development has changed hands so many times, that the business owners have no idea who hosts their website, nor whose account controls it. The world won’t end without this information, but until I get it, their website can never be updated, and I can’t implement any branded email for that business. Basically, nothing can change.

I’ve preached the gospel of documentation before, but for you fellow IT technicians, I thought I’d give some tips.

In my experience, those in the IT field tends to have stronger math skills than language skills, so technical documentation doesn’t come naturally to most. But the fundamental importance of documentation cannot be overstated. And although technical writing is a career in itself, it is a skill that should be cultivated by every IT pro.

Servers are probably the easiest place to start. In a busy IT environment, a lot can change in a short period. To avoid the impression that you’re laying track while trying to catch a moving train, start with something that doesn’t necessarily change so quickly.

Clean Up First

Sometimes businesses grow so fast that the infrastructure doesn’t have time to be tidy. One client that comes to my mind was so overly complex that the only way I could even fathom beginning to write documentation for was to start consolidating things. There were four different internet connections and gateways, each with their own configuration. I replaced those with a single, 4-WAN-port router. There were also two different fax servers and two NAS devices, none of which worked properly. I culled the herd until the infrastructure made sense again and from there I could rebuild.

Ask Questions Like Your Life Depends On It

The devil is in the details. Capture everything you can. And I mean everything – even down to the date of deployment and hard drive serial numbers. That can save a lot of time down the road to determine warranty status, or to schedule hardware upgrades. If there are any quirks or special considerations for a particular piece of hardware, include that in the notes. A proprietary piece of software? Include it. Does it have RAID? How is it configured? Is the drive partitioned? How? Is it backed up? When and how? Are notifications sent out upon success/failure? To whom? Most importantly, what roles does the server fill? Domain Controller? File, web, or database server? DHCP? DNS? VPN? E-Mail? Fax? Are there shared folders? Where is the original install media? Does it have a static or dynamic address?

Bottom line is, an outsider (assuming all random outsiders are also IT technicians) should be able to walk in off the street and know, at a glance, every practical nuance of the device in question. Because frankly, that random outsider could be you. Sometimes a server could be a champ and work without any intervention for ages, and then POOF. It breaks, and you know nothing about it because you never had to.

Avoid the proverbial egg on your face with comprehensive documentation.

Software & Licenses

This can be a long list, depending on the size of the business in question. The types of clients I work with are comparatively small – anywhere from two to fifty users. But even small businesses typically have a surprisingly long list of software that they frequently use. If they use accounting software, one would hope that they keep a record of their correspondence with the vendor, which typically includes the key codes needed to activate the software. I would argue that any and all codes should be kept in a unified IT document as well.

The kinds of information captured here are purchase dates, license codes, license restrictions, registration information, system requirements or dependencies, and also vendor information.

My documentation will sometimes refer to to software user manuals, and I try to also identify where that manual can be found, to save time sleuthing around the internet.

Include Contact Info

Yours, the client’s, everyone’s. Include the phone company. The ISP. The web host. The domain registrar. The go-to electrician. Anyone who either you or the client might need to contact. It’s not enough that the info is on your speed dial. That doesn’t do the client any good after you were hit by a bus.

Diagrams

Perhaps one of the biggest time savers. Some networks are simple: a router with many clients. Some are not. Cover your bases. The definitive diagram designer application for Windows is Microsoft Visio, and for Mac it’s Omnigraffle. There are other alternatives. Diagrams aren’t always limited to complex networks either. Maybe the client has clustered servers or a co-location. Or maybe they utilize server virtualization. Diagrams are always helpful. That’s why instruction manuals are usually full of them.

Time Is Money

You may be sensing a theme here. IT documentation should be designed to save time. As a reference document, it saves your precious time, and makes you look professional, and more importantly, proactive. If anything were to happen to you, it’s also a form of insurance for the client, because now at least some of your extensive knowledge can be recovered or shared. If you work for a company with many technicians, then all the better. Your fate is no longer tied with that one client. You can send the new guy, if he’s up for it.

Update It Regularly

Regularly is relative. In some cases, collecting all of this information is done passively over a very long period. The last one I finished took roughly six months. The important thing is that you update it as you make changes, and audit it say once a year.

IT infrastructure is a living breathing beast that grows and expands with the business. Documentation should grow and expand with it, or it quickly becomes useless.

Use A Template

Save yourself time in the future by making a template in whatever word processor you chose. The information you collect is largely the same no matter who you’re doing it for.

Up until recently I used a Pages template (yes, on a Mac), because hey, it’s pretty. But now I use Scrivener, which is what you might call a document project management tool. At it’s heart, it’s a word processor, but with a few new tricks. How to use Scrivener is way outside the scope of this document, but suffice it to say, it’s perfect for technical writing. And for those of you who already use Scrivener, I’ve included a template that you’re welcome to use.

Scrivener IT Documentation Template

I was inspired to do this post by Sharon Bennett (@bennettbusiness) with her article “My IT Guy was Hit by a Bus!“, which resonated with me because my early mentors used the same metaphor to drive home the importance of – yes – documentation. Her post included a great example template that looks to have been written in MS Word, which I’ve included a link to as well.

Sharon Bennett’s Great Documentation Example

Her articles are actually really presented well and when I read them, I find myself nodding in agreement. She does a far better job at speaking to the Small Business audience than I ever have. Check out her site here: http://bennettbusinessconnections.com

Do you have any experiences where proper documentation saved you from disaster? Have your own templates or methods for documentation? Something important that I missed? Let me know in the comments!

Not to beat a dead horse, but I wanted to be clear on the importance of IT documentation. To date, I’ve yet to start with a client who already has it. In some cases I’ve been able to force the previous IT support vendor to put something together from their records (always an awkward conversation), but even then it’s been so inaccurate that it is virtually worthless.

I wish I remembered who first told me “document it, or it doesn’t exist”. It might have been my boss when I used to work as a systems admin at a local software developer company, as that mantra is more common with programmers. But of all the advice I’ve been given in my career, that one stands out the most.

Ironically, when I went to technical college, we were taught how to tear down hardware and build it up again, how not to electrocute ourselves, and how to diagnose both hardware and software issues with computers. But what was woefully absent was any kind of documentation training, which is a real shame. But to be frank, I think this really separates the professionals from the amateurs.

Francis Bacon once famously said “Knowledge is power”. With IT documentation, you harness the power to make informed decisions about your infrastructure.