![\"\"](\"http:\/\/edutechdebate.org\/wp-content\/uploads\/2011\/05\/EMIS.jpg\" "\\"EMIS\\"")
<\/center><\/p>\nMany of the international projects in which the author has been involved have been funder through the large international donors. Typically this involvement has been consultancy on the development of the requirements specification for a computer system. This is then followed by a procurement exercise which is usually a fairly lengthy exercise. This would then be followed by a development and or configuration exercise before delivery and acceptance can commence.<\/p>\n
This approach is fundamentally flawed.<\/b><\/p>\n
Most users find it difficult to fully grasp a paper based system specification. This is equally true whether the user is based in Africa, New York or London. The overall process is necessarily time consuming. Given that quite often the development of the EMIS is coinciding with the introduction of radical changes to the Education System itself, it is quite likely that the requirements will themselves have changed by the time the EMIS is implemented. This approach to software procurement is likely to lead to a solution that does not represent good value for money. Again this is not a problem that is restricted to Africa, nor indeed to EMIS. The author has first hand experience of the failure of a large health system in the UK that has failed to deliver what was promised.<\/p>\n
There is also a problem that appears to arise from the nature of the way that funding is delivered \u2013 where there is a single budget line for \u2018EMIS\u2019. This leads to a desire to include \u2018everything\u2019 in the specification. This in turn will lead to a longer specification \/ development \/ installation cycle which in turn further increases the risk that the requirements on the ground will have changed before the system is delivered. <\/p>\n
A new problem that the author is starting to see relates to the technology being proposed. Many advisors will argue that \u2018current practice\u2019 would (for example) expect that delivery relies upon access to the internet and on high speed communications. This often overlooks technical difficulties on the ground or upon unreasonable expectations of what will be delivered \u2018in the future\u2019.<\/p>\n
Finally, there is often a sustainability problem, in that the recipient is often unable to afford to pay for the necessary support for the system. Donors will agree to cover the capital expense of the system development but will not agree to cover the total life cost of a system.<\/p>\n
What are the solutions?<\/b><\/p>\n
An EMIS system will typically consist of a database and application software. However, attention should also be given to the users<\/i> of the system. Indeed the author would argue that the establishment of an EMIS Home Unit should be the first priority before any specification or development of an EMIS should commence. This must be staffed by people with a wide knowledge base. They must fully understand the education system (and be aware of the changes proposed to the education system that will probably be happening in parallel with the EMIS development). <\/p>\n
There should also be staff who have technical (IT) skills. These staff must be able to make decisions on behalf of the Ministry of Education. Indeed they must be empowered. In my experience, Ministries have paid lip-service to this requirement whilst not in reality grasped the importance and significance of this step. EMIS staff have not been relieved of other duties (or at least supported) leaving them to continue with their current duties whilst also helping with the design of the new system.<\/p>\n
RAD (Rapid Application Development) technology offers an alternative approach to systems design and development. Rapid Application Development was a response to non-agile processes developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method. One problem with previous methodologies was that applications took so long to build that requirements had changed before the system was complete, resulting in inadequate or even unusable systems. Another problem was the assumption that a methodical requirements analysis phase alone would identify all the critical requirements. Ample evidence attests to the fact that this is seldom the case, even for projects with highly experienced professionals at all levels.<\/p>\n
The developer and the end user can sit together and look at actual screen and report layouts. This will give the end user a much better feel for what will (and will NOT!) work. Core representatives can be left with working prototypes for demonstration to the broader user community in order to get a consensus about the requirements. In this model, the development of the specification is taking place in conjunction with the system and database development. Of course, this changes the nature of consultancy that is being delivered by donors. Now the consultants must be able to provide classical needs analysis but must also be able to develop and or configure computer software.<\/p>\n
There is then the issue of the scale of the developments. Rather than specifying a complex system in a single shot that attempts to deliver everything to everybody, a better approach is to deliver components in manageable sections. Of course, these must be scheduled in a way that provides meaningful functionality to the users (at least a sub-set of all the users). As well as benefitting the users, this has the benefit that donors see tangible results. These need not mean that a fully functional system cannot be delivered in this way, it simply means that users (and donors) are seeing benefits along the way. Of course this may mean that it becomes harder for the donor to pre-define a budgetary figure for application development. <\/p>\n
This approach is now being adopted in the development of a Tertiary EMIS system in Botswana. Although the first phase is yet to be completed (and therefore the results cannot yet be demonstrated) it is the belief of the author that this will give a better experience for the system users and a more relevant system.<\/p>\n