Executive Summary

The government of HKSAR ("the Government") has become aware that its

existing system development methodologies have at times limited both its

efficiency and effectiveness, and has been looking for alternative software

engineering techniques to address these issues. One of the potential

methodologies that has recently become a mainstream software development

approach is the agile software development methodology ("agile"). The Office

of the Government Chief Information Officer (OGCIO) commissioned Deloitte

to perform a consultancy study to assess the practicability of agile in software

development projects in the Government.

The study contains three main phases. Phase one includes studying the

current-state and practices to identify the constraints and challenges for the

agile adoption. Phase two includes consolidating the current-state findings and

proposing recommendations for the Government to overcome the challenges.

Phase three includes determining suitable types of projects for agile adoption

and proposing an implementation strategy and roadmap. In this report, Deloitte

("we") will share our results obtained from the study with the Government,

including our research approach, key findings, challenges, recommendations,

types of suitable projects, implementation strategy and roadmap.

Based upon our analysis, agile is practical and adoptable for the Government

within the current policy and regulation boundaries. However, there are still

some hurdles that need to be overcome in order to roll out agile successfully

from project, people and technical perspectives.

Page : 2 of 17
Current-state Key Findings

Throughout the study, we reviewed and analysed the typical Government

project lifecycle to identify current project processes, activities, and

stakeholders involved. The project lifecycle begins with the initiate phase,

followed by the plan, execute, close, and monitor and control phases. By

examining the activities within each phase in the project lifecycle, we noted

that there were distinct project-activity groupings, consisting of integration,

finance, time / plans, contract, communication, risk, scope / change, people,

and quality. Within these groupings, we pinpointed focus areas for our

interviews and surveys, so as to further identify potential opportunities for agile

development, and also performed comparison against overseas agile best

practices. We had conducted a total of 13 interviews for internal government

stakeholders including senior management and representatives from different

OGCIO support teams as well as information technology management units

(ITMUs) from bureaux/departments (B/Ds).

IT Industry Agile Readiness

Interviews and online surveys were conducted for external vendors to assess

the readiness of agile in the local IT industry.

The results of our interviews and surveys of vendors corroborated the

Government's observation that agile is not widely-adopted in the local IT

industry. Most local companies and staff possessed less than 5 years of agile

experience. However, some local agile education was available in Hong Kong

and agile manpower was also accessible in the local market. It is also

encouraging that over half of the vendors would welcome the Government’s

Page : 3 of 17
adoption of agile, and majority of them believe they can be ready for agile

projects within one to three years if there is demand from the Government.

Major Concerns and Challenges

We found that many stakeholders, including members of senior management,

realised that the current-state methodologies led to delayed launches and

failure to meet user expectations at times, and that the adoption of agile should

lead to higher efficiency, accuracy, and cost savings for certain types of

projects. Furthermore, agile aligns with Government initiatives and senior

management's future vision regarding cloud computing and mobile

applications.

A quick summary of major concerns and challenges is listed below.

Constraints on Government procurement

• There may be concerns about fairness: if the scope of work is changed

after the tendering process, it is unfair to other tenderers who bid on the

scope described in the tender.

• Interim payment may not be applicable for agile, as it is difficult to define

payment milestones if the scope is not fixed.

Necessity of documentations

• It may be difficult to define "just enough" documentation under the current

Government environment, as a certain detailed level of documentation is

considered necessary for future references and to protect the

Government's interests.

Page : 4 of 17
Limited market capabilities and knowledge in agile

• It may be difficult for the Government to adopt agile, as agile is not

widely-used in the local IT market, and the Government may not be able

to procure agile services from IT vendors.

Constraints on end user involvement

• There may be limited user resources and support to provide frequent user

involvement with the project team as required by agile, due to user's other

routine work.

Uncertainties in agile project management

• It is unclear how agile timeboxes can be integrated with existing project

management methodology, as current practices rely on milestones control

and regular progress reports.

• Current monitoring criteria, which are based on percentage of completion,

cannot effectively keep track of agile projects, as timebox management is

different from the percentage of completion method.

• Formal changes based on current change management process may take

weeks, which is not fast enough to allow the frequent changes common in

agile.

Difficult to accept testing results and releases

• It will be difficult to determine completion of an agile project / release when

user-requested changes make the development of the product deviate

from the pre-defined scope.

Page : 5 of 17
Limitation on working environment

• While agile development relies on close cooperation and collaboration

between all team members and stakeholders, it may be difficult to find

dedicated project workspace required for co-locating the project team and

