An Agile Approach towards eGovernment Solution Procurement and Implementation: An Experience from Sri Lanka

Introduction

In November 2002, the Government of Sri Lanka, launched ‘e-Sri Lanka’ as a national development initiative, with the objective of using Information and Communication Technology (ICT) to foster social integration, peace, economic growth and poverty reduction.

Through the implementation of e-Sri Lanka, the goal was to create an enabling environment, where multi-stakeholder partnerships with the public sector, private sector and civil society would be developed, to ‘take the dividends of ICT to every village, to every citizen, to every business and to transform the way government works’ (ICTA 2004, Hanna 2007). The Information and Communication Technology Agency of Sri Lanka (ICTA), which became operational in July 2003 under the Information and Communication Technology Act (Act number 27 of July 2003), is the implementing organization for the e-Sri Lanka initiative.

To fulfill its mandate, the ICTA is currently implementing programs in the areas of; (1) building the national information infrastructure, (2) re-engineering government, (3) investment promotion and private sector development, (4) developing ICT-knowledgeable human resources, and (5) societal applications development (or e-Society).

The e-Sri Lanka program is funded by the World Bank as a loan. Thus, all projects within the e-Sri Lanka have to strictly adhere to the World Bank procurement guidelines.
 
Procurement of eGovernment Solutions

Almost all of the software development projects in the e-Sri Lanka program have so far been within the re-engineering government component. Many of these projects have been subjected to significant delays due to various issues. Most of them headed towards implementation more than one year after the completion of their respective system studies. These major eGovernment solutions were procured by leveraging the World Bank’s single-stage Information Systems (IS) procurement method (World Bank 2008).

In their motivation to introduce specialized standardized bidding documents for the procurement of IT solutions under World Bank financing, the bank states that such Information Systems Standardized Bidding Documents (IS SBDs), “provide bidding and contracting models that facilitate successful installation, integration, and operation of a range of information technology applications – from straightforward supply and maintenance of technology products, to complex development, integration and operation of mission-critical information systems”.

However, the information system development process models that are imposed on projects that use these World Bank IS SBDs  (both in single-stage and two-stage formats), are similar to the Sequential Software Development Model also known as the Waterfall Model as illustrated in Figure 1 (Royce 1970). The salient point is that, according to this procurement methodology, all requirements have to be identified and detailed out up-front, primarily in a functional manner. A solutions provider (vendor) is then procured to implement the entire solution.

This method of requirements engineering is also referred to as, ‘Big Requirements Up-Front (BRUF)’. In practice and in literature (Ambler and Likes 2012, The Standish Group 2008), the BRUF approach is considered to lead towards significant wastage and therefore, is regarded as a financially risky methodology.

Fig 1. The Sequential Software Development Model

In the IS procurement guidelines document (World Bank 2008), the World Bank acknowledges that large Information Technology (IT) and IS contracts are among the most challenging to procure because; “their technical content is diverse and difficult to define; they are highly affected by changing business objectives, organizational politics, and institutional capacity of the end-user; they are subject to rapid technological change over the project life-cycle; and they entail mixtures of professional engineering services and supply of diverse hard and soft technologies”.

The IS SBD guidelines describe how technical requirements should be specified to ensure that mandatory and preferred features are clearly indicated and to enhance the clarity of the specifications.

This traditional approach to development of e-government solutions, primarily predicated on the underlying procurement mandates, has led to significant challenges as documented by Heeks in 2002 and other researchers (Gichoya 2006, Dada 2006).

Unfortunately, almost all e-government solution stakeholders seem to accept this dismal track record as an unavoidable consequence of the underlying procurement models, thereby ignoring the adoption of best practices that could effectively address the e-government solution challenges and improve the solution success rates.

In fact, in his popular and widely referenced software engineering textbook (Sommerville 2009), Ian Sommerville states that the prevailing sense is that good software engineering process models cannot be used for e-government solutions and that their resultant benefits cannot be derived by government organizations worldwide because these models “conflict with the procurement models of many organizations where complete system specification is part of the system development contract”.

 
Global Trends in the Development of IT Solutions

