Abu Dhabi m-Services Strategy€¦ · email : [email protected] ... It is the goal...

1

I M P L E M E N T A T I O N G U I D E

Abu Dhabi m-Services Strategy

Contents

About ADSIC 4

Contact 4

Executive Summary 5

Overview to m-Services Strategy 7

• m-Services Target Model Development 10

• International Benchmarking 11

• m-Services Strategic Thrusts 13

• Introduction to Service Modernization 15

• Benefits of Service Modernization 17

m-Services Conceptual Architecture 18

• Architecture Guiding Principles 19

• m-Services Conceptual Architecture 20

• m-Services Target State Realization 23

ADGE m-Services Operating Model Requirement 25

• ADGE m-Services Team Roles and Responsibilities 26

• m-Services Portfolio Planning 29

• The m-Services Selection and Prioritization Process 31

• Mobile App Delivery Medium Selection 37

• m-Services Design Considerations 43

• m-Services Governance Model 46

• m-Services Key performance indicators (KPIs) 49

ADGE Actions for m-Services Strategy Implementation 52

Appendix A: Summary Comparison of m-Services Delivery Media 59

B: Digital Leadership Guideline 60

C: m-Services Qualification Guideline 64

D: Web App by Default Guideline 68

E: m-Services Mobile App Medium Selection Guideline 70

4

About ADSIC

Abu Dhabi Systems & Information Centre (ADSIC) is the government entity in charge of developing Abu Dhabi’s ICT framework and delivering IT-enabled services to the people of the Abu Dhabi emirate.

Abu Dhabi Systems & Information Centre is working towards the digital transformation of Abu Dhabi Government services aiming to establish the Abu Dhabi Government’s leading position among top global governments.

Mission

To enable the modernisation ofgovernment services through information technology.

Vision

To be a high performance governmentdelivering world class services to the benefit of all its customers.

Values

CompetencyCustomer Focus

ExcellenceInnovationRespect

SustainabilityTeamwork

Transparency

Contact Us:

Abu Dhabi Systems & Information CentreDigital Services TeamPhone: +971 2 671 7000 Fax: +971 2 671 7333email : [email protected] : adsic.abudhabi.ae

Executive Summary

6

Executive Summary

Executive Summary

Governments around the world are increasingly using mobile channels to extend the reach and impact of the services they offer to their constituents by leveraging rapid developments in the Information

and Communication Technology (ICT) sector and accompanying innovations in mobile technologies. These developments, coupled with high mobile and smartphone penetration rates, have provided an optimal environment for governments to enhance how they provide services and how constituents consume them, with the goal of fostering a more connected society. The adoption of mobile technologies for the delivery of m-Services allows government services to be more personalized, gain a wider reach, and cater to the ever-increasing mobility of citizens, businesses, and government employees alike.

The Abu Dhabi Government has made progress in its effort to deliver effective digital services to all of its citizens, private-sector businesses, employees, and government entities. As part of this effort, the government is determined to make available to its increasingly mobile, connected constituents a portfolio of high-impact mobile government services, to enable them to access key services easily and conveniently, anytime, anywhere. To that end, the Abu Dhabi Systems and Information Centre (ADSIC) has laid out the Abu Dhabi Mobile Government Services (m-Services) Strategy as a basis for guiding all Abu Dhabi Government Entities (ADGEs) as they modernize and digitize the services they offer and extend them to the appropriate mobile channels. It is important to note that the mobile government (m-Government) does not replace e-government but rather complements it; thus it should be considered an integral part of e-Government that leverages existing investments in e-Government infrastructure services and shared e-Government shared platforms.

The Abu Dhabi Government m-Services Strategy Implementation Guide is designed to provide an introduction to the overall m-Services Strategy, clarify the key areas and steps all ADGEs should consider in their effort to realize their m-Services agenda, and assist strategic planners, service portfolio managers, IT managers, and architects in planning for, developing, and delivering m-Services. This guide is divided into four sections, each of which is critical in carrying out the m-Services Strategy:

1 1 An Introduction to the m-Services Strategy1 The m-Services Strategy outlines key initiatives for ADSIC and the ADGEs as they work together to deliver on the strategy’s milestones and objectives.

1 2 An Overview of the m-Services Conceptual Architecture1 In order to increase access to m-Services, improve interoperability among ADGEs, and optimize costs, while building on the existing e-Government architecture, the m-Services Strategy defines for a target m-Services conceptual architecture that will support the long-term design, development, and implementation of all high-impact m-Services.

1 3 The m-Services Operating Model for ADGEs1 To ensure the establishment of a strong m-Services foundation that can support the rollout of the most effective m-Services, ADSIC has developed an m-Services operating model consistent with the requirements of the m-Services Strategy that each ADGE should adopt.

1 4 ADGE Actions for m-Services Implementation1 This section describes the actions that need to be taken by ADGE to successfully realize the m-Services Strategy in line with the strategic priorities. There are FOUR actions to follow where each has many steps:

11 Build Internal m-Services Capabilities

21 Develop m-Services Portfolio

31 Develop m-Services Transformation plan

41 Deliver m-Services

• m-Services Target Model Development 10

• International Benchmarking 11

• m-Services Strategic Thrusts 13

• Introduction to Service Transformation 15

• Benefits of Service Modernization 17

Overview to m-Services Strategy

8


The United Arab Emirates government recently launched the Mobile Government initiative to enhance the ways in which Government Entities, both local and federal, can provide services to their constituents. As

such, they are accelerating the pace of innovation by extending the role of ICT in modernizing their service portfolios and by finding new ways to increase end-user satisfaction in their interactions with the UAE government.

In its effort to accelerate the pace of development of mobile services, the Abu Dhabi Systems & Information Centre (ADSIC) has defined the Abu Dhabi Government m-Services Strategy to help and guide Abu Dhabi Government Entities (ADGEs) in implementing the Mobile Government initiative and to accelerate the pace of m-Services development, in line with Abu Dhabi’s e-Government strategy imperatives.

It is important to note that the emergence of mobile government (m-Government) is an expansion of e-Government and follows the same paradigms in digitizing government services for consumption by the public. As such, m-Services should be seen as a new access channel for public services, to be used only when the mobile channel’s specific attributes can enhance a particular e-Service and add a new dimension to how increasingly mobile end-users interact with government entities (Figure 1).

Figure 1. m-Services Delivery Channel


9


m-Government does not replace e-Government but rather complements it; thus it should be considered an integral part of e-Government that leverages existing investments in e-Government infrastructure services and shared e-Government shared platforms, such as the government Enterprise Service Bus (ESB), ADNet etc. It remains subject to the e-Government strategy and operating and governance models (see Figure 2).

Figure 2. m-Services Integral to e-Government

www

10


m-Services Target Model Development

The Abu Dhabi Government m-Services Strategy was defined by conducting a baseline analysis of existing m-Services capabilities across the Abu Dhabi Government, by engaging key stakeholders within

several ADGEs, and by gathering relevant business requirements (Figure 3). Furthermore, an extensive benchmarking exercise was conducted to identify those countries that are leading in providing government m-Services, including the U.K., the U.S., Singapore, Canada, and South Korea, to analyze their digital services strategies and related operating models, and to derive key insights applicable to the Abu Dhabi Government m-Services effort.

Figure:3. m-Services Target Model Development – Key Inputs

11


International Benchmarking

The analysis was performed across several key dimensions, including the composition of the country’s m-Services portfolio, the technology platform and choice of mobile delivery channels, staffing and

talent capabilities, critical portfolio planning and m-Services development processes, and the overarching e-governance model. The resulting key findings served as inputs into the definition of the Abu Dhabi Government m-Services Strategy (see Table 1).

BenchmarkAssessmentDimensions

Key Findings Examples

Portfolio

Central Listing of m-Services, and Private Sector Engagement in Portfolio Development

The U1K1 delivers its digital services through a topic-based

central portal optimized for mobile, and serves as one face

to the government

Singapore showcases government mobile

apps developed by the government or the private

sector on its open data platform repository

Platformm-Services Realization Through Web Apps on

Shared Platform

The U1K1 government favors mobile web apps as its primary mobile channel and considers native apps only by exception

The South Korean National Computing and Information

Agency provides shared cloud and mobile platforms

People

Establishment of Digital Services Teams Within e-Gov Custodians and

Entities

The U1S1’s e-Gov custodian, OMB1, has established the Digital Services Innovation

Center to support departments in implementing digital

services

Canada’s model stipulates that each federal

department or agency assigns its m-Services

teams in accordance with established standards

Processesm-Services Qualification

and Delivery Medium Selection

The U1K1’s Digital Strategy proposes the prioritization

criteria for digital services and tasks all departments with

planning the redesign of their services

The process of justifying a device-based (i.e. native)

mobile app is set by Canada’s Treasury Board

Secretariat

Governance

Elevated Digital Services Accountability, and

Adoption of Performance Management

In Singapore, the iDA2 elevated the ownership of

the m-Services strategy by appointing the government

agencies’ CIOs to the governance board

To enable performance reporting, the U1K1 GDS has

launched the Transaction Explorer platform to track

and report on transactional services

1) Office of Management and Budget 2) Infocomm Development Authority

Table 1: Benchmark & Best Practices – Findings and Takeaways

12


Among the key findings the benchmarking effort revealed the following key points:

• Most countries set their m-Services strategy at the national level, as a part of their national ICT strategy; indeed, keeping all m-Services efforts within the country’s overall digital services activities is critical to their success.

• Creating a centralized listing of all government m-Services was also a common theme, as was ensuring a role for the private sector in contributing to the government m-Services portfolio.

• Several benchmarked countries favored the use of Web apps as a medium for their m-Services, and typically required a strong rationale to justify the alternative development of native or hybrid apps.

• Many countries created a dedicated digital services team to own the digital agenda and provide support to government departments as they planned and delivered their respective m-Services portfolio.

• Strong emphasis on the planning phase of the m-Services program, including the establishment of well-defined criteria to guide government agencies and departments in qualifying and selecting those government services best suited for mobile enablement.

• Lastly, many countries have put in place a strong governance model designed to elevate the ownership of and accountability for the digital agenda to the highest levels in government to ensure alignment with the overall digital strategy.

13


m-Services Strategic Thrusts

It is the goal of the Abu Dhabi m-Services Strategy to support the full realization of Abu Dhabi’s e-Government vision of providing high performance world-class digital services to all constituents in Abu Dhabi. To

achieve this goal, the m-Services Strategy highlights four strategic thrusts, each of which is underlined by three strategic imperatives; together, they are critical to the formation of a strong m-Services foundation (see Figure 4).

Figure 4: m-Services Strategy Overview

1 1 Build Digital Government Capabilities:

Develop internal capabilities at both the ADSIC and the ADGE level to drive the strategic planning needed to implement new digital services, and to govern the digital services agenda. Key objectives in this area include:

• Augmenting the capabilities of ADSIC’s staff to support the delivery of m-Services

• Improving ADGEs’ m-Services staff readiness by delivering m-Services training, and assign key m-Services delivery roles within the ADGEs

• Designing and implementing the m-Services governance model, including performance measurement and reporting

“High Performance Government Delivering World Class Services To The Benefit of All Its Customers”

14


