The relationship between enterprise IT and service providers can be difficult. IT has frustrations in achieving optimal service levels. Service providers, as it turns out, have an equal number of bugaboos when it comes to their enterprise clients’ readiness for and acceptance of provider intervention.
We asked providers across a range of services what advice they can offer to smooth out some typical bumps in the road for their clients. Here’s a look at what they had to say.
1. Focus on the business users’ needs, not the technology.
One of the biggest mistakes that enterprise IT makes when engaging a service provider is focusing too much on finding technology to solve the problem instead of fully understanding the problem that needs to be solved.
Consider the problems that can arise if you take a “technology first” approach to data management. Stan Christiaens, CTO at service provider Collibra, which specializes in data governance, says focusing on the technology rather than the problem can create chaos, especially if different technologies are pieced together and critical information is siloed in different groups and departments within the organization. Such a hodgepodge strategy erodes user trust about the reliability of data.
“There needs to be a much greater emphasis and focus on the business users and the processes and methods they use to find the data that’s most important to them,” Christiaens says. Once you understand that, he explains, IT can help create governance rules and policies accordingly, enabling business users and data scientists to find, understand and trust the data they need to fuel critical insights.
2. Don’t get caught in the ‘expert’ trap.
Companies must be careful to choose services that work for the whole company, not just one person. Catering to power users can get you into a heap of trouble.
This is especially true when it comes to services that rely on certain skill sets. “Just because you have someone on your team who is an expert with a specific tool or programming language doesn’t mean it is what’s best for your specific enterprise system,” says Steve Logue, senior business development manager at Surety Systems, which focuses on ERP systems.
Logue gives the example of a client, a women’s apparel company, that had implemented a system primarily because it had an in-house developer who could build custom programs and outbound interfaces for the application. The developer subsequently left the company, making it difficult for the remaining users to “future-proof” the system, he says. For instance, that developer’s custom-built programs might break if users installed patches that the software vendor had intended for the off-the-shelf version of its system, Logue explains.
Companies should make sure that the services they choose will still work even if an expert user isn’t around to maintain the system. Most providers nowadays have tools that need little customization and easily adapt to updates.
3. Know the problem you need to solve.
“One of the most challenging things for solution providers is that the customer often doesn’t have a complete understanding of the problem they’re trying to solve,” says Jeremy Larkin, CTO at Imgix, a provider of real-time image processing and delivery services.
Therefore, service providers often spend a lot of time trying to understand the client’s enterprise environment when the client should have had that information ready before the engagement began.
Larkin acknowledges that “it kind of makes sense” that clients may not fully grasp their own problems, because “part of the reason they’re outsourcing in the first place is they have something they don’t know how to solve on their own.” But it nonetheless “makes things very hard on us, because it means they often can’t [provide answers] we need to structure the best solution for them,” he adds. “At the worst, it could mean they end up buying something that doesn’t actually solve their core issue.”
Carlos Meléndez, COO at Wovenware, a software development and engineering company in Puerto Rico, agrees. “By providing more information to service providers, IT teams would help bring more value to the projects and to their own organizations,” he says, adding that they could also “potentially save money.”
A good place to start is to know the requirements of the system you want to develop. Meléndez encourages IT to work with end users to make sure they capture the correct requirements.
Knowing the requirements in advance enables service providers “to efficiently develop a system that meets the company’s needs,” Meléndez says, adding that it also enables them “to bid their project fees based on the actual requirements rather than factoring in potential scenarios.”
Part of the problem, according to Meléndez, is that IT sometimes sees service provider relationships as opportunities to offload responsibility. “System development is a partnership. To get the greatest value, it shouldn’t be about transferring responsibility from the IT team to the service provider, but rather about both strategically collaborating throughout the process,” he says.
4. Be prepared to share details of your current IT infrastructure.
Clients that aren’t well acquainted with their own IT infrastructures create problems for service providers.
“One of the biggest issues we face on a consistent basis is a lack of knowledge about the current IT infrastructure,” says Emil Sayegh, CEO of Hostway, a global cloud and managed hosting provider. “So, before we can begin on transitioning to a public/private/hybrid cloud or dedicated infrastructure, it requires an assessment by one of our solution architects.”
When a service provider is forced to study a client’s architecture, timelines are delayed, requirements must be revisited, and costs start to rise.
“We run into situations where software is cobbled together running on multiple operating systems and on multiple generations of hardware — and it’s still on physical servers,” Sayegh says. “It’s much better if the customer has made some transition to virtual servers, which is a good steppingstone to the cloud.”
5. Remember: Training isn’t a one-time exercise.
When engaging service providers, IT shops have been known to budget for initial training on the application but not for ongoing instruction. That’s a big mistake, says Sarah Lahav, CEO of SysAid Technologies, a help desk and IT service management provider.
“Things will change,” she says. Additional training will be needed when new people join the IT team and new features are added to the system.
Therefore, IT’s contracts with service providers should allow for as-needed training.
6. Identify a point person to act as IT’s sole liaison with the service provider.
Service providers may have difficulty interacting with IT departments that have multiple silos, so it’s important for IT to choose someone to act as a single point of contact.
Nathan Ziege, director of application development at software development and technical services provider GlowTouch, says the client must appoint a technical liaison who can work across the entire enterprise IT team to gather specifications and resolve incidents.
For instance, if Ziege’s team is working on an API and runs into a problem downstream with a billing system, they want a champion on the client side who can bring in the person responsible for the billing system.
“Whoever represents the enterprise IT team should be someone who can reach across the various departments within IT to get all the relevant teams on board and ready to participate,” Ziege says.
7. Make sure your provider understands how you like to communicate.
Communication can be a big hurdle for service provider-enterprise IT relationships. Service providers must know at the start how the client likes to communicate, including the key systems they use.
“Working on an internal infosecurity team for a security service provider provides an interesting perspective on improving communication,” says Katie Ledoux, an information security analyst at security provider Rapid7. “For both sides, whether you’re on an internal IT team or a service provider, the first step must be setting expectations, defining goals and adapting to each other’s communication styles.”
She emphasizes that knowing the specifics of a client’s approach to communication — “when to use email, phone, ticketing systems etc. versus more casual channels like Slack or other chat platforms” — can help teams work together more effectively. “No one wants to disrupt another team’s workflow,” she says. “We know it’s not effective.”
Make sure to stipulate in your contract the communications systems essential to enterprise IT’s workflow.
8. Be as clear as possible about your expectations.
Every business relationship involves certain expectations, but IT doesn’t always make its expectations completely clear in contracts with service providers.
One detail that’s often overlooked is the metric IT will use to gauge whether its expectations have been fulfilled. “Trust can only be built and maintained on the basis of mutual clarity. Therefore, transparency of IT’s priority measurements for each service provider relationship is foundational to success,” says Michael Hubbard, global vice president of ServiceNow’s Inspire advisory program.
Enterprises must be clear from the outset which metrics, such as cost, quality, availability, value and adoption, they plan to use to judge how well the service provider met their needs.
“Service providers can optimize their delivery in many ways, but don’t make them guess on your priorities, nor on how you will measure their achievement,” Hubbard says.
He recommends an exercise where the enterprise envisions a future headline it would share in an internal memo defining the success of the engagement with the service provider. The headline would include quantifiable outcomes, such as cost savings, the project’s deadline and projected ongoing returns on investment.
Hubbard says this exercise helps everyone work toward the same goal. “Day in and day out, especially in times of crisis or tough decisions, this anchors the team,” he says. “When weighing the options of going right versus left on a topic, asking which route best supports the outcome quickly drives to a preferred direction of action.”
SysAid’s Lahav says enterprise IT should manage contracts by the “spirit of the agreement” rather than the “letter of the law.”
“Service providers rarely try to fail against contracted service levels — it’s bad business to do so,” she says. So, while some type of remedial action may be necessary to address persistent failure, she suggest that, in general, if a service provider is working hard to meet tough service-level targets, it might be better to evaluate the provider’s performance on a monthly basis, in the context of the full duration of the contract, rather than on short-term results.
9. Understand that service providers have been hired to help, not harm.
Enterprise IT teams can be wary of working with third parties, especially if it wasn’t their idea to hire a service provider. Therefore, service providers spend a lot of time — sometimes too much time — trying to convince IT that they are there to help.
“As a service provider, we get to work with many different types of technologies across multiple industries, and that gives us a unique perspective on what works and what doesn’t,” says Eric Hobbs, CEO of Technology Associates, a managed IT services and support firm. “But in many cases, this can devolve into a competition that starts from a guilty until proven innocent standpoint where we spend more time convincing internal IT teams that we do indeed know what we’re talking about and that proposed solutions deserve serious review as opposed to constant roadblocks.”
He adds that if a service provider has been engaged, it’s normally because the status quo isn’t delivering the results management wants. “Internal IT teams need to be open and willing to accept new ideas and new approaches versus seeing service providers as a threat,” he says. “I wish enterprise IT teams knew we are here to help — not to look good ourselves but to help the IT team look good.”
This story, “9 things your service provider wants you to know” was originally published by