Communicating your intranet requirements

Comments4

Looking for a clear and simple path to a new intranet? Download our free Intranet Buyers Workbook to learn 10 key steps in evaluating intranet solutions.

Are you a company looking for a new intranet? Are you wondering if ThoughtFarmer meets your needs? Are you looking for a way to make your evaluation process a lot easier?

image: The Consumer Decision Making Process (Kotler) as found in Peter Morville’s book, Ambient Findability.

Buying software is not an easy job. There’s a ton of software options out there. We’ve been on the other side of the table for many years, having done countless CMS evaluations for our professional services clients in building large public websites and intranets. We’ve relied on vendor evaluation lists and requirements checklists like those published by Tony Byrne at CMS Watch and James Robertson at StepTwo. You may have viewed the Gartner Magic Quadrant report, which we also appear in. You may have enlisted a professional services firm to help with the evaluation.

These tactics are all useful and help you march through the myriad of choices from Total Set to Awareness Set and onwards towards your final destination of Consideration and Choice. Of course, if only we could be quite as rational in our decision making as Kotler’s lovely flow chart diagram. Most often, the decision process is still a bit of a black box.

One helpful tip that came across my inbox the other day was from a potential client who’s in the process of evaluating ThoughtFarmer. They sent me a detailed spreadsheet with their requirements. Now this is not unusual and often forms the basis of the evaluation process. But what was unusual was the way they documented their requirements.

They took the typical software requirement of “the system shall do X” and wrapped it with some more context. It’s a user-centred requirement, without needing to write some massively detailed use case.

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 so special about this way of documenting requirements?

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. I quickly got a sense of the different roles they had involved in their intranet.

They stated what they wanted. They wanted to be able to blog. Or more to the point, they wanted users to be able to publish their own information on what they were doing (which may be satisfied by the feature of a blog, but may also be satisfied in some other way). I understood their goals.

They told us why. Again, 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 if we have a feature which may meet the need, but better than that, we now understand a bit more as to why it’s being requested. If they think they want a blog, but explain why and we discern that perhaps they want a more wiki-like feature, we can now begin to engage in that dialogue with them about their needs and how we can meet it.

So for you intranet managers out there, evaluating software packages, this is a great place to start.

Ask yourself the following:

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

You’ll save yourself and the vendors you’re talking to quite a bit of time and effort in clearly communicating your requirements. Remember, it’s really about the needs and wants of your end users, not some shopping list of features.

Now that you know how to create intranet requirements, get in touch for a demo of ThoughtFarmer social intranet software.

Comments4

Join The Discussion

  1. greg

    I like this approach. Simple and to the point. One question: how do you know what’s a nice-to-have v. must-have?

  2. Gord

    Greg,

    There’s lots of methods out there for prioritizing requirements. Our roots are in custom web development and we continually challenged our clients to prioritize their needs and wants. You can take a look at a fairly rigorous process from “Mr Requirements” Karl Wiegers (some great reading on his website and also in his Microsoft Press books on requirements).

    These types of approaches rely on some kind of group consensus on the value of a requirement. When you’re not working in a custom development world however, it’s really easy to get caught up in the “it’s not costing me anything to have all of these features!” approach. The risk is to have 1000 requirements and for them all to be mandatory.

    For introducing new intranet software into the organization and in particular social intranet software which may be very different from the previous intranet 1.0 paradigm, I’d argue that you need to focus the most on features that will aid in acceptance and adoption. What will get people using this tool? What’s our biggest problem that we’re trying to solve? If I could only pick three things I needed this intranet to help me with, what would they be?

    What drives acceptance and usage (and therefore value) is perceived usefulness and perceived ease of use. I’d suggest starting there as an investigation with a larger group on what’s really important and what’s just window dressing.

  3. Nadine

    Thanks for this example Gord.

    I really like the approach, and the clarity it gives to the vendors. And also to yourself, so that you are always keeping in mind why you are asking for something and not just creating a shopping list of cool functionality, or attempting to identify the solution.

    I’m going to try this out on some upcoming enhancement requirements!

  4. Gord

    I should also point out, that wasn’t the only 3 columns that I received in the requirements spreadsheet. There was also a priority column (Essential, Important, Nice to Have – a variation on Mandatory & Desirable), another column for further description of the requirement, and a handy ID column to remind yourself of which requirement you were talking about.

    Again, a simple, but powerful approach that provided a high degree of usefulness for both the author and the author’s different stakeholders, as well as the vendor having to evaluate the request. Both sides found it valuable, which isn’t often the case with long, tedious requirements docs.

Comments are closed.