Intranet CMS compare and contrast

I’ve been reminiscing over my time working on the Justice intranet and it got me thinking about the differences between the hoops and obstacles that I used to have to put up with compared to some of the standard issue features of using WordPress as a CMS today.

It’s been with great joy that I have witnessed government departments and other bodies choosing WordPress as the CMS for their websites and intranets. I am filled with glee when they pick a supplier from the Government Cloudstore for their hosting. Why? Because I spent years working on an intranet in a very restrictive framework, backed by very expensive IT contracts. My older blog posts are filled with gripes about not being able to use PHP or a database, and tales of 60K quotes from IT suppliers to flick a switch on our Google Search Appliance to allow it talk to another internal database.

Happily, I’m in a different world now, where people have more sense than money. This blog post is not a plug for WordPress, but rather a stroll down Memory Lane with a *compare and contrast* of how things used to (still do?) work at MoJ using a combination of manual Dreamweaver publishing and RedDot CMS, with the intranets that I am developing now. Aside from the main benefits of an open source CMS, here are some of the time-saving, money-saving differences that stick out for me…

New stories

BEFORE: We managed our news stories separately from the *static* intranet page content, in a clunky Red Dot CMS, which, like most things back then, pushed the developers to their limits in terms of dealing with the limited technology. We managed to build a system to allow editors to add news stories with featured images, thumbnails and galleries, featured on the homepage, with monthly archives.

We’d often source photos from press office shots from a flip camera or from various campaign graphics that had been developed in-house. Intranet editors would then have to prepare photos and images using a graphics package (Fireworks, which I still love), creating different sizes for use across the intranet as a feature photo or thumbnail, and getting the file format correct and the exact dimensions as required for each of the different image placements. The intranet was designed before *responsive* and *mobile first* were around, and also for a pretty standard desktop viewport across the organisation.

But it took effort and time to add an image and to create the page and make sure it was listed in the monthly archive. News stories with galleries of photos soon became few and far between because the effort required to resize and crop images for, let’s say, a 12 photo gallery, and upload them and attach them to a news story, would be considerable. And with less and less staff dedicated to do the job, the functionality that we spent days developing, didn’t get used.

Publishers had to rely on developers to manually update the monthly calendar listings at the change of every month, and year. 

And I never managed to get images to appear in search results.

AFTER: Title. Body copy. Featured image. Publish.

Working with images in WordPress is a doddle. In its simplest form, you just drag and drop from your local copy to the media library. Images are automatically resized for use across the intranet. You can crop, resize and rotate images directly within WordPress so there is no need for the expense of graphic packages, not to mention the appalling process of actually getting a bit of software installed on your PC. Bulk uploads are easy. As are creating a gallery or a carousel. It takes minutes. Thumbnail images appear wherever the page is listed across the site. 
Archive listings come as standard. As do images in search results 🙂

Broken link checker

BEFORE: The only way to do a comprehensive check for broken links was to run a manual scan of the whole local copy of the intranet in Dreamweaver. To do an absolute complete scan you’d have to download all the news stories (managed in a separate Red Dot CMS) locally too. And there could be 3 new news stories a day? The scan took hours on the super-fast laptops. As an alternative to this, we relied on reports that I had configured in Google Analytics to capture broken links, reporting the previous day.

AFTER: We use the Broken Links Checker plugin that runs behind the scenes and sends email alerts to individual publishers with details of their problem page. There’s no overhead in time wasted by the central team doing manual scans. The link checker also checks external links, so when you have to publish a link to the Cabinet Office website, which inevitably changes 10 minutes later, staff will see a greyed out link with a line through it until editors can get the *final final* link to the document with yet another version number.

Working with other editors

BEFORE: If you happened to be working on the same page as someone else, then it was pot luck who saved and overwrote the file. I myself was guilty of completely trashing a morning of developer’s work – sorry Matt! We did try to implement Dreamweaver file-locking for individual publishers, but it was such a palaver that we turned it off and I guess to this day, if you try to edit letter A of the A to Z, it will still be locked by Geoff.
WordPress multi-user locks