user representatives.

Misalignment with cloud computing

• There are concerns on whether agile conflicts with cloud services, and

does not align with the directions that the Government is heading towards.

Uncommon to empower user representatives

• Project teams in the current state are not empowered, but agile project

teams must make decisions and be accountable for delivering the product

and providing quick feedback to the developers for acceptance of

deliverables. It is not common currently for PSC to delegate key decision

power to internal project manager (IPM) and business-users, although

PSC cannot frequently be involved in agile projects.

Agile Practices in Overseas Countries

After identifying the major adoption concerns and challenges, we had looked

into other countries to better understand the way how they adopted agile and

found out what can be leveraged from their past experiences.

Agile is commonly adopted in the public sector in western countries, including

the United States (U.S.), Canada and the United Kingdom (U.K.) for different

types of new application systems development such as web applications,

Page : 6 of 17
cloud based applications, case management systems, workflow driven

applications, customer information systems and geographical information

systems. Research on agile practices in the governments of China, Singapore

and India was also conducted and the results showed that agile is not widely

adopted in the public sector of these Asian countries.

Due to typical strict government environment, we have seen that overseas

governments usually adopt agile in a more structured and disciplined manner

for government-wide adoption. Moreover, we have observed that it is essential

to employ rapid change management as a means to embrace and facilitate

change, to delegate decision making power to the project team, and to

frequently solicit and heed end user feedback.

Using the U.K. as an example, its government has carried out various pilot

projects that have shown the benefits of agile, which has led to the U.K.

government encouraging agile practices in their recent information and

communications technology (ICT) strategy. The benefits are:

• Timely delivery and predictable budget – By fixing the project deadlines

and actively managing the scope of each work package, the projects

were delivered on time and within budget.

• Controlled risks – Issues were identified early to minimise re-planning time

which greatly reduced the overall project risk.

• Increased client confidence – Constant involvement of the client and key

stakeholders throughout the project ensured the correct products were

developed that matched expectations.

Page : 7 of 17
Recommendations

When adopting agile, we first need to consider adoption at the organisational

