• Tidak ada hasil yang ditemukan

5.5 Presentation of Qualitative Analysis

5.5.1 Interview Findings from Technical Personnel

5.5.1.2 Collaboration Practices

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.

118

“The architecture of government m-government service provisioning in Tanzania is a two-step system for the USSD menu service whereby citizens access services via the mGov platform which then reconnects them to specific host systems; while for the Pull and Push services citizens directly connect to the systems of the service hosting organisation, i.e. the government organisation hosting or designated for a particular public service provision” (Respondent 2, sub-theme MTA).

And,

"For us to be able to provide our service via mobile phones cost-effectively, we are required to utilize existing government platforms to connect to the outside world;

therefore we will need to work with the e-government agency and mobile phone companies” (Respondent 15, sub-themes MTA, MS).

m-Government service provisioning involves several stakeholders with different roles and responsibilities. Respondents in responding to question A5 (Appendix B) noted:

“To facilitate the provision of m-government services, three keys players must come into agreement and work together; these are public service providing organisation, mobile infrastructure access provider (eGA) and mobile phone operators”

(Respondent 3, sub-theme MS).

And,

“Decisions on the level of access citizens should have, and service hosting organisations make the information that they can access. For instance, for the LUKU service, TANESCO is responsible for verifying and authenticating all transactions

(Respondent 1, sub-theme MS).

The extracts above suggest that m-government service provisioning is a multi-tier architecture that involves several stakeholders with different roles and responsibilities.

Stakeholders for m-government service provisioning in Tanzania thus include the e- Government Agency (eGA) as an infrastructure access provider, mobile phone operators and Internet service providers for telecommunication services, public service providers for public service provisioning and finally policymakers for the legal and regulatory framework for providing m-government services.

119 Service Upgrading

Since m-government service provision in Tanzania involves two applications, that is, the infrastructure and the service application from different government organisations, it was crucial to establish practice on application and content updating. First, it was critical to establish the origin or trigger for change for such service provisioning architecture with multiple stakeholders. Responding to questions A6 and A7, all four organisations acknowledged that change may be a result of ‘system/plan changes’, ‘technology advancements’, while organisations B, C and D had an additional theme for triggering change; that is, ‘citizen complaints’. Responses to verify this include:

“Needs for updating/upgrading the mobile platform arise either due to changes in the rollout plan, technology change or user complaints” (Respondent 9, sub-themes PC, CC and TC).

And,

“It is on the basis of user complaints, technology advancements and structural changes that we make recommendations to programmers to make changes on the service applications” (Respondent 5, sub-themes CC, TC, GC).

Also,

"Occasionally, service upgrading has been a result of changes in guidelines and procedures and some cases due to change in technology. We sometimes are forced to amend our services to address complains from the public regarding our services"

(Respondent 13, sub-themes GC, TC, CC).

Moreover, interview responses on questions A6.1 and A7.1 shed light on the roles and responsibilities of stakeholders on service application and content updating/upgrading practice, indicating that each stakeholder is responsible for their particular application in m- government service provisioning. The responses included:

“Different stakeholders have different roles and limitations. For instance, the mGov platform updating/upgrading is the sole responsibility of eGA while the service application changes are the responsibility of service hosting organisations. However, service changes can also be affected by eGA on special request and approval by the client. Service application changes are solely the responsibility of eGA clients"

(Respondent 3, sub-theme MS).

120 Similarly,

“We can only change the service application in terms of updating it or upgrading it.

We do not have access to the platform application” (Respondent 8, sub-theme MS).

The quotes above suggest that a high level of synchronisation and collaboration is required to facilitate change management among stakeholders in m-government service provisioning in Tanzania. Consequently, it was essential to investigate how change is managed in terms of communication among stakeholders.

Managing Changes

This part presents responses that establish the practice for communicating change for updating/upgrading m-government service provisioning in Tanzania. Generally, the responses indicated that communication among m-government service provisioning stakeholders takes place before changes are carried out. In responding to questions A6.2 and A7.2 (Appendix B), two organisations, A and B, indicated the presence of a proper structure upon which change is communicated among stakeholders. Responses to verify this include:

“To perform any changes (updating/upgrading) on the mobile platform, a change management process is invoked which facilitates change communication and approval by relevant stakeholders (i.e. eGA, government organisations and mobile operators)” (Respondent 5, sub-theme CMP).

Another respondent stated:

Change management gets invoked when changes are to be made on the platform for which eGA clients are notified and must provide their approval for such changes to be effected” (Respondent 2, sub-theme CMP).

However, the other two organisations, C and D, acknowledged that there is no proper channel for communicating change within and outside the organisations. Their responses were:

“We deal with different organisations, therefore in most cases with implementing the change and later notify our stakeholders of the service changes made to bring them abreast” (Respondent 9, sub-theme LN).

And,

121

"Due to the sheer number of services we provide, sometimes it is difficult to communicate all the changes to our stakeholders before. So, at the same time, we implement the necessary changes and just notify our stakeholders later” (Respondent 15, sub-theme LN).

Also, in examining the types of changes that are performed and the initiators of change, in three organisations, B, C and D, responses revealed that most changes are primarily a reaction to citizens’ feedback, while organisation A indicated citizens’ feedback is just a secondary trigger for changes at their level. The responses to questions A6 and A7 (Appendix B) in relation to this matter were:

"Most changes are a result of feedback from users; when they encounter a problem they report it back to us, and we then notify the system development people to make the necessary changes" (Respondent 7, sub-theme CC).

The excerpts above indicate that most changes are ad-hoc changes, a result of citizens’

feedback or challenges in using the services provided.

However, in terms of change scheduling, responses corresponding to questions A6.3 and A 7.3 (Appendix B) indicate that in most cases it is carried out on ad-hoc basis, reactive rather than proactive, as said by one respondent:

“There is no fixed time scheduled for implementing changes” (Respondent 3, sub- theme ADI).

The quotes from the responses indicate that change on m-government service provisioning is not centralized; that is, it is initiated and carried out by the individual stakeholders with some limited communication and coordination. However, with such a provision structure with multiple stakeholders, high coordination and synchronisation of stakeholders' activities that affect m-government services are required. One respondent, in responding to question A9 (Appendix B), further affirmed this shortfall as follows:

"However it is noted that interoperability across service applications and legacy systems is still a challenge mostly due to lack of access and ownership of the software sources codes as many were funded and developed through private consultancies"

(Respondent 2, sub-theme IC).

122