Information systems development for healthcare in Africa: The INDEHELA-Methods project

Transcription

1 Paper to be presented in the 3rd International Working Conference on Health Informatics in Africa, HELINA 99, 29 November 1 December 1999, Harare, Zimbabwe. Submitted on 10 October Information systems development for healthcare in Africa: The INDEHELA-Methods project Abstract H. Abimbola Soriyan, Obafemi Awolowo University, Nigeria Mikko J. Korpela, University of Kuopio, Finland Anja S. Mursu, University of Jyväskylä, Finland Kimba Kailou, Obafemi Awolowo University, Nigeria Karen C. Olufokunbi, Obafemi Awolowo University, Nigeria Appropriate software packages for African hospitals and health centres cannot be found off the shelf they must be developed locally. To be properly equipped to provide healthcare institutions in Africa with appropriate information systems, local systems developers need Information Systems Development (ISD) methods and education that is adjusted to the socio-economic and technological context in question. The INDEHELA-Methods project (Methods for Informatics Development for Health in Africa) by the Obafemi Awolowo University, Nigeria, and University of Kuopio, Finland, is to develop in such a Made-in-Nigeria ISD methodology. The research design has three inputs: (1) literature review of relevant ISD methodologies globally; (2) theoretical analysis of the special requirements in Africa and Nigeria; (3) a survey about the existing practice and problems among Nigerian software companies. The inputs are merged together to an adapted methodology which will be tested and further developed in an action research manner. Resulting from the research so far, a methodology Made in Nigeria for Nigeria should be a portfolio of methods addressing the following issues:- 1. Project planning and management 2. Requirements analysis 3. Risk analysis, planning for sustainability and ensuring a positive socio-economic impact 4. Grand design (designing the main functionality of an information system) 5. Technical implementation 6. Organisational implementation (putting IT into use) 7. Long-term support This paper summarises the first outline of the ISD methodology resulting from the project. 1. Background The need for an African Information Society has been widely recognised in recent years by development agencies and governments alike. In pragmatic terms this high-flying slogan means that Information Technology (IT) is now seen as one of the key ingredients in accelerating socio-economic development and in narrowing the gap between Africa and the industrialised countries. Since healthcare is one of the highest-priority sectors for socio-economic development, this implies that the effectiveness and efficiency of African healthcare institutions, too, should be enhanced by introducing appropriate healthcare information systems. However, appropriate software packages for

2 Soriyan et al., Information Systems Development for Health in Africa 2 African hospitals and health centres cannot be found off the shelf. The requirements are too different for an African hospital to be able to benefit from an American or European hospital application without major adjustment, and the situation is even more problematic in primary healthcare. Appropriate information systems for African healthcare must thus be developed locally, even if a foreign package can be used as a starting point (cf. Heeks, 1999 a). However, to be properly equipped to provide healthcare institutions in Africa with appropriate information systems, local systems developers need Information Systems Development (ISD) methods and education that is adjusted to the socioeconomic and technological context in question (Avgerou, 1996; Waema, 1996). A distinction must be made between a software product (application package) and an information system (IS). The latter refers to the information processing activities in an organisation which may or may not be facilitated by modern information technology i.e., an IS is a social system including some technological elements, IT in use. A respective distinction must be made between Software Engineering which deals with the technical construction of software products, and ISD which deals with how to serve organisational purposes by means of software products. During the system lifecycle, the emphasis between ISD (the white parts in Figure 1) and Software Engineering (the grey parts in Figure 1) varies. If organisational purposes can be served by pre-existing software products, ISD can proceed from requirements analysis directly to putting IT into use, but usually some technical implementation work is needed as well. (Korpela et al., forthcoming c) IT in use: maintenance, assessment Early design phase : problem identification, needs analysis, requirements analysis, grand design Late design phase : procurement, deployment, integration, adaptation, introduction, training Software Engineering: Technical construction of software products Figure 1: ISD and Software Engineering in the system lifecycle (Korpela et al., forthcoming c). The more technical tasks in the system lifecycle tend to be more universal between socio-economic and cultural contexts, while the more social tasks of course tend to be effected more by the specific organisational, cultural, infrastructural, economic and political setting in which ISD takes place (Korpela et al., forthcoming a). When searching for ISD methods and education adjusted to the needs of African systems developers, the emphasis must thus be on the most social parts of the work, while C programming is C programming everywhere. 2. Objective The Department of Computer Science and Engineering of the Obafemi Awolowo University, Ile-Ife, Nigeria, and the Computing Centre of the University of Kuopio, Finland, established the INDEHELA- -Methods project (Methods for Informatics Development for Health in Africa) to develop a Made-in- Nigeria ISD methodology for Nigerian systems practitioners, with special emphasis on the requirements of the healthcare sector. The project started in 1998 and is intended to finish by the end