21 Deploy Future-Ready Digital Government Infrastructure:

Lay the foundation for the development of digital services on a platform that leverages existing Abu Dhabi eGov infrastructure but is also future-ready and flexible enough to account for new trends and improvements in technology. Key objectives within this area include:

• Developing a shared mobile services delivery platform for the development and delivery of m-Services

• Augmenting the shared e-Government platform with mobile components (including mobile Public Key Infrastructure (PKI), messaging gateways, payment gateways, digital signature capability, and others)

• Augmenting the existing shared e-Government platform with specific requirements and guidelines for m-Services

31 Develop Integrated Digital Services:

Develop integrated digital services for the Abu Dhabi Government consisting of high-priority m-services provided through optimized, user-friendly mobile apps. Key objectives include:

• Improving ADGEs’ m-Services portfolio development and management capabilities

• Developing and implementing Customer-Centric and integrated m-Services for citizens and businesses through web apps—or in exceptional cases through native or hybrid apps

• Creating an effective m-Services performance management framework with specific KPIs for monitoring progress & continues improvement.

41 Promote Open Government and Innovation:

Engage the private sector in aiding the development of government services and in creating sector-specific m-Services to improve the richness of Abu Dhabi’s digital services portfolio and to increase m-Services uptake and user awareness. Key objectives include:

• Engaging the private sector in further developing and innovating the government m-Services portfolio through the implementation of an open data initiative

• Driving the development of sector-specific mobile strategies—in particular, m-Education and m-Health

• Establishing a program for showcasing and promoting government m-Services

The successful implementation of this strategy will result in a vibrant m-Services ecosystem with two valuable benefits to both citizens and the government.

First, creating m-Services in accordance with the guidelines set by the strategy will result in a good end-user experience and in effective, high-impact m-Services that are accessible by everyone, anywhere and anytime.

Second, adhering to this strategy will create a more effective government with an enhanced digital services portfolio and more efficient internal operations.

15


Introduction to Service Modernization

Government Services Definition

A government service is an end-to-end process established by a government entity and intended to fulfill a specific need for specific users, including citizens (G2C), businesses (G2B), government entities

(G2G), and employees (G2E). The services can be delivered through any number of channels, including offline channels such as government offices, and online channels such as internet, and mobile devices. As an end-to-end process a service includes the request initiation, front office and back office activities as well as the request closing (see Figure 5).

As such a government service consists of three components:

1. Technology, consisting of IT applications and data sources

2. People, such as stakeholders within government entities or other related departments.

3. Processes, such as business processes, IT processes, and fees

Figure 5: Government Services

• Registerchildbirth• Requestpension• Applyfordriving license• Registervehicle• Paytrafficfines

Portal

CallCentre

Counter

Kiosk&Mobile

Other(e.g.InteractiveTV)

Service Provider Access Delivery Channels Service Receiver (Client)

Commercial

Government EntitiesG2G

Citizens & EmployeesG2C &G2E

BusinessG2B

EducationTransportation

Government Entities

Health Care Town Planning

• Applyfortradelicense• Requestimportpermit• Requestlabourcard• Applyfortourist

license

• InteroperabilityinformationbetweenADGEs(i.e.MwaqifTicket,Employeeinformation,etc.)

www

16


Figure 6: Definition of Transformed Services

Service Transformation

Service transformation is the process of transforming service from offline channels to online channels, a service is deemed to be transformed once it has undergone two stages (see Figure 6).

Stage 1: Services Modernization

Through this stage the ADGE is required to design and develop the service around the Citizen or Business (customer) needs in line with a Customer-Centric approach. This may require streamlining, re-engineering or modifying service processes or enacting new and modify regulations. ADGEs shall lead this stage in coordination with ADSIC.

Stage 2: Service Integration

Services are fully integrated with the required Abu Dhabi e-Gov Platform elements such as Portal, Mobile Platform, CRM etc. This stage is led by ADSIC with support from ADGEs.

17


Benefits of Service Modernization

Modernizing services entails the following direct benefits for an ADGE:

• Enhanced customer experience – The ADGE will immediately provide enhanced service delivery to their customers by reducing visits to multiple ADGEs, and simplifying complex, manual processes.

Modernized services will also increase service accessibility and convenience for the public by being available through additional access channels.

• Increased productivity through automation – Difficult paper-based services will be replaced by efficient electronic services, thus reducing complexity for ADGEs and customers.

Internal operations will also be streamlined and transitioned to electronic process management.

• Increased government efficiency – The intra-communication of ADGEs will increase due to electronic service availability and standards-based communication.

Also, electronic services will replace old, outdated manual transactions between ADGEs.

• Increased capacity for service delivery – The ADGE will be able to serve more customers due to modernized services since their services will be streamlined, automated, or electronically available.

• Increased flexibility - Modernizing an ADGE’s services will allow the ADGE to be flexible in adapting to changing business needs.

This increased agility is a direct by-product of modernizing the ADGE’s services.

• Overall cost savings - The service modernization process will lower overall costs since it will decrease the need to rebuild redundant systems, decrease integration costs, and allow for more efficient allocation of resources.

• Architecture Guiding Principles 19

• m-Services Conceptual Architecture 20

• m-Services Target State Realization 23

m-Services Conceptual Architecture

19


Architecture Guiding Principles

The design of the target m-Services conceptual architecture that will ultimately support all m-Services was influenced by six key guiding principles, each of which carries its own set of implications. These

implications have been translated into key recommendations used to shape the target m-Services delivery platform (see Figure 7).

Figure 7: m-Services Platform Guiding Principles

20


Figure 8: m-Services Conceptual Architecture Diagram - Target State


The target m-Services architecture is designed to promote the efficient creation of m-Services. It relies on the service-oriented architecture (SOA) principles adopted and promoted by the overall e-Government

architecture, whereby services are developed by the ADGEs, exposed on the shared government Enterprise Service Bus (ESB), and used by every medium through which the service is offered, including mobile apps. The m-Services architecture target state consists of four key conceptual elements (see Figure 8):

1 1 The m-Services Directory:

This is the central directory and access point for all Abu Dhabi Government Services information through a simple and centralized interface, if the transactional m-service is available on the Abu Dhabi mobile portal, the user will consume the service form Abu Dhabi portal. However if the m-service is available on the ADGE’s mobile apps or ADGE mobile web app, then will route users to the service location.

The m-Services directory will include those high-impact government transactional services that are most suited to the mobile channel, selected and prioritized based on the m-Services Qualifications Guideline (see Appendix C). The service list can be categorized by service topic, life event or by the ADGE providing the respective m-Services.

In general, not every government service or e-Service is a candidate for an m-Service, and key considerations such as service reach, impact, and complexity need to be taken into account to qualify existing government services for the mobile channel. As such, it is expected that a selected set of government services will be part of the target m-Services portfolio. Section m-Services Selection & prioritization Process outlines the key criteria for developing the Abu Dhabi Government m-Services portfolio.

21


21 The m-Services Delivery Platform:

This is the target platform that will support all mobile web, native, and hybrid apps, and promote cross-device compatibility while also supporting the HTML5 web standard on which web apps are built. As the number of mobile operating systems increases, so does the effort, management complexity, and investment needed to develop and maintain government m-Services that can run on different mobile operating systems and devices, including iPhones, iPads, Android phones and tablets, and Blackberrys, among others. It is the position of Abu Dhabi Government that (G2C & G2B) m-Services must be developed to run on any mobile device currently existing or yet to come, by adopting the “Web App by Default Guideline” (see Appendix D). However if the m-services is targeting the G2G or G2E constituents native and hybrid mobile applications can be adopted.

Developing m-Services as web apps will provide the Abu Dhabi Government with greater reach to all constituents in the most cost-effective manner. m-Services offered as web apps will be more easily found by users and can be immediately accessed without the extra step and effort involved in downloading a native or hybrid mobile app. Moreover, since web apps are device-agnostic and do not require that multiple versions for different devices and operating systems be developed and maintained separately, their total cost of ownership is significantly lower.

To this end, ADSIC will establish the central m-Services delivery platform to facilitate the development and hosting of m-Services as web apps for citizens (G2C) and businesses (G2B). In addition, ADSIC will establish the Abu Dhabi Government App Center, or “app store,” to host and manage those m-Services developed as native and hybrid mobile applications for government employees (G2E) and intra-government operations (G2G), and the devices they run on.

31 Shared e-Government Platform:

This platform, already created by ADSIC to provide access to the core components needed to develop all e-Government services, will also contain a set of common technology components intended to ease the development and execution of m-Services. These include key components such as the payment gateway, messaging gateway, identity management, location-based services, ESB, and others.

Because m-Services are intended as part of the overall e-Government architecture, they will be developed to leverage the existing shared e-Government platform, which will be augmented by ADSIC to provide mobile-specific services including:

• Identity Management: The existing e-Government Single Sign-On (SSO) will be employed for user authentication and identity management, and will be extended to ease the mobile user registration process.

• Payment Gateway: The shared payment gateway will include key features such as multiparty payment settlement. Aggregated payment reporting at the individual and entity level will also be provided.

• Messaging Gateway: The shared messaging gateway will be able to handle user notifications via SMS.

• Location-Based Services: This shared service will enable determination of the location of the service user and provide location-pertinent information, , local search, service-center locators, and other information.

22


• Enterprise Service Bus (ESB): The existing ESB will continue to be used to publish m-Service APIs and facilitate the development of digital services and interoperability among ADGEs.

41 ADGE Services Layer:

A services layer consisting of ADGE services developed and transformed in line with the e-Government architecture and related standards, and published on the shared government ESB in the form of application programming interfaces (APIs) on which digital services can be developed. As not every government service is a candidate of for mobile enablement, ADGEs should follow a well-defined planning process to identify and prioritize government services, which are mobile candidates, based on a clear criteria assessing potential impact and reach for each service, refer to m-Services Selection and Prioritization.

Furthermore, the modernization of government services is a cornerstone in the provision of m-Services and constitutes a major effort in the realization of the Abu Dhabi Government’s digital agenda. The major challenge in provisioning m-Services lies in the optimization and simplification of each service and underlying business processes so that it will fit the digital world in general, and the mobile channel in particular.

To elevate the impact of the m-Services, the development of whole-of-government services should be adopted, while providing an improved user experience and meeting regulatory and government requirements of providing Customer-Centric services. ADGEs are expected to lead this significant undertaking with support from ADSIC.

23


m-Services Target State Realization

Abu Dhabi m-Government is targeting a centralized m-Services access layer for all Abu Dhabi Government m-Services. The directory will serve as a common place to list Abu Dhabi Government

Services information through a simple and centralized interface (see Figure 9). This approach will bring several key benefits to Abu Dhabi Government constituents and ADGEs alike:

• A consistent user experience across all Abu Dhabi Government m-Services by providing m-Services that adhere to consistent usability and design standards

• Easy access to government information and services, offering constituents a single, consistent format for all Abu Dhabi Government m-Services

• Improved service quality across all Abu Dhabi Government m-Services, such that all developed m-Services adhere to the same high availability standards and service level agreements.

• Increased trust in government m-Services that rely on the shared e-Government identity management capability.

• Optimized investments in the development of m-Services across ADGEs through the target shared m-Services Delivery platform.