In a critically acclaimed paper, “Managing the Development of Large Systems”, published in the proceedings of IEEE WESCON in August 1970, Dr. W. Royce presents this serial approach to software development – the Waterfall model – as a flawed and non-workable approach and recommends an iterative model with feedback from each phase influencing subsequent phases. Over the past 40 years, the global IT industry and academia have fine-tuned many aspects of the iterative model (Basili and Turner 1975, Jalote et al. 2003, Larman and Basili 2003).

Almost all large scale enterprise systems are now built according to this phased approach with significant feedback loops. Such enterprise system projects have succeeded in achieving their implementation objectives with considerable success.

Agile software engineering processes (Highsmith 2004, Shore and Warden 2007, Ambler and Likes 2012) have been practiced widely in the global IT industry and they have proven to have many benefits. Such processes focus on identifying the high-level scope, envisioning the initial requirements at a very high level and envisioning the initial architecture with details explored via iteration modeling. Agile software engineering processes feature software development in iterations with requirements evolving throughout the project lifetime.

The overall concept is to ‘model just enough for now’ with the premise that one can always revisit later.

As discussed by Scott Ambler (2002), these lightweight processes effectively meet project planning needs since the high-level requirements identification is sufficient to produce an initial cost estimate and schedule.

They minimize wastage through their ‘just in time’ approach to modeling which enables focus on only the aspects of the system that will be built.

Additionally, it has been shown that they generate better questions with respect to requirements elicitation, since the longer one waits to model a requirement, the more knowledge one would have regarding the domain, thereby enhancing the ability to ask more relevant questions and encouraging stakeholders to give better answers.

Furthermore, stakeholders have a better understanding of the system being built, since working software is delivered on a regular basis.
 
Impact of the Software Development Services Industry

Many global enterprises have further enhanced their successes in software solution development with tremendous ROI (return-on-investment), by leveraging the specialized and optimized services of outsourced and often offshore-based software development service providers.

The implementation capabilities of highly competent software development service providers are now a widely accepted norm amongst global enterprises. A report on global IT value trends (Standish Group 2008) shows that 70% of the industry respondents derive some degree of savings through outsourcing.
 
An Alternate Approach to eGovernment Solution Procurement and Development

The interesting question is whether it would be possible to borrow from the lessons, best practices and examples from the enterprise software development industry, in order to improve the success and development speed of eGovernment solutions.

The main objectives would be as follows:

1. Use agile and iterative software engineering processes that enable just-in-time adjustment to dynamic changes   in requirement scenarios.

2. Utilize outsourced software development services to take advantage of their optimized and specialized software      engineering skills and best practices, thereby reducing costs and increasing solution success rates.

3. Identify a highly transparent and speedy procurement methodology that would support the first two goals.

In order to meet these objectives, we devised and tried an alternate approach to eGovernment solution procurement and development at the ICT Agency of Sri Lanka. The main hurdle was to identify a suitable procurement approach that would enable this strategy. As we researched the available World Bank procurement approaches, we discovered that instead of the standard IS procurement method, the Consultancy procurement method provided the necessary flexibility to pursue a software development services strategy.

Using this consultancy procurement method, we devised a methodology to effectively harness agile software engineering best practices whilst engaging the cost-effective and specialized services of the outsourced software development services industry.

The salient features of this alternate approach — referred to, as the Software Development Services Approach (SDSA),are as follows:

1. An initial high level system or BPR (Business Process Re-engineering) study is used to define an overall enterprise architectural view of the solution space and the surrounding IT ecosystem.

2. The high level architectural view would be focused on an SOA (Service Oriented Architecture) pattern of assembling/composing services or on a Component-Based Software Engineering (CBSE) approach where the overall high-level solution is formulated as a composition of multiple sub-components.

3. The feasibility of such a “composed” architectural and technical solution is validated and presented to the stakeholders via a prototype implementation. For this purpose, readily available and highly customizable Free & Open Source Software (FOSS) packages and frameworks may be utilized.

4. Outsourced software development services vendors who could provide suitable software engineering teams to implement each module/service/component in an iterative manner, based on the specified enterprise architecture, are procured according to the Consultancy procurement guidelines. The vendor’s software engineering team would have to adhere to the specified architectural blueprint, along with the specified design patterns and styles in implementing their respective components.

