After the awarding of the AFAIB contract, TA was confronted with choosing the best approach to proceed with the project. The project proposal and contract contain a vaguely written functional specification without detailed technical specification. This was partly due to lack of time and shared trust that followed the demonstration of the prototype. It was agreed that the system would be developed in phases, based on the urgent needs and stage of operation of the bank. For example, it was compulsory that the account-management module be ready as soon as possible, while profit calculation could wait since the first time to use that feature would be after three months of operation.
Being a small company, almost everyone at TA was involved in the project. In this case, we only concentrate on the software development aspect of the contract, although necessary references are made to the hardware aspect. Four people were actively involved in the analysis, programming, testing, and implementation of the system: Usman Garba, Vicky Alabama, Musa Abass, and Joseph Cardozo. They constituted the development team. Joseph was appointed as the Project Manager to coordinate the development work and liase with the bank for daily updates and demonstrations of new features. He was also involved in the development of several modules and supported Vicky Alabama, who led the testing.
Under normal circumstances, and being the first time that these two organizations cooperated with each other, there supposed to be some kind of reasonable level of detailed description of what should be delivered. This was difficult in this situation since neither party knew how far the system would be developed. What was agreed upon was only the delivery of a banking system that would allow account management, post and process transactions, and perform normal banking procedures in addition to the profit calculation. The fact that the detailed description was not in written form posed some problems at later stages of the project.
Even though there are various ISD methodologies, each one has various advantage and disadvantages (see Avison & Fitzgerald, 1995, pp. 261–406, for detailed discussion). Considering the time and the low-cost requirements, prototyping was chosen as the methodology for developing the system (for further detailed review of prototyping see Alavi, 1984; Budde et al., 1992; Hardgrave & Wilson, 1999; Henson, 1991; Jason & Smith, 1985; Mogensen, 1991; Trigg, Bodker, & Groenbaek, 1991). According to Hirschheim and Klein (1992), making a prototype to eventually become the system involves five phases, as represented in Figure 1. The first stage is to identify some of the basic requirements without any pretensions that these are either complete or not subject to drastic changes. The second phase is to develop a design that meets these requirements and to implement them. The third phase is to have the user experiment with the prototype under the developer's supervision, recording bad and good features. The fourth phase is the revision and enhancements of the prototype based on the outcome of the third phase. This phase includes redefining and gradual completion of the requirements and also improving the interface and reliability. The last phase is actually continuous and includes repetition of phases three and four until the user is satisfied or money and time do not permit further revisions.
Figure 1: Phase Structure of Prototyping
They also decided to use one-tier procedural architecture (see Chaffee, 2000) with enhanced capability to utilize the local area network. Since the whole project had started with a demonstration of a prototype in exactly similar hardware environment designed for the bank, the users were able to see the system in real-life situation. Although there are different kinds of prototyping, as described by Hirschheim and Klein (1992), this project used several features of each variant of prototyping. At earlier stages, horizontal prototyping was used to give the users an idea of the system without much computation, except when it was absolutely required. As the project advanced, and with the basic features already in place, emphasis shifted to vertical prototyping that provides full functionality for each module. The system was also designed in a cooperative manner (Trigg, Bodker, & Groenbaek, 1991) and could also be seen as evolutionary development (Budde, Kautz, Kuhlenkamp, & Zullighoven, 1992). Since the project team lacked detailed understanding of Islamic banking principles, it worked closely with Khaled, the finance manager.
Prototyping involves heavy use of productivity tools such as database languages, code generators, screen painters, and generators, etc., to enhance the process of logical design and ease the physical design in a cost-effective manner. This influenced the choice of the programming language and the techniques used. Because Khaled had been previously exposed to software development using Visual Basic, he strongly wished that the system could be developed with it. However, the development team at TA was not prepared to experiment on a technology where it lacked expertise. This has led to the failure of many software development projects (see Paynter & Pearson, 1998, for example, and Lyytinen, Mathiassen, & Ropponen, 1998, for software risks). Although it was not a problem to use Visual Basic, the risk was considered too high with the time schedule of AFAIB. Handling the functionality and meeting the specification of a new banking paradigm were considered sufficient challenges. In its previous projects, TA had used Clipper and FoxPro. To meet the prototyping need, the team finally agreed to use FoxPro, which provides enough functionality to support prototyping. Emphasis was put on writing reusable codes, and the system was highly thus reducing the coding time and making changes easier. The system was designed and implemented in a Microsoft DOS environment; however, the networking, file and record-sharing capability of Foxpro enabled the system to run on the bank's Novell Network LAN. The entire system resides on the server, and the data was not separated from the procedures as in the case of client/server systems. This obviously affected the speed of the system and lead to some minor problems associated with file sharing and record-locking techniques of flat files.
Security and reliability of the system is one of the major priorities of the management of AFAIB. Consideration was given to this from the very beginning. Apart from the well-defined, role-based access to the system, the tables were encrypted and the data was scrambled at record level.
Unlike most projects, the starting date of this project was known but the completion period was agreed upon without any specific end date. In principle, when the need of the users were met, i.e., when a complete banking package acceptable to both parties was delivered, the project would be considered completed. This was a bit clumsy since the requirements of a growing organization could keep increasing and, thus, the project may never end. Nevertheless, this did not raise much concern since TA saw it as an opportunity to develop a longer-term relationship with the bank and secure all its future IT projects. Even though the project was large enough to use project management tools, none were used on this project— everything was handled manually. The writing of the technical and user's manual in parallel with development assisted in simultaneously recording the relationship between one module and the others. The programming conventions of TA also ensured that each programming module was properly addressed and documented with detailed title and header information (date created, major data files, author, date amended, old file, etc.).
The project manager often met with the finance manager to clarify some design issues and demonstrate the latest update. When required, the entire team met with the representatives of the bank, mostly with the finance manager and the operation manager, to discuss the progress of the project. There were disagreements on a few occasions, when the finance manager changed what he had requested earlier after it had been implemented with much effort. TA was also under pressure to deliver the first indigenous Islamic banking system in the country. Some of these problems could be attributed to lack of any detailed specification in the contract. However, on those few occasions, differences were settled amicably.
Various risks were identified early and were carefully taken into consideration throughout the project. The bank was set up to keep a minimum essential manual record of the transactions, which meant the system could not be down at any time once the operation began, or the banking operation would come to a halt. There was also zero tolerance for transaction errors, which could adversely affect the image of the bank. Thus, adequate provisions were made in the error handling procedures. For example, a transaction had to be completed once it started, otherwise the debit might not have a corresponding credit and the whole account would not balance. This was a difficult and important issue, not only from the programming perspective, but also from the developing countries' infrastructure problems, for example, the inadequate electricity supply that often caused data corruption. It was also important that TA deliver each module as required; there could be no delay since it would mean an interruption in the bank's operations. The issue of budget and time overrun was out of the way by the nature of the contract. It was a fixed amount payable periodically without any direct attachment to the deliverables. Since the project did not have any specific end date, successful completion of the set objectives thus concluded the project.
In the absence of any written communication plans, the project team met often to agree on some important design issues, resolve any conflict, and to monitor the state of the development. Almost on daily basis, the bank was shown the latest version and its comments were incorporated immediately. The users were involved in the testing, which revealed several errors that would normally have occurred and been found after the system was in use. This experience also familiarizes the users with the kind of possible errors they might encounter when using the system and what to do at that stage. Their reception to the system was quite nice and the feeling of ownership was clearly evident through their participation. With the TA's experience with regard to problems with preparation of technical and user's manuals, these were written in parallel with the development. The usual practice was to wait for the system to be ready before the work on the manuals began. This usually causes delay in its completion.
As the success of the project become more realistic, everyone wanted to be part of the project. This led to some conflicts of interest and minor misunderstandings among the staff, but not directly within the development team, as it was too busy for any conflicts. As mentioned earlier, while the software project was going on, the hardware and networking project was also in top gear at the bank. When the bank eventually started operation and it began using the system, the error-handling program usually returned a red screen with the message, "Press ESC to continue and report the error to TA's engineer………." The problems were often reported to Sheikh Bwari or his staff who were often at the bank. As the head of technical services, he was very interested in the project. He knew that the hardware-servicing contract was anchored to the success of the software and was always eager to respond to the problems instantly.
Although he understood the process of software development, he always felt that the team was not doing enough to make the system stable and reliable. He usually spoke at the bank on behalf of the development team on what he knew a little about. This occasionally brought some disagreement between him and the development team. He sometimes made promises that are not realizable within the given time and expected the development team to comply. Through the head of the R&D, the development team also emphasized that the users were supposed to be communicating with them directly through the project manager and not through someone they considered external to the development process. It took some time before the problem was completely resolved, actually until the system become more stable and the users were no longer scared of the common errors.
Some practical issues that we often neglect in work practices sometime affect the output and the quality of project. Individuals have personal beliefs and values, and aligning those to fit into the organization where they work or the kind of work they do becomes quite important. The workers at the bank had to pray five times a day, three of which were within working hours. As a matter of fact, the room next to the banking hall, adjacent to the computer room, is a mosque. They often had to have a break during presentations or meetings to have prayer. Considering the pressure and the willingness of the project manager to get to the root of any pending problems, it often led to some frustration when the people who were supposed to be working with him had to break for prayers. As mentioned earlier, Musa Abass, the R&D manager at TA, is fluent in Arabic, the native language of the Egyptian finance manager. This automatically enabled a cordial professional relationship between the two of them and, in effect, with the development team. They often preferred to speak in Arabic on issues that did not concern other team members. Other members of the team even allowed Khaled to use Arabic to explain those Islamic banking concepts that could not be easily translated and explained in English. On the few occasions that the bank''s chairman visited the bank from Saudi Arabia, the language capability of the TA development team became useful. Apart from his impression about the performance of the system, the chairman was very comfortable with the language ability and religious beliefs of the vendor's team. Thus, a relationship that was beyond vendor-customer developed between the two companies due to this cultural influence.
While every detail might not be clearly spelled out, AFAIB had a clear goal for the project—an application system to run its banking operation. Khaled was an expert in Islamic finance and accounting, but it was not long before the development team realized the extent of his understanding of software development. AFAIB did not yet have any justification to hire a full-time IT manager, thus it had to rely on TA for all the IT services and strategies. Occasionally, the bank sought advice from IDB at Jeddah, but it still had to rely on TA for its implementation. This dependency and lack of adequate in-house expertise created an avenue for monopolistic bargaining for TA. TA was also left with its choice of technology and any kind of practice convenient for it. It was here that the professionalism of TA came into play. In spite of all these dependencies and freedom, TA ensured that it critically considered all possible options and provided justification for all the decisions made in the project. The approach used was to make the project manager completely independent of the team and work as a client advocate. In this role, he questioned any decision he felt was not good enough from professional point of view. He always took time to explain to Khaled why a particular option was chosen and its advantage over the others.
Similarly, AFAIB relied on TA to staff the department. TA assisted the bank to recruit one of its own trainees to work as the operator of the system and manage the IT unit of the bank. Again, without strictly adhering to professional ethics, it would have been easy to influence the operator to carry out the wishes of TA while compromising the quality and integrity of the system. As soon as the operator became a member of the AFAIB staff, he used his exposure and experience to contribute to the project and offer several constructive criticisms, even though the project was at advanced stage at the time of his arrival at the bank. There existed a mutual trust and care that transcended the vendor-customer relationship between TA and AFAIB. AFAIB believed TA would provide the best system that would enable the bank to compete well in the market without compromising the business strategy to its competitors (who also happened to be customers of TA). At this stage, every other bank wanted to know more about Islamic banking and its mode of operations. The relationship was not of customer-vendor but more of partners where both working towards the success of the project and organizational developments.
Who should own the intellectual property right to the final product? Was it AFAIB that understood Islamic banking and paid for the services to code it into the system for its use, or TA that labored to interpret and translate the Islamic banking knowledge into a codified form and got paid to do so? This issue of ownership was not discussed in much detail at the time the contract was awarded. AFAIB was preoccupied and satisfied to get a system to start its operations without thinking about the ownership issue and the future of the banking system. Meanwhile, TA had added a clause that gave it the ownership of the software. But the question was would TA be able to resell the package without the permission of AFAIB? As of the time this case study was written, this issue has not arisen and the relationship between TA and AFAIB was still very cordial.
There are many factors that could be responsible for the delivery of the system within the expected period. Apart from the fact that everyone was enthusiastic about the project, TA also provided an enabling environment and encouraged its staff to work hard. There was a goal-oriented culture and everyone involved in the project had a sense of achievement and belonging. All the project team members never hesitated to work overnight to deliver a new module in the following morning. The working culture at TA prior to this project allowed for flexible resumption and closing time. This became useful on this project as the development team members were already used to long hours of work. The leadership at the organization provided a good example. Usman Garba had a record of working later than anyone and arrived before all other team members. He was able to combine the development work with his normal management and administrative tasks, without allowing any of his duties to suffer. At the beginning of the project, there were no promises of any reward for the core development team if it met the deadline; it just worked in a professional manner and accepted the satisfaction of delivering a good product as its motivation. Although not having the possibility of providing stock options as is common in the Western countries, TA does offer yearly profit sharing to reward its staff.
The end of the project was a relative issue since there was no specification of the exact features that should be present in the completed system. However, after the first six months, the system was able to handle most of the basic operations of the bank; profits had been calculated twice. Profit calculation was one of the major tasks in the whole project. The system was also able to process various kinds of investment: Musharaka, Mudaraba, Istisna, etc., without any major problem. On a daily basis, the bank could produce trial balances and other reports, and everybody seemed happy. The system was accepted after nine months of development. To officially mark the end of the project, TA and AFAIB organized a big hand-over ceremony. However, there were still other parts of the bank and banking operations that needed to be computerized. The finance department still depended heavily on spreadsheets for some processes and calculations; the input comes mostly from the banking system but had to be re-entered manually.
At the handing-over ceremony, the project manager highlighted many features for the next version of the system. Even though e-banking was then not well-known in the country, he described a scenario where corporate customers could directly link their accounting systems to the banking package. He also suggested upgrading the system to a Microsoft Windows-based application. He suggested other applications like payroll, fixed-asset management, credit analysis system, etc., to complete the automation of the entire bank and its services. He suggested n-tier architecture where the user services would be separate from business and data services (Chaffee, 2000). All of these additional features would make the system more robust and scalable in preparation for when other AFAIB branches would be added to the system.
Shortly after the handing over and the official conclusion of the project, the project manager travelled to one Middle Eastern country in the fall of 1997 on annual vacation. During his holiday, he visited several organizations and was surprised to realize how far behind the technology that was used in the project was in comparison. He was exposed to new approaches that would have made the development work faster with better quality. Even though TA was able to accomplished most of the requirements with FoxPro, he found out about modern tools for software development and was eager to spread the news when he returned back to his company. The management of TA were quite aware of the developments in software tools, but it was confronted with many limitations due to the geographical location. As mentioned earlier, TA was the best IT organization in the country and there was no place to train its staff locally. The cost of sending them abroad would be too high, considering the fact that the market is a bit small and the businesses are not prepared to pay for the cost of modern technology. For example, in 1997, there was an attempt to recruit one Oracle expert from a neighboring country in order to bring Oracle expertise to TA. The attempt failed due to his demands. The local companies are not prepared to pay for the cost of the software, hence there was a need to balance the use of technology and the local market realities.