• Increased synergy, collaboration, and knowledge sharing across ADGEs in delivering Abu Dhabi Government m-Services, and in managing the central m-Services channel.

Figure 9: m-Services Target Access Model

24


In a collaborative and joint effort between ADSIC and ADGEs the realization of the target m-Services central access model will happen gradually and in TWO stages in order to minimize disruptions to the ADGEs’ current efforts of developing m-Services, until the fully centralized m-Services Access Model is completely implemented.

Stage 1: The interim m-Services architecture stage

During this stage ADSIC will establish the m-Services platform, and will extend the shared e-Government platform with the mobile-specific common services. Meanwhile, ADGEs in collaboration with ADSIC will work on confirming their respective m-Services portfolio and continue to develop the m-Services and expose them on the appropriate channels (web App) by default.

Once the m-Services platform is established, ADSIC in coordination with ADGEs will initiate the development of related transactional m-Services to deliver an initial set of m-Services; where ADSIC will focus on the development of the front-end user interface and the ADGEs will concentrate on the back-end services transformation efforts.

Stage 2: The m-Services architecture target state

When the fully centralized m-Services Delivery Platform is ready and the final stage of the conceptual architecture is reached, the ADGEs will use the m-Services platform to continue develop and implement all of their m-Services, choosing the mobile medium most appropriate for their distribution—primarily web apps—and then expose them through the m-Services directory.

Figure 10 illustrates the progression through the two stages of development of the m-Services conceptual architecture. The hybrid m-Services Access Model, which will provide ADGEs with access to the central m-Services delivery platform, will be adopted as an interim measure to minimize disruptions to the ongoing effort to develop m-Services, until the fully centralized m-Services Access Model is completely implemented.

Figure 10: m-Services Target Access Model

• ADGE m-Services Team Roles and Responsibilities 26

• m-Services Portfolio Planning 29

• The m-Services Selection and Prioritization Process 31

• Mobile App Delivery Medium Selection 37

• m-Services Design Considerations 43

• m-Services Governance Model 46

• m-Services Key performance indicators (KPIs) 49

ADGE m-Services Operating Model Requirement

26



The success of Abu Dhabi’s m-Services strategy will depend greatly on the ability of each ADGE to fulfill its role in the overall process. To accomplish this, ADGEs should implement the m-Services operating

model consistently, while cooperating with ADSIC for guidance and support. This section examines the four key components of the operating model:

• ADGE m-Services team roles and responsibilities

• m-Services Portfolio Planning

• m-Services Governance model

• m-Services Key performance indicators (KPIs).

ADGE m-Services Team Roles and Responsibilities

Ensuring the creation of properly staffed teams is a critical first step in adhering to the m-Services Strategy and rolling out successful m-Services initiatives. Each ADGE’s digital services team members will be responsible for all activities required to carry out the entity’s m-Services initiatives, including planning, development, implementation, and maintenance.

Two key digital services team roles, a Digital Leader and a Service Manager, are needed to elevate the ownership of the digital agenda within each entity, and to ensure clear ownership of the services transformation initiatives. As such, the digital leader and the service manager have specific key roles and responsibilities.

• Digital Leader: The role of Digital Leader should be at the Director General/Executive Director level, or the CIO of the entity.

• Service Manager: The role of Service Manager should be assigned to an employee who is a recognized reference on entity services matters with a deep understanding of the entity’s strategic and operational priorities.

• m-Services delivery Team: The role of m-Services delivery team should be assigned to the technical team who is responsible for the digital Services implementation.

27


Roles Key Resposibilities

Digital Leader

• Lead the development of entity-specific digital services strategy and entity m-Services portfolio in collaboration with entity stakeholders

• Ensure that the digital services strategy and roadmap are embedded in the entity’s planning process

• Oversee the annual digital services plan, implementation, and budget

• Ensure m-Services readiness and capability build-up within ADGE

• Measure and report on digital services program implementation progress

• Measure impact of digital services and propose related improvements

• Represent ADGE digital services team in interactions with ADSIC and ensure alignment with Abu Dhabi government m-Services strategy

• Participate in Digital Leader Council meetings to share best practices and lessons learned

Service Manager

• Support the development and implementation of the entity’s digital services strategy

• Take responsibility for the development of the entity’s digital services portfolio and implementa-tion agenda

• Support development of the entity’s annual digital services plan and budget

• Drive the vision for innovating and modernizing ADGE services

• Serve as a service owner and support digital services implementation activities, including re-quirements, design, development,

and testing

• Support the resolution of operational issues related to digital services

• Measure impact of digital services and propose related improvements

• Support the entity’s interactions with ADSIC and ensure alignment with Abu Dhabi’s overall government digital services strategy

• Coordinate with relevant departments within ADGE on digital services modernization

Table 2: Leadership Roles and Key Responsibilities

The Digital Leader and Service Manager will have their own unique set of responsibilities intended to ensure that the team’s ADGE can deliver the high-quality m-Services expected as part of Abu Dhabi’s overall m-Services strategy (see Table 2).

28


Equally important is the assignment of m-Services delivery roles to the ADGE digital services team, primarily consisting of six key positions (See Table 3):

Roles Key Responsibilities

m-Services Delivery Manager • Manages the m-Services development process throughout the lifecycle of each m-Service.

m-Services Business Analyst • Leads the functional design and analysis of all m-Services.

m-Services Visual Designer • Develops the visual and logical design of each m-Service.

m-Services Developer • Leads m-Services technical development and coding.

m-Services Content Developer • Develops content for m-Services in coordination with relevant ADGE departments.

m-Services Tester • Implements and oversees the quality assurance program for all m-Services.

Table 3: m-Services Delivery Role and Key Responsibilities

Note that these roles do not necessarily require new hires; they could be assigned to existing staff within the ADGE or to a third party (outsourcing).

29


m-Services Portfolio Planning

Every ADGE must consider carefully which services will comprise the m-Services portfolio. This section will define the concept of government services, and explain processes for selecting appropriate

m-Services, choosing the m-Services medium, and designing m-Services. A government service is an end-to-end process established by a government entity and intended to fulfil a specific need for specific users, including citizens, businesses, and employees. As such, there are four types of government services as showing in table 4:

Table 4: m-Services Delivery Role and Key Responsibilities

These government services can be delivered through any number of channels, including offline channels such as government offices, and online channels such as internet, and mobile devices. m-Services include any type of government services (G2C, G2G, G2B, and G2E) delivered through mobile channels, including feature phones, smart phones, and tablets.

30


When planning the m-Services portfolio, ADGEs should follow two key processes to identify and select only high-impact services that are best suited for mobile enablement, and that the right medium is chosen for delivering each m-Service.

11 m-Services Selection and Prioritization

• The m-Services selection and prioritization process analyzes every ADGE’s Services and filters them based on pre-defined m-Service criteria

• The process results in a list of candidate services for the mobile channel, and a prioritized order for implementation

21 m-Services Delivery Medium Selection

• The m-Services delivery medium selection process provides ADGEs with a clear rationalization for the optimal mobile delivery medium for each m-Service

• The process is exception-based—ADGE’s should provide justification for the decision to develop any m-Service as a native or hybrid app, backed by a clear business case

31


The goal of the government m-Services Strategy is to develop mobile capabilities for traditional government services as well as for e-services that may already exist. Not all government services, however, can be

transformed to m-Services. Whether or not any particular service is eligible to be transformed depends on the complexity of its underlying processes and the expected benefits of delivering it as an m-Service. The ability to report an accident immediately using a mobile phone with location-based technology, for example, might make it a better candidate for an m-Service than being able to fill out an application for issuing a passport.

Therefore, every potential mobile Service should be carefully assessed for eligibility to determine if it will meet the appropriate standards of impact and quality. The evaluation process should consist of an initial assessment based on whether or not the service can be transformed into an m-Service; those that pass this test should then be prioritized depending on their value as an m-Service (see Figure 11).

Figure 11: m-Services Selection and Prioritization Process

The m-Services Selection and Prioritization Process

23

ADGEs Services

Service 1

Service 2

Service 3

Service 4

Service 5

Service 6

Service 7

Service 8

Service 9

Service 10

Service 11

Service 12

Service 13

Service n

Eligible m-Services

Service 1

Service 3

Service 4

Service 5

Service 6

Service 7

Service 8

Service 9

Service 10

Service 11

Service 12

Service nm-ServicesInitial Assessment

Limiting BusinessProcess Requirements

Limited Reach

Complexity

m-ServicesPrioritization Criteria

Frequency of Usage

Reach

Simplicity of Usage

Automation

Immediacy

Location-Based

Service

m-Service 1

m-Service 9

m-Service 4

m-Service 11

m-Service 7

m-Service 12

m-Service 3

m-Service 2

m-Service n

Prioritized Short List

Rank

1

2

3

4

5

6

7

8

n

32


11 Initial m-Services Assessment

The goal of the initial assessment process is to determine which services are not eligible for delivery through a mobile channel. At this stage, three criteria are paramount:

• Limiting Business Process Requirements: Any service that requires the physical presence of the user to start or complete the process will not be suitable for mobile enablement. Notarizing a contract, for example, requires the physical presence of those involved as well as the availability of the relevant original documents; m-enabling it accomplishes no clear purpose.

• Limited Reach: Any service that reaches only a small segment of the target audience is not eligible for m-enablement, given its limited usage and minimal impact. The number of people applying for or renewing a fishing license, for example, is likely to be very small, and may include those who are not digitally enabled. Given its limited reach, the service should not be considered for mobile enablement.

• Complexity: Complex services that entail many steps, involve several separate entities, and require multiple attachments or lengthy user input forms are unlikely to benefit from being mobilized. Equally unsuited for m-enablement are services that require a complex registration or user onboarding process. An example might be issuing a passport, a complex, multi-step process

that requires filling out numerous lengthy forms and interacting with several different government entities.

21 m-Services Prioritization Criteria

Those services deemed eligible to be transformed into m-Services (passed initial assessment) should then be prioritized to determine the order in which the implementation process should proceed. This process should be based on six criteria: frequency of usage, reach, simplicity of usage, automation, immediacy, and location dependency. Each ADGE should assess its list of eligible services against each of these criteria and score them accordingly. Table 5 provides a more detailed description of each prioritization criteria and a guide to how to score them.

33


Dimensions and Weight Description Scoring1

Frequency of Usage (25%)

The number of times the service is used by the average target users each year

• 1: Service is used less than once a year

• 3: Service is used between 1-2 times a year

• 5: Service is used more than 3 times a year

Reach (25%)

The portion of the target audience the m-Service is expected to reach. The total number of people with a driving license would the target audience for an m-Service for renewing driving licenses

• 1: Less than 50% of the target audience is expected to use the m-Service

• 3: Between 50% and 80% of the target audience is expected to use the m-Service

• 5: More than 80% of the target audience is expected to use the m-Service

Simplicity of Usage (15%)

Simplicity of usage is a key driver for successful mobile app adoption. It can be determined by how quickly and easily users are able to consume government services through mobile channels. Key factors to consider when assessing how simple it is to use a m-Service include:

• Number of steps: The number of steps or screens the user goes through when consuming a government service. For example, a payment transaction may include retrieving the end-user record, validating or editing user data, selecting an item for payment, etc.

