Archive for the ‘intranet’ Category

Does “Intranet” Need a New Name?

Thursday, February 11th, 2010

James Robertson has an excellent post, Future principle: it’s more than the intranet, where he summarizes a movement to replace the term “intranet” with a word that reflects what an intranet could be. To quote:

There are some that would like to dump the “intranet” name, as it’s associated with the “old” vision of intranets as a publishing platform, a dumping group for documents, and a place for the CEO to post his thoughts.

This narrow vision of the intranet must certainly die. In the process, intranet teams need to go from being custodians of an internal website, to facilitators for business improvements. In many ways, the word “intranet” has too much baggage, and is an anchor for much-needed changes.

I agree that many people hear the word intranet and immediately think “dumping ground” but one does wonder if companies will not sully the next name by their continued failure to execute on the vision. The term “intranet” is actually pretty good and should be able to ride on the coat tails of the internet. The name “internet” wasn’t brought down by failures like GeoCities because there is so much innovation happening; and failure is a necessary by-product of innovation. The difference is that failure kills most corporate intranets. Many intranets are big waterfall I.T. projects that are “complete” after launch. There is no time or budget left to learn from mistakes and adjust — the equivalent of a failed internet start-up but without the decency of shutting the servers down.

I don’t expect companies will improve their execution of intranet projects until they start to change the way they build, launch, and manage internal products. The companies that are ahead of the curve should give their intranet an internal name to make users expect and work for more than the status quo.

BTW, I have a great replacement for the term “intranet” but I am not going to tell anyone because, sooner or later, it will be ruined by some comatose intranet initiative looking for some easy re-branding. :P

Should you host your intranet and corporate website on one platform?

Tuesday, November 10th, 2009

Often times by the time a client gets to finding me, they have reached a point where they are ready to throw away their entire web infrastructure: both their corporate website and their intranet. They hope that one well executed product selection can solve both problems. When approached by this kind of prospective client I am careful to set the expectation that this hope is probably not realistic — not impossible, just not realistic. That said, there are a few conditions where putting your intranet and external website on one stack does work. Here are the criteria that I use.

  1. The intranet is informational rather than collaborative. Different people mean different things when they say the word “intranet.” For some, an intranet is just a collection of web pages that only employees can see. Others think of tools and workspaces that allow employees to collaborate and get things done. If you had the latter in mind, chances are you will be looking for a document management, ECM, or portal system like Sharepoint for knowledge worker collaboration. These systems are technically capable of pure web publishing but that is not their strength. Your website management team will feel constrained by a platform that treats web publishing as an afterthought. If you think of your employees and customers/prospects simply as different audiences that you need to publish to, a single platform may work just fine.
  2. The company has other platforms on which to build specialized, dynamic web applications. Sooner or later (or probably already) your company is going to need to develop content-oriented web applications and your WCMS is a logical place to start. However, these web applications are likely to introduce the most demanding and specialized requirements. It is quite possible that the union of your intranet and external website application requirements filter out every viable CMS — or at least force some painful compromises. If you have an alternative stack on which to build your fancy custom applications (possibly pulling content from your WCMS) and can let your WCMS focus on simple web publishing, you greatly increase the chance that you can comfortably support both internal and external publishing.
  3. The corporate website and intranet are owned by one communications group. Today you may be able to align your intranet and external publishing needs; but will they stay aligned? How will you arbitrate between the competing priorities of the intranet and marketing website? What if those priorities don’t just compete for resources but actually conflict with each other? Things can get ugly when two different departments with different goals argue over what feature needs to be added next. These decisions get a lot easier if both the intranet and external website are owned by one communications group. Companies that are structured this way are usually small and can benefit the most from sharing the infrastructure cost between the intranet and extranet. Having the intranet owned by a communications group also pretty much ensures that criterion 1 is satisfied.

If your company meets these criteria, there is a good possibility that one instance of one CMS platform could serve you quite well. Otherwise, I would recommend doing one of your two projects and then putting the product that you used on the short list of products to consider for the other. If it turns out that the one platform supports the requirements of the second project, buy another instance of the software (hopefully at a discount) and start a new project to implement it. Take advantage of code and idea re-use but don’t let that constrain the flexibility and agility that you need to achieve your goals.

PDF or HTML?

Tuesday, June 30th, 2009

Alex Manchester, from Step Two Designs has a very useful article on when to publish Intranet content in PDF format rather than HTML. I agree with Alex’s point that PDF is suboptimal for most content because of several limitations (most of them around the additional overhead in editing and reading the document) but still has its place: like for documents that are distributed for printing.