5. The outsourced software development vendor teams would be required to work under the close supervision and guidance of the architectural and technology experts nominated by the main eGovernment solution procurement and project management entity — the ICT Agency in the Sri Lankan scenario.

6. The outsourced software development vendor teams will be required to submit frequent source code drops into the ICT Agency (or some other agreed upon) Source Code Management (SCM) system, thereby facilitating adherence to the latest software engineering and configuration management best practices.

7. Long-term solution support & maintenance and solution governance is procured from a suitable provider, who in turn, would be expected to obtain appropriate & requisite support licenses/agreements from relevant technology vendors.

Process Comparison of the Serial and Agile Approaches

This Software Development Services Approach described above is best appreciated by comparing its differences to the original (serial) approach to solutions procurement and development. In order to clearly illustrate these differences, both approaches are analyzed below, by mapping them onto the phases, disciplines and activities of the well-known software engineering process — the Enterprise Unified Process (EUP) — as depicted in Figure 2 (Ambler, Nalbone and Vizdos 2005).

Fig 2. The Enterprise Unified Process

From a process perspective, the original (serial) approach to eGovernment solution procurement and development as imposed by the World Bank’s IS procurement methodology, can be mapped onto the EUP as illustrated in Figure 3.

Fig 3. Serial Approach to eGovernment Solution Procurement and Development

The main steps/activities of this serial approach are:

1. Procuring a vendor to do a comprehensive systems/BPR study – depicted as step (1) in Figure 3.

2. Procuring a vendor to implement a solution based on the requirements documented in the systems/BPR study, typically including a 3-5 year system maintenance component – depicted as step (2)a in Figure 3.

Within the original approach, the ICT Agency was typically involved in the overall project management up to the beginning of the production phase (the steps depicted in black in Figure 5). Whilst the procured vendor was expected to implement the system with an overall enterprise architectural viewpoint — depicted as step (2)b in Figure 3 — empirically, this aspect was unfortunately ignored and disciplines such as strategic re-use of software components were not considered with high priority.

In contrast, within the alternate Software Development Services Approach to eGovernment solution procurement and development, as illustrated in Figure 4, the focus is on procuring vendors who would provide implementation capabilities to build the solutions according to a predefined enterprise architectural design. Thus, the primary steps in this approach are,

1. Procuring a vendor to do a high-level systems/BPR study – depicted as step (1) in Figure 4.

2. Formulating an overall enterprise architectural view, including identification of major software modules, the grouping of the modules into projects/phases (including a logical architectural view), the deployment architectural view and the overall implementation timeline – depicted as step (2) in Figure 4.

3. Procuring software development services vendors to develop the software components within each project, in an iterative manner — depicted as step (3) in Figure 4.

4. Procuring a vendor to provide software maintenance and support services for 3-5 years — depicted as step (4) in Figure 4.

Fig 4. The Agile Software Development Services Approach to eGovernment Solution Development

Similar to the original approach, the ICT Agency was involved in overall project management (the steps depicted in black in Figure 4). In addition, within this agile approach, the ICT Agency (and other government stakeholders) also drove the formulation of the overall enterprise architectural viewpoint and other software engineering process disciplines such as strategic re-use of software components. In the Sri Lankan scenario, the ICT Agency accomplished these aspects with the assistance of a carefully nominated Software Architecture Group of Experts (SAGE).

When replicating the agile SDSA in situations where a particular agency may not have the requisite software architectural and technical expertise, this aspect could also be procured from software architectural service providers.
 
Implementation Comparison of the Serial and Agile Approaches

A major re-engineering government program initiative under the e-Sri Lanka program, the LankaGate project, as well as the e-Revenue License project, were procured following this agile Software Development Services Approach. The e-Population Registry, e-Pensions and e-Divisional Secretariats projects in the re-engineering government initiative of the e-Sri Lanka program were procured under World Bank’s IS procurement methodology.

Following the typical nature of complete solution procurement imposed by the IS procurement methodology, the e-Population Registry, e-Pensions and e-Divisional Secretariats projects were procured as complete solutions encompassing the following key aspects of eGovernment solutions:

• Detailed system study based on the guidance given by the BPR report.

• Application design, development and deployment.

• User training.

• Purchase and installation of requisite computer hardware including servers.

