Imagine: the current intranet is in need of replacement. You’ve been asked to set up a new intranet, but what do you need to consider before starting? Which of your colleagues can help you? How do you get ideas on paper, and how do you select a supplier? This article covers all these questions.
A traditional intranet is organised from the top down; traffic is all one-way. For example, a traditional intranet contains employee profiles, workflows, news about the organisation, and other static content managed by a select number of editors.
A social intranet includes all the above information, but adds an additional social component. For example, if the traditional intranet includes news about the organisation, the social intranet can supplement this by giving employees the chance to respond to news releases and even publish their own news.
Moreover, if the traditional intranet includes employee profiles, the social intranet can add an extra dimension by allowing employees to edit and extend their profiles with information about aspects such as their expertise, skills and finished projects. With a social intranet, employees can also work together in teams.
A social intranet can help transfer responsibility for information to those in lower levels of the organisation’s hierarchy. Employees themselves become responsible for obtaining and publishing information, which is a way of placing more trust in them and giving them more responsibility.
A number of studies have shown that a social intranet can:
Social components make mass interaction across all layers of the organisation possible. People who don’t know each other are connected by topics, questions or interests. We use these connections to collaborate on solving issues and achieving ambitions: that is social business.
Imagine that the moment has arrived, and you are looking at a new social intranet. Your next task is to convince the rest of the organisation. Where do you start? First of all, it’s important to write a good business case.
It might be obvious, but it has to be repeated: you won’t get far without a business case, and it’s not enough to simply say 'we want to share knowledge' or 'we want to improve collaboration'. When writing a good business case, don’t settle for quick solutions, and look beyond the first answer you get. A successful intranet contributes to an organisation’s goals, and these goals are therefore the point of departure when writing a business case for the social intranet. To find out what these are, keep asking why. See how you can contribute to these organisational goals by implementing and using a social intranet. Ask your client about his or her dreams, and which ambitions are doable.
Clarifying goals will facilitate your project. It will give you a better picture, for example, of an organisation’s priorities. More importantly, it will help your project run more smoothly, and get management involved during implementation. You will be solving real problems, and helping fulfil the ambitions of organisations.
Management must fulfil an exemplary role in decision-making and obtaining support. It’s never too early to generate such support for the project. In addition, make it clear to management what you expect from them. A message along the lines of 'If you want your people to change, you'll have to change yourself first' helps.
You can make specific agreements with the management; this could include management responding to questions daily, communicating less by email, or writing a weekly blog in the form of a 'Look at the week'.
Implementing a social intranet requires a lot of expertise and input from different departments. Set up the project group, but don’t make the common mistake of limiting yourself to departments such as Communication, HR and IT. Take a look at the roles occupied by people outside the hierarchical organisational structure. Who are the most influential people? Who are the early adopters?
It’s something we all recognise; project members who have to go home earlier, project members who can’t free up time because of their 'real work', and team leaders with no time for project members because of sick leave or pressure in the department. All this puts your project at risk. To be a real team, you have to demand 100% commitment over a relatively short time.
How are you going to roll out the new intranet in your organisation? A big-bang event, or a small start with a limited group? Do you want everything in place before the launch, or are you going to introduce elements step by step? The roll-out strategy largely defines the length of your project and the time employees have to wait to see the new intranet for the first time. We are firm believers in small projects and taking small, regular steps forward.
Suppliers possess lots of knowledge and experience, but the trick is to be able to use it. We’ve seen that collaboration in this area can be erratic. This is frequently due to traditional ‘us & them’ ideas about customers and suppliers, or the way procurement or purchasing rules are interpreted. However, this is unnecessary. As long as you are transparent in what you request from different parties, you can achieve benefits in terms of your project and selection of supplier.
One disadvantage of only getting suppliers involved in your project at a late stage is that you sometimes have no idea about what can be achieved using a standard solution. We regularly encounter problems in the phasing of projects because the standard solution can do more than that described in procurement specifications.
In your selection process, you can distinguish between a Request for Information (RFI) and the actual selection based on a Schedule of Requirements (SoR). Limiting yourself to a Schedule of Requirements can result in the context being unclear for the supplier. We also tend to answer all questions with a simple 'yes', if that seems necessary commercially.
We have noticed an increasing dependence on the opinions of end users when making the actual selection of a social intranet. This is often the result of the selection being based on a Program of Requirements and a Proof of Concept (PoC). A PoC is a supplier’s pilot software environment, which is used to demonstrate the performance of his product. The SoR covers the main specifications, while a PoC deals with the features offered.
End users can use the PoC and a number of specific assignments to test the various software packages, and determine their preferences. Some examples of assignments: ‘Create a team for an innovation group, and invite people’, ‘Extend your profile with your areas of knowledge’, or ‘Post a photo or video, and ask people to comment.'