3 Soriyan et al., Information Systems Development for Health in Africa 3 of The resulting ISD methods, techniques, work practices and educational materials should comply with the following criteria.?? The methods must address the actual day-to-day needs of Nigerian systems developers; i.e., the methodological development must not be based on what the researchers think that the practitioners need, but on what the practitioners themselves see as areas of improvement.?? The methods must incorporate the latest results of the international ISD research, to the extent that the findings and recommendations generated in industrialised countries are found relevant or can be adjusted to the requirements of Nigerian systems practitioners. In other words, Made-in-Nigeria ISD methods does not mean second-class or second-hand methods, but the best methods for the specific task in question ISD in Nigeria.?? The methods must pay special attention to issues which are more pronounced in the severely constrained context of Nigerian healthcare than in the more affluent societies for which the existing ISD methodologies are tailored. Such issues may include the sustainability and affordability of the resulting information systems; the socio-economic justification of the resulting systems, which in healthcare means that the systems must have a positive impact on public health; community involvement in primary healthcare information systems design; and so on.?? Although emphasis must be on the more social parts of the system lifecycle, the methodological portfolio must include a sample Rapid Application Development (RAD) toolkit for the efficient technical implementation of the required software products.?? The methods and techniques must not remain theoretical recommendations by researchers, but be tested in practical systems development in healthcare.?? The methods and techniques must be documented as Lecture Notes and technical manuals, so that they can be adopted into university education and on-the-job training of computer professionals in Nigeria, and adapted and adjusted by colleagues in other African countries if found practicable. 3. Research methodology Since there is no prior empirical research on how ISD is practised in Nigeria and what are the problems perceived by the practitioners, the study must proceed from an interpretative, knowledgebuilding research approach to a constructive one (Orlikowski and Baroudi, 1991; Järvinen, 1999). Correspondingly, the research design has three inputs followed by a constructive phase (Figure 2; Korpela et al., forthcoming a): Literature review of relevant methods, techniques and practices (globally) Theoretical analysis of special requirements in Nigeria and Africa Survey and case studies of the existing practice and problems in Nigeria Made-in-Nigeria systems development methodology Action research = experimentation in host projects Diffusion of results to practitioners in Nigeria and Africa Figure 2: The overall research design (Korpela et al., forthcoming a). (1) Relevant ISD methods, techniques and practices developed in other countries must be identified

4 Soriyan et al., Information Systems Development for Health in Africa 4 through a literature review. Relevant methods can also be found in related other fields in addition to ISD for instance, in work research, organisational studies, primary healthcare projects, international development projects, etc. Empirical studies on ISD practice in other countries, although regrettably rare, must be studied to acquire guidance concerning the research methodology (e.g., Kensing et al., 1998). (2) Theoretical analysis must be applied on identifying areas where the requirements for and constraints of ISD in Nigeria and in Africa in general may differ significantly from those of the industrialised countries. The development of adjusted ISD methods and techniques can then be focused mainly on these areas. (3) An overall view of the existing practice and problems in ISD in Nigeria can be achieved through an interview survey among Nigerian software companies. The overall view must be supplemented by descriptive in-depth case studies in a few companies and projects. (4) The three inputs are merged together to an adapted methodology, a portfolio of methods and techniques. Initially the methodology will be just a prototype which must be tested and further developed through action research (Avison et al., 1999) in one or two real life host projects. The most accessible testing ground for the emerging methodology will be the MINPHIS (Made-in- Nigeria Primary Healthcare and Hospital Information System) project of the same universities, presented in other HELINA 99 papers. The methodology will also be tested in Systems Analysis courses and final year projects of Computer Science students in the university. Later on the methodology should be tested in a software company by systems practitioners, and further developed again according to the feedback received. Main research questions: Risk factors? Software development project IT company or department Methods, techniques, practices? Information system development IT user organisation Sustainability? Information technology in use Impact? IT users clients Impact on: Society Organisations Individuals

