How to sell an intranet project to your IT decision-makers

The investment of intranet software needs to tick a lot of boxes. And with any new tech, there is traditionally pushback from IT. When getting the green light from this department is notoriously challenging, how do you sell an intranet project to your IT decision-makers?

---

When the idea of investing in some intranet software is presented to an organization, there is traditionally one department that needs particular consideration. While internal comms and HR are looking at the challenges the intranet will solve, IT is more like to examine the challenges that the software will bring. This different perspective isn’t often included in preliminary plans, while an employee-focus dominates the requirement checklist.

As a result, frustration can grow between the intranet project team and IT in these early stages. Customarily, the comms team investigates some products, selects the one that they think suits their needs, then invites someone from IT in as a formality to get the green light to proceed.

Unfortunately, what often happens is the opposite. When the IT team doesn’t greenlight the project, it will be concerns over integration, security, or a technical issue. But to everyone else, it feels like an endless problem, rejecting the choice of solution to start investigating their own. These rebuffs can push the project back months.

Another common issue is IT stating that the intranet project will demand too much of the team’s time – a resource that is unavailable now or at any point in the immediate future. This technical requirement means that the project will need to be postponed.

And, when you’re leading an intranet project team and are ready to move forward, these kinds of pushbacks can feel very confusing and frustrating. It can often feel like IT is deliberately trying to block the project.  

In most organizations, IT aren’t creating a problem on purpose. They just have a different perspective on the impact of new software on the business.

You and your team may have been reviewing software demos and weighing up the pros and cons of various intranet platforms for weeks or months before approaching IT. And from their point of view, a colleague who, to their knowledge, has no definitive technical expertise has already selected some software and now expects IT to approve it without any meaningful input at all.

Why IT departments are hesitant about incoming software

Consider that IT’s role is largely about reducing risk to the business – we can see that their hesitant and tentative approach to this situation does make some sense.  

What could go wrong that might create this risk?

#1 The responsibility falls on them

Their initial reluctance could be down to the fear that they will end up being responsible for the project. At the early stages of the intranet project, this might seem an over-reaction, but it’s hard to predict what can happen over a typical two to six-month rollout. Personal situations can change quickly, and comms staff and project team members could leave the business halfway through. It’s not unrealistic that IT might then be expected to pick up ownership of it. This is an onus that most departments would struggle to find the resource for. 

#2 Integration issues with existing tech stack

Another critical function of IT is to ensure that the organization’s applications suite works well together. It’s true that IT’s approach to this can be somewhat simplistic. It’s often been assumed that buying products from the same vendor means that seamless integration is a given. This, however, has been proven wrong on countless occasions. For example, SharePoint Online/365 is better integrated with the Office suite than ever before, but, as many organizations using it will attest, it’s still a very long way from perfect. 

Selecting a platform from a vendor that IT hasn’t heard of before, increases the chances that they will object to it due to a fear that it won’t play nicely with the rest of the estate. They might also have personal or professional loyalties to certain vendors.

In my role as a software salesperson, I particularly remember a meeting with a large charity. Their project team members were excited about what Interact could provide, and the internal comms manager declared they were “vendor-neutral”. This sounded a good premise for the meeting until one of the three IT representatives pointed out that his job title was “Microsoft Applications Engineer”, a clear sign that he was definitely not vendor-neutral. By suggesting something was not a Microsoft product, the team were unwittingly threatening his job.

It’s worth noting that by the end of the meeting after he had seen Interact’s integration with SharePoint – even potentially allowing them to reach fundraising staff without an expensive SharePoint license – he became a strong supporter. However, he needed to be brought back from a very negative initial impression by ensuring he was listened to, involved, and engaged with the process.

#3 Technical support

IT also needs to factor in the technical side of the rollout.  For modern SaaS solutions like Interact, this is not a considerable amount of work. But IT doesn’t necessarily know that yet.

If the platform you’re bringing to them requires any kind of development or technical support, they are quite right to say hold back and first work out if they have the capability, tools, and resources to manage this.

#4 Multi-platform access challenges

