How To Stop Your WordPress Intranet Becoming An Unmanageable Mess

How To Stop Your WordPress Intranet Becoming An Unmanageable Mess

Given its popularity, it’s only natural that organizations should look to WordPress as a potential intranet solution.

It’s far too easy, however, to get carried away and load up a site with every plugin imaginable and end up with an unmanageable mess.

So how you can avoid disaster and ensure that your WordPress intranet is fit for purpose, is solving your organization’s problems and is not going to have co-workers muttering about you over the water cooler?

Promo image
Avoid the urge to install every plugin imaginable and keep it simple

Intranets Are Different

Intranets are curious beasts and building one requires a very different approach to that used to build a public site.

The good news is that both the owner and the audience are clearly defined and easily accessible. The bad news is that both the owner and the audience are clearly defined and easily accessible.

Everything you do as the “intranet builder” will be done in front of a good many more people than when building a public site (whose audience you rarely, if ever meet), especially if you work in the organization concerned. Whilst triumphs will largely go unnoticed – such is life in web projects – mistakes will be on view to a large audience who potentially all have access to you. There will be nowhere to hide.

Of course, it’s not all bad news. You are also dealing with a controlled environment where there should be no surprises and that you may be able to influence. For example, you’ll have a pretty good idea of the operating system and browser that visitors will be using to access the site and may well not have to worry about supporting a wide-range of different set-ups.

(Although perhaps if the organization in question is still using IE7 or worse, IE6, you might want to reconsider!)

A clearly defined audience means that it’s relatively easy to get wants and needs but also means that it’s also easy to get swamped with requirements as every employee produces a list of every feature and function they’ve ever needed resulting in the dreaded and potentially debilitating Scope Creep.

The major driver for this creep is that intranet development is generally underpinned by an inclusive approach. In theory, such an approach makes sense – you have a defined and accessible audience so why not go straight to the source and find out what people want?

The issue is that you will be the only person on the project thinking about that organization as a whole: everyone else will be thinking about themselves first and foremost – what do I want the intranet to do? – and perhaps their immediate team or department. But certainly not the whole organization and why would someone in Accounts care about the Sales team being able to share product specs?

A key component of building an intranet is being a feature wrangler. Not an easy job as there’ll be plenty of them and saying “no” to people that you may deal with on a regular basis is difficult. Might as well realize now that you cannot and will not please everyone.

A final difference, and perhaps the most significant, is that intranets are much harder to place a value on (and consequently calculate a return-on-investment) than public sites. Intranets are nebulous by nature (the term doesn’t really mean anything other than an internal website) and unlike their public-facing cousins don’t always have a clearly defined business purpose with goals and plenty of analytics to check that the site is delivering.

Things To Consider

When it comes to designing your intranet solution, there are a number of considerations.

Difficulty increases exponentially with number of plugins

If you’ve already built a few WordPress sites then you’ll be (perhaps painfully) aware of the pitfalls of loading up your installation with a million-and-one plugins:

  • Every plugin has some management overhead, so more plugins means more overhead
  • Greater chance of plugin conflict, more plugins means more code and the chance that naming conflicts or simply functional conflicts (one function undoes the work of another) will arise
  • More interfaces to integrate and make consistent, this is perhaps the biggest issue when building a site, that each plugin that creates output will need to be integrated to a common look and feel
  • More back-end entry data screens, each with its own particular nuances and behavior when it comes to the user interface

The aim, therefore, is to have as few plugins as possible and for those plugins that you do use to be well-coded with a good track record for support and updates.

Front-end v Back-end Content Creation

The more users you can involve in creating content the more successful the intranet will be. As well as going a long way to ensuring that the intranet contains a constant flow of new and updated content, a large cohort of users spreads feelings of ownership.

How content is created is, therefore, a key consideration. Do you allow users access to the admin interface? What level of access do you give them? Or do you avoid the admin interface altogether and keep content creation only in the familiar front-end (perhaps using Gravity Forms)?

