The intranet forms a social space for interaction between people. This requires rules and limits that are adapted to the special features of the medium. Firstly, top management should describe or at least legitimize the objective. This “vision of the intranet” can be used time and time again as an anchor and basis for discussion on the focus and design of the system: 

• Can everyone make an active contribution? Does freedom of expression rule in this system, or is conforming behavior desired? 
• Do we trust our employees and give them the freedom to design the system according to their own needs and those of the different projects, or is its use restricted so that the system is more suited to receiving information and less as a tool for performing daily work? 
• Is information in the company generally transparent and accessible to everyone, or do areas exist that are restricted? What is the basis for this type of restriction? 
• How important is transparency for the company?

The boundaries for shaping all of these questions are blurred. And, of course, there have to be limitations. However, a clear idea that is legitimized by the senior management is certainly helpful to an intranet. 

The role of the works council is to try and make this label and vision as open as possible and to give employees a large degree of freedom. 

In theory, your intranet team can implement all of these activities themselves without the involvement of the works council. But employee representatives can’t work all of this out on their own. Ultimately that isn’t the point, however. The basic message is that involving the works council makes systematic sense. 

In fact, I’m firmly convinced that early involvement in the project makes good sense, even when the board expressly supports the project and is at war with the works council at the same time: 

• It allows you to address and clarify any doubts early on. 
• It allows you to identify areas that cause problems and eliminate them if required. 
• It allows you to prevent bottlenecks shortly before the intranet goes live. 

Don’t end up as one of those intranet teams that have to postpone the launch by six months because the works council decides to refuse to sign the company agreement for tactical reasons! That happens a lot more than you might think, unfortunately. 

The Social Intranet as a Digital Home 

The fact that we’re sitting here talking about intranet projects is probably because you want to establish a standardized portal that glues together the information, collaboration, and cooperation at your company. A little bit like a digital home that you love to come back to and that has real value. Unfortunately, that’s not so easy to achieve.

The larger a company is, the more valuable it is to establish a home. However, the complexity increases enormously once you hit a hundred employees. If you want to bring the joys of an intranet home to an organization with 500 employees, you’ll often be faced with several locations and perhaps different cultures and languages. And if you want to achieve success in a corporation with a central information platform like this, you’ll have to gird yourself for the mammoth task ahead. 

For example, it’s much easier to set up a video conferencing solution at a company than an intranet. Does everyone want more visual communication across the locations at your company, but you still don’t have a corresponding solution in place at the moment? Great: then unpack and roll out Zoom or Google Meet and everyone will be happy. This is not a trivial undertaking either, of course, but it still involves mainly operational work not the complex combination of politics, existing technologies, and the will to change, topped off by a generous dollop of the still unknown level of motivation shown by every third employee, which is the case with an overarching intranet project.

And there are a lot more of these simpler individual tasks involved than you might think. You don’t have a group chat solution in place for real-time business communication, and everyone uses WhatsApp as shadow IT? Really easy: just find a solution, roll it out, and you’re up and running! 

But this is where the problem begins. The internal rollout of all of these special individual solutions increases the level of complexity and ambiguity. Which system should I use now and for what? And why not just continue using the tool I already have that I’ve gotten used to? Why can Microsoft Teams also do “wikis” now when the only reason we have them is for chatting and video calling? And anyway, we use Confluence from Atlassian as a wiki, don’t we? And what’s wrong with using WhatsApp? And why should I use Google Chat now, when Department XYZ already has Slack?

I could go on with these questions ad nauseam. The thing is that there are no clear-cut answers to these questions. That’s because in the market and for good reason, all of these solutions have millions of dollars’ worth of stock invested in them. You can’t simply erase their usefulness in a 30-minute conversation. 

Many intranet projects fail because the project teams don’t spend enough time worrying about the ordeal they’re facing. 

We’ve already discussed how difficult it is for employees to switch from WhatsApp to an official internal chat solution if the new software is of poorer quality or significantly limited in scope in comparison. In the end, what counts for me as an employee is that I can successfully do my work. If my child is sick and I need someone to replace me on my shift, I use the technology that allows me to organize a replacement as quickly as possible. Company policy is of little interest to me in an emergency. Only the results count. 

If you start an intranet project internally, you need to worry about other software torpedoing your new system. So which software is that? What is it good or perhaps even better at doing? Why do employees use it? What can I do to make a change? If your system comes out worse in 50% of the functional comparisons and it can’t keep up in terms of quality with the individual solutions, you should give serious thought to whether your intranet will manage to survive for very long. 

A lot can be achieved with political power. But exercising political power is an exhausting endeavor. Utility, in contrast, is elegant and effective. 

An approach that keeps all the special solutions you have in the company alive and aligns your system in a way that integrates these solutions holds much more promise. 

There will of course be exceptions. For example, WhatsApp should actually be blocked in all companies for legal reasons. It may be practical, but it won’t be so easy for your company to sign a data processing agreement (DPA) as a legal basis with Facebook as the owner of WhatsApp. But let’s leave that detail off to the side for a moment.

So, an intranet doesn’t have to map all applications as long as rudimentary integration is possible. In case of doubt, there can simply be a “no integration” policy if there are no intersections between specific systems. 

For example, for our “group chat” application, we’ve defined in-house that we can view chat histories even though chats are fleeting communication. Employees who discuss relevant information in the course of a chat should make sure to document and store them in a revision-proof manner. Chats have a short lifespan and can get lost or be deleted. This makes it easier for us to use different chat solutions in the company.

An integration can, of course, also consist of links that connect two interrelated elements housed in separate systems. We refer to this internally as a “simple connection,” because the connection has to be made manually and can also “break” if a link no longer works. 

Advantageous for your intranet is when you can connect the central portal to a super-strong application that’s indispensable for your company. (The classic: the daily lunch menu from the company canteen on the intranet.) 

This is the reason why we decided at the time to set up and develop our Atlassian Confluence-based Linchpin intranet. As I have already said, Confluence is a corporate wiki, even though its creator would rather position it as a team collaboration application today. This wiki can map two applications particularly well: documentation and reference. Whenever something from the company needs to be looked up, checked, or learned, Confluence is a market-leading solution. 

Confluence’s positioning as a knowledge management system is so strong that it can easily exist alongside Microsoft SharePoint, Office 365, and Google Workspace. The specific tasks are so close to the central applications of an intranet that it presents us with an excellent opportunity to position user scenarios sustainably, such as news announcements, event organization, documentation, and the quick communication of decisions. 

But I don’t want to turn our conversation into a promotional event for our solution. There are other intranet platforms as well that are based on Microsoft or Google, and they’re just as valid. And again, other providers are completely independent, offering seamless integration with the systems mentioned as well as others. 

At this point, I find it difficult to give you specific tips that you can apply directly to make your workday easier. Instead, here are some general recommendations: 

• Accept that establishing a central intranet for the whole workforce is a complex task that requires a lot of attention to detail and also takes a lot of time. A successful project doesn’t happen overnight, even with methodical planning.
• Say goodbye to the thought of being able to impose your will on your co-workers by exercising political power and, in case of doubt, disable any unwanted competing systems or prohibit their use. 
• Instead, come to terms with the idea that special solutions of this type will be able to live on. Their integration can actually take place systematically and automatically. That said, however, absolutely no integration or even “simple” integration of these solutions using links is conceivable or even okay. 
• Concentrate on the application instead of the large overarching solution. Try to map as many practical applications as possible with the central system – particularly, of course, those user scenarios that are close to the intranet (e.g. news announcement, documenting content, and providing references and documentation for retrieval purposes).

Link to this page: https://seibert.biz/intranetbookusagelabel