Ramesh S Arunachalam
Rural Finance Practitioner
The last few years have seen a lot of technology pilots and especially, to deliver (retail) financial services to low income people. And this seems to be the increasing trend in Indian micro-finance as well. While few of these have succeeded and scaled up, some have remained, at best, pilots and many have, in fact, even disappeared – so much so that, one industry observer remarked that the use of technology is sort of hyperbole…the search for a low cost (affordable) retail technology model still continues, despite some successes[ii]…
While I strongly feel that the potential to use and exploit technology does exist, I do however also believe that, such technology pilots must be evaluated in a dispassionate and objective manner – so that course corrections are possible and something meaningful emerges from the IT pilot. And attention to several critical aspects is required for such a dispassionate evaluation. Accordingly, this post highlights several generic lessons regarding IT pilots (based on experience) and identifies critical factors for their objective evaluation
“Too Much IT Focus in Pilot”: First, IT pilot projects could focus too much on the IT aspect whilst perhaps missing the opportunity to learn about the extent to which the product/service meets the needs of the target customer, or the sales process. And this typically could result in the point of sale becoming merely a point of presence. In such instances, it can be argued that the right balance has not been established between the activities of marketing and IT development at an early stage – and changing this during, or immediately after the pilot requires strong and involved leadership and sometimes may even be impossible.
Therefore, it seems appropriate to ask the following questions:
1. Does the pilot have too much IT focus?
2. If yes, are senior management and pilot amenable to (any required) on-course corrections?
3. Does the pilot benefit from involved leadership of the senior management?
4. Will change management therefore be easy and effective?
There are two important lessons that I derive from experience and these are given below:
Lesson # 1: Balanced focus on several aspects, a critical requirement in IT pilot-testing: To derive maximum benefits, pilots that attempt to test and deliver innovative technology for delivering financial services to the poor must pay equal attention to all (other) aspects in the business model ranging from customer preferences and demand to product concept/design, delivery channels, pricing, post sales service/follow-up. Disproportionate attention to these various factors could result in distorting (or skewing) the results of the pilot test and thereby, may affect success at rollout. For example, one may conclude that the product is not liked by the customers, whereas, in fact, the product may be appropriate and liked but the REAL problem could be with staff, delivery channels and the like. Hence, it is imperative that: (1) evaluations of pilots focus on all aspects required for taking the product/service to the customers; and (2) more importantly, pilots themselves are handled in a balanced manner with a focus on a various functional aspects required for successful delivery of an appropriate product/service to the customers
Lesson # 2: To facilitate effective change management (if required), senior management must show proactive and involved leadership: Based on feedback received during the pilot, substantive (and sometimes, even far reaching) changes may have to be made subsequently – to pilot design and/or implementation. Without question, strong and involved leadership and senior management commitment is required to effect and manage these (unexpected) changes in a successful manner. Lack of involved leadership, in responding to this need for change can have (negative) impact on the final results and experience has shown that this lack of involved leadership could result in chaos and confusion, ultimately leading to failure. This is especially true for technology (IT) pilots where a significant cost is already incurred during the pilot.
“Too Close to Pilot to Evaluate it Objectively”: Second, it therefore follows that IT pilot tests must be conducted in an very open-minded fashion - so that data and reports received can be analysed in a way that identifies the key factors of success or failure. The project managers who have developed the product/service from the outset are sometimes too "close" to the product/service to be fully objective and will surely benefit from additional dispassionate analysis by colleagues with broad technical and commercial skills.
Therefore, it seems appropriate to ask the following questions:
5. Has the pilot been conducted in an open fashion or is it closely guarded by a select few?
6. Does the pilot have a team leader who believes in objective analysis of the pilot?
7. Are colleagues (with distance from the pilot) encouraged to analyse the working of the pilot and provide feedback?
There are two important lessons that I derive from experience and these are given below:
Lesson # 3: Role of champions in objective evaluation of IT pilots: Champions or team leaders of IT pilots must play a lead role in ensuring that the pilots results are evaluated with openness and objectivity – sometimes, closeness to the pilot may prevent such a candid analysis and under such circumstances, it may be better to have ‘neutral’ outsiders evaluate the effectiveness of the pilot
Lesson # 4: Dispassionate Evaluation of IT Pilots, A Mandatory Requirement: IT Pilots must be evaluated in an objective manner with ‘distance’ from the concept being tested, especially in terms of people doing the evaluation. Dispassionate analysis is the key and it needs to be backed by playing “devil’s” advocate that could really help in questioning each and every aspect in a candid and analytical manner. Such an approach will help in ascertaining the real causes of problems and help in forging effective and quick solutions. For example, poor implementation may mask good product design and get the evaluator to conclude that the product design is inappropriate for the customers whereas, in fact, the product design may be appropriate but the delivery channel or staff could be the real problem. Such a wrong analysis may result in (erroneous) changes being made to the product design whereas in reality poor implementation could have been the culprit. As the matrix below identifies, there are several possibilities and hence, analysis of pilot results should be methodical, analytical and objective to avoid such problems
“Pilots Mirroring Real World Scale and Situation”: Thirdly, as the FDCF and other experiences clearly illustrate, the real benefits of piloting IT systems lie in doing so in almost real life environments. This implies that projects have to be implemented at sufficient scale for the results obtained to be invaluable - because of the closeness to the real world in terms of operational and environmental (regulatory) similarity as well as size of operations. Hence, especially, the scaling up of such projects should not be a problem as problems encountered, successes met and other aspects unearthed can be taken as very close to what could occur in a real ‘real world situation’ as opposed to lab ‘real world situation’.
Therefore, it seems appropriate to ask the following questions:
8. Has the pilot been conducted at a scale similar to real world operations?
9. Has the piloting been done in a real world like situation – both from an operational and environmental (regulatory) sense?
10. Is the pilot in accordance with existing regulatory framework and does it have the basic adaptability to respond and change in accordance with future/likely regulatory changes?
There are two important lessons that I derive from experience and these are given below:
Lesson # 5: Piloting Must Be at Scale and Simulating Real World Situation: There are two issues here: a) piloting must be done at a scale reflective of the real world situation; and b) piloting must be done at a level that would force regulatory authorities to have a serious look at the pilot and its impact. When pilots are not at scale and do not mirror the real world scenario, there are many factors that could result in the “false” success of the pilot, which may not be possible in the real world situation. Likewise, the converse could also be true whereby, certain factors that require minimum scale may not seem viable during a very small-scale pilot
Lesson # 6: IT Pilots Must Be Capable of Adapting to Regulatory Changes: Sometimes, the regulatory environment may force a pilot to change or adapt the design and this may have an impact. This is more true for IT pilots as technological changes/challenges are frequently occurring. IT Pilots should therefore have the inherent flexibility in such cases to be able to adapt quickly and effectively respond to such unexpected changes in the regulatory environment. This response should not be limited to the design aspects per se but must also relate to outcomes. Hence, pilots should take a complete view to readjust the strategy, implementation and results as otherwise, the pilot would be out of tune (out of fit) with the external environment.
While without question, the search for a low cost retail model for delivering various financial services to low income people should continue, such pilots, in order to be really useful, need to: 1) Be balanced in approach and not too narrowly focused on IT aspects; 2) Be flexible and have involved leadership of senior management so that change, if required, can be managed effectively; 3) Use champions to ensure an objective and dispassionate evaluation of the pilots; 4) Be conducted at scale and simulate the real world situation, both operationally and in terms of other environmental aspects; and 5) Be adaptable to meet changing regulatory requirements, as and when required…
Cheers
Have a Nice Day
[i] I would like to gratefully acknowledge the work of DFID FDCF, ENTERPLAN (COFFEE), MicroSave and several others, who papers and resources have given me valuable insights. Parts of the above post have been adapted from the writings of this author (Ramesh S Arunachalam) and others for the above organizations. I would also like to acknowledge the following paper from which a lot of ideas have been used - Arunachalam Ramesh S (2008c) “Microfinance and Technology – Critical Issues, Lessons and Future Implications”, Paper first written for the Microfinance India Conference, Oct 9 – 10th, 2007 New Delhi and subsequently revised significantly and published as part of the CORDAID Research Series, Netherlands
No comments:
Post a Comment