5 Soriyan et al., Information Systems Development for Health in Africa 5 Figure 3: The research questions in the survey and the case studies (Mursu et al., 1999). By mid-1999 we have conducted the first part of the survey interviews among 36 software project managers in eleven software companies, which can be regarded as a representative sample of the industry since only a minority of the computer companies have software and IS development activities. The first part of the survey deals narrowly with risk factors in software projects (Figure 3; Mursu et al., 1999), while the next parts will expand the scope to ISD practice in the broader sense, the sustainability of IT-in-use in user organisations, and the socio-economic impact of the information systems developed. The survey is complemented by in-depth interviews in three different software companies starting from November Results Initial results from the literature review and the theoretical parts (Korpela et al., forthcoming a; Mursu et al., forthcoming), methodological issues and first results of the survey (Mursu et al., 1999; Korpela et al., forthcoming c), as well as the results of two exploratory action research experiments (Korpela et al., 1998; Korpela et al., forthcoming b) have been published in more detail elsewhere. In this paper we summarise the findings so far into a first outline of the ISD methodology which should result from the project. The outline is not yet an empirically proved end result of the study, but a theoretically and empirically informed report on which issues we currently consider to be required in the methodology. The purpose of the outcome is thus to start an iterative process in which ISD researchers and practitioners in Nigeria, in other African countries and globally can comment on the preliminary results and help us improve them in the future phases. Resulting from the research so far, we think that a methodology Made in Nigeria for Nigeria should be a portfolio of methods addressing the following issues:- 1. Project planning and management 2. Requirements analysis 3. Risk analysis, planning for sustainability and ensuring a positive socio-economic impact 4. Grand design (designing the main functionality of an information system) 5. Technical implementation 6. Organisational implementation (putting IT into use) 7. Long-term support Requirements analysis and risk analysis are the areas in which we have been able to conduct some more profound work so far. In the rest of this section, we will elaborate on these two areas and discuss the other areas more briefly. 4.1 Project planning and management methods In empirical studies, project planning and management has repeatedly been found one of the most important subtasks of ISD work, and one which is not given respective emphasis during the university education of systems developers (e.g., Kensing et al., 1998). The first results of our survey, although not conclusive, suggest that Nigeria is no exception. However, project planning and management is a prime example of a research topic which cannot be

