Gord| November 24th, 2009
4 Comments »
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.
I was interested to read 
