>> continued from previous page
Do Your Cultures Match?
When we started planning this package, our bet was that softer factors such as IT culture and professionalism probably didn't matter. We've changed our mind, based on those we interviewed as well as personal pain.
It probably wouldn't bother you that guys in dark suits and white shirts fix your desktop PCs, but this isn't the corporate culture clash you should be on the lookout to avoid. For instance, does your potential service provider offer information on demand? How about when you don't demand it? Do questions or problems languish or get passed around a maze until an "expert" appears from "corporate"? Or is someone willing to take the problem in hand and shepherd it through the process to get you an answer within a reasonable amount of time?
Does the culture tend to be inclusive or exclusive? If you have a question about whether a service is under contract, do your providers read the pact with an eye to get the service in or push it out? For example, one IT manager we interviewed had a contract for desktop-hardware services with Ikon Services, Syracuse, N.Y. He had a problem with some out-of-warranty machines that were not included under the current contract inventory, and, without much of a fuss, the representative included them and made a note to add them to the next year's inventory.
An organization with a subsidiary that relied on a local "break/fix" service provider recently had a horrible experience. The service provider, totally out of the loop with what was expected at the parent organization in terms of professional network management, decided that since "nobody else relied on the server," they'd cowboy a network move with no formal change-management procedures. The resulting day and a half of downtime, with nobody at the parent organization able to look up anything on the subsidiary server, taught the company that even the IT decisions of subsidiaries can cause pain. A tough lesson to learn.
What are the Credentials of Service Staff?
We'll be the last to tell you that only certified network professionals are any good, but certification is one benchmark that tells you at least how trained the service provider's staff is. For example, of the eight sample companies we surveyed, all require various certifications, but only Computer Sciences Corp. and Hewett-Packard require certification, a bachelor's and a master's. One other indicator, of course, is the curricula vitae of key staffers: There's no third-party verification possible with these, but you can at least examine them for inconsistencies. Whatever you use as a benchmark, insist upon knowing the basic qualifications of individuals who will be servicing your organization. Nothing beats years of real-world experience.
How Consistent is the Expertise Level?
Bait and switch is one of the most aggravating practices in the service-provider industry. Providers show up to the sales meeting with their top guns but deploy a neophyte crew on your project.
The IT manager of a financial-services institution says he combats this tactic by asking to talk to "Joe Average" service person at the sales meeting. He then drills this person, not only to ensure that he or she is adequate to fill the need but also to tell if this person is actually the service provider's top gun. He says, "Normally, you can tell if someone is higher in the ranks simply by asking, 'What servers do you look after?' or 'Tell me about your typical workday.' "
How Much Travel and Associated Expenses Will be Necessary?
Folks usually talk a good game about remote support during sales meetings, but reality can be quite different. It's important to outline expectations. If Web collaboration software is used to avoid travel, so much the better: Conference calls with whiteboarding tend to be more productive, and the desktop-sharing features of collaboration software can be a huge hassle- and time-saver (see "Sharing Is Daring," February 18, 2002, for details). Of course, collaboration software can be a good thing if done right, but at some point, people need to be willing to hit the road. Outlining when this is necessary in your service contract is essential.
How Easy Will it be to "Insource" This Function?
You'll want to get to the issue of preserving the long-term flexibility to bring things back in-house or even shift to a different provider. You're not doing anyone a favor if you lock into a provider so tightly that major surgery will be necessary to extricate you from the relationship.
Just as you standardize on technology and methodology to cut costs in your IT organization, service organizations also attempt to standardize as much as possible. But their cookie-cutter approach may be really hard to back off in your environment; it's best to find out up front what types of changes the service organization is targeting for your shop. For example, if you have standardized on Oracle and have lots of in-house expertise with Oracle, it doesn't make sense for an outside service organization to start deploying Microsoft SQL server as part of a helpdesk offering.
What Third-Party Reviews Have Been Done, and What Monitoring Can You Perform?
A security provider that hasn't done a third-party security audit is somewhat suspect. Similarly, it pays to ask general service providers for their organizational credentials: Have they had a business audit done recently?
The natural follow-up on a third-party audit is for your organization to make periodic spot-checks on the performance of the service. This could be as complex as monitoring network traffic or as simple as making some monitored helpdesk calls. In either case, monitoring is a must. If you do not monitor the relationship, there is no accountability.
A security manager (we'll call him "Kojak") for a large, multinational financial services organization had several stories to relate. The company's MSP (managed-security provider) claimed it was using firewalls to protect some company Web sites the MSP was hosting, but apparently the MSP was using routers. This was discovered after a lot of money had been paid. Then the company went out of business, so there wasn't a lot of recourse.
Kojak also says he's seen an MSP misconfigure a firewall rule set and leave ftp open, in conjunction with an internal administrator leaving the ftp daemon running with full anonymous account access. The site became a warez dumping ground. "The lesson here," Kojak says, "is that you need to check up on your provider on a periodic basis." Of course, this is as true for your use of MSPs as it is for ISVs, or anyone who can intentionally or unintentionally cause your organization harm.
Are the Deliverables Realistic?
Beware of vendors who promise the world. You may discover you have bought into the minivan of service providers: It can haul furniture, carry children and drive on the highway, but it isn't good at high-speed delivery. Again, do not trust those who gloss over what could be a complex project. Experience shows that folks who identify specific deliverables (such as "build test bed for environment-specific GroupWise installation; import small portion of users to lab environment; validate migration strategy; convert small department") typically do better than those who swag it all into "migrate GroupWise environment to Exchange."
Buying into professionals who are good at what they do, and who outline possible limitations and landmines, is preferable to buying the pitch of a bubbly service provider rep who is simply eager to please.
Kojak also related, with equal parts humor and annoyance, the following: An MSP was asked to make a rule change at a given time. A remote MSP employee made the change as soon as the shift changed, not noticing the time requirement. The customer's techs spent three hours wondering why the network was down. They troubleshot, dug out all their tools, tested and eventually called the MSP. "Yeah, we made the change as requested," was the response. The moral of the story, Kojak says, is "someone sitting in a remote location who has the keys to your equipment needs to be drilled--and drilled and drilled--on process. Enthusiasm by a service provider to please can cost you big time."
Jonathan Feldman is chief technical manager of the Chatham County Government in Savannah, Ga., and a Network Computing contributing editor Send your comments on these articles to him at jf@feldman.org.