6 Soriyan et al., Information Systems Development for Health in Africa 6 studied in depth by surveys. Statistics on responses to questions of the type How much problem there is with project management in your company (1=very little, 5=very much)? How relevant is the project management education you received during your formal education (1=highly irrelevant, 5=highly relevant? can indicate whether this is a high-priority issue or not. However, to find out what kind of problems there are and whether they are specific to the Nigerian context or not, we need to proceed to more in-depth case studies of actual projects. The methodological portfolio of Nigerian systems developers must no doubt contain some principles, tried practices and techniques of project planning and management. The bulk of them can probably be adopted from western literature. It requires further empirical research to decide if there is a major need for local adaptation or for some additions which have not been sufficiently covered by western literature. 4.2 Methods for requirements analysis Requirements analysis refers to the earliest part of systems development, when the need for systematic information processing and possibly for IT also is studied and assessed. If a need is identified and an IT-based solution found feasible, requirements analysis leads into more or less formal specifications of what kind of hardware and software needs to be purchased or developed to facilitate the need. Although requirements analysis is generally the first action to be taken in an ISD undertaking, it is often necessary to return to re-analysing the requirements again when something changes or some new understanding emerges during ISD. Requirements analysis is a fuzzy task and varies highly according to the setting. When the objective is to develop packaged software for global mass markets, requirements analysis can be quite tedious and its outcome can be quite formal and technical specifications. However, in small and heterogeneous markets typical in Nigeria, systems developers should be able to quickly and flexibly grasp the peculiar stakeholders, objectives, possibilities and constraints etc. in each new setting. Furthermore, the customers in Nigeria are on average relatively less knowledgeable about IT and its potential than in industrialised countries. Early on during the project we therefore started to search for quick and flexible but scientifically sound techniques for systems developers to grasp new work settings. Through literature survey we identified a work development methodology based on Activity Theory, and modified it further to suit our needs. In May 1998 we conducted a small experiment in using Activity Analysis and Development in studying the needs for a primary healthcare information system in a teaching health centre in Ile-Ife, Nigeria. The theoretical basis and the experiment are presented in more detail elsewhere (Korpela et al., forthcoming b). The experiment was highly encouraging and we are including a further modified version of activity analysis as an early requirements analysis technique in our portfolio. Basically, in activity analysis the system developer first tries to identify the collective work activity which the new information system is to directly facilitate (e.g., keeping medical records in a health centre). Then he or she helps representatives of that activity (medical records officers) identify the outcome, process, actors, means, and other main elements of that activity, using a checklist which can be presented as a graphic model. Figure 4 presents an abstract version of the model in practice the model should better be illustrated by replacing circles and boxes by pictures of real people, tools, etc. (Korpela, 1999 b)

7 Soriyan et al., Information Systems Development for Health in Africa 7 Mode of operation Collective actor: group or team Means of coordination and communication: division of work, rules, etc. Actors, subjects Means of work, instruments, facilities Work process: Object Outcome Elements of a work activity Figure 4: The elements of a collective work activity (Korpela et al., forthcoming b). The scope of the analysis is then enlarged by studying for whom are the outcomes of the central activity intended (e.g., to doctors, to managers) and for what kind of an activity by those people. These people should also be involved in the analysis to some extent. Likewise, it is analysed who produces and in what kind of activities the tools, objects, actors, rules, etc. required in the central activity. Another checklist is used in identifying these networks of supporting and supported activities, presented in an abstract form in Figure 5. Besides the activities, it is useful to identify which organisational boundaries exist between them. (Korpela, 1999 b) In the final step, the system developer and the actors of the activities to be facilitated (the would-be users as well as indirect beneficiaries ) move from analysis to activity development by asking where in the central activity or in the network pieces do not fit together well i.e., where there is need for improvement. A historical perspective and the future workshop technique can be used. During this step the participants can identify the need for some new information processing or technology, but also the need for some educational intervention, organisational change, or the like. (Korpela, 1999 b)

8 Soriyan et al., Information Systems Development for Health in Africa 8 Producing or supporting activities > > Supported or object activities Organisation under a common management Management activity Rules, etc. Actors Means Object Outcome Figure 5: Activity networks as an abstract model (Korpela et al., forthcoming b). Requirements analysis in the sense used here results in a vision of the future which is shared by all the stakeholders a common roadmap and an outline of the technical and non-technical tasks ahead, not a detailed specification of a software product yet. It was indicated above that not only the direct users of the would-be system are to be involved, but the indirect beneficiaries also i.e., the users clients who are supposed to be better served by the users when the latter have the new system. In healthcare this ultimately means the communities served by the healthcare facilities in question. Therefore we arranged another exploratory experiment in July 1996 in community involvement in requirements analysis for primary healthcare information management (Korpela et al., 1998). Without going into the details we stress that it is possible, important and highly useful, but not an unproblematic task, to involve representatives of local communities in the design process. 4.3 Methods for risk analysis, sustainability and a positive socio-economic impact Information system development is a complex and difficult task to manage. Many times software projects end in failure (Keil et al., 1998) or the delivered technical system does not have a significant positive impact on the performance of the organisation, or the equipment is under-utilised or even abandoned (Odedra, 1992). Risk management has been found to be an important part of the success of the system development process. Most analyses of software disaster projects have indicated that if the high-risk elements had been identified and resolved in time, the problems would have been avoided or considerably reduced (Boehm, 1989; Charette, 1989; Ropponen et al., 1997). Software project risk can be defined

9 Soriyan et al., Information Systems Development for Health in Africa 9 according to Barki et al. (1993) as a project uncertainty associated with the magnitude of potential loss due to a project failure. In western literature, failures in system development usually refer to cost overruns, project delays, and unmet user needs in software production projects (Barki et al., 1993). However, in Africa the understanding of success or failure in ISD has a broader meaning (Waema, 1996), and the scope of risk analysis should be expanded from software projects only to information systems that is IT in use in a wider and longer-term perspective. The magnitude of constraints in Africa makes the sustainability of information systems a major issue. Besides software project risk factors, the emphasis in system development should be in factors that promote useful, sustainable applications and in such risk factors that threaten the long-term usability of IT. Risk Category Source of Risk, Nature of Risk 0. Socio-Economic Context Broader Context: Condition of the political environment 1. Corporate Environment Immediate Environment: Changes in the business environment or poor alignment of the system with the organisational culture. 2. Sponsorship/Ownership Mandate: Lack of mandate for the project manager to execute the project plan. Lack of trust or poor relationships with the owners of the system. 3. Relationship Management User Relationships : Lack of trust and inadequate user involvement. Unclear roles and expectations among users or other stakeholders. 4. Project Management Management: Poor or inefficient management strategy and execution. 5. Scope System Scope: Unclear, changing or partial understanding of the system scope and mission. 6. Requirements Requirements: Inadequate or poor management of system requirements; poor validation of system requirements. 7. Funding Resource management: Too little or badly estimated resources for system development. 8. Scheduling Resource control: Poor management of resource consumption and needs. Poor timing. 9. Development Process Process: Inappropriate or lacking process approach. 10. Personnel Skills: Inadequate personnel skills in development and process management. 11. Staffing Staffing: Changes in personnel or staffing levels, unavailability of key personnel resources. 12. Technology Technology: Inadequate understanding of the chosen technology. 13. External Dependencies Development environment: Poor management or control over dependencies with external agents. 14. Planning Planning: No interest or inadequate skills to plan the project. Table 1: Risk categories. In order to manage risks in the system development process, one has to know the pertinent risk factors. One popular and easy method for identifying risk factors is the use of checklists. The first phase of our Delphi study among Nigerian software experts resulted in a list of risk factors including 72 items, combining factors identified by experts from Nigeria, Hong Kong, the United States and Finland. It is

10 Soriyan et al., Information Systems Development for Health in Africa 10 an up-to-date checklist that can be used in software project management when assessing project risks. However, this kind of a list is never complete and it can be too cumbersome and complicated to be used in practice because of its size (Schmidt et al., 1997). So the list has been categorised into a more manageable size of 15 risk categories (Table 1) modified from Schmidt et al. (1997). One useful and even more simple categorisation of risks is presented in Figure 6 (Keil et al., 1998). This categorisation is based on studies conducted in Hong Kong, the United States and Finland the picture may change in Nigeria when Nigerian experts will assess the relative importance of risk factors in the future phases of our Delphi study. Anyway, the categories are useful when assessing possible risks in software development projects. Perceived Relative Importance of Risk High Moderate 1 Customer Mandate 4 Environment 2 Scope and Requirements 3 Execution Low High Perceived Level of Control Figure 6: A risk categorisation framework. Quadrant 1 (Customer Mandate) includes the commitment of both senior management and those who will actually use the system. This category requires risk mitigation strategies that create and maintain good relationships with customers and promote customer commitment to project. The risks in this quadrant cannot be fully controlled by a project manager but can be influenced by him or her. (Keil et al., 1998) Quadrant 2 (Scope and Requirements) includes risks involved with the ambiguities and uncertainties that arise in establishing the project s scope and requirements. Risk mitigation strategies in this quadrant should emphasise the management of ambiguity and change. These risks should be controlled by a project manager. (Keil et al., 1998) Quadrant 3 (Execution) concerns the risk factors in the actual execution of the project. The risk mitigation strategy in this area should emphasise internal evaluations coupled with external reviews to keep a project on track. Project managers must follow an established development methodology and proactively anticipate and respond to events that can threaten the development process. (Keil et al., 1998) Quadrant 4 (Environment) means the project environment, both inside and outside the organisation. Usually a project manager has little or no control over these risks, which can however be significant and dangerous. Contingency planning is one sensible strategy for dealing with environmental risks (Keil et al., 1998). In Nigeria, the importance of this category is much higher than in industrialised countries. Methods for risk analysis are quite easy to find and apply. To find or create methods for assuring the

11 Soriyan et al., Information Systems Development for Health in Africa 11 sustainability of IT is more challenging. Currently we don t yet have a checklist of sustainability factors which could be used in assessing the system development process. From the health sector, however, we have found a sustainability analysis method (Reynolds and Stinson, 1993) which is modified into the steps in Table 2 for our purposes. The method has not been tested in any ISD project, so the suitability of this model is still hypothetical. Step 1. Introduction: Who are the users, what is the purpose of the application, what is the scope, what is the level of demand for the technology Step 2. Sustainability objectives: What are the desired outcomes, what are the services, what are the required resources to keep the application in action, what is the appropriateness of the technology to the application environment (cost-effectiveness, affordability, suitability) Step 3. Analyse factors: Factors that could be threats to sustainability of application. Work out a strategy for dealing with each threat. What are the financial implications? The factors include: 1. Target population size (meaning clients and clients clients), composition, and distribution; 2. Target group knowledge, attitudes, practises (users); 3. Service quality; 4. Management support; 5. Organisational capacity; 6. Political commitment; 7. Personnel resources; 8. Programme revenues; 9. Programme expenditures; 10. Environment Step 4. Strategic assessment: Strategic responses to threats and opportunities of each factor. Neutralise threats, take advantages of opportunities. Step 5. Strategy, action plan: Summarise strategy, action plan. Step 6. Financial assessment: Take budget -> do What-If-Analysis -> Adjusted projections -> summarise to the strategy Table 2: A sustainability analysis framework adapted from the health sector. The activity network analysis mentioned under requirements analysis methods fits well with step 2 of Table 2. We intend to now combine these two approaches into a sustainability analysis and design checklist for systems developers, and test the checklist in our action research cases. The involvement of all relevant stakeholders identified through activity network analysis including management and local communities in the healthcare sector provides some assurance that the wouldbe system will have a positive socio-economic impact on those to be served. In turn, if all the stakeholders perceive the system as beneficial and important to them, they will support the system in the long term and thus contribute to its sustainability (Korpela et al., 1998). The impact of IT is difficult to analyse, however (Heeks, 1999 b), and more research is needed on this aspect. It is also very important to safeguard against unintended negative socio-economic impacts, which usually accumulate on the less privileged and less powerful of the stakeholders. To study this issue and to develop practicable methods to manage it, we are focusing on the gender-related impact of IS development and IS use that is, we study if and how the ISD practices and methods have a different impact on male developers, users and clients compared to female developers, users and clients. The ultimate objective is to ensure that ISD methods and education make ISD practitioners aware of the possibility of gender-related impacts, so that for instance potential negative socio-economic impacts of

12 Soriyan et al., Information Systems Development for Health in Africa 12 certain project management methods on female developers are identified and corrected. The affordability of the would-be system is another issue which should receive proper attention already during the requirements analysis phase that is, in outlining the vision of the future, the stakeholders should also consider if they can afford the intended system in the short and long terms. The analytical procedure should guide the stakeholders into searching for the more affordable alternatives. More research and experimentation is needed on this issue as well. 4.4 Grand design methods If the roadmap provided by requirements analysis indicates that it is necessary to develop a new software application, the next step is to move on to draft an outline of the functionality to be included in the application. We call it the grand design. The objective of the grand design is to bridge the gap between the utility-oriented rough vision produced by requirements analysis and the implementationoriented precise specifications needed for programming. In large-scale software engineering today, the Universal Modelling Language (UML) has become the standard notation for specifying software systems, at least in theory (Jacobson, 1994). In the small projects and severely constrained design settings typical in Nigeria, the bulk of UML seems unnecessarily tedious and detailed. However, the use case modelling technique of UML appears appropriate for drafting the functionality in the grand design. Theoretically, we argue that use case modelling deals with the individual actions (Figure 7) that are parts of the collective activity (Figure 3). That is, each use case defines one subtask needed in achieving the outcome of the overall activity, performed by (usually) one actor using some subset of the technological system (usually a few forms, prints and the like). In practical terms the use case model does not need to be more than a narrative script of how the actor performs the action using the wouldbe technical system, starting from a given situation and resulting in a set of specified outcomes. For instance, one use case of a hospital information system would be the recording of a new patient s demographic data on the database by a medical records officer. Actors, subjects Means of work, instruments, facilities Shared object of work Jointly aspired outcome of work Figure 7: Individual actions merging into a joint activity (Korpela et al., forthcoming b). In principle, when all the use cases required in the work activity have been described, we have a complete narrative description of all the functionality that the would-be software system shall have. This set of use case descriptions can be used both as a contract specification, a system documentation,

13 Soriyan et al., Information Systems Development for Health in Africa 13 a work order for programmers, a guideline for testing, and a basis for a user manual. In practice it is not feasible to try to specify all the use cases in detail in beforehand, but to have first just a list of the required use cases and to proceed into implementing the individual use cases in a prototyping manner in parallel with specifying them in collaboration with the users. Further experimentation is required to reveal when it is necessary to actually produce the use case descriptions, and when a rough outline of the grand design together with prototyping is sufficient. This is probably highly dependent on the technical implementation methods used. 4.5 Technical implementation methods Our intention is of course not to prescribe which technologies Nigerian software companies should use. However, it is feasible to recommend high-level Rapid Applications Development (RAD) toolkits which produce more user friendly and more maintainable applications more efficiently than low-level programming. Furthermore, in educating Computer Science students in the Made-in-Nigeria methodology, there needs to be a sample implementation technology to be used in exercises. Therefore we will include in the portfolio technical implementation examples based on the FixIT toolkit used in developing the Made-in-Nigeria Primary Healthcare and Hospital Information System (MINPHIS). The sample RAD toolkit includes the FileMan public-domain database management system of the U.S. Department of Veterans Affairs, running on the Caché programming platform on Windows NT, the Delphi application development technology, and the FixIT high-level building blocks developed for FileMan databases (Korpela, 1999 a). Briefly, modern applications can be developed using the FileMan-Delphi-FixIT toolkit by composing them from prefabricated high-level components, instead of by coding them on a low level. Similar RAD toolkits are available for commercial databases, although they tend to be quite expensive. A RAD as the implementation technology has some profound implications on the technical design and implementation methods. The prototyping and iterative nature of the implementation process increases at the expense of formal specification and rigid designs. With a RAD, the developer should first have the grand functional and architectural design of the system, proceed into designing the main database structure, and then implement the database, forms, functions and reports of each use case at a time. For instance with our sample RAD toolkit, the developer can produce the fully functional forms for one use case in minutes. It is then crucial that these prototypes are presented to a representative group of would-be users very early, to uncover any major design flaws. Early hands-on interaction between the users and the developers on the prototypes of a couple of core use cases also gives the users and managers of the client company a concrete idea of what they are going to have. It is thus useful to implement prototypes of the core use cases even in parallel with requirements analysis, particularly if the client has no prior experience on using the kind of IT considered. The prototype becomes a concrete shared language for the designers and users to express their mutual requirements and questions, and to learn from each other. The completed use cases of the prototype become a product which can be put into use already while some other use cases are still just rough ideas. In this case even the daily use experience of the early parts can inform the design of the late parts.

14 Soriyan et al., Information Systems Development for Health in Africa 14 So far we have technical implementation experience on our own host project only. The survey provides an overview of the state of the art in technical implementation methods and tools in Nigerian software companies, but the view must be backed up by in-depth cases. 4.6 Methods for organisational implementation (putting IT into use) Organisational implementation, or the introduction of an IT application into the user organisation, has two faces. From the software developers viewpoint it is to deploy their product into one or more user sites, depending on whether it is a tailored or a packaged product. From the user organisation s viewpoint it is to purchase a new tool to facilitate their work. In first-time development of packages and in tailoring these aspects merge. According to our survey results, tailoring is much more common in Nigeria than to develop packages, so our portfolio of methods will have an emphasis on such organisational implementation settings which are merged with technical implementation. We wish to re-emphasise that whether technical implementation is included or not, organisational implementation must always include requirements analysis (Figure 1). Our survey results and action research experience are so far not sufficient to indicate whether this area will require major adaptation to either the existing practice or to the methods suggested by western literature. 4.7 Methods for long-term support In the section dealing with sustainability, we already mentioned that it is important to involve all the stakeholders of the activity network into supporting the would-be information system in the long term. However, more detailed guidance is needed on how the long-term support should be organised, so that the users and their clients feedback will reach the IS professionals, bug fixes and functional enhancements will be delivered on time, different software versions and site configurations can be managed, etc. Research on this area is at the final end of our project schedule, so at the moment we have no major empirical results or theoretical propositions yet. 5. Conclusion We argued that one of the prerequisites for appropriate, locally developed information systems for healthcare in Africa is the availability of ISD methods, techniques and education adjusted to the specific constraints and requirements of the everyday work of African systems developers. We also presented the research design for developing a portfolio of ISD methods and techniques Made in Nigeria for Nigeria. Resulting from the first phase of theoretical and empirical research, we presented a preliminary outline of the topics to be included in the portfolio, and discussed in more detail the methods for requirements analysis, risk analysis, sustainability and a positive socio-economic impact. Other topics were covered in a more superficial way. This paper is the first outline of the Lecture Notes and technical manuals which should result from the project. The methods and techniques will be presented in more detail and submitted to the assessment and criticism of colleagues from other countries in a one-day workshop after HELINA 99. The feedback from the workshop will provide us with guidance on how to make the methodology increasingly relevant to other African countries also, besides Nigeria. The final methodology and experience on applying it to ISD practice and education should be available in HELINA 2002.

15 Soriyan et al., Information Systems Development for Health in Africa 15 Acknowledgement This research was funded by the Academy of Finland through the INDEHELA-Methods project. References Avgerou C (1996). Transferability of information technology and organisational practices. In: Odedra- Straub M (ed.), Global Information Technology and Socio-Economic Development. Nashua: Ivy League, pp Avison D, Lau F, Myers M, Nielsen PA (1999). Action research. Communications of the ACM 42(1), pp Barki H, Rivard S, Talbot J (1993). Toward an assessment of software development risk. Journal of Management Information Systems 10:(2), Boehm BW (1989). Software Risk Management Tutorial. Washington, DC: IEEE Computer Society Press. Charette RN (1989). Software Engineering Risk Analysis and Management. New York: McGraw- Hill. Heeks R (1999 a). Software strategies in developing countries. Communications of the ACM 42(6), pp Heeks R (1999 b). Information and Communication Technologies, Poverty and Development. Manchester: University of Manchester, Institute for Development Policy and Management, Working Paper Series no. 5. Jacobson I (1994). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. Järvinen P (1999). On Research Methods. Tampere: Opinpaja. Keil M, Cule PE, Lyytinen K, Schmidt R (1998). A framework for identifying software project risks. Communications of the ACM 41(11), Kensing F, Simonsen J, Bødker K (1998). MUST a method for participatory design. Human- Computer Interaction 13(2), Korpela M (1999 a). Moving a valuable heritage to the network computing architecture. In: Proceedings of the 1999 Annual HIMSS Conference, Vol. 3, Chicago: Healthcare Information and Management Systems Society, pp Korpela M (1999 b). Activity Analysis and Development in a Nutshell. Web page. Korpela M, Soriyan HA, Olufokunbi KC, Onayade AA, Davies-Adetugbo A, Adesanmi D (1998). Community participation in health informatics in Africa: An experiment in tripartite partnership in Ile-Ife,

16 Soriyan et al., Information Systems Development for Health in Africa 16 Nigeria. Computer Supported Cooperative Work 7:(3 4), Korpela M, Soriyan HA, Olufokunbi KC, Mursu A (forthcoming a). Made-in-Nigeria systems development methodologies: An action research project in the health sector. In: Avgerou C, Walsham G (eds.), Implementation and evaluation of information systems in developing countries. Korpela M, Olufokunbi KC, Soriyan HA (forthcoming b). Activity analysis as a method for information systems development: General introduction and experiments from Nigeria and Finland. Scandinavian Journal of Information Systems, Special Issue on Activity Theory in the Design of Technology. Korpela M, Mursu A, Soriyan HA, Olufokunbi KC (forthcoming c). Information systems development as an activity. Computer Supported Cooperative Work, Special Issue on Activity Theory and Design. Mursu A, Soriyan HA, Olufokunbi KC, Korpela M (1999). From software risks to sustainable information systems: Setting the stage for a Delphi study in Nigeria. Journal of Global Information Technology Management, 2:(3), Mursu A, Soriyan HA, Olufokunbi K, Korpela M (forthcoming). Information systems development in a developing country: Theoretical analysis of special requirements in Nigeria and Africa. Accepted in the HICSS-33 minitrack on Information Technology in Developing Countries, Hawaii, 4 7 January Odedra M (1992). Much more than human resource development for Africa. In: Bhatnagar S (ed.), Information Technology Manpower: Key Issues for Developing Countries, New Delhi: Tata McGraw-Hill, pp Orlikowski WJ, Baroudi JJ (1991). Studying information technology in organizations: Research approaches and assumptions. Information System Research 2(1), pp Reynolds J, Stinson W (1993). Sustainability analysis. Primary Health Care Management Advancement Programme. Bangkok: Aga Khan Foundation. Ropponen J, Lyytinen K (1997). Can software risk management improve system development: an exploratory study. European Journal of Information Systems 6, Schmidt R, Lyytinen K, Keil M, Cule P (1997). Identifying Software Project Risks: An International Delphi Study. Hong Kong University of Science and Technology Working Paper. Waema TM (1996). Implementation of information technology projects and economic development: Issues, problems and strategies. In: Odedra-Straub M (ed.), Global Information Technology and Socio-Economic Development. Nashua: Ivy League, pp