• Hosting applications at a specified location.

• Support and maintenance of the software solution system and hardware systems.

The estimated versus actual project time durations for these projects are listed in Table 1. All these projects exceeded their estimated time-lines.

 Table 1: Time-lines of Projects Procured under the IS Procurement Methodology

As previously noted, the LankaGate project and the e-Revenue License project were procured according to the agile approach discussed above. Each of these solutions featured several component projects that were procured separately, and in parallel (wherever possible). The list of LankaGate component projects are given in Table 2.

The agility permitted by the Software Development Services Approach for solution procurement and development infused a considerable amount of flexibility in these component projects. In contrast, under the IS procurement approach, it was not possible to respond to similar situations in a logical and timely manner. Some notable examples of such flexibilities observed in the LankaGate and e-Revenue projects are listed below:

• Service providers for the component projects were a mixture of outsourced software development services companies and a government agency.

• After overall project implementation was started, component projects deemed as unnecessary due to better understanding derived after partial implementation of surrounding components were easily terminated in a timely and cost effective manner.

• Demonstrated flexibility when implementing e-Services that span across several government agencies such as the Vehicle Information e-Service.

• After overall project implementation was started, certain e-Services (component projects) were developed in-house (within the ICT Agency), upon realization that they were not suitable to be bundled into a single contract due to the diversity of the engagement and complications in stakeholder interest.

• Adoption of different flavors of the consultancy procurement methodology based on core requirement consideration. For example, QBS (Quality Based Selection) versus QCBS (Quality and Cost Based Selection).

Table 2: Component Projects of LankaGate Procured under the Alternate Approach

Risk and IPR Comparison of the Serial and Agile Approaches to eGovernment Solution Development

The agile SDSA reduces the risk for the vendor, since their overall responsibilities are reduced in comparison to the implementation and deployment of the ‘entire solution’ according to a large volume of requirements specified up-front, as in the original IS procurement approach.

The agile SDSA approach also significantly eases the overall risk of the primary eGovernment solution procurement entity since the project complexity and duration is highly reduced to manageable components, phases and activities. Furthermore, this approach provides a huge advantage to government stakeholders of the target eGovernment solution, since they receive their solutions iteratively, within shorter time-frames, and in a more flexible manner, thereby allowing for agile deviations from the original plans in the spirit of embracing inevitable change.

A typical SDSA component project would be 3-4 months in duration. The primary selection criterion would be the vendor’s capabilities in developing solutions according to a given architecture, whilst leveraging specified technologies.

Additionally, if a particular solution implementation service provider procured under SDSA fails in their responsibilities for some reason, then that particular component project can be re-procured without causing a major problem in the overall project timeline and budget.

This is because the component projects are of short time duration, tend to be procured and implemented in parallel, and feature lower costs due to the focus on software implementation services. In contrast, a project procured under the World Bank’s IS procurement methodology would be impacted with a major upheaval in the case of such an eventuality, due to its “complete” solution implementation and its “single procurement” nature.

Since the nature of agile SDSA procurement is focused on obtaining implementation services in contrast to the implemented solution, an important additional benefit is that the primary procuring agency is able to retain complete IPR (Intellectual Property Rights) of the eGovernment solution without significantly impacting the cost of the solution.

In contrast, the tendency with the traditional IS procurement approach is to allow the procured solution provider to own the IPR or for the primary procuring agency to share the IPR with the procured solution provider.
 
Conclusion

The Software Development Services Approach (SDSA) for the procurement and implementation of eGovernment solutions effectively harnesses agile software engineering best practices within standard procurement guidelines while leveraging the cost-effective and specialized outsourced software development services industry.

Actual comparisons are presented in this paper to illustrate the highly impressive time reductions and significant flexibility achieved by applying this alternate approach to procuring eGovernment solutions in Sri Lanka.

This approach was possible even within the World Bank’s onerous and exacting procurement guidelines. Thus we believe that the agile SDSA that we devised and implemented at the ICT Agency in Sri Lanka can be used within many highly stringent procurement models and yet, yield highly impressive results in terms of time, cost and success rates of e-government projects.

References
 
Ambler, S. W. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Published by Wiley Publishers, March 21st, 2002. 400 pages. [Last accessed February 21st, 2009].
Publisher – Google Scholar