We have fancy locking for all editors so that two people can’t both work on the same page at the same time. And you can take control of a page if it’s still locked by someone who left the organisation. There is a revision history so you can go back in time to compare or restore previous versions. And if you delete a page, you don’t have to submit a request for change to restore from a backup and then wait; you restore from the trash.

Forms, surveys, polls

BEFORE: Adding a poll to the intranet was a major event. Someone had to code it up in confirmit, an external web survey service, and a developer would have to embed the poll into the news page. And then it had to be taken off again when voting was over.

Surveys always linked off to the external survey website and had to be created by the evaluation guy and only if we had enough credits available.

As far as online intranet forms go.. No PHP + No database = No online forms

AFTER: We use the GravityForms plugin for intranets that require forms. Editors can create their own forms using a simple visual interface, and add them to intranet pages. Or their own surveys or polls, for that matter. This is a premium plugin that we include as part of client projects, but would be covered by a GPC (government procurement card) purchase if you want to download your own. The plugin emails responses to a specified email recipient and also stores them in WordPress.


BEFORE: I mentioned that we didn’t have file-locking on static content pages and there was certainly no workflow for static pages. But we did have workflow for the Red Dot news stories that required some editors to have their work approved before being published.

AFTER: Workflow isn’t a standard feature in WordPress, but we have used plugins for some of our clients to allow pages to be reviewed and approved before being published. To be honest, digital teams seem to be so small these days that CMS workflow is not something that we get asked for a lot. But for larger teams, or teams who need sign-off before publication, and especially for untrained, devolved intranet publishers, it’s a requirement.

Staff profiles

BEFORE: I don’t think we ever had a staff directory that was adequate. Staff always used to resort to looking up a phone number in their local Outlook email client. The online directory was never up to date. I don’t know what the official figures are, but I clocked at least a 6% staff turnover from our Google Analytics reports. That’s a lot of people to add and delete from the database, regularly. I think at most, at one point, we had 1 person responsible for this task. And then it fell into disrepair.

In fact, I don’t think I’ve ever worked on an intranet with a useful, functioning staff directory. I’ve seen them. I remember being wowed by Cheryl Lesser’s tour of the Thomson Reuters colleague finder a few years back. And it is my dream to create one for an intranet and to start playing around with social features.

AFTER: With the uptake of the GovIntranet WordPress theme it looks like I finally have the chance to work on a staff directory. With PHP and a database *raspberry*

It’s an intranet feature that is very close to my heart and one that I look forward to knuckling down with. Hmm, a GOV.UK-style people finder…

An intranet inspired by GOV.UK

I started the new year by kicking off an intranet project with the very switched-on digital comms team at DCMS who wanted the next iteration of their intranet to follow the GDS design principles.


The project brief for this new intranet was to develop a CMS to enable the digital comms team to manage a task-based set of content, with design and style inspired by GOV.UK and the GDS design principles.

The team wanted to use tagging and categorisation to group, surface and link content across different parts of the intranet. And they wanted to radically reduce the amount of content and simplify navigation.


I was very pleased to start work on this project. The team had already done a lot of the information architecture work in determining which elements of content will go onto the intranet, and how to organise it. Adopting many of the GDS design principles in their work, the intranet will be geared around staff. It will act as a source of essential and useful guidance and information, and a place to discuss topics. Where information already exists elsewhere on other websites or internal systems then the intranet will link to it. No duplication. And in terms of content itself, the intranet will contain clearly-written tasks and guides giving information to staff. No vanity pages or stacks of rubbish that tends to be allowed to accumulate and fester on a badly-managed intranet.

The intranet design is responsive, using GOV.UK-style fonts with big headings and large text. Clear signposting and minimal navigation makes it easy to use and read on any device.

