Five Reasons Why IT Doesn’t Want to Support Your Next Martech Purchase

Making requests in a corporate environment is a delicate dance of data and psychoanalysis. You need to be able to prove your case, and you need to understand exactly who you’re talking to and what they need.

In some corporate dynamics, the system is weighted towards turning away your requests rather than granting them. There are a lot of reasons why this can be true, but we want to specifically look at the dynamic between the Marketing Team and IT.

We see five main reasons why IT doesn’t want to support your next Martech purchase.

1. Your Requested Tech Doesn’t Match the Company’s Stack

With a lot of software as a service (SaaS) companies out there nowadays, this is becoming less of a problem. It can be tricky if the organization needs to self-host or has other privacy/security concerns. Where we deal with it most often is when creating a custom solution that needs to fit alongside the other systems a company is running. Specifically, think about a value-add layer of software to the medical device that your company is selling. Or, you could be adding an additional piece of interaction to your website to serve a very particular customer need. 

This process can be a non-starter if you have something that just completely will not fit. Ideally, your vendor should be able to provide a solution that will work, but be sure to check before you get too invested. Without upfront evaluation, this can lead to unpleasant surprises down the road.

2. IT Doesn’t Want to Be Stuck Holding the Bag

And who can blame them? 

If Marcom buys a new solution that breaks a year later, it’s now IT’s problem to clean up. Hopefully, your vendor created strong enough documentation to guide IT to the right spot, but there’s no guarantee that will be enough.

The ideal solution would seem to be training new people on the project. However, getting new people up to speed on a system that they didn’t build tends not to be viable. It’s common for decisions to be made along the way that are difficult to pass from team to team, because they require context that is no longer available to them. 

We recommend clients consider a budget for maintenance and improvements any time they consider custom software. Not only do you want to keep the program running the way it should, but you’ll often think of new pieces you can add on to what’s started.

3. IT Already Has a Solution or People Who Can Create a Solution

Here’s an interesting one.

It’s certainly a fair argument, and this is where you should learn a lot about your IT team’s capabilities before looking for something else that can plug in. You want IT on your side, and understanding the team’s strengths and weaknesses will help you in making the right kinds of requests. 

The delicate part of this conversation comes in when your team offers a solution that isn’t as robust as you need it to be. You may be able to either get custom development work done from an external vendor to supplement what your IT team offers. In other cases, you will have a direct clash where other systems would need to replace what your IT team has built. You’ll definitely need as much data as possible to demonstrate why you need to move away from the systems that the company has either invested in or built. It’s difficult to be patient enough, but you may find benefit in utilizing the available system as far as you can. Then you demonstrate where else your team could benefit from a different solution.

It’s much stronger positioning to ask for a new solution after you have outgrown what your company offers, rather than trying to bypass it entirely.

4. Budget: It’s Cheaper to Go Internal

Again, another fair argument.

If another department already has software that looks a lot like what you’re hoping to get, you probably can reuse that software in your division. Be open to considering what your company has. It may not be exactly what you’re hoping for, but it’s going to be a heck of a lot faster to start there than it is to wait for the one you want.

Similar to the last point, see if you can outgrow the solution or prove why your case is different enough to warrant new software if you’re still feeling constrained.

5. Power Struggle: IT Doesn’t Want Anyone Else in the Sandbox

Ooh, yeah, this one isn’t fun.

This reason is unpleasant to talk about, but it is something that definitely happens.

Whenever possible, you always want to look for that diplomatic solution that’s going to allow you to understand someone else’s concerns and see what you can do to assuage them. 

You can ask questions like the following: 

• Is this a matter of security? 
• Can you set up an environment that allows for a developer to not mess anything up for other people?
• Can we try a limited version of software to see how it will play alongside everything else?

There usually is a solution available if people avoid getting too aggressive and/or defensive in the process. 

If things don’t work out, this is where you have to rely on the data to make a strong case and get senior leaders involved in the discussion. It’s not fun, but this is part of it sometimes.

What Else? 

Are there other key reasons? Are there other solutions you’ve seen work better than what I’ve suggested? Let’s chat about it on LinkedIn. I’d love to hear your thoughts.