8 Common Mistakes When Launching an Intranet

While it is common knowledge that building an active website is a difficult task, intranets are often assumed to be easier. Nothing further from the truth. An intranet requires a lot of planning and effort. Otherwise, it will most likely become a deserted place with outdated content which no one ever visits. Below are the few most common mistakes made when building intranets.

1. Thinking from the management point of view

Quite often intranets are started as a management decision. The leadership team realizes that it needs the means to communicate to employees and the intranet is the obvious choice. The intranet is created - and the management communicates… but no one reads.

To get employees engaged, communication has to important for them. Just like the content on a sales website has to be directed to the needs and requirements of the clients, the intranet has to be created with the employee in the center. Only when employees decide to use the intranet regularly for their own reasons, will the management be able to reach them there with its messages.

Of course, it is a good idea to have an email mechanism sending updates about new content to employees to make sure they do not miss important updates, but if they do not feel the communication is relevant for them, they will ignore it altogether anyway.

2. Launching an intranet as a single event

When you create a blog, it is a great idea to have prepared at least 10-20 blog posts beforehand so that it is certain that you will have things to publish the first few weeks. The same applies to an intranet. It makes sense to plan the first few months of the life of the new platform beforehand, to be sure it will remain active. 

If, after the initial launch, the “Welcome to the new intranet” message remains the first one there, everyone will forget about the intranet quickly. To keep people engaged and excited and pull them into a habit of visiting the intranet, the first few weeks will be really crucial and should have a lot of content published.

Maintaining an intranet is a process, not an event. A plan has to be prepared for how it will be run continuously.

3. Starting too big

It is easy to envision a great portal with lots of content and features - a separate section for news from each department etc. The reality, however, is mostly such, that it is really difficult to keep up with a large plan (unless you have a big dedicated full-time team of course).

A much better approach is to start small and grow. Start with just one news board and a few most useful integrations which solve actual pain points of the employees. When this works and there is appetite and room for more, additional things can be slowly added one by one. 

Such iterative approach will have 2 benefits:

1. You will not overshoot with ambitions which cannot be delivered.
2. The intranet will grow. People will see new features as progress.

Plan big - act small.

4. Overcomplicating the technology

An intranet, as it grows, can grow a lot. Being in the center of the company, it often gets integrated with many systems. Everything that does not have a place of its own is often just added to the intranet: carpooling, room reservations, cafeteria vouchers, you-name-it.

On the one hand, this is good. An intranet which has a lot of features which are needed and used is what one wants to build. On the other hand, once it is integrated with “everything” it is quite often difficult to alter it or replace it. Furthermore, replacing other systems gets tricky as the new ones have to be integrated into the intranet from the start. The complexity can quickly grow out of proportion and strangle any flexibility.

Good architectural design is key to sort out this problem. The current technology allows us to build great, decoupled solutions which can be easily replaced one by one rather than all together. To achieve this the following principles should be adhered to:

1. Communicate systems via APIs rather than directly. It is much easier to replace or alter an API then a monolithic architecture which assumes particular data structures in an external database.
2. Decouple functionalities. If you have to display KPIs from an external system it often makes more sense to create an embeddable javascript app which queries the rest application rather than bake the solution into the intranet core. 

5. Assuming employees will visit for content

As an intranet creator and maintainer, one will expect that all eyes will be fixed on new updates and content. That is however not the default case. Typically, with their daily tasks, employees do not have time nor interest to regularly check the intranet website to see what’s new.

The best way to get the staff to visit the intranet is to place on it tools which help them work (eg. documentation) or things that they need (time tracker or a feed of KPIs etc). They will visit to get access to the tools and will see the updates at the same time. 

Think of it this way - you would love to be able to place something on your website that would make your customers visit it every day. In the case of your employees, you can do that. And if it is something that helps them work better at the same time - it’s a win-win situation.

6. Lack of good search

Employees will remember what they read on the intranet and may want to return to it sometimes even after a few months or years. Google will not be able to index this content, so the only thing you can offer is a good search you create yourself.

People are used to really good search functionality and if a service is lacking it, it is really frustrating for everyone. 

7. Lack of training for new employees

An intranet in an organization will grow and evolve. If you do not show new employees how it works and what can be found there, it might take them a long time to understand just how many things are there available for them.

An overview of the intranet should be part of the induction process of each new employee. It will save them and their superior a lot of time.

8. Lack of post-launch analysis

Often an intranet will be launched and then everyone will go back to business as usual without any further analysis. However, if you do not watch the employees interact with the intranet and see how they use it, if you do not send post-launch feedback forms, you will never learn about the many things that could be improved or added to make the intranet much better.

Building an intranet should be an iterative process. Build - try - test - repeat. Only this way, you will be able to build something really valuable to the whole company.