Life should not be like a box of chocolates when selecting an MIS for your program’s M&E

Time for user requirements to get respect

I’ve previously written about the benefits of a management information system (MIS) for the purposes of monitoring and evaluation (M&E) programs/projects aimed at (co-)creating positive social change as well as the key factors to consider in the decision-making around the adoption an MIS.

In part 2 of the above-mentioned article, I talked about the critical first steps to take towards establishing an MIS that is both practical and effective and that aligns with the program/project’s objective of creating positive social impact.

In this article, I’d like to underscore something that may not have been sufficiently emphasized in the previous articles:

• the central importance of user requirements.

The bottom line is that user requirements are required before selecting or developing an MIS using the criteria outlined in part 2 of the previous 2-part series.

Let’s explore the ‘why’, ‘what’, and ‘how’ of those required requirements. (I know, using the same root word four times in two sentences is probably to be frowned upon…but forgive me as it truly is the most appropriate word in this context!)

Why are user requirements required?

A recurring theme across the elements of the MIS introduced in part 1 of the aforementioned 2-part article series – and explicitly highlighted in part 2 – is user requirements. It is of utmost importance that user requirements be specified before proceeding to select an off-the-shelf MIS or having a bespoke system developed.

Why?

For the simple reason that if you don’t articulate what you want, then you’re not likely to get what you want. I love every single line in the movie Forrest Gump, but never knowing what you’re gonna get when it comes to the MIS ‘box of chocolates’ just won’t do.

The documentation of user requirements: the URS/URD, who writes it, and what to include

The UR-what?

The term for the document in which user requirements are defined is called the user requirements specification (URS) or user requirements document (URD). The URS/URD provides a high-level description of the users’ expectations of the MIS, with emphasis on system parameters.

Who writes the URS/URD?

Given what the URS/URD provides, it is thus best written by the system owner (that is, managers of the program for which the MIS is being developed) and end-users (often program team members at global and/or country levels) as they are best placed to know the expectations – after all, those expectations are theirs.

It is perfectly fine to start out with a description of the requirements in non-technical layperson terms, which takes into consideration the non-technical composition of the team writing the initial draft of the URS/URD.

However, if desired, the program team also may want to invite input from a qualified MIS/software development expert as a means of assuring quality. This person could be a competent member of the program’s operations team, for example, or an external expert (but, to avoid conflict of interest, not one who might later bid to furnish the MIS). Note: This person should not provide input into the user requirements themselves, unless s/he will also be a user of the eventual system; s/he should also ideally refrain from curtailing the expression of user expectations (e.g., based on their knowledge of the prevailing technological capabilities) as this could create a situation in which the final version of the URS/URD is not an accurate representation of the users’ actual requirements. (Later on down the line, this person could possibly also draft the technical system requirements – including technical architecture, technical component description, system security, and more – that will be needed.)

What to include in the URS/URD

The URS or URD should ideally include:

• background information on the program and the reason why an MIS is being sought, including key concepts and key stakeholders;
• a description of the scope and key objectives of the system (“to assist with writing [the objective], ask the following questions: ‘What am I trying to achieve?’ and ‘What problems will this product solve?’” (Intersys UK 2021);
• documentation of the operational and functional requirements of the system, including its major functions, user groups, interfaces (user views at each point), and intended system integrations;
• the system’s data requirements (i.e., a description of the type of information that the system should be able to process);
• the security requirements that the system should meet;
• the system’s life cycle, i.e., how users will ideally be familiarized with/trained on the system and how it will be maintained; and
• the timeframe for the MIS to be in place.

How to draft the URS/URD: two key best practices

Unique numbering of each user requirement

It is best practice to number each individual requirement and to prioritize each one, at a minimum in terms of “must-have” and “nice-to-have”.

Clarity, comprehensiveness, concision

The most important overarching criterion for the URS is that it be unambiguous, comprehensive, and concise. A poorly-written URS with vague requirements and ambiguous language is like a poorly-written terms of reference (ToR) – it can lead to confusion and disappointment, with consequences on the timeliness of the system’s delivery and on its effectiveness, both of which have follow-on impacts on budget.

To avoid such issues:

• ensure that the terms used are specific and measurable (i.e., rather than employing “subjective terms such as ‘easy’ or ‘faster’”, state requirements in ways than “can be confirmed by examination, test, or demonstration” and/or quantified (Intersys UK 2021)):
• include supporting documents (e.g.: “images, sketches or mock-ups of concepts central to the project, such as user interfaces; examples of software and systems that already fulfil some of the requirements you’d like incorporated…[and] end-user personas” (Intersys UK 2021)).

Conclusion – and then it’s over to you!

Once the URS document has been finalized and approved, the next critical part of the MIS selection task begins:

• applying criteria to help choose between the available MIS options.

The five criteria that I recommend applying in the MIS selection process include the following:

1. features and functionality;
2. user interface;
3. usability;
4. integrations; and
5. value-for-money.

Each of these selection criteria is discussed, in turn, in part 2 of the 2-part article series on the topic of MISes for M&E.

The criteria could be applied to all MIS options that might be available; however, to maximize efficiency, an initial shortlist could be developed first, a shortlist based, for example, on word-of-mouth, social proof, possibly even a budget ceiling (but one that considers the true value of adopting an MIS). The criteria would then be applied to this shortlist, which typically includes off-the-shelf systems/platforms though certain circumstances may necessitate the consideration of developing or extending a bespoke system. The selection criteria should also be applied to whatever the prevailing system might be – yes, even if that ‘system’ is just an Excel spreadsheet! – so that it, too, can be objectively assessed for fitness of purpose.

Resources to guide the application of these criteria are exclusively available to ‘Reimagine M&E: The Workshop’ members. If you too would like to benefit from this and other M&E resources, consider becoming a member! Learn more and apply here.

References:

Intersys UK (2021, March 24). This is How to Write a Foolproof User Requirements Specification. Blog article. Available at: https://intersys.co.uk/2021/03/24/this-is-how-to-write-a-foolproof-user-requirements-specification/ (last accessed 25 September 2023).

Photo credit:

Monique Carrati on Unsplash

Suggestion for how to cite this article (using APA 7 style):

Shejavali, K. (2023, October 2). Life should not be like a box of chocolates when selecting an MIS for your program’s M&E: user requirements are required. Blog post. RM3 Consulting. Available at: https://rm3resources.com/blog/life-not-box-of-chocolates-MIS-user-requirements-are-required (accessed: [insert the date that you last accessed this article at the link provided]).