Tip - Defining your Information Management requirements

I was having a discussion in email some time ago, with someone about what their requirements were for information management and I suggested an approach for them to define their requirements. I developed the suggestion further in order to make this post.

To a large extent, the typical approach is for users to take an ad hoc, features-based approach to stating their requirements. That is, looking at the features of an information management system (e.g., Evernote or InfoSelect or Gmail, amongst others) and saying "Look how useful that is" or "I don't like this" (e.g., a "ribbon" menu) or "I do like this" (e.g., the ribbon). This actually is not the most helpful way (to a developer) to go about providing or gathering requirements, since a like or a dislike does not necessarily define a requirement nor does it necessarily even identify a requirement. This is why attempting to build a requirements list by, for example, a straw pole (likes and dislikes) is usually doomed to failure. It is, in fact, irrational.

As WE Deming said, "Action that is not based on sound theory or best practice is irrational by definition".

The requirements-based approach, on the other hand, basically says "This is how and why I want an information management system to work for me", and it does not concern itself with features or how the system is to work (the latter is the developer's domain).

What I would therefore recommend is that, if you have not already done so, then take a leaf out of the Kepner-Tregoe approach (an approach to rational management) and use a 3-column table:

• in column 1, write down a list of these things that you want to be able to do (requirements);
• in column 2, write down against each item in the list why you want to be able to do that thing (i.e., what is the purpose of that requirement?).
• in column 3, write down the appropriate priority - A or B or C - for each requirement, where:
  * A = Mandatory ("must have").
  * B = Highly desirable.
  * C = Nice-to-have.

This approach is the one I usually take for myself and (in the role of an IT and management consultant) one that I often recommend for my clients.

The act of drawing up your requirements like this can be quite useful, because usually it means that:

1. you will be able to more clearly understand your own information management requirements as a whole (there they all are, in front of you, in the 3-column table).
2. you will be able to more clearly articulate those requirements (they will have been defined).
3. you will be able to more easily communicate those requirements (because they will be clearly articulated).
4. the rationale will be clear: the requirements will have been identified in a consistent and rational manner (as opposed to being thrown out in an ad hoc manner with little or no substantiation).

As a spin-off, you also might discover something about your requirements and their purposes that you might not have previously appreciated (i.e., not been fully aware of or understood).

Once you have such a requirements list, then you could - for example - give it to the developers of (say) Gmail or InfoSelect or Evernote, or people who might be able to suggest ways of meeting the requirements using the available desktop + cloud technologies.

If your requirements grow or change - as invariably happens - then you update the table to reflect the changes. That way you maintain a current and consistent picture of your requirements and will not have to dream it up (and inadvertently forget some) each time someone asks you.

There are some further - and interesting - points about the requirements list which is probably worth mentioning here:

(a) By taking the steps (as above) to build the list, the user is effectively taking responsibility for defining what it is that they want do (the requirements), and why (purpose), and how important (priority) those requirements are. If the user furthermore maintains an updated list of those requirements, then they are continuing with that responsibility.

(b) It can be seen therefore, from this, that it is not the developer's responsibility to somehow "know" your requirements by some process of magic, or osmosis, or telepathy. Therefore, berating the developer for not building in some feature that would meet your requirements - where you have not communicated them to him/her in the first place - could be regarded as being irrational.

(c) This is not to absolve the developer of the business responsibility for systematically soliciting and gathering user requirements in a similar manner to that above, and for taking note and acting on those requirements. Nor does it absolve the developer of the responsibility for researching and applying the art of what is possible using new technologies (e.g., "cloud" computing) that could be incorporated into the system to better meet the users' evolving (and defined) requirements. Failure to do these things will probably run the very real risk of product obsolescence.