• Number of attachments: The number of attachments required to consume a government service. For example, a user might be required to upload several attachments, such as passport copies, Emirates ID, or a driver’s license to consume a service.

• Length of data entry forms: The number of data entry fields per form, or the number of forms required to consume a government service. Applying for a new passport, for example, or a title deed, will likely require filling out lengthy forms.

• 1: Service is complex, requiring more than 5 steps (screens) or more than 3 transactions, more than 3 attachments, or long data entry fields (more than 10) to execute

• 3: Service is moderately complex requiring 3 to 5 steps (screens) or 2-3 transactions, 1-2 attachments, or limited data entry forms (5-10 fields) to execute

• 5: Service is simple, requiring less than 3 steps or less than 2 transactions, 0-1 attachments, or minimal data entry form (less than 5 fields) to execute

Automation(15%)

The degree to which the service can be automated and the effort required to automate it—integrating back-end systems, for example.

• 1: Service is complex and requires effort to be automated

• 3: Service automation is moderate in complexity

• 5: Service is already automated (e.g. e-service)

Immediacy(15%)

The element of urgency or immediate need to create a government service (such as emergency-related services, the status of key transactions, or “on-the-spot” information services)

• 1: Service is not time-sensitive (e.g. Booking an Appointment)

• 3: Service is more convenient with immediate or fast delivery (e.g. reporting a traffic jam)

• 5: Service is very time sensitive (e.g. reporting a crime)

Location-Based(5%)

The dependency of the service on information that locates the user (e.g. GPS coordinates for the physical location of end-users when invoking the service)

• 1: Service is not enriched by or dependent on location information

• 3: Service is enriched by location information

• 5: Service is dependent on location information

Note (1)The assigned thresholds for each of the assessment criteria are subject to change to meet the requirements set by ADSIC

Table 5: m-Services Prioritization Criteria

34


Once the proposed m-Services are scored, they can be classified into three main priority categories determining their order of implementation:

• Priority 1 (Score of 4-5): High-impact services to be considered for first-phase enablement

• Priority 2 (Score of 3): Services to be considered for second-phase enablement

• Priority 3 (Score of less than 3): Services to be considered for mobile enablement in the future

Accompanying this toolkit is the m-Services Prioritization Criteria Template, which ADGEs should use to score and prioritize each of their planned m-Services (see Figure 12). The sidebar offers two examples of how the criteria for scoring m-Services should be used in practice.

Figure 12: m-Services Prioritization Criteria Template

35


Prioritization Criteria ExamplesThe following examples illustrate how the mechanism for scoring and prioritizing potential m-Services should be carried out:

Example 1: Paying a Traffic Fine

This is a simple service used at some point by the majority of the driving population, making it ideal for mobile channel enablement. The services received a score of 4 out of 5.

The table below highlights the scoring rationale.

Criteria Service Characteristics Score

Frequency of Usage Frequent usage (between 1-2 times a year) 3

Reach Wide reach targeting all drivers 5

Simplicity of Usage Simple to execute (retrieve record and pay fines) 5

Automation Already enabled on the portal, and back-end automation complete 5

Immediacy Rarely needed on a urgent basis, and moderately time-sensitive 3

Location-Based Not dependent on location data 1

Weighted Average 4

36


Prioritization Criteria ExamplesExample 2: Reporting an incident

This service can be used by residents in all age groups. It depends on location-based data, and delivering it immediately will greatly benefit all end users. Thus, it is ideal for mobile enablement. The service received a score of 3.9 out of 5. The table below highlights the rationale.

Criteria Service Characteristics Score

Frequency of Usage Frequent usage (between 1-2 times a year) 3

Reach Targets all UAE locals, residents, and visitors 5

Simplicity of Usage Requires moderate mobile literacy and the ability to attach incident photos and location 3

AutomationIntegrates simply with back-end operations and infrastructure to enable the reception of coordinates, pictures, and user information

3

Immediacy Satisfies the requirement for urgency of action when needed 5

Location-Based Uses location data 5

Weighted Average 319

Thus, both services can be categorized as high-impact services that should be considered for inclusion in the first phase of mobile enablement.

37


Each service chosen for mobile transformation (passed the m-Services Selection and Prioritization criteria) will require a particular set of functions to ensure optimal service delivery through the

appropriate channel. Matching the service being delivered with the appropriate delivery medium is an essential step in realizing the critical delivery goals of convenience, appropriate design, and efficient, high-quality services. Table 6 lists the three mobile app media through which m-Services can be delivered.

Mobile App Medium Description

Mobile Web App

• Mobile Web Apps are applications that are written with web technologies (HTML5, CSS, JavaScript), and have the look and feel of a native app. They are accessed through a device browser using a URL address and offer the widest range of device support.

Native Mobile App

• Native apps are installed on the device and accessed through icons on the device home screen. The apps are installed from a private app store (e.g. Google Play or Apple’s App Store). Native apps are developed specifically for each platform taking full advantage of device features and functionality.

Hybrid Mobile App

• Hybrid apps work like native apps and are installed through a private app store (e.g. Google Play or Apple’s App Store). A hybrid app is built using web technology, and wrapped in a platform specific shell, allowing developers to access native APIs and use device specific hardware features. In sum, a hybrid app is an app developed in combination with HTML 5 and native technology.

Table 6: m-Services Mobile Delivery Media

Mobile App Delivery Medium Selection

In determining the most suitable medium for an m-Service, the primary characteristics of each medium should be assessed with respect to the objective of the particular m-Service to be delivered and its target audience. Selecting the appropriate medium involves a number of key considerations that should be taken into account (see Figure 13):

Figure 13: Mobile App Medium Selection – Key Considerations

38


1 1 Time and cost for development and maintenance: Compared with mobile web apps, native and hybrid apps require special development skills for each of the operating systems they are developed for. As a result, they may be more costly and time-consuming to develop than mobile web apps, for which HTML5 skills are sufficient

21 Findability: m-Services delivered through web apps can be easily found using a simple search engine query and may be bookmarked for repeated usage. Finding specific native and hybrid m-Services for the first time, however, can be more complicated and is often hindered by the app store process itself, including limited descriptions of each app and the need to download them to the mobile device to discover related content.

31 Upgradability: Upgrading a native or a hybrid app is a lengthy process due to restrictions app store may place on the process and various security measures incorporated into the app. Moreover, this process does not guarantee full user adoption, as it is dependent on the willingness of users to update the app and on the compatibility of their smartphones with the upgrade. m-Services provided through web apps can be updated instantly simply by modifying the web app itself without end-user involvement.

41 Immediacy: Due to the more challenging process of downloading native and hybrid apps from the app store, first-time access to m-Services is likely to be delayed. Once on the device, however, they provide users with immediate access to m-Services. Web apps always provide immediate access to m-Services through a search engine, and they can be bookmarked.

51 Multi-platform Compatibility: Because native and hybrid apps need to be run on a variety of platforms, they should be developed across multiple platforms, such as the iPhone and Blackberry, to allow all constituents use the services. Web apps are HTML based, which makes them generally available across platforms and allows for increased reach while making use of fewer resources.

61 Graphics: Because native and hybrid apps have access to the device’s hardware, they can fully leverage all the functions of the mobile devices they run on, delivering a rich user experience along with complex interactions when needed. Web apps, however, have limited access to the device hardware, and so cannot deliver as rich a user experience or support for complex interactions and graphics.

71 Performance: Native apps typically deliver faster user-interface (UI) responsiveness, whereas web and hybrid apps are perceived to have slower UI response, as some of their components have to be rendered using HTML5.

81 Distribution: Native and hybrid apps are distributed through app stores while web apps are accessed directly over the web and do not require end user action.

91 Access to Device: Because native and hybrid apps are stored directly on the device itself, they can access all the device’s elements and functionalities. While web apps currently have more limited access to phone functions, the use of HTML5 is allowing them to access more device functions as the standard advances.

101 Notifications: Native and hybrid apps can provide users with push notifications and reminders when needed, whereas mobile web apps require refreshing the web content to receive notifications.

111 Device Storage: The data included in native and hybrid apps can be stored locally on the device, whereas the web apps data are stored on the server side. As such, there should be security consideration when using native or hybrid apps, to protect the data stored locally.

39


121 Location Awareness: All mobile apps can leverage location data from the device and use it as an input for m-Services.

131 Connection Requirements: Native and hybrid apps are stored on the device and can provide some informational services without being connected online, although all interactive and transactional services will require a mobile connection. Web apps do not yet offer offline storage capabilities, and require online access.

141 Technical Skills: Developing native apps—and to a lesser extent hybrid apps—requires specialized skills and areas of expertise for each operating system on which they are being developed. Developing Web apps only requires HTML5 skills to provide delivery across different platforms.

See Appendix A for a summary comparison of mobile app medium options along the key selection considerations:

The consequences of choosing one medium over another are critical, and that makes the choice a strategic one, which needs to be fully rationalized. The questions listed in Figure 14 can guide entities in determining the appropriate medium for each m-Service they plan to offer.

Figure 14: m-Services Mobile Delivery Medium Selection Questions

m-Services Delivery Medium Selection Process Steps

Doyourequiretheservicetobemobileplatformagnostic?

Doestheservicerequirearichuserexperiencefordelivery?No

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Doestheservicerequirenativefunctionalitynotavailablethroughwebapps?

Doyouhaveagressivetimelineorstrictbudgetconstraints?

Doyouhavetherequiredresourcesandcapabilitiestodevelopandsupportthemobileapplication?

Istheapptobeusedoffline?

InsufficientJustification

SufficientJustification

40


11 Does the service require a rich user experience for delivery?

m-Services requiring high interactivity, seamless navigation, object rich user interfaces, or fast user-interface responsiveness cannot be optimally provided through mobile web apps. As such, they are better provided through native or hybrid apps.

21 Does the service need to be platform-agnostic?

m-Services reaching a large target audience are more suited for mobile web apps due to the wide availability of browsers on a variety of platforms

31 Does the service require native functionality not available through web apps?

m-Services requiring native functionality that cannot be delivered through mobile web apps or supported by HTML5 are good candidates for development as native or hybrid apps.

41 Is the app to be used offline?

m-Services that require offline capabilities such as local data storage are good candidates for native or hybrid app development.

51 Is there an aggressive timeline or strict budget constraints for developing the app?

Native or hybrid apps are not ideal for m-Services projects with a strict budget or an aggressive timeline, since their development costs are relatively higher and they take longer to bring to market as they must first go through each app store’s listing process.

61 Are the resources and capabilities required to develop and support the mobile application currently available?

m-Services delivered through native or hybrid apps require resources with specialized skillsets, deep technical expertise, and the ability to provide constant development support to maintain the apps as the various platforms get updated and new versions of the device hardware are released by the respective vendors. Web apps, on the other hand, allow for support across different platforms, and only require HTML5 skills to develop.

41


m-Services Mobile Delivery Medium Selection Examples

The following examples illustrate how the mechanism for selecting the suitable m-Service delivery medium:

• Example 1: Paying a Traffic Fine

paying a traffic fine is a simple procedure that does not warned several steps to execution and high level of interactivity. Moreover, despite the fact that it is improved by seamless navigation, it does not require an object rich UI nor a particularly fast performance to support complex processes.

