How to better communicate your intranet requirements

How to better communicate your intranet requirements

Capturing the needs of stakeholders is important, but the form of those needs and requirements is critical. Learn how to effectively communicate your intranet requirements to ensure you get the right platform for your organization.

February 19, 2018

Are you a company looking for a new intranet? Are you looking for a way to make your evaluation process a lot easier?

Selecting an intranet solution can feel overwhelming. There are many different products and platforms available, which makes differentiating between them all a little challenging.

Most organizations will appoint a project owner (usually a communications manager, IT manager, or HR manager) to gather requirements from project stakeholders, identify a list of vendors, and evaluate these tools against the requirements to ultimately make a recommendation and selection.

While this process “works” in the way that something ends up being purchased, it often results in the selection of a product that doesn’t quite meet the needs of its users. Software is often purchased based on features, whereas success hinges on its usability. Sure the platform has all (or most) of the features deemed important, but if they are difficult to use, employees won’t be able to get work done.

How can organizations avoid this trap? Capturing the needs of stakeholders is important, but the form of those needs and requirements is critical. A while back we received a set of requirements from a potential client who was in the process of evaluating ThoughtFarmer. They sent us a detailed spreadsheet with their requirements, as expected. But what was different was the way they documented their requirements.

If you like this blog, you’ll love our newsletter
From workbooks and whitepapers, to blog content and best practices, our monthly newsletter is full of great content, advice, and expert insight.

Instead of a list of features written as “the system shall do X,” they instead took each requirement and placed it in the context of the user. It’s a user-centered requirement, without needing to write some massively detailed use case.

Each requirement was written using the following template:

As a [role of user] I would like to [description of task] so that I can [description of end goal]

Here’s an example of a single requirement.

As a... I would like... So that...
User to be able to post blogs about the things I am working on people can keep up to date with things I do, which may be relevant for them as well

What’s special about this way of documenting intranet requirements is that they identified who this requirement was for: the user.

They also included requirements from many other users, including the Intranet Manager, the IT Manager, and the Intranet Editor. We quickly got a sense of the different roles they had involved in their intranet, which helped me get a sense of their would-be intranet requirements.

In the above example, they stated what they wanted: the ability to blog. Specifically, they wanted users to be able to write about what they were working on. They also stated why they wanted such a feature: to keep people informed about what their colleagues were working on, since it may impact their goals. In short, they gave us a bit more context around the request: we want a blog and here’s why.

The advantage for us (as a vendor) is that context removes the requirement to work with assumptions. If you simply poll your stakeholders, you might come back with a feature like “must have wiki support”, but additional context may suggest an alternative feature—or customization of an existing feature—may be more appropriate in terms of actually achieving the end goal.

So instead of writing “must have wiki support” this requirement would become:

As an... I would like... So that...
Inventory Manager to collaboratively edit our stock taking procedures we can have a living manual of best practices that are always up to date and accurate

So, when documenting the requirements for your intranet, ask yourself the following:

  • Who’s the user?
  • What do they want?
  • Why?

This approach will go a lot further in clearly communicating your intranet requirements in the form of the needs and wants of your end users, instead of a long list of features.

In the case of this potential client, we were able to clearly articulate how ThoughtFarmer met their users’ needs, and they went on to purchase and successfully implement ThoughtFarmer inside their organization.

If you’re interested in using this approach to better describe your intranet requirements, be sure to download our 10 step guide to a new intranet.

Editor’s Note: This post was originally published in November 2009 and has been completely revamped and updated for accuracy and comprehensiveness.

Have questions? Get in touch! We're always happy to hear from you.