You’ll need to think about the users, the likely content creators and how important it is to distribute the content creation process (hint: very important).

Single Install v Multisite

Even the smallest organizations will likely have multiple projects on the go, whilst larger organizations throw teams and departments into the mix.

A key initial consideration is whether to have a single installation or whether to go down the multisite path and allow individual teams and projects to have their own subsite.

Be very careful. It’s easy to get carried away and go for multisite but, as with plugins, every site is adding to the maintenance overhead. Think very hard about the implications of multisite and whether there are the time and resources to manage a network. If there isn’t, then don’t suggest it!

That said, there are clear-cut scenarios where multisite works well. Keeping in mind that single sign-on is an absolute given, then an intranet that consists of a blog, a knowledge-base and a shared calendar is likely to be better delivered as a multisite with each function operating in its own domain (and the main site acting as an aggregator) where it can run with its own theme, rather than trying to shoehorn all the functionality into the one site.

Internal v External Hosting

This is usually quite a vexed question. Likely, you will be the most ambivalent about whether the intranet is hosted internally or externally (you might actually have a preference for external simply because it might mean you can get something set up with a lot less hassle and lot quicker than waiting on an internal IT department) as your stakeholders grapple with fears about security conflicting with the desire to make the intranet readily available to those out-of-the-office.

Your role here is to advise. List the pros and cons of each approach and highlight any requirements that might be compromised or require tweaking by either approach.

Never play down the security aspect. It’s always better to assume that a breach of an externally hosted site will occur and therefore plan the content it will contain accordingly.

WordPress Is A CMS Optimized For Blogging

It’s disingenuous to call WordPress a blogging tool given its full-featured code base and extraordinary extensibility but it is a content management system that is optimized on a blogging content model and trying to implement anything other than a blog does attract a higher degree of difficulty.

When considering requirements it will always pay-off in the long-run to go for the solution whose content model is closer to the blogging model. For example, the best knowledge-base solutions (and there are some exceptional ones out there for WordPress) leverage the blog content model of post, category and tag and provide a far better experience than the wiki plugins.

WordPress Only Or Best Of Breed?

Which brings us to the other big question: should you base your solution entirely on WordPress or should you use best of breed applications and implement single sign-on across them (either via a bridge or perhaps LDAP given this is an internal application)?

If you need to provide a wiki, it would be hard to justify using a wiki plugin for WordPress over a purpose-built wiki application such as MediaWiki.

Clearly, though, increasing the number of applications, just like increasing the number of plugins, adds additional overload to the management of the solution, perhaps even more so given that this means another application to master.

Using just one application, WordPress, is clearly preferable and so the best course of action will ultimately be to suggest solutions that you know are appropriate for WordPress by paring back the requirement to its basic need. A wiki, for example, is not a requirement it is a solution: the requirement is for knowledge sharing and that could be achieved via any one of a number of WordPress-friendly knowledge-base or question and answers plugins.

Building A Solution

Collect Problems Not Requirements

When defining the solution’s needs, then, don’t gather requirements gather problems and issues.

If you gather requirements, you’ll find that you’ll end up with a list as long as your arm containing every feature and function that someone has ever felt they had the need for.

Problems and issues are harder to articulate and so what you’ll find that people are really motivated by the biggest pain points. This will automatically filter out a lot of the nice-to-haves, the one-offs and the just plain weird leaving you with a list of bona fide problems that need solving.

That filtering in itself might be justification in itself to focus on problems but what you’ll also find is that solving problems is a lot more fulfilling for you, makes the cost of the intranet project much easier to justify and delights users far more than simply meeting a request.

Scenario-driven Development

When you’ve got your list of problems, you’ll need to a create a scenario for each one that describes the user actions in an ideal scenario. For example:

Scenario Sales.1 – Messages to field sales staff

