Showing posts with label business. Show all posts
Showing posts with label business. Show all posts

Sunday, January 20, 2008

Time or Money?

Ask a business owner which is more valuable, and they'll invariably tell you time. But back in undergrad for most computer science folks it was probably the opposite… long nights fiddling with Samba, rebuilding your NT4 PDC, or fighting with your Java apps – there was plenty of time to hack away at problems... just because. But how many of us invest the time in learning new stuff now that we’ve got business’s to run, or teams to manage? I mean doing more than just keeping our heads above water in this rapidly changing IT service provider industry, and actually investing in learning something completely new… especially something where the ROI isn’t obvious?

For SBSers, maybe that’s learning a bit about 2008 core, or maybe it’s Linux, or scripting, or even C#. The point is, if your head is above water, and your business is growing, your model is working for you – so it’s time to start managing you’re most valuable asset – your time. You should be looking for opportunities to delegate more and more of the revenue generating aspects of your business to the people working for you, so that you can invest time in new areas. How? Look around – you probably have really great people working for you. Don’t believe me? Try rewarding them. I know that’ s a bit counter to what you’ll find scattered about “leadership” training programs – who for some reason – seem to think people want to feel good more than they want rewards. Forget that for a minute, and find someone who’s willing to make sacrifices – and then just start rewarding them. Bonus them out, reward them for making your life easier, and push them to fail. Think failure is a bad thing? I’d much rather have employees who will do anything for me, and sometimes fail – than a group of people scared to act because they're scared of what might happen when they do fail.

The bottom line... Time is your most valuable asset. Look for opportunities to delegate the day-to-day aspects of running your business so that you can go off and learn something new. Reward your best people, encourage risk, and move on to bigger and better things.

Monday, October 22, 2007

Employee Termination Policy in the SMB segment

Browsing Chris’s blog (which has tons of useful and informed commentary) I came across a post on employee termination policies. This is an often overlooked piece of working in the SMB segment. Why the miss? Good question…

First – perhaps most obvious … Small IT service providers (which really should already have lots of familiarity with security and trust), usually don’t have the right experience here, and as a result most of them are terrible at it. Why? Maybe they’re too small to know what a larger organization needs … or maybe they have the wrong employees (or owners)… but I’d be willing to wager that most who are bad at this, are bad because they’re so concerned about preserving the existing revenue streams… with not rocking the boat, that they turn a blind eye to helping clients manage other forms of risk. Let me give you a couple of examples on risk… Licensing a mess? See no evil. Employee’s with grossly inappropriate (or negligent) access? Hear no evil. Or the worst offender… provider is too busy. They’re too busy to add-value… too scared of risking the revenue stream, or too fill-in-the-blank that they really fail across the board… and unfortunately, it’s the customer who pays.

Need examples of the risks here?
Employee X is terminated, no one tells the IT service provider – and… use your imagination.

Employee X misrepresents their previous employer … or steals sensitive information, or wreaks havoc by deleting files (or randomly modifying data). An endless stream of nightmare-ish events.

And the worst thing about this? Most clients will have no idea that their IT service provider is responsible for this miss. Sure, the client might not have notified you… but did you ever bring it to their attention that the risk existed?

I can hear the complaints now… it’s too hard to sell a client on this. Really? You really can’t sell clients on having a policy and procedure in-place for managing turnover? What kind of effort does it take to put something in-place, and get HR and ownership to buy-in? Hours? Days? Is that too much for your clients to swallow? If so – start upgrading your client-base. Because I haven’t found a business owner – or decision making HR-person that didn’t think this was a reasonable risk to address - it's your job to figure out how to address it within the context of your client's expectations. And remember, this isn’t selling on fear… in fact, if you have to sell this at all, and it’s not a frank conversation between you – the trusted advisor – and your client, then you’re missing more than just this.

If this doesn’t make sense to you, put yourself in the shoes of an IT manager, HR person, or owner of your client organization (and then ask yourself why you haven’t been doing this all along). I guarantee you that if you were in those shoes at a mid-size organization, you’d be taking ownership of this yourself and getting it addressed ASAP. So do, and it might open up more doors at the client. At the very least, you’re cleaning up messes, and addressing real-world risk.

Tuesday, August 21, 2007

What’s your value proposition?

