Big vs Small - Forging an effective MSP business

In terms of effective and profitable RMM service delivery, which is it better to be: a small one or two man shop working out of a garage or a large shop with four-hundred plus business customers?  To answer this we first need to look at the pros vs. cons within each environment.

Generally speaking, a small shop is likely to have working in their advantage:

• A high degree of price and product flexibility &
• Very few committed hours

Unfortunately, this usually means that:

• Tasks and projects are scattered &
• There's little cash in reserve

Which is really tough because:

• It's very hard to get traction &
• You're a bitch to your customer's whims

OK, lets look at the other side of the coin.  Again, generally speaking, a large shop is likely to have working to their advantage:

• A high level of product specialization and hyper-efficient product delivery &
• Known good processes for the vast majority of customer requests

Which sounds much better than Option A until you consider this also means:

• An equal amount of product rigidity &
• A discouraging environment for innovation

For a bottom line result of:

• Tomorrow's product isn't being built because
• You're a bitch to the process

Good thing I'm not a motivational coach, eh?  Neither of these environments seem to be good MSP incubators - so how and were do you find your chrysalis?  (and did I just type 100 words just to end up at the same question, said differently?)

That's just it.  There is no greener grass here.  There is no relationship between the size of your company and the ability to quickly and competently metamorphose into a pure MSP delivery shop.  The diatribe above was mostly pulled from my discussions with prospects and customers telling me why it was harder for them to make this transition.  Truth is, size just doesn't impact the formula.

What matters is organization, knowledge and understanding.  Rule #1 for building your MSP

• Know Your Windows
• Know Your Customer
• Know Your LabTech

I don't mean 'Know' in the archaic, I mean the old-fashioned 'Know', borne of gumption, ability, determination and pride.

Know your Windows.  I'd like to think this first fundamental needs no further elucidation.

Know your Customer.  This is one of your biggest competitive advantages.  This should also be your inspiration.  Ask yourself, 'What is it they ultimately want?'.  Don't think stuff like Outlook 12 and the new slate tablet thing.  Think more big picture:  they want an email front end and a portable tablet.  Then take it next level:  consider what they intend to do with that email editor and that portable tablet.  Then use your expertise to guide them to the smartest choice.  Offer them exactly what you would do, were you them.  This process may very well come back full circle to Outlook 12 and the Pro Tablet. Or it may not but that mental exercise did it's job in that it forced you to really consider your customer's needs from their shoes.

Know your LabTech.  All this means is using your knowledge of Windows and your understanding of your customer's needs to create automation that elegantly delivers exactly that.

More on this later...

Guns and Butter

'Guns and Butter is an economic term to illustrate options in resource allocation.  Do you (as a country) pour your efforts into your military?  Into your people?  Or some of one and some of the other?  If the latter, what ratios do you use?

Your MSP business faces a similar quandary, except replace Guns & Butter with RMM & PSA.  You've only limited development time and resources - where will you spend them?

Having been with LabTech for five years now, I've spoken with countless IT support companies in the process of transitioning to a Managed Service Providership.  These companies have similarly numerous philosophies on how to do it so I've seen all sides of the coin - some houses only want RMM, others treat it as a necessary evil and focus all available efforts on the PSA.

(Warning: potential RMM bias alert!) It seems to me your RMM is the meat and potatoes of your MSP business and everything else is... well, everything else.  While not optimal, I'm sure I can provide (much!) more value to my customers being RMM heavy as opposed to being PSA heavy.  Sure I may be losing a few bucks in inefficiencies but then again, maybe I'm not if you consider the savings of NOT building that tracking.

No, of course I'm not advocating you just let rip and 'see what happens'.  That's a poor business model no matter how capable you are.  Conversely so is micro-managing.  What do I mean by that?  Let me give you some example questions I've heard to demonstrate:

How do I make LabTech add time for every automatic remediation it performs?  How do I track this?
How do I detect a new workstation or computer has come into the environment and pro-rate the introduction date against the monthly rate?

The problem with this strategy is that this is yesterday's business model - and the world is changing.  The above questions assume we're trading time for money but the philosophy behind MSP is exactly opposite.  We need to deliver a more 21st century business model.  Something a little more...  Netflix(ish).  Their model: give us a buck a month and have all ya want for that month.  'Ya ate a ton?  Great!  Ya ate nothing?  Great!'  Either way, the next question is: 'Would you like another month of service?'  Now, instead of bean counting they can focus their efforts almost exclusively to service delivery (and new subscriber acquisitions.)  Not a bad business model, eh?

