TABLE OF CONTENTS
- Comparison with paper-based data collection
- MDC time efficiency considerations
MDC has some clear benefits (fast processing, minimal cleaning, complex question routing etc.), but also has very specific limitations (e.g. it is not very effective for collecting a lot of qualitative data). Although these positive and negative aspects are already well documented within the humanitarian sector in the past, here is a brief summary and comparison with paper-based data collection.
Keep in mind that depending on the context, MDC might not always be the most suitable approach.
The following considerations can help to determine whether the use of MDC can be appropriate:
- Relevance: i.e not relevant for qualitative data collection, not relevant if the sample size is too small and therefore the investment might not be worth the effort …
- Cost associated and time to get familiar with the technique and technology
- Quality: i.e. the likelihood that MDC can help in reducing errors and obtain good data
- Feasibility: i.e. the likelihood that MDC can help us obtain good data given contextual factors such as the security context, availability of suitable data collectors/hardware etc.
- Suitability: i.e. the likelihood that MDC is appropriate to obtain good data from the informants in question. E.g. are there gender-, age-, culture-specific issues that might affect collection through mobile device? Or create mistrust in communities?
Safety: i.e. the extent to which the MDC can help ensuring those involved in data collection do not suffer any negative consequences as a consequence of their participation. E.g. is it possible to ensure informant anonymity and maintain data security when using this method? Will you be raising the visibility of aid staff in an area where this can be an issue?
Comparison with paper-based data collection
Mobile Data Collection is often compared to paper-based data collection in order to highlight its advantages and disadvantages. This visual aims to sum up these aspects :
It is important to mention that 2 main aspects in particular are not covered here, as they can fall either in the advantages or disadvantages depending on the context:
- aspects related to data protection: on the one hand, MDC can improve data security by centralizing data in an online – and password-protected – database with restricted access, thus excluding the risk of paper forms being lost or stolen. On the other hand, by having all the data centralized in one place, it also exacerbates the risk of large volumes of data being compromised if unauthorized users gain access to the server, especially in MDC platforms that are not sufficiently secure. The associated risks should therefore be analyzed based on context: a conflict-affected context with tech-savvy armed groups for instance, is very different from a peaceful rural setting with little chance of data being hacked.
- aspects related to environmental protection (or nuisance): MDC can be seen as avoiding multiple printing of paper forms and therefore supporting an environmental effort. However, the question of the production of the phones, of the associated energy use and of the recycling of the batteries is definitely a thorn in the foot of any promoter of a green approach to data collection.
To go further on the comparison you can see :
- this article from Humans Of Data : Choosing the Right Tool for Data Collection: Paper vs. Digital Tools vs. IVR.
- this manual : Paper-to-mobile data collection: a manual of The U.S. Global Development Lab & FHI 360
And to dig deeper in MDC advantages and inconvenients you can see this article from the World Bank Blogs : Using mobile phones in data collection: Opportunities, issues and challenges.
MDC time efficiency considerations
Let’s have a thorough look at the aspect of time saving . This element is commonly used as one of the strongest arguments for promoting the use of Mobile Data Collection, but is often misunderstood .
The figure below compares the time approximately spent during each step of a full data collection process using MDC versus paper-based data collection.
One always hears that MDC saves time by producing ready-to-share and ready-to-analyze data without the need for double data entry, a very time-consuming step, both in terms of HR and of survey timeline.
However, setting-up a proper Mobile Data Collection implies a longer preparation phase, requiring proper planning. This is particularly the case in the development and testing of forms. Nonetheless, in a quality-oriented approach, the more time you allocate in your tool ahead of its deployment, the less time you will need to spend addressing errors during the stressful deployment phase and the faster you will be able to access high quality results.
In summary, what is important to note is that, although overall the data collection workflow is quicker through the use of MDC, the time gained occurs mostly during and after the data collection; while the preparation phase, if done as it should (i.e. with a strong focus on data quality and analysis) becomes longer.
NOTE: This visual is of course not a one size fits all representation of the situation as every data collection has its own specificities. However, it aims at giving a synthesized vision based on CartONG’s experience of data collection over the last decade.
Keep in mind that some specific features (that sometimes also apply to paper-based data collection) might increase the time for coding a form.
Overview of factors affecting preparation time
While not possible to allocate a fixed amount of time for each of the below factors, each one will extend the amount of time needed to complete the creation of the data collection system, which you might want to cater into your preparation work.
- Multiple Languages – While the addition of multiple languages to a form is not particularly time consuming in itself, the translation can take time if done internally. If done externally it is usually best to create an Excel template where the translated texts can be added. Extra care is needed with different alphabets/writing systems to make sure that mistakes are not made when merging the languages into one form.
- Multiple data entry methods – If a form is designed to be used either on a mobile device or via a webform and the organisation later decides to allow data entry from the other previously unused option this can cause some problems, as the tool behaviours may be different. The form then needs to be fully tested on the two types of interfaces. Sometimes this occurs when data is recorded using only a mobile device but then cleaned or modified via the webform feature of the server.
- Lists of geographic locations – Lists of geographic locations can lead to multiple copies of a form being used in different countries, each with its own set of locations. In forms where there is one long list of locations, there can be performance issues in the filtering of the locations which can take time to fully test. List of locations also tend to change over time creating maintenance tasks.
- Multiple forms combined – When data from one form flows into or joins with data from another form, additional complexities are created for the user and additional guidance often needs to be given via hints and instructions.
- Calculations – Forms which include the calculation of key indicators or metrics, each one based on a range of combinations of responses to multiple previous questions, require lengthy testing as many different scenarios are possible.
- Form details – Of course forms which contain more questions or forms which require more complicated constraints and relevancies will take more time than shorter, simpler forms. The inclusion of lots of visual design features such as text formatting, hyperlinks, images and complex relations between different questions can also add to the complexity.
Warning: You should also pay attention to non-finalised design, this is probably the biggest factor. Try to have the list of questions, the order, the parameters and any form requirements definitively established before you start coding and testing your form. Where there is a request for the form but the requirements for the form are subject to change or are decided on bit by bit, the form development process becomes much more complicated and testing tends to take place multiple times.