Since my last post, I’ve been reflecting on what others have been posting in comments and elsewhere about partnering with Microsoft, Software without service, and the like. One thing that strikes me about the “infrastructure” side of the work we do is that from a business perspective, delivering infrastructure is really just a necessary evil. If you think about it, infrastructure is certainly the biggest “risk” in terms of the relationship (managing expectations, delivering services, and closing the project), the most capital-intensive (outlays for equipment), and the most difficult to manage from a labor perspective (preventing overruns and the like). Now we certainly do business on the infrastructure side, and we still deliver equipment and infrastructure to our client’s “server rooms”. Are we profitable on a project-basis? – maybe… but I liken it to selling razors. We deliver infrastructure (the razor) at or above our cost, but we make our real margins as we work-up the services stack. What I mean by the services stack, is going from a break-fix shop, to having some type of “managed services” offering, to eventually becoming the trusted advisor and/or virtual IT Director for the businesses that our clients own. As we work up the stack, it’s these “softer skills” that are the most profitable… getting infrastructure on-site is the just the hook that we use to deliver everything else that we do… and the more I think about it, the less I care if I’m delivering via the cloud, or via equipment. To use another analogy… think about gold rush of the 1850’s… sure maybe guys like Hurst (think Microsoft, Google, and Dell) made vast fortunes, but most of the miners (SBSC’s and IT Pros) just scraped by, or worse, went bust. In between, were the guys and gals that moved up the stack, and sold mining tools and equipment. It’s these types of businesses that thrived as people went out seeking their fortune. Look at the SMB IT segment, who’s moving up the stack today, and what exactly does the stack look like?

So I’m looking at the cloud and thinking about IT infrastructure… be it OWN’s offerings, or the various platforms that you can use to build-out solutions… think 3TERA, Amazon, and Sun (and to a lesser extent VMWare, and Virtual Server). The utility/grid computing folks are in business to deliver scalable infrastructure that “just works”, so that they can insert their “infrastructure-tax” (just like the Google advertising tax, or the Microsoft Windows tax) into tomorrow’s solutions. Why? Because it’s zero-touch (and has higher margins than selling boxes). You design a really good scalable “grid”, and you sell computing as a utility to companies that want to offer some type of application or service (this should all sound very familiar). The ASP (for lack of a better term) then treats the utility as an incremental cost of doing business, and can factor it into the solution they’re delivering. What’s great for the grid-folks is that they make money as their customers are successful, but they can offer the utility virtually zero-touch, and as we all know… zero-touch and scalability is where the money is.

Taking into account services via the cloud, where are we – as SBSC’s and IT Pros – going? We’re probably not going to go out and build our own grids (the grid-folks of tomorrow will be the Dell’s and HP’s of today), because grids already exist in some form today; they’re inexpensive, highly complex, and evolving. The one-man-shops and network plumbers who just deliver infrastructure are the businesses at the greatest risk – because they’re going to get squeezed from both sides (i.e. the cloud, and service providers with a niche further up the stack). Next up are the better-run small companies that just do break-fix – it will be slower in coming, but any one of us who can present a reasonable value-based argument is going to be better able to deliver services than that bunch. Next up are the vast majority of us who deliver some mix of managed services, break-fix, and block-hours. We’re the ones who need to be seriously considering how we deliver services – either partnering to deliver infrastructure via the cloud, building our own clouds, and/or moving further up the services-stack. To go back to the mining analogy… if we as SBSC’s, and IT Pros are mining gold… what do we need to do? Well, selling our services to each other is one good option, and moving up the stack to become virtual IT directors, developers, and the like for our clients is another. But as we look at some of the niches within the stack, there’s only so much room… how many different OWNs can the SMB community support… or how many MSPUs can provide really valuable mentoring to the SMB IT community? Sure, maybe we have a rising tide effect going on – but I’d venture that there will only be so many players further up the stack. Now maybe those companies have businesses that do work throughout the services stack… but they each have their own niche and value proposition that is unique and that not everyone in the community can readily deliver. So they’re better miners than us within their niches, and as a result are less vulnerable to a Microsoft or Google.

The future is unwritten.

That's true... and we don’t know how the grid computing game is going to play out just yet. But we can make some informed guesses based on past technology cycles, and I think we really need to be prepared in order to compete and stay relevant. Does that mean I won’t be selling infrastructure tomorrow? No, I probably will be. But I’ll probably be delivering infrastructure via the cloud and via equipment, focusing on service as a subscription, and I’ll keep moving up the stack delivering “IT Director” services to my clients. At the end of the day, it’s about the relationship that you have with your clients, and how good of job you’re able to do at scaling your offering, while remaining competitive.

Tuesday, July 17, 2007

How-to: Handle job candidates who back-out after accepting an offer

It looks like Andy had a job candidate back-out on him after they had already accepted an offer. Thought I’d do a short post on some of the learning’s we’ve had with this already, just in case anyone else is going though the same thing.

First of all… don’t feel bad, because it happens. Try not to get frustrated, and realize that it’s just a cost of doing business. Easier said than done maybe, but it’s a goal, right? Best approach is to find ways to minimize the amount of pain that results when this does happen. As an aside, I’ve had candidates shop the offer after accepting, and it’s something that is hard to eliminate… often an employer will throw money at a good employee who’s considering leaving… so just keep that in mind. That said, the vast majority of the candidates that have accepted an offer seem to come on-board, and I always have a frank conversation with them about their current employer, and the likelihood of them doing a counter-offer, reminding them that we won’t get into a bidding war.

