Planning for Mobile Based M&E Systems

Adopting a mobile based M&E system will, for most organisations, be a large scale IT investment. All investment carries risk and for IT projects this unfortunately has proved exceptionally high.

Depending on which study you read failure rates are anywhere between 40% and 70% and certainly high enough for organisations to ask why do such investments fail and what can be done to mitigate such a high risk.

This content follows a very simplified approach to mitigating risk. It serves to illustrate process rather than demonstrate it.

You would not build a house without a plan and you shouldn't attempt to develop custom software without a scope. Either a poor scope, or none whatsoever, is the single most common reason for cost and time overruns in software development. A scope is the single most important tool you can have in developing custom software. From the scope; flows the control of the process, the mock-ups, the specification, the testing and the ultimate system.

A software scope broadly defines the functionality you require from the software. It should not include costs, planning or resource allocation. Essentially is a statement of the overriding problem you want the software to solve and broadly how it will solve it.

The first step should be to define the overriding problem you want your software to solve, what triggered a realisation of this problem and how this aligns to your strategic direction. This will form the goal of your software scope.

So, for example, you may have

‘The 2014-16 Strategic Plan coincides with the full adoption of Results-Based Management (RBM) by the Organization. An internal review shows current data collection methodology and practice lack the integrity to satisfy this approach’.

Setting out the effects of the overriding problem is an important step as it allows you to identify the desired results. This in turn will form the critical success factors you will apply to the project. So, based on the above your effects caused by the overriding problem may be:

• Currently data is collected and stored in dispersed non standardized archives, is census in type, and restricts analysis to a descriptive level inappropriate for RBM.
• Aggregated data sets from different archives rarely correspond and traceability of records to actual beneficiaries is questionable.
• All data is collected by junior staff, working remotely and unsupervised and no formal system of quality control exists to cover this.
• Assembling and compiling these archives for internal and external reports has become the main function of the M&E department.
• Management lack sufficient confidence in aggregated data to carry out analysis.
• Current data is often only compiled and available for analysis on a quarterly basis.
• Current data storage does not meet best practice for data protection.
• Communication is unidirectionally in the organization. Rarely is the resultant information shared or presented diagonally amongst staff.

The best scope in the world is largely meaningless unless it is tied or constrained to the reality of your organisations operating environment. This is particularly important in the development space where the technical assumptions of inexperienced contractors may prove widely ambitious for developing economies.

• The system will work well over poor connectivity < 3Mbps.
• The system will work with poor or no cell coverage.
• The system will work on so called ‘Grey goods’ hardware.
• Application users will not have a high level of fluency in English.
• Application users will not have a high level of computer literacy.

Because most people use software they tend to make assumptions about the feasibility of what can and can’t be done by developers. Most get it wrong and often underestimate a task’s complexity. Setting out your assumptions at the start allows infeasible or impractical expectations to be flagged before you start.

• Existing organization data can be uploaded onto the new system.
• Data entry software can be deployed to both mobile and web without significant recoding.
• Several different languages and their character sets can be stored on the same database.
• The hardware for a mobile system can be purchased 'in country'.

Exclusions and risks are common elements on project planning.

Examples of exclusions could include:

• Developing and implementing changes to HR.
• 'In country' training and support.

Examples of risks may include:

• Current 'in country' mobile network declines in quality.
• Mobile devices are sufficiently robust to survive the working environment.
• Mobile deceive GPS is sufficiently accurate.