We went straight into prototype design for this project. No wireframes. The team had a working prototype to preview and play with just one week after kickoff. We’ve iterated and tweaked until what we have now will be the new intranet.

Only three main navigation options and no left-hand menus on this intranet. No branches of pathways to navigate. Just a big pot of information, organised sensibly, accessible chiefly via a big search box, something that I have been longing to experiment with for ages. For staff who prefer to browse and navigate, and I still come across staff who shy away from search, there are lists of topics, organised by category and tagged to allow traversing across sections of the intranet. So it will be possible to hop around and browse, for example, all ministerial tasks or all broadband projects, or everything tagged building move whether it be news, tasks or job vacancies.


The bulk of the content is made up of tasks and guides, taken from the GOV.UK idea of quick answers and guides. This is your typical guidance section of the intranet. But this isn’t organised into never-ending sections of intranet pages, with annexes from an employee manual that span nine levels deep into the navigation. No. It is essentially a databank of answers to typical questions asked by staff. Some answers are short and quick and we’ve called these tasks. Some require a bit more information and we’ve called these guides. They all sit in the pot and are accessible via search or by browsing categories and tags. Tasks are one-page answers to common questions such as “get a replacement building pass” or “book a meeting room”. Guides, such as “using your desktop phone” or “facilities in the new building”, are a cluster of individual, one-page chapters, split into discrete, digestible chunks.

The team will also manage internal vacancies through the intranet, linking these in closely with internal projects. In fact, this is the first intranet that I’ve worked on that will have a dedicated project area containing an overview of current programmes and projects in the department, high-level and detailed information, plus links to associated vacancies. This project section will highlight the actual work that is being done by DCMS and will help staff to feel involved in, and to understand the goals of the department and ultimately how this fits in with wider government policy.

Forums and blogs

Staff will also have the chance to hang out in the forums in an open and unmoderated environment.

In addition to the task-based content, there will be a blog for specific projects. And this seems to be the perfect answer to the age-old problem of vanity publishing. Wanna write about your department or project and showcase what you do? Fine. Not on the guidance section of this intranet, though. You’ll get your own area where you can write about what you do and get involved with staff who are interested. You’ll be responsible for keeping it up to date and for answering questions and comments from staff. Still interested? Sign-up here.


Search works great because the intranet is not filled with piles of badly labelled rubbish deemed as absolutely essential intranet content by some un-digital head of department. The content is slick, well-written, well-titled and tagged. And there’s not mounds of it.


Although there is a fair amount of room devoted to the corporate news feed, the homepage will provide aggregated feeds of the most active pages across core intranet content,  powered by live data from Google Analytics, and topical buzz from the staff forums. It will also feature freshly-published content, and the departmental Twitter feed.


From the publishing side of the fence, developing the CMS for the intranet in WordPress has been a dream come true for me. If you read my blog, you’ll be used to me moaning and complaining about the lack of an acceptable IT platform or not being allowed to use Open Source software or even a database when I worked at MoJ. Having these tools available to me now is like being the proverbial kid in the candy store.

Size and timescale

This is probably the smallest intranet that I’ve worked on. And it promises to be the most streamlined, task-based, user-focused and data-driven intranet that I’ve worked on, with well-managed content and governance for ongoing publishing. It will be a pleasure to handover this CMS to the content team, knowing that they will keep it pure.

This will also be my shortest intranet project. We’ve not launched yet, but working with Open Source software in an agile manner, with a switched-on team who have managed their own content population, has meant that this intranet will have been designed, built and populated from scratch, within a two month timeframe. And the cost? A mere fraction of a drop in the ocean compared to the millions of pounds of public money that I have seen wasted on repeated efforts to get an intranet right.

Project motivation and team working

The new intranet preempts a move to a new building location, and will be used as a major source of news and information for staff on the move. DCMS will save money by moving to an Open Source solution and hosting from the G-Cloud and severing contracts with existing IT providers.

Working agile in an agency environment means that we don’t have stand-up scrums every morning. But we do get the chance to develop, test and iterate in short sprints of work. Nothing makes for a great project like the people that you work with and it’s been a real pleasure to knuckle down with the DCMS digital comms team who have come up with a great concept for an intranet and obviously have the vision and backing at higher levels to make it happen, while doing other work on the public website move to GOV.UK.

Related posts

The horrors of devolved publishing

I like the idea of allowing staff to create and post corporate content on the intranet. But, in my experience, the idea hardly ever works well. It’s essential that publishers know how to create effective online content. Devolved publishing makes it difficult to maintain consistent quality, structure and findability.

Centralised publishing

MoJ intranet colours
Communication professionals produce the corporate announcements and news stories for our intranet. The style for news articles is short and clear. The content gets to the point and, where possible, leads readers deeper into the meaty intranet guidance pages.

The meaty information is supplied by other departments, and before it makes it onto the intranet it undergoes a bit of sense-checking from the digital team (who are also communication professionals.) They will advise on the content structure and suggest rewrites and SEO tweaks before they go ahead and publish.

These meaty guidance pages are the core of the intranet. The look-up information, the how-to guides, the statistics and policies and forms. Due to our processes and relationships between the different teams within the communications department, the intranet content is well-organised and well-written. We police the intranet quite strictly. And as a result our pages are consistent in look and feel, style and layout.

Our Google search engine works really well. We index HTML pages plus associated PDF and Microsoft Office documents. Search results are crispy clean. Most people find what they want on the first results page. We know this from our analytics.

Search results page

Devolved publishing

But about a year ago, we were asked to develop a system of devolved publishing to replace the Human Resources section of the intranet.

Human Resources is, by far, the most popular area of the intranet. It contains all the information that is most dear and most personal to staff; pay, pensions, sick forms, maternity leave, annual leave, training and claiming expenses, as well as more sensitive topics such as bullying, performance improvement plans and whistle-blowing.


Over the past year we’ve been working with our HR department to create the CMS system for them. I designed and tested the existing HR intranet information architecture as part of the 2010 intranet redesign. It was pretty easy to fit the new HR content into the existing structure. The only difference that I had to build in was a staff and a manager version of each page. I opted to use tabs, which fit well with Jakob Nielsen’s rule of using tabs to alternate between views, within the same context.

After months of development, we released the CMS to the HR department. We spent a day training the publishers how to use the CMS and how to name files and add metadata. They went away with a personalised user manual, armed to start building their content which would replace the existing HR section.

Pilot testing

When the content was complete, the HR department used a pilot group to test the new section with around 3000 people for two months in a ring-fenced area of the intranet. During this time I moved onto our website convergence project, having signed off the new HR navigation structure, leaving the HR people to make content updates.

Go live

The new HR guidance area went live in April, designed to go hand in hand with a new online HR self-service transaction system. The self-service platform was developed outside the digital team using an Oracle platform, in a drive to save money, and streamline and share internal processes.

And I’m not impressed with the results! I had a few days off work with a throat bug last week. I tried to fill out my sick form this week. Apparently it’s now called a return to work form. And it doesn’t exist on the intranet. I easily find the sick absence page (this still remains from my IA design!) They talk about the form. They instruct me to fill it in. But I can’t find the form. Not in the links on the page. Not in the search results. I even look in the back-end folders in an attempt to get my hands on it. No luck. So I assume that with the new self-service system I will be able to fill out my sick form online. How fabulous! This is what modern intranets are supposed to offer. An online, automated system where I can fill out a form for my manager’s approval and it all magically goes through to the HR department for processing.

Yet I knew in the back of my head that I wasn’t going to enjoy this experience. The system was designed by “IT” people. It uses some big brand product that will offer bugger all flexibility in interface design. And, even though I managed to login successfully, I still couldn’t find out how to do my sick form. Nothing at all about sick absence. Loads and loads of drop-down menus filled with codes that I don’t understand. So I ask my manager if she needs to request the form for me somehow? No. She can’t find anything either. No wonder the helpdesk gets flooded with calls.

The search results page is now infected with excel spreadsheets titled “Sheet 1” and forms with titles like “MatB1” and “CNF1a” making it hard for staff to make sense of them.

I recently found out that while my back was turned, our CMS developer was snipered with numerous requests for change from the HR people, coming in through the back door in the disguise of “system defects.” Our developer saw the word “defect” and immediately made the necessary “corrections” to the structure. It’s disappointing when our team have delivered a perfectly good system for publishing content within an agreed content structure, that the publishers cannot then just concentrate on producing their content.

So we are left with a section of the intranet where the structure has been tampered with and the content is just not up to scratch. And I’m not blaming the handful of people that we trained to load content into the CMS. During some periods I know that only one person was battling with the constant content additions and corrections. The inadequate content is the result of human resources professionals who believe that their communication skills work just as well online as they do on paper. The badly designed transactional system is the results of IT professionals who are still in the mindset of delivering “software” and expecting the “user” to learn how it works. And when the final result doesn’t work, their response is to slap lengthy announcements on the HR intranet section homepage explaining where to find the information, and to create endless videos to illustrate how to use the system. When will people learn that testing a system with real live people in the first place saves all this patching up after the system goes live?

All too often, I see web and intranet projects being too rigidly project-managed with more emphasis on documentation and ticking boxes than doing the actual work required to deliver a usable product that works right first time. The intranet is about people; staff, employees, workers. We need to provide quality information and services for them. Fortunately, the intranet doesn’t have a start and end date that can be nicely squeezed into a project timeline; it is alive with the ebb and flow of content updates, additions and improvements, campaigns, corporate messages, experiments and realignments. And as such, it gives us all the chance to make mistakes and put things right. But the HR content is “owned” by the HR people so the best I can do is advise. Next steps for this popular area of intranet content is to smarten up the information, make sure all the necessary forms and documents are available, and go through every document to check SEO metadata. And it would be a good idea to revisit the self-service system and integrate it more into the intranet.

Whether devolved or centralised, communication professionals who supply content for the intranet must be digitally-aware. They need to know how to write and layout pages for online reading and how to optimise documents for the search engine. They could also adopt the idea of testing and sense-checking their content before going live.

I have seen a devolved publishing intranet model work very well when I worked on the London Underground intranet with a tight group of well-trained, well-managed and engaged publishers. But even here, I’ll never forget in the early days, the proud publisher who posted an animated gif of his revolving head, and the guy who thought that never-ending cascading menus were a good idea for accessibility.

Other sites

Squiz is the shizz

Squiz provide and support the MySource Matrix content management system.

The nice men from Squiz came to visit us today and I have to admit to being excited before the demo of their product suite. I checked out their website a few weeks ago and was very impressed.

I don’t know why I haven’t bumped into them before now; they’ve been going for over 10 years. Probably because the product is Open Source and I haven’t held out any hope of ever being allowed to use it.

The Open Source suite offers:

  • Enterprise CMS
  • Search (Funnelback)
  • Analytics (based on Google Analytics)
  • Integrated social media/networking

The Australian Federal Government already uses the system, as do a handful of UK agencies. The software is obviously free. And Squiz offer a support service including secure hosting.

How could we benefit?


The system has all the functionality that we would need; simple on-screen editing, user privileges, workflow, scheduled publishing, platform-specific templates (e.g. desktop browser or mobile device), track changes and real-time pages (rather than published HTML). Video support and image catalogue. A customisable frontend means that you can weave search, analytics and social functionality into the site’s pages. Suitable for both intranet and internet.

On the web we would be able to build an engaging site with a rich user experience. On the intranet we would be able to deliver targeted content to specific business areas using one central system. With the ability to deliver mobile content we would have the chance to reach out to front-line staff.