Next, it might be worth seeking legal advice if it really bothers you. It’s been my observation that the threat of legal action is a powerful one, even if there doesn’t appear to be much that can actually be done in this arena that’s really worth doing… but your mileage and options may vary.

After that come the practical things. First of all, get your bases covered… we don’t tune up phone contracts until after the first 90-days (consider letting them expense it, if it’s a sticking point), nor do we order business cards during that time period. In fact, we don’t do a lot of things until those first 90-days have passed. We stipulate that the first 90-days are an “evaluation period” when brining someone on, and that they’ll receive some type of review at the end of that time period. Other stuff we limit or otherwise restrict during that time period... Domain Admin access on client systems is restricted, as is access to the premesis after hours, all server room access, unsupervised access to clients (during the first month), and a few other things more specific to our business.

Things we do…
We do order a laptop/workstation once they accept (we can always use spares).
We do tune up a network account, and phone extension.
We do conduct the various HR tasks related to on-boarding.
We do send out a new employee introduction email to our employees as well as clients
We have lunch with the new person.
We do compensate based on the prevailing market rates (who wants an employee that doesn’t stick around beyond a year?).

Otherwise, pretty much everything is negotiable and flexible - despite the above. Oh yeah, and we try real hard to not let candidates who back out on us bother us too much.

Tuesday, March 20, 2007

Business: The new client on-boarding process

To follow-up on my last post, one of the learning opportunities that came out of the DST effort was in our client on-boarding process. For the uninitiated, client on-boarding is just what it sounds like… the process that we follow when we add a new client. So how is this connected to daylight saving time?

Competing priorities.

For us the two most common ways that we engage a new client is through project work, or in some type business-down situation. As much as I wish that new clients all came on with clean, working systems, fully patched, using our supported application-stack… we all know that's just not how it works. What we did have though just prior to the DST change, was a CPA firm that brought us on to handle support issues and get them though tax season, as well as to do a network assessment and make recommendations to better prepare them for next year.

At the point that we brought this client on, we were running at about 125% utilization. Utilization is one of the metrics that we use to help measure our staffing/loading, and 125% is pretty high. As individuals maybe you and I can each do 150% for weeks on end, but as an organization, you can't expect to max out all of your people for an extended period of time without developing quality issues.

Getting back to the process – the client came on-board just days prior to the DST change. As a result, there wasn't enough time to schedule a proper network assessment. The on-site Engineer did a spot-check of their system to hit the highlights and... they were way out of date. The servers were all running 2003 (no SP), Exchange 2003 (no SP), no patch-management tools, out-of-date antivirus software... the list goes on. With DST approaching, we met with the client and highlighted the DST risks, and the considerable effort that would need to take place prior to the change. We then started working though the punch-list to get them covered for the DST change. Complicating this was the fact that the this is their busy season as April 15th approaches, so treading lightly while still accomplishing everything was a key deliverable.

End result?

We were successful. Everything was patched, and functioning prior to the deadline. However, this success came a cost. From an internal perspective we were busy re-prioritizing tasks, shuffling resources, and generally making life difficult for ourselves. As a result, it has became apparent that we need a more effective client-on-boarding process. Not only should this process better address some obvious deficiencies – the hand-off from sales, technical account ownership, and network assessment projects, but also incorporate our metrics into the process. For instance, does our utilization rate, effectiveness rating, pipeline, and profitability in existing verticals support adding this client? Does this vertical present any business-specific risks? Or In other words, does this client fit our business model, and if so, can we effectively bring them on without risking current clients?

Thursday, September 28, 2006

Business: The Guide to a Successful Managed Services Practice… Or, how a $100 book saved me $12,000

So maybe you don’t trust Vlad’s opinion of Eric’s book… I mean, really… how do we know he’s not just plugging the book for his buddy, right?

Having read though the book myself last weekend, I have to say it’s a great resource for any SMB IT service provider. It doesn’t matter if you’re a 1-man break-fix shop looking to get out of the hole that you’re in, or if you’re already doing good work in a business that can scale, you will learn something. Oh, and if you ONLY come away with $100 worth of value, then you missed the point entirely.

I’m not going to write another review… that’s already been done effectively elsewhere. What did the book do for me? Like the title says… one week after having read it, the $100 book saved me $12,000. Don’t believe me? Okay… we’ve been looking at advertising options and working on the business plan for a while now… essentially, we’re trying to figure out a way to generate more good leads. The book talks about that… and we already have the numbers to drill down though for our ROI calculations… the $12,000 would have been better spent on… just about anything else. So instead of blowing 12K and hoping, we have a better plan. Are we where we want to be yet? NO! But 12K in savings isn’t bad for a casual read on the weekend… and it’s already paid for my trip to SMB nation next year.