How we sold WordPress as a big intranet solution

This is part of the talk I proposed for WordCamp US. Thanks to a few things I’ve read lately, I feel moved to write some of this out.

Our intranet is a big, crazy mess. It’s old. You would probably be hard pressed to find many 20 year old intranets (as ours is). I’ve been on the intranet team since the home page was a bulleted list of links. One of my very first intranet projects was coding up the first version of our home page that used graphics. At the time, the company browser was NCSA Mosaic. Special permission was required to access Netscape Navigator. I worked on the intranet team for a while, I think, before I got permission. Seeing a tiling background for the first time was… pretty trippy. I digress.

The intranet started in our Publications division, but moved to IT because the focus was on the technology. I wasn’t around for that part so I am speculating. It’s kind of a pity that it left Pubs, because those folks at least understand content. IT doesn’t. Hence, there’s never been any governance or effort to organize the intranet as a whole. Certain sections have gotten a lot of that sort of that attention over the years, but the experience as a whole for the end user is disjointed, exasperating and crazy.

A couple of years ago my company started a process of what I might describe as intensive navel-gazing. We’re growing up, we’re modernizing. We’re shining lights into a few cluttered broom closets. I guess the intranet is one of those broom closets. One of the execs instructed the head of Internal Communications to summarize the problems with the intranet, and thus the bright light came to shine upon us. One of the big problems she identified was that there is no CMS for the intranet.

Around the same time a certain technology solution was being floated as an option for the intranet. It had been used to great fanfare and happiness for our external web site. It’s Java, and it’s expensive, and it’s all wrong for the intranet in a lot of ways, but explaining that and getting a better solution in place was a job of work.

We didn’t go through a nice, logical evaluation to decide to use WordPress. No, I just kind of came up with the idea during my yearly review the year this was all going on. There is some logic to it: we’re PHP developers, and we’ve been running a fairly sizeable WP multisite install for a few years now – it’s used for internal blogging. I also knew that whenever I put a user in front of the WordPress editor, they loved the UI. We had people asking for WordPress sites all the time, because of its rep as being friendly to use.

So we put together a pitch, a slide deck that I presented to the head of Internal Comms. By the end of the pitch, she was completely on board. I honestly can’t remember a lot of what was in that slide deck, because there was one selling point that was a complete accident, and it wound up being the key to the whole thing.

 

We could make it look like the flagship corporate site.  That was the killer.

In the slide deck, I had some screen shots of one-off WordPress sites that peppered the intranet. One of them was a site where a premium WP theme had been carefully tweaked by one of the external site designers to resemble the external site. I do emphasize resemble here, because to me the differences were glaring and obvious. Not so much to someone who hasn’t been building web sites for many years. That was the screen shot that she focused on – she was amazed that WordPress could look like sas.com.

People who aren’t web developers often have a hard time understanding that when a good web developer works with a CMS, we largely decouple content, presentation, and functionality. I knew that clients often had trouble understanding the implications of this, but I really didn’t understand how deep that lack of understanding is until that moment. It was clear that in her mind, and in the minds of other executives, the only way to get that sas.com look was with the expensive Java CMS that my team wanted no part of. They did not imagine that it was possible to make a site look like sas.com with any other tool.

In their minds, the sas.com look and the Java CMS were synonymous and completely linked together. Demonstrating (albeit accidentally) that this was not the case was the first thing that sold WordPress.

 

WordPress is just cheaper.

I was asked to add a cost comparison to the slide deck – the total dollar cost of Mr. Java CMS vs. WordPress. This was the second huge selling point as you can probably imagine if you know anything about WordPress. Here are the ways in which WordPress is cheaper:

  • Software licensing cost. Well, there is none for WordPress itself, and it exists in an ecosystem of a billionty free plugins and themes. For Big Java you pay not only for multiple server licenses – for each instance in your infrastructure – but you pay for author seats for everyone who ever touches the UI.
  • Hardware. WordPress was already running on our existing web servers. Mr. Big Java would require several dedicated new servers.
  • Training. Whatever we needed could be had from existing resources our corporate library already pays for, like Lynda.com. Mr. Big Java requires extensive paid training courses for authors and developers.
  • Consulting. None needed as far as we knew for WordPress, but without Java expertise on the intranet team, consulting services would have been needed to use Big Java on the intranet.

There was just no competition.

I would like to add that this has panned out exactly as we thought. We’ve thrown no new hardware at this project, we’ve spent less than $250 on plugins, and going to a couple of $40 local WordCamps has been our main training expense. Okay, going to WC US will cost a little more than that, but it still doesn’t hold a candle to the $$$ involved in just getting a Big Java site moving.

People resources were also a huge selling point. The three PHP developers already on salary were enough to take this on. A small army of Java devs (plus consultants) was needed for the Big Java project on sas.com. They got the initial launch done faster but that had a lot to do with the other small army of content and design folks staffing the project. Intranets generally don’t have a content and governance department devoted to them and such is the case with ours. I feel that as developers we have not had any trouble keeping up with the demands of the content owners, because the content owners just don’t have a very big pipeline. They may have to wait a couple of weeks for a new page element to be added to the theme, but usually not much more than that and we are never the bottleneck. The real resource constraints are not developers – they’re design, content, and governance resources.

 

A simpler solution is better for an intranet

Big Java CMS requires training of end users. Everyone who touches the UI not only needs a seat paid for, but also a paid training course. To even use the thing.

That just does not fly with an intranet where hundreds of people could be content owners and content ownership shifts like desert sands. If there was one thing everyone already knew about WordPress, it was that it is easy to use. We came away with a mandate to keep the usage of it simple, but otherwise in this regard WordPress sold itself and we didn’t have to work hard to make everyone realize that it is a much more practical solution for an intranet environment. For an intranet you pretty much have to have something that anyone can walk up and use.

 

We can make it do whatever you want.

When the people making the decisions were doubtful of WordPress as a “real CMS”, I’d fall back on the fact that we are experienced PHP devs and it is open source software. I was confident that we could make it do whatever is needed. In a lean situation like this with unpredictable requirements and a small staff, an Open Source project is a kind of insurance policy, because the limitations are really the skills of your developers and not the capabilities of the software.

I have a lot of faith in our skills, because all three of us have not only customized many different CMSes over the years, we’ve also rolled our own numerous times.

The huge ecosystem of plugins and themes in the WordPress world also reinforced my belief that we could make it do whatever, because clearly so many diverse things had been done with it already.

 

So far WordPress has not made liars of us.

The theme thus far truly does look like sas.com – much more so than that screen shot in the slide deck! The three of us have kept up with the content folks. They seem to pick up the usage of new features easily so it’s simple enough, for now. We’ve not thrown money at it, and it hasn’t let us down.

To be entirely fair, it is early days yet. We haven’t launched with the first business unit’s content yet, much less converted the entire intranet over to WordPress. In a few months we’ll see if this is all still true.

 

Related reading

The stuff that shoved me in the direction of writing all of this down.