Great Intranets

by Yuval Ararat on 20/05/2011

After a day in ibf24 from ibf I was chugging along until Jonathan Phillips contacted me through Twitter. we had a nice discussion about the implementation of intranets, is the budget the main factor in determining if the project will be a success or are there more factors.

My take was that it is not just budget; although budget does set the tone and can influence the size it is still not the deciding factor. You can do amazing things on the smallest budget if you keep the focus of the goals and implement them rigorously, for example i will take WWF intranet, which is a combination of Google Apps and a CMS.

During the 24 hrs which i partaken in only a few (10) of them we were exposed to many intranets of organisations, it was like having a door open to the heart of other organisations and check to see how they are doing things. the good thing about this was you got to see some shoe string operations with amazing implementations when it comes to the adaptability of the intranet to the users and some major brands with intranets that seem to be inactive or lonely.

During our discussion Jonathan also pointed me to his blogpost describing the characteristic of a successful intranet and asked me to respond.

This is my response to Jonathan’s post.

I will start with the definition of Great, i believe it lacks the context and thus encompasses things that are cultural and things that are technological.
Important and significant is only a valid point if the intranet is doing its job in delivering the content in a manner that is useful and engaging. When this happens you get a site that is important and significant to the company, only if users use it it is important and this is a product not a goal.

This logic applies to Wonderful, First Rate, very good, remarkable and consequential, this is not something you can target when implementing a service nor when maintaining it. It could be of extraordinary powers, very admirable, unusual and considerable in degree, power, intensity. these things can be planed but usually cost much if the system we are replacing is great and likeable.

For references I will list the Characteristics Jonathan pointed
1. An open, multi-way communication vehicle: Top Down, Bottom Up, Peer-to-Peer
2. A facilitator of enterprise collaboration
3. An executor of business transactions
4. A tool that positively impacts every job in your company
5. A gateway to business knowledge
6. A digital reflection of the values of the company
7. Serves to build enterprise community
8. Transparent governance, management and strategy
9. An engaging space
10. Available where your employees need it
I agree with all of the other items, they are the corner stone of the intranet in my opinion, but the one thing i want to talk about here is how do you achieve this.

There is an illusion that all these characteristics relate to a single entity and thus translate this to a single product to solve the problem.

This is nice if you have a very limited team with a non-diverse need. If that is the case you can probably suffice with a good WordPress implementation and be done with it.

Most cases are not this easy and require a more complex environment to facilitate the users needs.

The question is of how we assemble this ménage of solutions? Do we turn to an all encompassing solution that has the potential to flop and make the whole intranet look like a joke? do we assemble it with products?
Who makes the decision of what product to implement and how do we know which one is the best for our users?
In my experience, the implementations I have found to be most successful were experiments in their youth. They were implemented from a need of a certain group and then spread to the organisation.
I also like to look at the economy of products in the organisation, much like a startup some products in the intranet get a lot of traction and some don’t. this economy environment lets you choose the solutions that match the crowd.
As oppose to core solutions that are there for a predefined business process our intranet is a service for the users in order to get the core business process done more effectively.
Since these are not mandatory system and they come to support the processes we have the privilege of experimenting and failing, the experiments should be like little staretups in the intranet, if they get to pitch and show value they stay if they don’t they go.
The merit of a solutions value should be based on the “Value to the user”/Cost if it is greater then 1 we are winning if it is smaller we are losing. in my personal opinion 1 is a great equilibrium for some applications.
The process i am suggesting is this:
1. Check to see what groups are using today and figure out if they are pleased or not. there could be some wiki’s and other tools lurking in the groups.
2. Let the groups experiment with the tools on the market and choose the ones to be tested.
3. Put analytic tools on the solutions tested to get the usage and let the users start working with the tools.
4. Check after a period of time what tools were used most.
5. Check to see how they helped and if they stand the merit of exposure to the whole intranet.
6. If they do seem like a good candidate to solve an unsolved problem in the organisation merge them into the intranet.
7. Check the value, rinse and repeat
This way like Lego blocks you will pick the matching tools for your people and not force them to use the technology that looked cool in the sales pitch.
if the tools are SaaS, like Yammer, then use them yourself and try to get people to send emails to you with the success stories from those tools.

On another note, this method holds some problems in it that will be present whenever we dont go with the single entity approach, it lacks the integration between solutions. this is the one thing that is a requirement on the developers to tailor the integration and find the solution for interoperability when there is no standard available.
This will be the biggest hurdle but it is still not as big as picking the wrong software for your users, some of the SaaS give a great solution as they integrate to the dashboard’s and websites easily.

Oh just something from the ibf24 twitter feed, intranet in 3 months is not a valid response, 3 months for the WCM might be ok but development of the product does not stop here.

Digiprove sealCopyright secured by Digiprove © 2011 Yuval Ararat

Leave a Comment

Previous post:

Next post: