Skip to main content

The case against making IT the sole owner of your intranet

network
(Image credit: Image source: Shutterstock/Toria)

Before the recent advent of “off the shelf” intranet products, companies built their own systems. They would start with a platform technology (such as SharePoint), and the IT team would spend a year or more building a custom intranet on top of it. Given the undoubtedly technical nature of the work, it only made sense to put the IT department at the center of this task. But that same focus on IT also explains why the vast majority of intranets — 90 percent, according to my company’s research with Gartner — actually fail to meet their initial objectives.

Intranets might be technical products first and foremost, but they are also social instruments at their core. They exist to facilitate the free flow of information and ideas between an organization’s collaborators. Unfortunately, IT developers are rarely user interface or employee engagement experts. Sure — the intranets they create are certainly functional. But from the user’s perspective, they’re far from ideal: They’re either too sparse on information to be helpful or too complex to even be accessible.

That means the same team tasked with building the intranet — the IT department — also tends to be its biggest obstacle.

What happens when IT and the intranet work in opposition?

Companies continue to build their own intranets despite the many issues outlined above. Why? To put it simply, many companies underestimate the burden this approach places on the IT team — not to mention the organization as a whole.

In addition to building out the intranet’s infrastructure, IT is also responsible for its ongoing maintenance. Some outsource that duty to the internal communications team, which leaves nontech professionals in charge of a complicated piece of software. Other IT teams handle the maintenance themselves. However, that distracts them from core duties and results in an intranet that works fine for IT but fails to truly meet the needs of other departments.

Because intranets thrive or die based on user input, these systems must make participation a painless process for everyone. Despite this, intranets developed by IT departments often put up roadblocks in the form of text-heavy interfaces and needlessly complex folder taxonomies. They make it hard to search, difficult to publish, and impossible for anyone — except the IT department — to administer. In practice, these IT-built intranets work in direct opposition to their intended purpose, further stifling the flow of information across an organization, keeping workers across departments siloed, and making its intranet much more likely to fail.

Of course, this has broad consequences for any company. Building an imperfect intranet hogs precious tech resources, both during development and through any ongoing maintenance. And with the average intranet taking an average of 1.2 years simply to deploy, according to Nielsen Norman Group research, the risk of wasted resources (not to mention overall failure) increases by the day.

It also takes up users’ time and creates unnecessary confusion and communication lapses, making them reluctant to log into the intranet in the first place. Perhaps worst of all, an intranet rife with bad information (whether it’s outdated, incorrect, or lacking context) is less than ideal for decision-making and can lead to disastrous results.

These are all considerations to keep in mind when deciding how to implement an intranet and who to involve besides just the IT team.

How organizations can collaborate to create a successful intranet

Let’s go back to the basics for a minute and put this argument in context. An intranet has two core purposes:

  • Connect employees across distributed teams and locations
  • Organize critical knowledge so that employees can stay in the know and productive

By definition, the intranet is a cross-departmental tool with myriad intended and accidental applications. Putting one department (in this case, IT) in charge of the entire ship makes little logical sense.

Instead of this, IT should drive the technical parts of the project in collaboration with stakeholders from throughout the entire organization. Best practices dictate letting business owners maintain their domains directly with an intranet administrator (and this person is usually within the internal communications department). IT can be pulled in for any specific troubleshooting, but it plays a hands-off role otherwise. The users are at the center of the experience, and the ideal stakeholders can continuously stock the intranet with highly relevant and up-to-date information.

In short, the best thing IT can do is enable its users to update, maintain, and administer the intranet without having to handhold, implement additional staffers, or overcome cumbersome technical hurdles. That means implementing federated administration capabilities that address access controls and usage rights across the entire organization. (For example, an HR team should be able to update its intranet domain content without needing assistance or authorization from IT.)

Removing the technical gatekeeper that is the IT team liberates the intranet to evolve organically. It also makes the platform more likely to thrive over the long term by promoting its single most important predictor of success: executive engagement.

Unsurprisingly, intranets fail when leadership can’t see their value. Putting managers and department heads in charge of their own domains makes them powerful advocates for the system, and they can curate the content to be relevant for executives and employees alike.

Some additional help might be required in the form of content contributors, information administrators, and engagement evangelists, but those roles can be sourced to the internal communications team. With the right technology and the right approach to oversight, intranets can live up to their greatest potential and achieve their goals.

The first step towards this end is rejecting the legacy thinking that IT must build and run custom intranet software alone. There is too much evidence against that IT-centric approach — and too much in favor of putting users in control of their own intranet. The modern workforce is one that knows how to make use of cross-functional teams and collaborate outside of their departmental spheres. Why shouldn’t the intranet be a cross-functional effort as well? If your own company’s intranet depends heavily on resident technologists (or is lagging in some way), now could be the perfect time to reevaluate its workflows.

Dhiraj Sharma, founder and CEO, Simpplr