Another major factor for modern intranets is multi-platform access – this facilitates your users to access the company intranet from anywhere. This function should be “out-of-the-box” easy, and for most businesses, implementation is straightforward.

But there are plenty of organizations that find it a problem due to environmental constraints.  Those businesses in more restrictive or security-conscious industries like finance can require some planning.  If your staff work on customer sites, it might even require some configuration to provide full functionality behind their firewalls.

Accessing the intranet through mobile devices like phones and tablets is an expected intranet feature these days but set up varies from business to business.  Does your business provide standard phones and manage the installed apps? Does your business allow “Bring Your Own Device” ? Is it a blend of the two?  

#5 The Active Directory

A final and very common concern is the state of your organization’s Active Directory, which is typically entirely managed by IT. Interact, like many platforms, can integrate with Active Directory to automate the creation, management, and deletion of user accounts. When a new employee joins, IT creates them an account in Active Directory, and Interact can hoover up that information so the changes are automatically made to the intranet.

It’s a great system that works perfectly, however, when there are pre-existing issues within the Directory, these same problems feed into the intranet directory by default. For example, if a third of your HR team have their department set as “Human Resources”, a third have it set as “HR” and the rest are using your new, rebranded “People Services” moniker… then all three of those departments will be set up in Interact. 

Likewise, if the organization has not been managing AD well – typically this means the new starter process is good, but the leaver process is terrible – you could discover that access is not being removed from people who have left the business, for example. This would clearly be something that IT would flag as “unacceptable risk”.

Situations like this are bound to cause friction. Often the intranet project team excitedly tells IT that their platform of choice imports data from Active Directory, assuming IT will be overjoyed. However, with the knowledge that the Directory isn’t managed correctly, their reaction is often subdued.

 “Yes… that’s great… in theory…” they begin, before throwing the grenade. “But, our Active Directory is really out of date and can’t be relied on at all. It’s on our project list to have a full clean-up. We know it needs sorting.  It was supposed to be done in 2019 but got postponed due to the new CRM.  Then we were going to do it in 2020, but all the remote working meant we had to postpone it again.  There’s no resource in 2021 so I think it might be 2022 before we can do this project”.

This might be an exaggeration – but only slightly. But for the IT department, shining a spotlight on what is the shortcomings of what is essentially their responsibility, can put them in a very awkward position. It creates a sense of shame or fear: not the ideal mindset for someone to be in if you want them to be part of the approval party.

How the right intranet tech can overcome the usual IT challenges

Let’s be clear: for Interact projects, most of these potential problems are not problems at all.  They are handled by the Interact project team as routine configuration tasks when onboarding every customer. IT’s involvement in the actual delivery of an Interact intranet is minimal – but your IT team doesn’t know that and so, are understandably nervous.

With all that in mind, a non-tech colleague approaching them saying “I’ve chosen this, let’s get it!” won’t go down well. It is a potential risk, possibly a threat, and probably extra work they don’t want or need. 

It’s no surprise their reactions are not what you hoped for.

So how do we solve this? How do we introduce our exciting solution to them in a way that doesn’t cause them to go into a negative mindset?

The answer is timing.  The thing that causes almost all of the above problems is speaking to IT far too late in the process.  IT needs to be involved as early as possible – ideally at the requirement gathering stage, but if not, at the stage where you first meet prospective suppliers.

Depending on your IT team, this request to engage early might not be accepted.

They may not have the time or inclination to sit in all the product demos – it is not unheard of for IT to decline invitations at this stage and request to be invited later in the process. It’s important for you to insist on their presence. Even if you have written proof that they refused to engage, you will still look foolish having to restart the selection process when they need to get involved later.

A great way to solve this problem is to ensure they get the best value for their time. Have them join the meeting after the comms team has seen the demo, then give them an extra thirty minutes with the vendors to ask their questions around integration, security, risk, and so on.  They might even see a tailored demonstration that focuses less on content management and more on the underlying technology.

By ensuring their time is respected and used on subjects they are interested in and seeking their input, and listening to their concerns, you will usually turn potential blockers into firm supporters. 

Having the support of your technical team from the very beginning is a powerful way to maximize your intranet project’s chances of moving quickly without meeting resistance.