How Companies Fail in Choosing Intranet Software

There is only one intranet software that is the world’s best. It’s ours.

It’s the condensed marketing message of most ads, not only for intranets. We all know it can’t be true if two people say it. But the main problem is that companies still try to find out who is right and who is lying.

analysing

But the fundamental truth is, that the right solution depends on your preferences. If your budget is tight, you may choose something other than the solution with the most comprehensive features. Some solutions work out of the box, others need long deployment times.

If companies would get their priorities right, they would be able to compare and choose better. Do you want your intranet to be cheap? Should it be quickly available? Should it have all features possible? Do you need awesome usability?

A simple ranking would be sufficient. But the most common answer is: It depends. In all RfPs for big intranet projects that I have seen, not one company was able to tell us if any one criteria was really more important than the other. The RfPs all read the same:

Here is the list of criteria. Please fill out our table and we’ll reevaluate as we get and understand your answers.

Some even include weights for certain criteria to indicate that they are more important. But if you look at the impact, it’s minor.

I do not criticize that companies decide subjectively. I hate that they pretend to be objective in their decision.

There is no objective decision. Decisions for an intranet project are always trade-offs. It’s one thing above the other. The underlying problem is taking responsibility for the result.

No one wants to be responsible, when the new intranet sucks. And all former intranets actually sucked.

So intranet teams often engage in vanity activities that do not help in the end, but that help to “cover your ass” (CYA). I do not think that all comparison checklists are worthless. It is helpful for teams to get to know intranet software and options better.

The major flaws of checklists

  1. Overemphasis on quantity
    Checklists make it easy to have the main features (Compete with email, Create rich text online, Connect and collaborate with other employees, …) be just one check box, and have tens or even hundreds of other checkboxes, that are merely irrelevant.
  2. Subjectiveness
    It is scientifically proven that value benefit analyses do not offer objective judgements.
  3. Waste of time
    The time it takes to create the criteria and to have vendors fill out the spreadsheets and then evaluate everything is not wisely spent. That’s why we have created a public platform for such comparisons, called the Intranet Compass. We understand that companies need this. But intranet teams should focus on ways to really understand the software instead of looking at tables for a long time.

There is a long blog post about the problems of checklists for intranet comparisons here.

Yes, I am against checklists. And I am against teams trying to not be responsible. But it’s usually not very helpful to be against something. You have to be for something to actually change things for the better.

Use your evaluation time in the software, not on it

The key change that I ask intranet teams to pursue is to actually work with the software that you think may help you. And please don’t do it alone. Do it with your team. Modern intranets are all about collaboration and team effort. That renders testing intranet software quite difficult. There are quite some use cases that you want to cover:

  • Asynchronous communication
  • Asynchronous collaboration
  • Synchronous communication (real-time)
  • Synchronous collaboration (real-time)

Organizing meetings and a project in a modern environment

In my guest blog post for Atlassian about 111 reasons for an enterprise wiki, I have laid out numerous use cases that you could work on in such an early phase of intranet software testing. But the most reasonable and relevant use case for you to test is to try to organize your intranet team meetings and the entire project’s progress in the intranet you are testing. Try to gather information, develop a structure, add files and ideas, and record all the stuff that emerges when you do such a big project. Put all of these things in the software and see how it works.

I hear your objection: “But the vendor will see all of our information and assessments.” Yes, true. But wouldn’t it be wise to share this stuff with them? They will help you understand where you’re wrong, and shine a light on their own software’s strengths. If you use the time that vendors usually give you for free for such work “on your project information gathering and testing,” you’ll actually have the vendor help you progress.

And the best is: It’s real. This is a real project with real data that matters to you and your company.

If you use this data in 3 to 5 systems, it will not take long to find out what rocks in which software, and what sucks. You can tell the vendors and see how they react.

This is how intranet teams should choose and work on intranet software alternatives.

Lesen Sie diesen Artikel auf Deutsch.

Share article:Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page