Too often PDF serves as a crutch for users with limited web content management tools and skills. For many, it is easier to save a MS Word document as a PDF and upload it than to work with HTML (either through a CMS or using an HTML editor). The real cost of using PDF occurs after the content is published when users have to wait for Acrobat to load only to find that the document is not what they are looking for and when the document needs to be updated but the original Word document has been lost. I think the most painful abuse is the case where the company has a wiki and users upload MS Word and PDF files as attachments rather than edit the content in the pages. Doing this degrades your wiki into a poor man’s shared drive — and that is very poor.

What your intranet needs is a publisher!

Monday, June 1st, 2009


J. Jonah Jameson

Originally uploaded by OntologicalDoubt

While I work with companies from many different industries, most of my clients media and publishing companies. I like working with publishers for many reasons — not the least of which is the fact that this is an industry in transition and it is exciting to see my clients innovating and re-inventing themselves. But the main reason publishers are so interesting to work with is that they, more than any other industry, understand the value of content. It is their business. While you could make the argument that a publisher’s key asset is its audience (not the content), it is the content that attracts the audience. Publishers push their organizations to produce content that an audience wants to read and then look for ways to monetize that audience.

Compare that with other types of companies. How many marketing organizations think of their website copy as only a modest improvement over the Latin text that the web designer left behind? Internal content is worse. Updating the intranet is the last priority for the average knowledge worker. People have more gratifying responsibilities than contributing to a web site that nobody wants to read. In most companies, employees are not recognized for their intranet contributions. Take, for example, a knowledge base. If you have a brilliant piece of information, depending on where you work, it may be better to share it with individuals you know and have them “owe you” than to leave it to rot a in a place where nobody will benefit from it.

Companies fool themselves when they think that if the tool makes contributing easy, staff will all of the sudden think contributing content is their number one priority. You might get a slight uptick of activity when you deploy a new publishing system, but after the novelty wears off, people will go back to their old habits. Writing content is hard work no matter how “fun” the tool is to use. Employees will gravitate to work that is either easier to do or more rewarding (that is, things that are measured by their bosses).

Assuming that enterprise content has value and is worth managing, there needs to be someone in the organization responsible for maintaining that value. Enterprise content needs someone to represent the audience and ensure that they are being served. Enterprise content needs a publisher. Pardon the geeky comic book reference but think of Peter Parker’s (aka Spiderman) obnoxious boss J. Jonah Jameson (pictured above). He relentlessly pushes his staff to create content that he knows his readers want to read. Granted, nobody wants to work for a jerk like that. But is it any better to work for someone who doesn’t care about what you produce?

In the media and publishing world, Clay Shirky theorizes that the role of the publisher is becoming unnecessary. The Internet has solved the journalist’s problem of reaching an audience. But that assumes that the journalist wants to become his own publisher. The blogging phenomenon has seen just that. Bloggers (citizen journalists) put up their own websites and invest large amounts of time building and cultivating their audiences. They look at traffic stats; they think about wording for SEO and click through; they tag; they obsess over establishing their personal brand. They didn’t do this just because the blogging tools were easy to use. The first generation of blogging tools stunk. But the first generation of bloggers really wanted to publish and they were just happy for the opportunity. Inconveniences and poor usability were not going to hold them back from having their voices on the Web.

Many Enterprise 2.0 advocates predicted the same thing would happen inside the firewall; that employees would self publish with the same zeal on the Intranet as they did on their personal blogs if they had similar tools available to them. It didn’t happen — not because they couldn’t figure out the tools but because they were too smart about managing their time. They knew that they would gain more during their 9-5 work day from doing other things. They satisfied their inner publisher during nights and weekends at home where they could reach a much larger audience and own their content. If they could get away with it, they would sneak in a post to their personal blog from their cube.

There is only so much you can do to motivate your employees to “want” to publish on your Intranet. You can make it part of their job description; you can recognize their efforts. But you will probably not be able to create the hunger for attention within your firewall that will unleash that entrepreneurial publisher spirit. If they have that spirit within them, it will be expressed on their personal blogs. To get your employees to act like journalists, you need a J. Jonah Jameson type. Maybe not as abrasive, but just as passionate. Have your internal publisher imagine that he is in a circulation war with a competing intranet and that he should do whatever it takes to capture and enthrall subscribers. Just tell him to 86 the cigar; he will never get that approved by HR.