Current: Sales Manager communicates with his field sales staff via email. Difficult to track feedback as some staff reply-all and some just reply to sender. Difficult to keep track and access previous messages. Managing email distribution list a chore given sales turnover quite high.

Desired: Field sales staff comments are available to all field sales staff to view. Previous messages can be searched. Access to messages controlled as part of employee join / leaving process.

No doubt your brain is already coming up with a solution – clearly this is a straight-forward blog – and it’s fine to document this somewhere, but there is no need to share this with the Sales Manager or a Field Service Person. All you need to agree with them is the scenario.

One option you do have is to go more detailed. The above scenario could actually be split into at least 3 smaller, more specific scenarios, depending on whether the Sales Manager (SM) or a Field Sales Person (FSP) is performing the action:

1. SM sends message to FSP
2. FSP comments on message (variation: adding photo to comment)
3. FSP searches for older message

Thinking About Project Velocity

Project velocity is an agile term but is useful for any project regardless of the project methodology.

Critical to the success of virtually any project is to get early wins. Not only does that mean that you are solving problems but you’ll also be instilling confidence in you, the project and the intranet in general.

Project velocity, then, needs to be highest at the beginning of the project and that means carefully selecting those scenarios that are either easy to solve or related or preferably both. You might grade the scenarios on degree of difficulty before you put your project plan together but making sure you can release relatively quickly after the project starts is imperative to its success.

It won’t take long before news of an update to the intranet ceases to be news and that’s when you can slow down and tackle the thornier scenarios on your list.

Giving Yourself A Shot At Success

Intranet projects can be pretty daunting for all the reasons outlined so far but mostly because you are probably sitting amongst your users and you effectively have nowhere to hide if it all goes wrong.

So, here’s some tips to help you maximize your chance of success:

Keep It Simple (Don’t Shoot Yourself In The Foot)

This is the most important tip and by some margin because too many projects fail to live up to expectations simply because those implementing it make it unnecessarily complicated.

Your job is to find the simplest solutions possible to allow for the scenarios you have documented: nothing more, nothing less.

Don’t Make Decisions Alone – Use A Working Group

In any organization, no matter what the size, you’ll get competing priorities and decisions will have to be made that will leave someone feeling hard done by.

Don’t make those decisions by yourself. Depersonalize those decisions by putting together a small working group and have them make the decision. It’s a useful tactic to put the loudest critic on the working group – it’s amazing how collegiate such people can become when given the responsibility to make decisions for the organization as a whole.

Prioritize Quick Wins

We talked about project velocity earlier and it’s a real boost to a project to be able to get an early release out there to show that it’s really happening. Not to mention you’ll be solving problems as you go.

Multiple releases covering a distinct set of scenarios will bring those quick wins and stand the project in good stead.

Be Transparent About Progress

Your first task should be to create a blog for the project and post regularly and honestly about what’s happening. If something is going to be late, or a scenario has been moved to a later release then tell people and the sooner the better.

Have A Process For Assessing Last Minute, Out-of-the-blue Scenarios

One of the great spanners in the wheels of project management are those last minute scenarios that appear unexpectedly and almost inevitably are of drop-everything-else importance.

These decisions need to referred to your working group who should use a formal change management process to assess the impacts, costs and resource requirements of accommodating the request. Many requests simply end up not making it through the process as they tend

Don’t Promise The Moon

If you are going to maintain project velocity then you have to make sure that your deliverables are realistic, so don’t raise expectations by promising too much. It’s far better to find that your release was actually much easier than you anticipated and that you are ready to go earlier than you thought than to delay because you have over-promised, especially in those early releases.

Do a good job up front and you’ll find you’ll be cut a lot more slack with any subsequent releases that overrun.

Never Underestimate Training / Support Requirements

When planning releases it’s too easy to look at the project as simply a technical one: there’s a problem, here’s a solution, next!

Every time you introduce new functionality, you are going to need to train your users and support them. Whether it’s a screencast or a full-on demonstration, you need to make provision in your plan for creating training material and providing support.