If you focus your efforts almost exclusively on your customer's environment, you'll soon be stunned how little effort is required to maintain it.  First you'll need to learn how to script - in Windows and in LabTech.  Learn application packaging and automate both deployment and onboarding events.  Learn policy management and apply it using both Active Directory and LabTech (bonus points for using LabTech to automate Active Directory GPO's)  Do these things and you'll find no matter what your customer comes up with, not only can you do it - you can automate it.  This is the core of profitability for a Managed Service Provider.

Of course you'll want to do some risk mitigation (e.g. structure it so if LabTech agents are removed, ALL your automation ceases operation within the environment.)  Now, bill like the insurance companies do: based upon risk.  Does your customer insist everyone needs to be a local administrators?  That should cost more than a more regulated environment.  Are you enabled to automatically push anti-virus to any computer without it?  If so, that should ease the cost of providing MSP services as there a little less risk.

There are other considerations to this tactic.  Next, we'll talk about hiring 300 and the inherently disruptive nature of this business model (and the natural implications of such.)  Stay tuned!

This Powershell thing is kinda useful

A LabTech user says 'Rob, I need to create a search for all Windows Servers that have the Windows
Server Backup feature installed.  How do I do this?'

Well, this is a bit of a problem as the LabTech agent doesn't pull Server Feature metrics.  So we'll need to rely on another metric such as an Extra Data Field (XDF).  The trick is to tie the feature installed/not installed to the XDF.  That way we can provide a search for that (or any other) Windows Server feature.  For this we need a script.

Before we whip out our script editors, we ought to first determine exactly how we plan to pull that metric.  Best case is that we can query the registry for a yes/no.  Unfortunately, if that registry key exists, I couldn't find it.

So we're stuck w/ a WMI call.  Bah, what a hassle!  This requires us to create a .VBS script that queries the namespace, add some logic to iterate thru the MOF and then pull the needed metrics.  Whoops, don't forget the error-handling!

There's got to be a better way.  And sure enough, there is: Microsoft's PowerShell.  We can query WMI thru the PowerShell.  Even better yet, we can actually structure our query to one line.  Like this:

get-wmiObject win32_serverFeature | select ID | where {$_.id -eq "39"}

To paraphrase, this query is looking for an ID where the ID = 39.  Now, check this link.  You'll find a list of all the Win32 Server Features in WMI.  If you go thru the list, you'll see that 39 is just what we're looking for:  'Windows Server Backup Feature'.  If the target computer does have the Backup Features installed, then the query will include an ID of 39.  Of which, of course, the ID will necessarily = 39.  Simple, eh?

So to get a LabTech to offer a Server Feature search, we just need to flip an XDF based upon the output of this script.  In my environment, I created an un-editable, computer-object checkbox XDF and assigned a script to my Windows Servers that:

PowerShell Command (yep, the very same one listed above)
If %powershellresult% contains 39 then :CheckTheBackupCheckbox
If %powershellresult% not contains 39 then :UnCheckTheBackupCheckbox

Take a minute to go thru that Microsoft reference page.  Do you see any Feature types you'd like to have a LabTech search for?

Finally, you may want to create more scripts like this.  What's the best way to test?  Open a target server, open the CMD Prompt tab and send powershell commands right thru LabTech.  Just be sure to preface the command with the tilde (~) and LabTech will display the output.  Pretty cool, huh?

"It can't be done" (Part II)

As soon as one asshole shows up to say 'it can't be done', some other asshole shows up and does just that.

"It can't be done"

Next time you hear 'it can't be done', consider this guy and remember: there is a virtue to having a can-do attitude!

Other LabTech Webs

Here's a few more resources for those of you looking for more LabTech content and contacts.  HatTip to Samy of Stack Advisors for these links. (thanks Samy!)

GitHub - https://github.com/ManagedITStack

Subreddit - http://www.reddit.com/r/managedit/

IRC - http://webchat.freenode.net/?channels=%23%23labtech&uio=d4 (##labtech on the freenode IRC network)