Figure 15: m-Services Mobile Delivery Medium Paying a Traffic Fine example

InsufficientJustification

Doyourequiretheservicetobemobileplatformagnostic?

Doestheservicerequirearichuserexperiencefordelivery?

No

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Doestheservicerequirenativefunctionalitynotavailablethroughwebapps?

Doyouhaveagressivetimelineorstrictbudgetconstraints?

Doyouhavetherequiredresourcesandcapabilitiestodevelopandsupportthemobileapplication?

Istheapptobeusedoffline?

SufficientJustification

Selection Process

42


In accordance with the “Web App by Default Guideline” (see Appendix D), ADSIC has determined that the mobile web app medium should be the default medium for all Abu Dhabi Government m-Services. The web app medium offers several advantages over the native and hybrid media:

• Cost: Because web apps are browser-based, they are “device-agnostic”—they can be developed once, delivered to any mobile device, and maintained and updated centrally, substantially lowering their total cost of ownership. Native and hybrid apps, in contrast, must be developed and maintained for each platform, a significantly more expensive and time-consuming process.

• Reach and Findability: Because web apps are device-agnostic, they can be easily found and accessed by users on any device, and do not require complex downloading processes. Native and hybrid apps, on the other hand, require the use of specific devices, restricting users’ ability to find and download them.

• Simplicity: Most m-Services do not require the complex interactions or object-rich user interface available with native or hybrid apps; web apps can be designed in a user-centric way to satisfy the requirements of most m-Services.

• Accessibility: Government m-Services must be available to all constituents and quickly accessed by users. Web apps offer rapid access, they can be bookmarked by users for repeat access, and their content and underlying processes can be easily updated.

Given that most government services are simple in nature and do not require complex processing or rich graphics, it is ADSIC’s view that mobile web app is the best suited medium for government m-Services, allowing for maximum target audience reach, while lowering the total cost of ownership. The decision to develop native or hybrid apps for government m-Services should be backed by a clear rationale detailing the cost benefit analysis.

43


m-Services Design Considerations

When designing m-Services, each entity’s m-Services delivery team should take into account key technology and design considerations which are specific to the context of m-Services. These

considerations can be behavioral (users may be distracted, the usage environment can be limited) or functional (users may have low bandwidth; some phones have limited display screen and input options).

m-Services teams can take these limitations into account by focusing on three key design elements:

• User-Centric Design: m-Services with a user-centric design are both more relevant to users and easier to use. User-centric design consists of three key elements (see Figure 16).

Figure 16: User-Centric Design Elements

Inclusion

User-Centric

NeedsContext

32

30

123456

Does the service require a rich user experience for delivery?

Does the service need to be platform-agnostic

Does the service require native functionality not available through web apps?

Is the app to be used offline?

Is there an aggressive timeline or strict budget constraints for developing the app?

Are the resources and capabilities required to develop and support the app currently available?

• Design for Inclusion: The Abu Dhabi Government’s mobile presence should be able to reach all users, including people with disabilities, accounting for user segments with varying degrees of mobile literacy.

• Design for Usage Context: In designing m-Services, developers should account for the mobile context, where user attention spans are shorter, screens are smaller, and input mechanisms may be limited.

• Design for User Needs: m-Services should focus on fulfilling the needs of targeted users, which will require a close analysis of the target user community how and when constituents use their mobile devices, now and in the future. Such needs include having a single access to government services, and aggregating all related services under one service instance through composite services.

• Cross-device Compatibility: Ensuring the all apps can be accessed by any device running on any operating system and through any web browser is essential in maximizing their reach. This includes tablets (such as Apple iPads, BlackBerry), smartphone operating systems (including Apple’s iOS, Android, and Windows) and web browsers (Opera, Chrome, Mozilla Firefox, and others).

(See Figure 17)

44


Figure 17: m-Services Cross Platform Support

Figure 17: m-Services Cross Platform Support

• User Engagement: Encouraging electronic engagement and integrating with social media platforms eases and improves interactions with constituents, thus enhancing the user experience. Figure 18 illustrates the six key user engagement channels to be leveraged.

Figure 18: User Engagement Channels

Social Media Plug Ins

Twitter Facebook Google+ FlickerMost FrequentlyAccessed Pages Top m-Services Live Chat

Customer Feedback

Feedback Forms Customer Satisfaction SurveyContact Center

Click to CallLocations

Nearest to you Email Us

Surveys Contact Us

FAQs

Quick Links Support

45


• Social media plug-ins: Linking directly to different social media simplifies the sharing of information and promotes user uptake. (e.g. users can share their experiences with ADGEs m-Services and encourage others to adopt the m-Services)

• Quick links: Providing quick links to the most frequently accessed m-Services and information from entities website sections will assist constituents and demonstrate the connected nature of the government.

• Support: Offering support by helping constituents complete transactions or find important information will promote the delivery of a user-friendly experience.

• Customer Feedback: m-Services delivery channel should offer users a form for filing complaints or reporting bugs and inconsistencies in their use.

• Surveys: Regular customer satisfaction surveys will help entities to improve their m-Services and support the iterative design process.

• Contact Us: m-Services delivery channel should provide the user with a means of contacting the government and getting additional support.

46


m-Services Governance Model

The Abu Dhabi Government m-Services Strategy is an integral part of the overall digital agenda of the Abu Dhabi Government, and requires a strong governance model to ensure that it is fully aligned with

the implementation goals of the Abu Dhabi Government strategy.

As such, the implementation of every ADGE’s m-Services strategy should be governed by the existing services modernization governance model, and comply with the same policies and standards. In reaching those implementation goals, ADGEs must also maintain and monitor the key performance indicators (KPIs) needed to manage progress, a critical aspect of the overall governance process.

In addition to the Executive Council and the existing e-Gov Services Transformation Program, which steers the delivery of the m-Services program, three primary groups will govern all government digital services (including m-Services) in Abu Dhabi (see Figure 19).

• Digital Government Board: This is the primary governance body. Its role is to make key decisions regarding the digital services agenda and to ensure alignment between the Abu Dhabi Government m-Services Strategy and the overall e-Government strategy.

• Digital Services Working Group: This body assesses and reviews all current and future digital services initiatives, oversees and reviews the progress of the ADGEs’ digital projects, and alerts the Digital Government Board to issues and concerns when they arise.

It also approves the ADGEs’ m-Services plans and demand requests and supports them in delivering their m-Services program.

• Digital Services Leaders Forum: This body is designed as a platform for capturing feedback from the ADGEs regarding best practices and issues in carrying out their digital services agenda, and provides thought leadership to the ADGEs on emerging and future trends.

Figure 19: Digital Government Governance Bodies

47


The target governance model is intended to elevate the ownership and accountability of the m-Services strategy and the overall digital agenda within the Abu Dhabi Government, and to provide the sponsorship and oversight needed to ensure the successful implementation of the Abu Dhabi Government m-Services Strategy.

It is designed to allow all stakeholders, including ADGEs, to become directly involved in the decision-making process as members of the Digital Government Board, and to play a key role alongside ADSIC when reviewing and approving the m-Services Strategy, services portfolio, and all related IT initiatives, as members of the Digital Services Working Group.

The model will be further supported by the Digital Services Leaders Forum, a bi-annual meeting during which each ADGE’s IT and business leaders, together with ADSIC’s strategy and operations directors, can review and assess technology requirements across ADGEs, and present recommendations on optimizing and creating synergies among the various m-Services initiatives (see Table 7).

Governance Body Key Roles and Responsibilities

Digital Government Board

• Review and approve e-Gov portfolio, and related priorities and initiatives

• Review critical issues and risks in the modernization of government services,

and make recommendations to resolve and mitigate them

• Review key performance indicators (KPIs) for e-Gov services, infrastructure,

architecture, process, and people, and propose improvements or corrective

measures

• Review and approve service-level agreements (SLAs) for the e-Gov services

portfolio, review performance against SLAs and strategic objectives, and

propose improvements accordingly

• Assess e-Gov program implementation progress and resulting impact

• Elevate to Abu Dhabi leadership key recommendations and decisions for

endorsement and enactment

• Report to Abu Dhabi Executive Council on overall progress on government

services modernization

48


Governance Body Key Roles and Responsibilities

Digital Services Working Group

• Review and approve m-Services strategy, portfolio, and related IT initiatives

• Review m-Services demand requests from ADGEs and assess demand alignment against e-Gov strategy and business objectives

• Recommend to Digital Government Board approval, adjustment, or rejection of ADGEs m-Services demand requests

• Support procurement process and review key sourcing decisions for m-Services initiatives

• Review escalated issues/ risks relating to delivery and operations of m-Services, and make recommendations to mitigate them

• Elevate to Digital Government Board key recommendations and decisions for endorsement and enactment

• Review m-Services program KPIs and report on progress

• Report to Digital Government Board overall progress on m-Services program realization

Digital Services Leaders Forum

• Review e-Gov strategy and related implementation progress

• Promote the m-Services concept to stakeholders and customers

• Seek and support opportunities for working jointly across government entities on the digital agenda

• Share learning and best practices in the delivery of the digital agenda across government entities

• Champion improvements to services delivery across government

• Provide strategic governance for the m-AbuDhabi single domain

• Recommend policies, standards, and procedures for mobile technologies, and act a focal point for cross agency initiatives

• Review and assess technology requirements across ADGEs, and present recommendations for the realization of optimization and synergies initiatives

In sum, the target governance model aims to:

• Develop governance bodies to regulate engagement and streamline governance activities around digital services planning, delivery, and operations

• Define key m-Services guidelines and standards and relevant compliance models

• Institutionalize the m-Services performance management framework across the m-Services value chain

Table 7: Governance Bodies – Key Roles and Responsibilities

49


m-Services Key Performance Indicators (KPIs)

Effective governance of the m-Services agenda and implementation process will require that all m-Services initiatives be monitored throughout their development and delivery lifecycle, to ensure that

they meet the requirements and expectations outlined in the Government m-Services Strategy. To do so, in coordination with ADSIC, ADGEs will develop a set of key performance indicators (KPIs) for each stage of the m-Service lifecycle, and then track them regularly and consistently. The development lifecycle consists of three main phases: Plan, Build, and Run (See Figure 20).

Figure 20: Performance Management across m-Services Lifecycle

• The Plan phase of m-Services involves planning the m-Services portfolio, and preparing project development and implementation plans in line with entity’s strategic objectives. Table 8 lists KPIs that ADGEs should monitor at this stage:

# KPI Description

1 Planned m-Services Percent of overall service portfolio that is candidate for mobile enablement

2 m-Services/Services Ratio Percent of overall service portfolio that is mobile enabled

3 Average Cost per m-Service

Average planned cost per m-Service project (total m-Service budget divided by the number of m-Service projects)

4 m-Services Budget Percent of the overall IT budget to be spent on new m-Services projects

5 m-Services User Engagement

Number of planned m-Services user engagement initiatives per year (including surveys, polls, etc.)

6 m-Services Marketing Number of m-Services promotional campaigns planned per year

Table 8: Plan Phase KPIs

Each phase has a set of KPIs associated with it:

50


