How over-centralisation kills a large intranet

Interesting discussion this week that had me thinking about the best way to manage an intranet (or more accurately, a large collection of intranets) within a huge organisation. The person on the other end of the phone line was questioning an organisation-wide site, on the grounds that no-one had asked for the central team’s permission / forgiveness during design and development (said team has not updated their “standard” design since 2002, but we’ll overlook that for the sake of the argument and pretend they’re up to date)

Some context: in the last 18 months the following was introduced to this particular intranet:

  1. A visual approach to process
  2. A clean, intuitive design with lots of whitespace
  3. Web standards
  4. Semantic coding
  5. Table-free, CSS-based layout
  6. Browser compatibility (Firefox & Opera, the excitement!)
  7. Accessibility

These elements did not exist previously and only 3-4 have been added in the 18 months since. So what’s the response from the “official”, central team? Incorporate the ideas to raise the overall online standards, or ignore and try to assert centralised control of everything? Sadly, the answer is the latter, and it’s common to most intranets I’ve seen.

People in the central team assume that central control of design and coding (with their best friend the Content Management System) leads to best practice where a tight set of rules and guidelines (cue repeated use of the words “police” and “govern” by my contact this week) keep subject matter experts in their place, and stop any attempt at design or coding from those hobbyists who really should be better sticking to MySpace.

But this is the wrong approach in every way, and for two main reasons:

1. It’s not possible

Even with a CMS in place, there are always too many other options and places for people to create and store content. This might be a techie department with their own servers under the desk, external online options (and thus security risks) or other mediums such as the LAN. Not only does this mean a loss of control for the central team, it also means the audience is going elsewhere – making the central intranet redundant.

A typical organisation might have hundreds of intranets and applications: just keeping track of them is likely to be exhausting, let alone an attempt at control.

2. It lowers standards

Strange though it might seem, locking down to a standard straightjacket for design and coding will in fact stifle creativity and good ideas. Had the intranet in question been locked down, the ideas listed in the context above might never have been visible, or added much later. Likewise, creative ways of doing process (Collaboration, social networks, tagging) would have to go through a labryinth and bottleneck to get anywhere – with the ideas people out in the field soon giving up.

The situation in (1) above adds to this: staff that DO manage to create new and interesting sites will exclude you from them, isolating the best ideas from those that should be the biggest drivers.

How I learnt to stop worrying and love the federated intranet

Like a good country of diverse provinces, federalism is always a smarter way to go than trying to shoehorn diverse cultures into a monocultural straightjacket. Some ideas below:

  1. Let go. Accept that the overall result will never be perfect, that some areas will always be playing catch-up and that the design will be out of date the moment the pixels hit the user’s screen. As long as the site meets the user’s needs, they’ll stick with you through the journey.
  2. Create a framework. Standards should still exist and be created: just think of them as guidelines rather than rules. Understood and communicated, a usable design or efficient coding is rarely going to be rejected by your stakeholders.
  3. Support and engage. Get out there and see what the other intranet owners are doing: chances are there’s ideas that can help you and vice versa. This also brings you a step closer to the users lower down, which may explain some of those “odd” decisions the owners have been making.
  4. Learn. No central team knows everything: new technologies are always popping up and a diverse community is likely to be across them. Keep the final say where you need to, but try and let most decisions be by consensus, not diktat.

Leave a Reply

Your email address will not be published. Required fields are marked *