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
