5.5 Presentation of Qualitative Analysis
5.5.1 Interview Findings from Technical Personnel
5.5.1.1 Service Development Practices
This sub-section presents interview responses on m-government service development practices. In understanding m-government service provisioning practice, it was critical to
114
examine m-government service development process. Consequently, the interviews conducted inquired on various aspects to establish m-government service design and development practices of participating organisations. Thus, two aspects of m-government service development practices relevant to the context of Tanzania were examined; platform development, that is the mGov platform, and service content development practices.
Service Requirement Analysis
Respondents from all four organisations, in responding to question A2, A2.2 and A3 (Appendix B), indicated that m-government services are established and designed based on existing service requirements through service “re-engineering”, “service automation” or “re- visiting requirements” of already existing services. One respondent stated:
“Since service requirements are already known from our existing services that were provided through physical channels, therefore our tasks are only to automate the service such that it can be provided via mobile phones” (Respondent 1, sub-themes ER, SA).
Similarly, another respondent acknowledged:
“Most of the services that we provide via mobile phones are existing ones, whose requirements are already known; hence there was no need to involve users.
Therefore, all we do is revisit their requirements and customize the services to be possible for provisioning on a mobile platform” (Respondent 5, sub-themes ER, SRE).
Also, another respondent indicated:
“To implement our service through mobile phones, all we do is re-engineer the currently physically provided services and make them available on mobile phones”
(Respondent 9, sub-theme SRE).
On the other hand, regarding the development of the mGov platform, the gateway to public mobile networks, respondents from organisation A, in responding to question A2.2, indicated that it is a result of high demand from ministries, departments and agencies (MDAs) to leverage the potentials of mobile technologies in public service provision. Contrary to requirements establishment for other existing public services, the mGov platform
115
requirements are a result of an extensive research work that was conducted. One respondent indicated:
“The mobile platform was developed after research on how government services can be delivered efficiently and effectively using ICT platform given the ICT constraints in the country” (Respondent 1, sub-theme NA).
Another respondent commented:
“We received several requests from other government organisations, especially those which lacked financial muscles to negotiate with operators, to take up this role and implement a structure that connects government products to public networks. Also, issues of service reliability, security and trust prompted the agency to consider a cost- effective and efficient way that could be affordable to many government organisations. Thus, we came up with the mGov platform as one of the solutions to act as a gateway for government mobile services” (Respondent 2, sub-theme NA).
The statement indicates that m-government services implementation of existing public services is carried out based on existing provisioning requirements and designs. The resulting m-government services are limited to interactivity requirements and designs, consequently inhibiting achievement of satisfactory citizen experience.
Service Design and Development
On issues concerning the development of m-government services, two aspects, that is, application development and content development practices, were examined corresponding to questions A2.1 and A3.1 (Appendix B). In exploring the practice regarding application development, it was noted that the government organisations achieve development either through “in-house development” or “outsourcing” from the private sector or other government organisations. Two organisations, A and B, indicated they develop their applications in-house. One respondent from organisation A noted:
“Most service applications that are currently embedded on the mGov platform were developed by us, while some few by the service hosting organisation either using their internal capacity or through outsourcing private contractors. Service hosting organisations are not forced to have their application developed by us. Similarly,
116
where the service application is hosted, is also solely the decision of the government organisation providing the service” (Respondent 2, sub-themes IHD, OD).
Also,
“Most of our applications are in-house built. We have a dedicated department with a skilled workforce to carry out application development" (Respondent 6, sub-theme IHD).
However, organisations C and D acknowledged outsourcing their application development processes either to other government organisations with capacity or to private contractors.
One respondent from organisation D reported:
“Due to limited capacity within the organisation, we commission most our software application development to other government organisations or private contractors with capacity” (Respondent 13, sub-themes LSP, OD).
Importantly, it is noted that the developed applications are guided by standards and guidelines provided to allow for connectivity to the mGov platform. Responding to question A3.2 (Appendix B), respondent 1 said:
“All application, whether developed by us or independently through hosting organisations, they must abide by certain standards and guidelines provided on our website to guide development and connectivity to the mGov platform” (Respondent 2, sub-theme DG).
Also, other respondents noted:
“Within the government nowadays there are specific standards and guidelines in developing applications that we have to follow” (Respondent 10, sub-theme DG)
“The coordinating agency for ICT implementation provides training on different standards and guidelines to ensure our systems connect to other applications within the government” (Respondent 14, sub-theme DG).
Thus, regarding application and service content development, the results indicate it is achieved through regulated and standardized in-house development or outsourcing development from the private sector.
117 Service Verification and Testing
Finally, regarding m-government service verification and testing practices that were examined, results show that in all the four organisations investigated, citizens, as primary consumers, are least involved in service development and provisioning. Similar to requirements elicitation and design practices, resulting m-government services are verified against assumed citizen needs. Some of the responses to question A2.3 (Appendix B) were:
“We do not deal directly with citizens … User needs verification is done against organisational business processes and service needs as established by the service hosting organisations” (Respondent 2, sub-theme UE, VIG).
And,
“Before handing over the developed service application, the system is tested against established user needs. Commonly, the testing involves system analysts who represent citizens, and also service administrators responsible with the day to day running of the services” (Respondent 8, sub-themes UE, VUN).
The above attestations suggest that m-government services are designed, developed and provisioned with minimum citizen involvement. These findings affirm the limited citizen awareness indicated by the quantitative results in section 5.4.2, as they are neither involved in the provisioning process nor are their needs targeted by the resulting m-government services.