• The Build phase of the m-Services development lifecycle relates to m-Services development, including coding, content generation, visual design, quality control, and testing as well as managing the financials of each m-Services project. Table 9 lists KPIs that ADGEs should use to monitor development:

# KPI Description

1 m-Services Projects in Development Percent of m-Services services in the development stage

2 m-Services Development Duration

Average number of days spent on the development of all m-Service applications

3 Success Rate Percent of m-Service projects successfully completed on time and on budget

4 Budget Overrun Rate Percent of total m-Service development projects with actual m-Service project costs greater than budgeted m-Service project cost

5 m-Service Budget Actual m-Service project cost as a percentage of budgeted m-Service project cost

6 Integration Time Average time spent automating or integrating backend services on the shared government platform for conversion to an m-Service

Table 9: Build Phase KPIs

51


• The Run phase involves the rolling out of m-Services and maintaining them in production. ADGEs should constantly monitor each m-Service to identify and apply potential areas of improvement, and to ensure the m-Service is meeting its strategic objectives and usage targets. For a list of possible KPIs to monitor at this stage (See Table 10 ).

# KPI Description

1 Total Visits Number of total visits to each m-Service application (both native and mobile web apps)

2 Application Downloads Total number of mobile applications downloaded by users (from the app store, for example)

3 Active Users Average number of active m-Service users per m-Service application

4 Convergence Rate Percent of visits by users which result in use of the app (both native app download and mobile web app usage)

5 Retention Rate Percent of users retained at set periods of time (the 1, 7, and 30-day mark, for instance) after application was first used or downloaded

6 Usage Time Average time users spent interacting with an m-Service

7 Number of Transactions Average number of transactions executed per m-Service

8 Bounce Rate Percent of users that leave after visiting only the web app’s landing page

9 Cancelled Transactions Percent of m-Service transactions cancelled by end-users prior to completion

10 User Satisfaction Percent of users who say they are satisfied with each m-Service

11 Number of Complaints Number of m-Service complaints received

12 Number of Resolved Complaints Percent of m-Service complaints addressed and resolved within a specific timeframe (as set by the services level agreement)

13 m-Services Ticket Resolution Time Average time between the opening and closing of an m-Services support ticket

14 Availability Rate Percent of time the m-Services platform is up and running per year

15 Average Hack Attempts Average number of failed security breach attempts

16 Software Issues Average number of bugs found per m-Service application

17 Software Issues Resolution Percent of fixed versus logged bugs found in m-Service applications

18 Promotion Expenses Percent of overall marketing budget spent on promoting m-Services

19 Operating Cost Average amount spent on operating m-Services (e.g. OPEX)

Table 10: Run Phase KPIs

ADGE Actions for m-Services Strategy Implementation• Appendix A: Summary Comparison of m-Services Delivery Media 59

• Appendix B: Digital Leadership Guideline 60

• Appendix C: m-Services Qualification Guideline 64

• Appendix D: Web App by Default Guideline 68

• Appendix E: m-Services Mobile App Medium Selection Guideline 70

53

ADGE Actions for m-Services Strategy Implementation

To remain fully aligned with the Abu Dhabi Government m-Services Strategy and ensure its full realization, every ADGE should take FOUR key actions decided to enable the m-Services Strategy. These actions

are designed to enable a well-regulated digital services operating model that will promote effective collaboration in the delivery of the ADGE’s m-Services, in accordance with the m-Services Guidelines discussed below.


1Action Steps

As a first step in carrying out the m-Services agenda, ADGEs must ensure that have the capabilities and skills needed to develop and implement the portfolio of m-Services, as well as a plan for training employees to equip them with the necessary expertise. This will require FOUR distinct steps (Refer to Section m-Services team roles & responsibilities) :

Build Internal m-Services Capabilities

• Establish clear ownership within ADGE who is to own and drive the digital services agenda, and define accountability within the ADGE’s leadership. In accordance with the “Digital Leadership Guideline (Appendix B)”, ADGE needs to appoint the following:

¤ Digital Leader responsible for owning and sponsoring the ADGE’s digital services agenda, and accountable for its realization.

¤ Service Manager who will be responsible for leading and guiding the ADGE’s digital services implementation.

• Augment the ADGE’s internal operating model with dedicated roles devoted specifically to supporting the planning and management of m-Services implementation, and owning their delivery from start all the way till Ready for Use state. As outlined in Section “m-Services team roles & responsibilities”, the m-Services delivery roles will consist of:

¤ m-Services Delivery Manager: Manages the m-Services development process throughout the lifecycle of each m-Service.

¤ m-Services Business Analyst: Leads the functional design and business analysis of all m-Services.

¤ m-Services Visual Designer: Develops the visual and logical design of each m-Service.

¤ m-Services Developer: Leads m-Services technical development and coding.

¤ m-Services Content Developer: Develops content for m-Services in coordination with relevant ADGE departments.

¤ m-Services Tester: Implements and oversees the quality assurance program for all m-Services.

• Identify training requirements and develop, in coordination with ADSIC, a training plan addressing current business needs as well as future requirements.

• As a result of this action, submit the m-Services team members list and training program to ADSIC.

54


Working with ADSIC, the ADGEs Service Manager should identify the ADGE services portfolio which includes the list of all government services (G2C, G2G, G2B & G2E) with their details. After obtaining the ADGE Digital Leader approval, the ADGE services portfolio will be incorporated into the centralized Government Services Portfolio (Refer to Section m-Services Portfolio Planning):

Develop ADGE m-Services Portfolio

• Confirm with ADSIC the current services portfolio, list of all services (G2C, G2G, G2B & G2E) including service details i.e. description, process, fees, delivery channel etc.

• Identify which information or service is needed to be shared or integrated with other government entities services or consumed from other government entities in order to identify the government interoperability requirements.

• Obtain Digital Leader approval for the ADGE services

• Submit the approved services portfolio to ADSIC

• Maintain the services portfolio updated in coordination with ADSIC.


2Action Steps

55



After finalizing the services portfolio, the ADGEs Service Manager in coordination with ADSIC shall develop the 2-year m-Services Transformation plan with clear smart objectives that details m-Services rollout plan, resources and estimated budget. The steps below outline the process for selecting appropriate m-Services, deciding on the best mobile medium for implementation and developing m-Services Transformation plan.

Develop m-Services Transformation Plan

• Identify potential ADGE-specific services that are candidates for mobile enablement over the next two years.

• Apply the m-Services qualification and selection process, as detailed in the “m-Services Qualification guideline” (Appendix C), to the identified services to ensure that those services with the most impact are identified and prioritized for mobile enablement.

• Apply the mobile medium selection process as detailed in the “Web App by Default Guideline” and the “m-Services Mobile Deliver Medium Selection Guideline”, for all candidate m-Services to Identify the most appropriate mobile medium per m-service.

• Finalize the list of prioritized m-Services, in coordination with ADSIC, and develop the annual plan for their development in accordance with the 2-year transformation plan.

• Estimate budget required to implement, operate and maintain the m-Services and share the plan with ADSIC as per the annual budget review process.

• In coordination with ADSIC define the relevant m-Services KPIs as outlined in section m-Services Key performance indicators (KPIs)

• Obtain Digital Leader approval for the services transformation plan.

• Submit approved m-services Transformation plan to ADSIC

3Action Steps

56