Funnelback search is sexy. Type-ahead functionality. Live results based on user activity and trending. Faceted results. User feedback. Clever. Certainly worth considering defecting from Google. Up to the minute upgrades, instead of having to jump through sulphurous hoops of red tape and third-party suppliers. Somebody pinch me. How much money could we save by cutting out inflated IT procurement and service contracts?


Based on the equally shizzling Google Analytics we would own our own data that we could feed back into the sites, improving search results, popular page and related information lists. And being able to provide up to the minute analysis is a bonus. The module also includes A/B and multivariate testing and reporting.


Integrated into the suite is a social module which allows people to use the intranet/website like we do out here on the web. Rating articles, commenting on posts, “liking” pages, sharing stuff. Polls and surveys. Plus RSS feeds and email alerts giving people the power to catch up on their preferred content. And of course there’s blogging and microblogging.

I hypothesise that the success of implementing any such system will hinge on the…

Staff directory

The backbone and starting point of a new platform and way of working is the staff directory. Focusing on the individual, who is responsible for keeping their profile up to date. Social functionality starts from the user profile where an enterprise version of a “social graph” begins to build. Over time we will be able to see which pages people like, which content generates buzz. Staff can connect and interact with each other no matter how far apart geographically.

Which rather brings me back to a post that I wrote back in March:

Whether, in these austere times, we’d be able to afford such a system, I don’t know. But maybe by cutting out our existing CMS system, our existing Google Search Appliance, our hosting and servers, our IT support and service overheads – we would actually save money.

Mentioned sites

Intranet redesign, Phase 5: migration, content freeze, dual publishing

The end is in sight

Remember that migration plan from phase 2? Having decided to publish back-issues of news stories to the start of 2009, I could quantify how much content we would need to migrate. I managed to cut the original content from 6416 entries down to 3000 entries. Some of this was by losing older news stories. The remainder I did by reorganising content into simplified chunks. Where a section had dozens of one-paragraph pages, I grouped and combined them into fewer pages. I removed out of date content. Cut out duplicated content. Barred the *what’s this doing on the intranet?* content.

So it was at this point in the project, around September 2009, that we agreed on an unofficial launch date of 1st January 2010. We reckoned we could populate the new intranet in that time. We would divert all our attention to the migration and bat off any new development work.

Migration checklist

We pulled a few extra resources from the web team to help out with migration. We had hands-on training for the CMS publishing and strict rules on page titles, metadata and file names.

I shared the master migration plan with the team through Google Docs which worked wonders for collaborating on our progress, showing up to the minute changes and no document check-out and check-in. Meh!

Content freeze

We announced a moratorium on intranet updates with the exception of corporate news and features and urgent ministerial and board messages.

Curious to note that having announced a content freeze, intranet content owners who had not done anything with their content for months and months suddenly wanted to update their pages. Don’t you love human nature?

Dual publishing

Because we had agreed to continue to publish news stories, I divided the migration work amongst the team with one person responsible for publishing ongoing news onto the existing intranet and also entering into the CMS for the new intranet. We had a few people working on news story back-issues. And a few working from the existing Dreamweaver content, manually building the green, blue and purple sections of the site.

Migration production line

Cut and paste. Cut and paste. Robot-like for weeks. The migration team laboured on. The traffic lights on our Google Docs spreadsheet slowly changed from red to green. We took this chance to do a little editorial work on pages as we moved them across, rewriting in plain English and reformatting pages to improve readability. I was also keeping an eye on our Google Search Appliance as it indexed the migrated content. Up and up went the page count. Perfect page titles all round!

A URL was leaked at some point and from studying Google Analytics I could see that there were about 60 people around the organisation looking at the new site before it was officially launched. I’m glad they were that interested!

Communications and launch

In my next post I’ll cover how we worked with our internal communications colleagues to prepare staff for the new intranet and how we have evaluated and evolved the intranet since launch.
In this series