level ("macro level”) according to our research and then consider adoption at

the project level ("micro level”).

At the macro level, there are two approaches. One is "disciplined agile" and

the other one is "core agile". Disciplined agile is a scalable, structural and

standard compliant (e.g., ISO9000 1 , Information Technology Infrastructure

Library (ITIL2)) approach which covers the full software project lifecycle from

project inception to transitioning the system into a production environment,

whereas core agile focuses on the technical aspects of system delivery

mechanism and only addresses a portion of the project lifecycle.

Since the Government is a large organisation that is driven by a set of

well-defined policies, regulations, procedures and guidelines, we recommend

that it goes with disciplined agile since disciplined agile is more structural and

covers the full software project lifecycle that will be appropriate for the

Government environment.

At the micro level, we have leveraged proven disciplined agile approaches

from overseas that best address the Government environment, using

1
The ISO 9000 family of standards relates to quality management systems and is designed to
help organizations ensure they meet the needs of customers and other stakeholders. The
standards are published by ISO, the International Organization for Standardization, and
available through National standards bodies. Referenced from
http://www.iso.org/iso/home.html
2
ITIL is a set of good practices for IT service management (ITSM) that focuses on aligning IT
services with the needs of business. Referenced from
http://www.itil-officialsite.com/AboutITIL/WhatisITIL.aspx
Page : 8 of 17
evaluation criteria that strike a balance between minimising change and

aligning with agile principles. The challenges we have identified in regards to

the Government’s agile adoption, and their solutions, are discussed below.

Government Procurement

We recommend that the current procurement process remain unchanged

under agile because agile services can be procured by fixed-priced contract

with clearly-defined, high-level scope. Deliverables of multiple timeboxes can

be packaged into releases as major milestones for payment.

Level of Documentation

Agile is not necessarily in conflict with existing documentation requirements,

although the agile principle of "just enough" documentation raises that concern.

We would like to clarify that agile does not limit documentation—it simply

applies the principle that documentation should be lightweight,

easy-to-understand, up-to-date, and effective and efficient at communicating.

In practice, we observe that this issue is resolved by adopting techniques

similar to Rapid Application Development 3 (RAD), where the level of

documentation is more defined. For agile projects, we recommend

documenting results using prototyping, business and functional modelling,

3
From OGCIO's document named "An introduction to RAD:" RAD refers to a development life
cycle designed to give much faster development and higher quality systems than the
traditional life cycle. It is designed to take advantage of powerful development software like
CASE tools, prototyping tools and code generators. The key objectives of RAD are: High
Speed, High Quality and Low Cost. Referenced from
http://www.ogcio.gov.hk/en/infrastructure/methodology/rad/rapid_application_development.ht
m
Page : 9 of 17
high-level solution design, and infrastructure architecture design in the System

Analysis and Design (SA&D) stage to reduce unnecessary documentation.

Capabilities and Knowledge of Agile – Government and Industry

Market capability should not be a concern as long as time is given to vendors

to prepare because majority of vendors claim they can be ready for agile

projects within one to three years if there is demand from the Government.

Furthermore, agile training for Information Technology Management Unit

(ITMU) and user representatives is crucial to the successful introduction of

agile development methods in the Government.

End User Involvement

Active user collaboration is imperative to any agile project. As such, we

recommend that organisational change management activities should be

performed so that officers understand the benefits of agile and accept agile

principles. A dedicated user representative should be appointed as part of the

project team, and required to work closely and regularly with the project team.

Vendors should state their expectations for user involvement in their proposals

to facilitate better resources planning.

Project Management

As IT projects can be unpredictable because requirements can change over

times, project teams ought to have the authority at any time to swap out

low-level requirements (e.g. search box auto completion) with low business

value derived from the high-level scope (e.g. Google alike search function) for

Page : 10 of 17
newly-identified low-level requirements with high business value, without going

through a formal, rigorous, change management process.

Under agile, if a timebox expires but not all of the predefined work is completed,

the Government can consider requesting the vendor to add additional

resources, extend the project’s overall schedule, or reduce unnecessary

low-level requirements to catch up. Instead of measuring the percentage of

completion of project activities, agile simply measures the completed software

features in timeboxes, which in many cases is more accurate and realistic. The

timebox management approach allows the project team to identify issues and

escalate to the Project Assurance Team (PAT) / Project Steering Committee

(PSC) earlier. The user representatives and PAT are expected to participate in

the product demonstration performed by the project team at the end of each

timebox. We also recommend that vendors should propose timeboxes for

development of high-level features, which will facilitate better project

management and help to prevent potential disputes.

Testing and Release

We recommend that vendors should provide a test report as evidence to show

the user that all the acceptance criteria are met. In case of time constraint, the

user is required to participate at product demonstration sessions and at a

minimum review the test report for each timebox. Users must define the testing

criteria that must be met prior to integration of each self-contained sub-feature,

so that users can test and accept each sub-feature individually.

Working Environment

Page : 11 of 17
Since agile development relies on close cooperation and collaboration

between all team members and stakeholders, we recommend co-locating

project team and user representatives. Where workspace is limited in some

Bureaux / Departments (B/Ds), we recommend utilising appropriate virtual

meeting tools (e.g., Web meetings) when co-locating the project team is not

feasible.

Cloud Computing

There is no evidence that agile conflicts with cloud computing and indeed

many cloud-based applications are developed using agile, such as Google

Apps and Salesforces.com. Whenever cloud computing can provide the

infrastructure required for quick development of e-services application, agile

may be one of the recommended methodologies to be used for development of

cloud-based e-services applications.

User Representative's Empowerment

Agile expects user representatives who work closely with the project team

should be empowered to make decisions on behalf of those they represent to

provide prompt responses to the project team—such as defining low-level

requirements and acceptance criteria. However, the Government structures

ensure every important decision flows up to senior levels, whereas agile

decision making (over requirements, for example) flows down, this implies a

cultural change is required and implementation strategy should take this

cultural change into consideration. We recommend that defining low-level

requirements and acceptance criteria should be delegated to the user

representatives. If PAT / PSC members are uncomfortable with delegating to

Page : 12 of 17
the user representative, one of their representatives, such as User Assurance

Coordinator (UAC), must work closely with the project team instead.

Long-Term Considerations

In addition to the above recommendations, there are also some additional

considerations, which we believe currently may be difficult to implement. Rapid

changes with high-level scope would increase the agility of the Government.

However, it is not practical to change high-level scope without going through

the formal change management process under the current regulation

boundary. In long term perspective, the Government can consider allowing

certain degree of changes in high-level scope (e.g. up to a certain percentage

of changes, that are measured in program development costs, of total contract

value) in order to enjoy further benefits from agile in a controlled manner.

Related terms and conditions may then need to be established, and expert

advices from the Government Logistics Department (GLD) and Department of

Justice (DoJ) may also need to be sought.

Summary of Changes

Although it is practical to implement agile in the Government, there are still a

lot of hurdles that need to be overcome. As a summary, some major changes

are:

Project aspect:

• Plan and manage projects with timeboxing approach to schedule major

milestones and monitor project progress

Page : 13 of 17
• Employ rapid change management for swapping low-level requirements

by the project team without going through rigorous formal change

management process to respond quickly to changes

People aspect:

• Empower user representatives to provide rapid feedbacks to the

development team, and make quick decisions such as changing of

low-level requirements

• Involve users evenly throughout the project lifecycle rather than heavily in

SA&D and UAT to collect early feedback from users and to adapt to

changes more quickly

Technical aspect:

• Use RAD techniques, such as prototyping, workshops and modelling for

documentations in SA&D as the minimum level of documents required for

agile

• Implement, test, release systems iteratively and incrementally using 1-4

week timebox approach to deliver self-contained and almost shippable

features faster

Types of Suitable Projects

Since not all the projects are suitable to use agile for software development in

the Government, a set of agile project selection criteria based on feasibility and

benefit are provided to determine which types of projects are suitable for agile.

Such criteria would be used to establish the agile adoption standpoint and to

Page : 14 of 17
facilitate project selection in the rollout strategy. Typically, development of new

applications for mobile, web and e-services, are most suitable types of projects

that the Government would potentially benefit the most from using agile

development.

Agile Adoption Standpoint

We recommend the Government should adopt agile as one of their

mainstream development methodologies in mid- to long-term, and encourage

its use for any suitable types of projects because of the higher demands for

better quality of IT service delivery, the growing trend of software development

projects that are suitable for agile (e.g. cloud enabled applications such as

mobile and e-services), the potentials to solve/relieve current issues in the

Government as well as the foreseeable benefits, such as timely delivery,

higher user satisfactions based on research from overseas governments.

According to result of surveys conducted by VersionOne and IBM, agile has an

advantage of saving up to 45% costs, achieving 63% - 203% more return on

investment compared to traditional methodology with more than 25%

increased productivity.

Nevertheless, one of the biggest hurdles for the agile adoption is its cultural

impact to end-users and IT practitioners due to the changes in project, people

and technical aspects described previously. Therefore, it is recommended to

rollout agile in a gradual pace, focusing initially on the most suitable project

types that the Government could benefit the most from agile to gain user's

buy-in as soon as possible.

Implementation Strategy and Roadmap

Page : 15 of 17
Based on our standpoint, we have proposed an implementation strategy

consisting of about twenty-six months high-level roadmap divided into three

stages (the preparation stage, the pilot stage, and the consolidation stage) and

each stage will be further grouped into three work streams (the operational

readiness, the stakeholder readiness and the external readiness).

The first stage ("preparation") of the roadmap is to prepare the Government

and the IT vendors for the upcoming agile adoption and bring an awareness of

agile benefits to Government stakeholders. The second stage (“pilot”) is to

execute at least 2-3 outsourcing pilot projects to gain agile experience and

maturity within the Government. The third stage ("consolidation") is to

consolidate experience and build best practices for agile projects. Checkpoints

are set between stages to review the adoption progress and ensure everything

is on the right track.

The first work stream, “Operational readiness” is to enable the Government

and its stakeholders to use agile easily. It consists of activities such as

reviewing existing project governance and management practices to relieve

constraints for agile adoption, if any, conducting agile pilot projects and

building best practices. The second stream, “Stakeholder readiness”, targets

to gain users buy-in on agile and addresses cultural issues by conducting

awareness training and setting up community of practice. The third work

stream, “External readiness” is to communicate with the local IT Industry to

ensure the Government can acquire agile services when needed.

Finally, due to the fact that agile is new to the Government and most of the

officers are inexperience in agile based on our observation, they may not be

Page : 16 of 17
willing to adopt the new methodology without seeing agile benefits and

maturity. Therefore, the Government is recommended to start with projects

most suitable for agile and then try suitable or less suitable projects, so that the

stakeholders may be more supportive when agile benefits can be

demonstrated and agile maturity increases gradually.

Conclusion

In summary, the study has identified current issues and agile adoption

concerns and challenges, and studied the local IT industry readiness for agile

software development. Recommendations have been proposed to address the

identified concerns and challenges. Selection criteria have also been

developed to facilitate the Government to select suitable types of projects that

would benefit most from agile adoption. Finally, an agile implementation

strategy and roadmap have been proposed for the Government consideration,

which can guide the Government on how to adopt the agile methodology in a

gradual pace.

Page : 17 of 17