Once the m-Services Transformation plan has been approved, the ADGE Service Delivery team should start implementing the plan to deliver m-Services and bring them to a Ready for Use state. ADGEs may develop their own m-services delivery platforms in the interim stage while always leveraging the existing shared e-Government infrastructure. However, once the target e-Government m-services delivery platform implementation is completed, ADGEs should rely on the central Abu Dhabi Government m-Services Delivery Platform for the delivery of their m-services. The steps to be taken at each stage are outlined below (Refer to Section m-Services Conceptual Architecture:

Deliver m-Services

Stage 1 :During the interim m-Services architecture stage, ADGEs should:

• In consultation with ADSIC, rationalize any new investments for procuring a mobile delivery platform and any related components to ensure alignment with the target m-services delivery platform to be designed and implemented by ADSIC.

• Leverage existing investments in mobile delivery platforms by ADGEs, wherever applicable, to develop and rollout m-Services in compliance with the m-Services Strategy guidelines.

• Services Delivery team should design m-services around the Citizen or Business (customer) needs in line with a Customer-Centric approach to provide a consistent user experience across all government m-Services.

• Services Delivery team should develop the m-services by leveraging existing shared e-Government infrastructure taking in consideration the following guiding principles:

4Action Steps

4

3

2

ADGEs should modernize their back-end services, exposing them through re-usable service APIs on the shared e-Government ESB. This will enhance interoperability throughout the Abu Dhabi Government and all ADGEs.

ADGEs should rely on the shared e-Government Single Sign-On component to elevate the security and facilitate m-Services user authentication, identity management and maintain a centralized users profile.

Leverage the existing e-Payment and messaging gateways the ADGEs currently use for the e- and m-Services portfolio, or those deployed by third parties such as vendors.

Adopt, where feasible, the “Web App By Default Guideline” (see Appendix D) while selectively developing native or hybrid m-Services apps when absolutely necessary.

1

57



Action Steps

Aggregate m-Services under each app technology used—native, hybrid, or web app—to minimize the ADGE’s instances of duplicate apps

Centralize access to current m-Services, where possible, by providing a single point of access to all existing apps on the ADGE website, thus enhancing the findability of m-Services by end-users

Leverage existing service usage terms and conditions when applicable, including existing privacy and data protection policies

Coordinate with ADSIC to link the modernized m-Services with Abu Dhabi Government Mobile Delivery Platform.

• Plan and conduct awareness campaigns to increase user uptake.

• Obtain frequent feedback from constituents on user satisfaction and use it to continuously update and improve each m-Service and to build a repository of lessons learned.

• Track KPIs throughout the m-Services development lifecycle - Plan, Build, Run - and take corrective action to ensure that targets are achieved as planned, report the KPIs status to ADSIC.

• In coordination with ADSIC maintain updating the Service portfolio status periodically.

8

7

6

5

58


In conclusion, while carrying out the above actions, ADGEs should comply with four foundational guidelines covering (see Appendices B-E):

1- Digital Leadership

2- m-Services Qualification

3- Web App by Default, and

4- m-Services Mobile Medium Selection

The goal of these guidelines is to aid the ADGEs in choosing digital leaders and service managers who are best suited to carry out the planning and implementation of m-Services. The guidelines also aim to assist ADGEs in planning for the m-Services roll-out, choosing the most appropriate and valuable services for mobile enablement, and deciding on the appropriate service design and medium for the most efficient delivery of each service.

Stage 2 : Once the Abu Dhabi Government m-Services delivery platform completed, ADGEs should:

• Migrate existing G2C and G2B m-Services to the central Abu Dhabi Government Mobile Delivery Platform in accordance with consolidated Abu Dhabi Government m-Services Transformation plan.

• Publish each G2G and G2E m-Services on a centralized Abu Dhabi Government App Center and leverage the centralized Abu Dhabi Government Mobile Device Management platform.

• Develop new m-Services on ADSIC’s mobile delivery platform, in compliance with the m-Services Strategy guidelines.

• Publish the ADGE’s m-Services portfolio on a centralized m-services directory managed by ADSIC.

• Follow ADSIC’s m-Services standards and design guidelines.

• Integrate all m-Services with a centralized government-wide e-Payment gateway.

• Leverage Abu Dhabi Government Identity Management framework for m-Services security, using a common user profile across all Abu Dhabi Government services and channels.

• Plan and conduct awareness campaigns to increase user uptake

59


Appendix A: Summary Comparison of m-Services Delivery Media

# Considerations Native App Web App Hybrid App

1Time and cost for development and

maintenance

Time-consuming to develop and update, with high

maintenance costs

Less time-consuming, with high

maintenance costs

Time-consuming, with high maintenance cost

2 Findability Limited findability of specific m-Services

Easily found through a search engine

Limited findability of specific m-Services

3 Upgradability Dependent on app store

processes and downloads by users

Instant and comprehensive

Dependent on app store processes and downloads by users

4 ImmediacyDelayed first-time access to m-Services (due to app store

download process)

Immediate access to m-Services at all

times

Delayed first-time access to

m-Services (due to app store download process)

5 Multi-platform Compatibility No Yes No

6 Graphics Native APIs HTML, Canvas, SVG HTML

7 Performance Fast Slow Slow

8 Distribution Application Store Web Application Store

9 Access to Device Yes Limited Yes

10 Notifications Yes Yes (through browser refresh) Yes

11 Device Storage Yes No Yes

12 Location Awareness Yes Yes Yes

13 Connection Requirements Online and offline Online Online and offline

14 Technical Skills Objective C, Java HTML5, CSS HTML5, CSS, JavaScript

60


Appendix B: Digital Leadership Guideline

11 Guideline Purpose

The purpose of this guideline is to highlight Abu Dhabi Government’s position on the assignment of the digital leader and service manager positions within each Abu Dhabi Government Entity (ADGE), and their respective roles, responsibilities, and qualifications.

The guideline targets and applies to all ADGE management responsible for assigning these digital leadership roles.

21 Guideline Overview

The Abu Dhabi e-Gov vision is to become a “high-performance government” that provides its constituents with high-impact government services through digital channels. To achieve this goal, ADGEs are required to build the internal capabilities needed to deliver government services through the appropriate digital channels, especially on the mobile channel and as part of the “mobile Government” initiative. ADGEs are required to elevate the ownership of the digital services agenda to the highest leadership levels—those with the authority necessary and the clear roles and responsibilities required to carry out the agenda. This will promote the oversight required for each ADGE’s digital transformation program, and ensure the successful realization of the ADGE’s m-Service strategy as it relates to its overall digital agenda.

The purpose of this guideline is to help ADGEs choose a Digital Leader and Service Manager who can assume accountability for the entity’s digital agenda and can drive and support the entity’s digital services transformation. The guideline also defines the Digital Leader’s and Service Manager’s key roles and responsibilities.

Digital Leader

a. Roles and Responsibilities

The Digital Leader is responsible for driving the development of the ADGE’s digital agenda (including m-Services), and overseeing its implementation in coordination with the entity’s management team. As such, the Digital Leader plays an active role throughout all phases of the digital services implementation lifecycle.

During the strategy and planning phase, the Digital Leader should:

• Act as the single point of contact for the entity’s strategic interactions with ADSIC

• Oversee the development of the entity’s digital services strategy in collaboration with entity stakeholders, and in line with the ADGE’s digital strategy and the Abu Dhabi Government’s m-Services strategic imperatives

• Approve the entity’s m-Services portfolio

• Ensure that the digital services strategy and roadmap are embedded in the entity’s overall planning process

• Approve the annual digital services plan and budget

61


During the implementation phase, the Digital Leader should:

• Ensure that the ADGE is both ready to implement the m-Services agenda and has the capabilities to do so.

• Oversee the implementation of the digital services strategy

• Report on progress in implementing the digital services program

• Assess the impact of digital services and propose related improvements

Finally, the Digital Leader should represent the ADGE when communicating with internal and external stakeholders. Accordingly, the Digital Leader should:

• Represent the ADGE in key interactions with ADSIC and ensure alignment with the Abu Dhabi government’s digital services strategy, including m-Services

• Participate in Digital Leader forum meetings to share best practices and lessons learned

• Ensure that the entity’s internal communication plan is aligned with its m-Services strategy and mandate

b. Qualifications

The role of Digital Leader should be at a Director General/Executive Director level, or the CIO of the entity.

Preferably, the assigned leader will have experience in leading transformation programs inside or outside the government, and an understanding of the Abu Dhabi government’s e-Gov and m-Services strategies and related implications for the ADGE.

Service Manager

a. Roles and Responsibilities

The Service Manager is responsible for supporting the development and delivery of the ADGE’s digital services agenda, including m-Services. The Service Manager also coordinates with the m-Services project delivery team and plays a key role throughout every phase of the digital services implementation lifecycle

During the strategy and planning phase, the Service Manager should:

• Support the development and implementation of the entity’s digital services strategy

• Own the development of the entity’s digital services portfolio

• Support the development of the entity’s annual digital services plan and budget

62


During the implementation and maintenance phase, the Service Manager should:

• Drive the vision for innovating and modernizing the entity’s digital services

• Own the digital services implementation agenda

• Serve as a service owner and support all digital services implementation activities, including requirements, design, development, and testing

• Represent the entity’s views on services transformation activities

• Support the resolution of operational issues related to digital services

• Measure the impact of digital services and propose related improvements

Finally, the Service Manager should also represent the ADGE when communicating with internal and external stakeholders. Therefore, the Service Manager should:

• Support all entity interactions with ADSIC and ensure alignment with the Abu Dhabi government’s digital services strategy

• Coordinate with the relevant departments within the ADGE on all digital services modernization efforts

b. Qualifications

The role of Service Manager should be assigned to an employee who is recognized as an expert reference on the entity’s digital services matters, has a deep understanding of the entity’s strategic and operational priorities, and has strong management skills in all planning, delivery, and operational activities.

Finally, the Service Manager should be knowledgeable about the Abu Dhabi’s government’s e-Gov and m-Services strategies and its implications for the ADGE.

31 Guideline Adoption

This guideline should be considered as each ADGE develops its internal digital services capabilities and assigns its digital services leadership roles, as mandated by the Abu Dhabi m-Services Strategy.

4. Exceptions

N/A

63


51 Definitions

Digital Services Leader Forum: A consultative body formed by ADSIC to include Digital Leaders across ADGEs to promote the digital agenda and seek opportunities for working together across ADGE boundaries to carry out the digital agenda.

The forum will also review and assess technology requirements across ADGEs and present recommendations on optimization opportunities across digital services initiatives

m-Services: Government services delivered through mobile medium channels. These services can be atomic (the lowest level of service granularity) or composite (a service consisting of several atomic services).

64


Appendix C: m-Services Qualification Guideline


The purpose of this guideline is to highlight the position of the Abu Dhabi Government on the selection and prioritization of government services for mobile channel enablement, and the composition of every Abu Dhabi Government Entity (ADGE) m-Services portfolio.

This guideline targets and applies to every ADGE Digital Services team responsible for the development and implementation of m-Services.

2. Guideline Overview

The Abu Dhabi Government strives to deliver high-impact government services through digital channels that can simplify the interaction between government entities and their constituents, improve service delivery, and promote end-user satisfaction and service uptake.

As such, the Abu Dhabi Government is seeking to further modernize the government’s service portfolio through the delivery of government services on mobile channels, or m-Services. However, not all government services are eligible for enablement on mobile channels.

Careful analysis and evaluation of each candidate government service is needed to ensure that the investment of time and effort by ADGEs to extend services through mobile channels will yield the expected benefits.

This guideline will help ADGEs identify the high-impact services to be provided through mobile channels and provides guidance for digital services managers when nominating and prioritizing government services for mobile enablement through the m-Services Selection and Prioritization process.

The process is meant to assist ADGEs in identifying and prioritizing m-Services using two main filters:

• The initial assessment is designed to help ADGEs identify government services which are not candidate for mobile channel enablement

• The prioritization criteria are intended to aid ADGEs in prioritizing target m-Services based on six key dimensions

m-Services Initial Assessment

The eligibility of a service should be evaluated carefully prior to mobile channel enablement to ensure the delivery of high-impact and high-quality m-Services to constituents. An initial assessment of the services’ relevance should be conducted to short-list candidate services for mobile enablement. Three key factors should be considered by the ADGE m-Services team when filtering services for mobile channel enablement during the initial assessment:

• Services with limiting business process requirements should be excluded from the m-Services eligibility pool (such as services requiring the user’s physical presence)

65


• Services with limited reach should be excluded from the m-Services eligibility pool (such as services targeting the least connected segment of the population or a small percentage of the addressable target audience)

• Services with high complexity should be excluded from the m-Services eligibility pool (such as services involving lengthy user input forms or multiple attachments)

m-Services Prioritization

The priority of the remaining services should be assessed and scored based on predetermined criteria to ensure that the highest impact services are rolled out first. ADGEs should assess the short-listed m-Services against each of these criteria and score them accordingly. The scored m-Services should then be classified into three main priority categories that will determine their order of implementation:

• Priority 1 (Score of 4-5): High-impact services to be considered for the first phase of enablement

• Priority 2 (Score 3): Services to be considered for the second phase of enablement

• Priority 3 (Score 3): Services to be considered for mobile enablement in the future

The following table provides a more detailed description of each prioritization criteria and the score associated with the different attributes of each criterion:

66


Dimensions and Weight Description Scoring1

Frequency of Usage (25%)

The number of the times the service is used by the average target users each year

• 1: Service is used less than once a year

• 3: Service is used between 1-2 times a year

• 5: Service is used more than 3 times a year

Reach (25%) The portion of the addressable audience the m-Service is expected to reach

• 1: Less than 50% of the addressable audience is expected to use the m-Service

• 3: Between 50% and 80% of the addressable audience is expected to use the m-Service

• 5: More than 80% of the addressable audience is expected to use the m-Service

Simplicity of Usage (15%)

Simplicity of usage is a key driver for successful mobile app adoption. It can be determined by how quickly and easily users are able to consume government services through mobile channels. Key factors to consider when assessing how simple it is to use a m-Service include:

• Number of steps: The number of steps or screens the user goes through when consuming a government service. For example, a payment transaction may include retrieving the end-user record, validating or editing user data, selecting an item for payment, etc.

• Number of attachments: The number of attachments required to consume a government service. For example, a user might be required to upload several attachments, such as passport copies, Emirates ID, or a driver’s license to consume a service.

• Length of data entry forms: The number of data entry fields per form, or the number of forms required to consume a government service. Applying for a new passport, for example, or a title deed, will likely require filling out lengthy forms.

• 1: Service is complex, requiring more than 5 steps (screens) or more than 3 transactions, more than 3 attachments, or long data entry fields (more than 10) to execute

• 3: Service is moderately complex requiring 3 to 5 steps (screens) or 2-3 transactions, 1-2 attachments, or limited data entry forms (5-10 fields) to execute

• 5: Service is simple, requiring less than 3 steps or less than 2 transactions, 0-1 attachments, or minimal data entry form (less than 5 fields) to execute

Automation (15%)

The degree to which the service can be automated and the effort required to automate it—integrating back-end systems, for example.

• 1: Service is complex and requires effort to be automated

• 3: Service automation is moderate in complexity

• 5: Service is already automated (e.g. e-service)

Immediacy (15%)

The element of urgency or immediate need to create a government service (such as emergency-related services, the status of key transactions, or “on-the-spot” information services)

• 1: Service is not time-sensitive (e.g. Booking an Appointment)

• 3: Service is more convenient with immediate or fast delivery (e.g. reporting a traffic jam)

• 5: Service is very time sensitive (e.g. reporting a crime)

Location-Based (5%)

The dependency of the service on location information (e.g. GPS coordinates)

• 1: Service is not enriched by or dependent on location information

• 3: Service is enriched by location information

• 5: Service is dependent on location information

67



This guideline should be adopted by the ADGE’s m-Services team when planning the entity’s m-Services portfolio.

41 Exceptions

In cases where the ADGE’s m-Services team believes that a service which scores low when applying the prioritization criteria should be deemed eligible for mobile channel enablement, or should have a higher priority for implementation:

• The Service Manager should provide the Digital Leader with a rationale for granting an exception to enable the given service through mobile channels, or to assign a higher priority for implementation.

51 Definitions

Service complexity/ simplicity of usage: The effort required for m-Service delivery or transaction completion (e.g. registration process, number of steps to completion, length of input forms)

Service reach: The size of the service target audience (e.g. size of addressable population, mobile capabilities of target population)

Service business process requirements: The business processes required for transaction completion or validation (e.g. user’s physical presence)

68


Appendix D: Web App by Default Guideline


The purpose of this guideline is to highlight the position of the Abu Dhabi Government concerning the provisioning of government m-Services through native, web, or hybrid apps. This guideline targets and applies to each Abu Dhabi Government Entity (ADGE) Digital Services team that is formally responsible for the development of m-Services on behalf of its entity.


In line with its vision to deliver world-class services for the benefit of all its customers, the Abu Dhabi Government is seeking to further modernize its government services portfolio through the delivery of government services on the mobile channel, or m-Services.

In delivering m-Services, it is critical to decide on the technology medium to be used to deliver the m-Service. In general, there are three options for ADGEs to consider:

• Native app

• Web app

• Hybrid app

Each technology medium has many advantages and disadvantages. However, for most Abu Dhabi Government m-Services, particularly government-to-citizen (G2C) and government-to-business (G2B) m-Services, the guideline recommends that ADGEs use web apps by default. The use of web apps for provisioning government services is optimal, for several reasons:

• Lower total cost of ownership: Web apps are device-agnostic and do not require the development and maintenance of multiple versions for different devices and operating systems. Native apps, on the other hand, require the development of separate versions for each operating system and should be constantly updated to keep up with the ever-changing mobile environment. However, the government cannot control whether or not the target audience is adopting the latest application versions. This forces the government to maintain backward compatibility in addition to device compatibility, which further increases the total cost of ownership for native or hybrid applications.

• Increased findability of web apps and specific services: Services provided through mobile web apps are developed in HTML and are therefore easily visible to search engines. Embedding an m-Service into a native app decreases search engine visibility, because the user might need to download the application in order to review all services offered.

• Immediate access to services: Web apps allow the user to engage immediately with the government and execute m-Services without the need to download a native or a hybrid app beforehand.

• Upgradability of web app content and services: Web apps ensure that m-Services are accurate and leverage the latest software releases with no action required by the end user to download new software releases.

• Multi-platform availability: Because web apps are developed on HTML code, they are inherently device-independent and can readily reach a wider audience. Moreover, web apps can be accessed on new devices with no extra effort or investment, since they run on mobile browsers irrespective of changes in devices’ operating systems.

69


Furthermore, HTML 5 is evolving rapidly, and most leading government m-Services programs are embracing it as a standard, since it meets most of the requirements for government m-Services, which do not require complex interactions or object-rich user interfaces.


This guideline should be adopted by all ADGE Digital Services teams when developing their entity’s m-Services

41 Exceptions

In cases where an ADGE believes that a specific G2C or G2B m-Service is better delivered through a native or a hybrid app, it should:

• Ensure the service in question has passed the m-Services qualification criteria as per the “m-Services Qualification” guideline

• Consider the rationalizations provided in the “m-Services Mobile Medium Selection” guideline

• Provide the Digital Leader with a detailed business case internally

• Validate the case for native or hybrid app development with the ADSIC team

For government-to-employee (G2E) and government-to-government (G2G) applications, ADGEs can choose the technology medium that best meets their requirements.

The key difference for G2E and G2G m-Services is that government entities have greater control over the target audience and the devices they use to run these services.

This allows entities, for example, to dictate or provide the type of devices and enforce timely software updates by all users.

51 Definitions

N/A

70


Appendix E: m-Services Mobile App Medium Selection Guideline


The purpose of this guideline is to guide Abu Dhabi Government Entities (ADGEs) in selecting the appropriate delivery medium (web, native, or hybrid apps) for their m-Services.

This guideline targets and applies to every ADGE Digital Services team that is formally responsible for the selection of the m-Services delivery medium on behalf of its entity.


In line with its vision to deliver world-class services for the benefit of all its constituents, Abu Dhabi Government is seeking to further modernize its government services portfolio through the delivery of government services on mobile channels, or m-Services.

The Abu Dhabi Government m-Services strategy has established a “Web App By Default” guideline for the delivery of government-to-citizen (G2C) and government-to-business (G2B) services. However, in cases where an ADGE believes a specific service is best delivered through a native or hybrid app, the ADGE Digital Services team should develop a clear and detailed business case rationalizing the need to deliver it as a native or hybrid app, and outlining the expected benefits, such as lower cost, reduced development time, or improved service delivery.

This guideline is intended to guide ADGEs in this exercise by highlighting important mobile app features to be considered when comparing different delivery media. It also provides key questions designed to aid ADGEs in the development of the business case and the justification for the native or hybrid app.

When considering the delivery of an m-Service through a native or hybrid app, the following key considerations should be taken into account:

• Time and cost for development and maintenance: Native and hybrid apps require special development skills and special platforms for each of the operating systems they are developed on. As a result, they are more costly and time-consuming to develop than mobile web apps.

• Findability: In the case of native and hybrid apps, finding specific m-Services for the first time can be complicated, and hindered by the app store delivery process itself (e.g. limited app descriptions and the need to download it). Alternatively, m-Services hosted on web apps can be found through a simple search engine and bookmarked for repeated usage.

• Upgradability: Upgrading a native or hybrid app is a lengthy process due to most app store’s restrictions and security measures. Furthermore, upgrading through app stores does not guarantee accurate dissemination of the modified information, as it is dependent on the willingness of users to update the app and on the compatibility of the mobile device with the upgraded app. m-Services provided through web apps can be updated instantly simply by modifying the web app.

71


• Immediacy: Because of the app store download process, first-time access to m-Services is delayed in the case of native and hybrid apps. Once on the device, however, they provide users with immediate access to the m-Service. Web apps, on the other hand, always provide immediate access to m-Services through a search engine, and can be bookmarked.

• Multi-platform availability: Users of Native and hybrid apps are necessarily limited to their device’s operating systems. As such, native and hybrid apps must be developed across multiple platforms to guarantee wide availability of m-Services. Web apps are generally available across platforms, which allows for increased reach while utilizing fewer resources.

• Graphics: Native and hybrid apps have direct access to the device’s hardware and can truly leverage mobile functionality to deliver a rich user interface, together with the potential for complex interactions when needed. Web apps have limited access to the hardware and cannot deliver a rich user interface supporting complex interactions.

• Performance: Native apps typically deliver the fastest performance whereas web and hybrid apps are generally slower.

• Native look and feel: Native and hybrid apps create a self-contained environment that eases interaction and fosters trust. Web apps can emulate this environment by using consistent design elements and navigation structure.

• Distribution: Native and hybrid apps are distributed through app stores, whereas web apps are distributed through the web.

• Access to Device: Native and hybrid apps are stored on the device and have access to main device elements and functionalities. Web apps have more limited access to phone functionalities. However, this is changing due to consistent progress in HTML5 technology.

• Notifications: Native and hybrid apps can provide users with push notifications and reminders when needed while web apps cannot.

• Storage: Data connected with native and hybrid apps are stored on secure files, whereas web app data are stored on a shared SQL server.

• Location Awareness: All mobile apps can leverage location data from the device and use it as an input for m-Services.

• Connection: Native and hybrid apps are stored on the device and can provide some informational services independently of a mobile connection, although any interactive and transactional service will require mobile connectivity. Web apps do not yet offer offline storage capabilities.

• Technical Skills: Developing native apps (and less so hybrid apps) requires specialized skills and areas of expertise in each operating system for which it is intended.

72


In addition to the above factors, the answers to several key questions should be considered when justifying the decision to develop a native or hybrid app:

i1 Does the service require a rich user experience for delivery?

m-Services requiring rich processes, such as high interactivity, seamless navigation, an object-rich user interface, or fast performance, cannot be provided through mobile web apps.

ii1 Do you require the service to be mobile-platform agnostic?

m-Services reaching a large target audience are more suited for mobile web apps to ensure a large platform support base.

iii1 Does the service require native functionality not available through web apps?

m-Services requiring native functionality that cannot be delivered through mobile web apps or supported by HTML5 are candidates for native or hybrid app development.

iv1 Is the app to be used offline?

m-Services that require offline capabilities such as local data storage are candidates for native or hybrid app development.

v1 Do you have an aggressive timeline or strict budget constraints?

Due to the relatively higher development cost and longer time to market, native and hybrid apps are not ideal for m-Services projects with a strict budget or an aggressive timeline.

vi1 Do you have the required resources and capabilities to develop and support the mobile app?

m-Services delivered through native apps require resources with specialized skillsets, deep technical expertise, and the ability to provide constant development support to maintain functionality as the platforms are updated.


This guideline should be adopted by the ADGE’s Digital Services team during the development of the business case rationalizing the implementation of a native or hybrid app.

41 Exceptions

For government-to-employees (G2E) and government-to-government (G2G) apps, ADGEs can choose the technology medium (native app, hybrid app, or web app) that best meets their requirements. The key difference for G2E and G2G m-Services is that government entities have greater control over the target audience and the devices they use to run these m-Services. This allows entities, for example, to dictate or provide the type of devices used and enforce timely software updates by all users.

73


51 Definitions

Hybrid apps: A hybrid app is part native app, part web app. It provides access to government information and services through a downloadable native application that serves as a wrapper for a web app developed in HTML. Hybrid applications can access device features available on the mobile device, and reduce development costs by leveraging HTML code compatible across different devices.

Native apps: A native app provides access to government information and services through an application that is downloadable on a mobile device. Native apps are device-specific and are typically optimized to take advantage of the device’s features.

Web apps: A web app provides access to government information and services through a device-independent application accessed through the device’s browser. It is built leveraging HTML5 and designed specifically to optimize the layout requirements of the mobile device and thus the user experience.

Date post:	01-Aug-2018
Category:	Documents
Upload:	lecong
View:	213 times
Download:	0 times

Abu Dhabi m-Services Strategy€¦ · email : [email protected] ... It is the goal...

Documents