Are Turnkey Solutions A Shortcut?

Simple Intranet is an turnkey intranet solution where for $95 (10 users), $195 (100 users) or $295 (unlimited users), you can implement an intranet quickly and easily with a host of features provided by base plugin and 23 additional plugins.

The list of features is pretty impressive and the cost relatively small and if you are in the market for a WordPress intranet then you should check out the demo.

However, turnkey solutions are not a magic bullet:

  • They implement a lot of functionality in one go. This truly is a big bang approach and the training and support requirement will be an order or magnitude greater than a multiple-release strategy. If nothing else, you’ll need to learn how the various components work yourself before you can train your users.
  • They don’t solve all your problems. Turnkey solutions have to pick the problems to solve and will therefore adopt a particular view of what an intranet will look like and how it should function. The appropriateness of the solution, and therefore how successful it will be, will depend on closely the turnkey solution’s view correlates with your own.
  • Customization may break the upgrade path. If you need to customize the solution, then you run the risk of future upgrades conflicting with your customizations making upgrading difficult or perhaps even impossible.

By far the best way to implement a turnkey solution is not to customize any functionality at all – just stick to the theme and general look and feel. This maintains your upgrade path and will make managing the installation and getting support from the vendor much easier.

The risk you run in taking such an approach is that too many of the existing problems remain unsolved.

The 3 Essential Features For A Highly Effective WordPress-Powered Intranet

Having said that every intranet is unique and you need to build it to solve the set of problems that you’ll identify in the planning stage, there are 3 essential features that you can keep in the back of your mind when fleshing out a solution.

P2-powered Blog(s)

Intra-organization blogs can be a quick and easy way to boost communication for projects and teams. P2 was built by Automattic and is still the leading collaborative blogging theme and is used, among others, by WooThemes and us here at WPMU DEV.

The P2 Guide provides a good introduction to the theme as well as listing derivative themes and useful plugins.

P2 is high on simplicity and low on training requirements and is a worthy core of any WordPress-powered intranet

Theme-driven Knowledge Base

Virtually every intranet will require some form of knowledge sharing. A wiki might seem like a good option but the wiki implementations for WordPress are generally not fantastic and although MediaWiki might provide the ultimate wiki option, you should try and steer clear of the multiple application pathway.

A better solution is to look at one of the knowledge base themes which will turn a WordPress blog into a fully-fledged knowledge repository.

These are premium solutions but as is usual with WordPress, premium is hardly going to break the bank, and some of the themes are very polished.

E-Forms With Gravity Forms

No organization is complete without a plethora of forms to be filled in: leave forms, travel forms, purchase requests, etc.

Moving these forms online can be a quick win of substantial benefit and when it comes to WordPress forms, the plugin of choice is Gravity Forms.

Gravity Forms has the flexibility to build virtually any type of form, including multi-page forms, and should be able to cover almost any requirement.

The only missing feature appears to be routing – if someone knows of a routing / approval / workflow add-on for Gravity Forms then let us know in the comments.

Ultimately, Success Is Down To How Not What

If you came here looking for a sketched-out solution for an intranet then no doubt you are disappointed.

The point is, there is no single solution – an intranet has to be designed to solve the problems of a particular organisation and so there is no one size fits all.

It’s also far too easy to overcomplicate a solution by adding plugin after plugin to provide functionality and features that no-one wants or needs.

Simplicity is the key. If a P2-powered blog (or a network of P2 blogs) will solve 80% of the identified problems then don’t try to make it any more complicated than that. Get that network up and running, get those quick wins and then move onto the next set of scenarios.

Implementing WordPress, installing themes and configuring plugins is not rocket science and almost anyone can do that. In an intranet project, the value you add is in listening to your users, helping them articulate their problems and then identifying the right components to provide the simplest solution to implement, to use and to manage.

The what is certainly important. But the how is critical.