Ambler, S. W. & Lines, M. (2012). Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise, Published by IBM Press, May 23, 2012, 544 pages.
Publisher – Google Scholar
 
Ambler, S. W., Nalbone, J. & Vizdos, M. (2005). ‘The Enterprise Unified Process: Extending the Rational Unified Process,’ Published by Prentice Hall PTR, USA.
Google Scholar

Basili, V. R. & Turner, A. J. (1975). “Iterative Enhancement, a Practical Technique for Software Development,” IEEE Transactions on Software Engineering, 1(4), Dec 1975.
Publisher – Google Scholar
 
Dada, D. (2006). “The Failure of E-government in Developing Countries: A Literature Review,” The Electronic Journal on Information Systems in Developing Countries, Vol. 26 Issue 1, pp. 1 -10.
Publisher – Google Scholar
 
El Emam, K. & Koru, A. G. (2008). “A Replicated Survey of IT Software Project Failures,” IEEE Software, vol. 25, no. 5, pp. 84-90.
Publisher – Google Scholar
 
Gichoya, D. (2006). “Factors Affecting the Successful Implementation of ICT Projects in Government,” The Electronic Journal of eGovernment, Volume 3 Issue 4, pp 175-184.
Publisher – Google Scholar
 
Hanna, N. K. (2007). “From Envisioning to Designing e-Development: The Experience of Sri Lanka,” Published by The World Bank.
Publisher – Google Scholar  

Heeks, R. (2002). “i-Development not e-Development: Special Issue on ICTs and Development,” Journal of International Development, 14(1), pp. 1-12.
Publisher – Google Scholar

Heeks, R. (2002). “Information Systems and Developing Countries: Failures, Successes, and Local Improvisations,” The Information Society, Volume 18, Issue 2, pp. 101-112.
Publisher – Google Scholar
 
Highsmith, J. (2004). ‘Agile Project Management: Creating Innovative Products,’ Published by Addison-Wesley Professional, April 16, 2004, 312 pages.
Google Scholar
 
Information and Communication Technology Agency (ICTA) of Sri Lanka (2004). ‘e-Sri Lanka Development Project: eGovernment Consultancy — Proposed eServices Report,’ ICTA, Sri Lanka, January 15, 2004.
 
Jalote, P., Palit, A. & Kurien, P. (2003). “Timeboxing: A Process Model for Iterative Software Development,” Journal of Systems and Software. Also Available in, Advances in Computers, Vol 6, 2004.
Publisher
 
Kroll, P. & Royce, W. (2005). “Key Principles for Business-Driven Development,” IBM Rational, from IBM Developer Works at, http://www.ibm.com/developerworks/rational/library/oct05/kroll/. [Last accessed on 28th February 2009].
Publisher
 
Larman, C. & Basili, V. R. (2003). “Iterative and Incremental Development: A Brief History,” IEEE Computer, IEEE Computer Society, 36 (6): 47—56. Also available at, http://c2.com/cgi/wiki/wiki?HistoryOfIterative. [Last accessed on 10th January 2009].
Publisher
 
Royce, W. W. (1970). “Managing the Development of Large Software Systems,” Proceedings of IEEE WESCON 26, Reprinted in Proceedings of the 9th International Conference on Software Engineering (ICSE-9), 1987, IEEE/ACM, pp. 328-338.
Publisher – Google Scholar
 
Shore, J. & Warden, S. (2007). The Art of Agile Development, Published by O’Reilly Media, October 26, 2007, 440 pages.
Publisher – Google Scholar
 
Sommerville, I. (2009). “Software Engineering,” 8th Edition, Published by Dorling Kindersley (India) Pvt. Ltd., licensees of Pearson Education in South Asia.
Publisher
 
The Standish Group (2008). ‘Trends in IT Value,’ From http://www.standishgroup.com [Last accessed on 18th August 2009].
Publisher
 
World Bank (2006). “Guidelines: Selection and Employment of Consultants by World Bank Borrowers,” Published by The World Bank, October 2006.
Publisher
 
World Bank (2008). ‘Supply and Installation of Information Systems – Single-Stage Bidding,’ Published by The World Bank, December 2008.