v^ -a - navigating software procurement in · navigating software procurement in ... open source...

Navigating Software Procurement in an “as-a-Service” Industry

A Practice Guide for ICT and Procurement Professionals

Practice Guide

Business Aspect Pty Ltd; 588 Boundary Street, Brisbane QLD 4000; PO Box 641, Spring Hill QLD 4004

PH: 07 3831 7600, Fax: 07 3831 7900; www.businessaspect.com.au; ACN: 112 888 785

CONTENTS

INTRODUCTION ......................................................................................................................2 HOW TO USE THIS GUIDE ........................................................................................................3

PART A: AN INVENTORY OF FEDERAL GOVERNMENT PROCUREMENT REQUIREMENTS ...... 4

THE EVOLUTION FROM BUILD TO SUBCRIBE ..........................................................................4 CHARTING THE SOFTWARE PROCUREMENT LANDSCAPE ......................................................6 THE FOUR PROCUREMENT PRINCIPLES ............................................................................................6 THE NINE PROCUREMENT PROCEDURES ...........................................................................................7 THE PROCUREMENT LIFECYCLE’S FOUR STAGES .................................................................................7 THE SEVEN MOST CRITICAL DIRECTIVES ............................................................................................8 THE IMPACT OF AGIMO CIRCULAR NUMBER 2010/004 ..................................................................9

PART B: ESTABLISHING A UNIFIED APPROACH TO SOFTWARE PROCUREMENT ................. 11

ENSURING A SUCCESSFUL SOFTWARE PROCUREMENT JOURNEY ....................................... 11 CONCLUSION ....................................................................................................................... 12

PART C: PRACTICAL TOOLS & CHECKLISTS ....................................................................... 13

APPLYING THE UNIFIED SOFTWARE PROCUREMENT FRAMEWORK .................................... 13 IDENTIFYING “ALL TYPES” OF AVAILABLE SOFTWARE (PHASE 2 & 3) ................................... 14 ENSURING ALIGNMENT OF PROCUREMENT STRATEGY WITH CPGS (PHASE 2) ................... 16 ENSURING COMPLIANCE WITH AGIMO ICT POLICIES (PHASE 3).......................................... 17 REVIEW TENDER CLAUSES (PHASE 3) ................................................................................... 18 REVIEW NON-FUNCTIONAL REQUIREMENTS (PHASE 3) ...................................................... 19 ASSESS SOFTWARE TYPE RISKS (PHASE 3) ............................................................................ 22

ABOUT THIS PRACTICE GUIDE ......................................................................................... 25

BACKGROUND ..................................................................................................................... 25 DISCLAIMER ......................................................................................................................... 25 REFERENCES ........................................................................................................................ 26

Business Aspect - Software Procurement Practice Guide Page: 2

INTRODUCTION

The last decade has seen a stark change not only in the way software solutions are delivered to public and private sector organisations alike, but also how such solutions are procured. Gone are the days of expending large amounts of capital to secure an expensive software licence for a centralised mainframe environment or build custom business applications. Today buyers can choose from a wide range of software procurement options ranging from traditional up front payments through to per user, per month models. In response to this increasing array of procurement choices, Australian government agencies, like their international counterparts, have been quick to formulate strategies and policies to address each emerging trend. Each new directive, whether it has been to address the shift away from bespoke developed software to pre-built packages or consideration of open source alternatives, provides additional insight for both senior ICT and procurement professionals alike. The Australian Government has been particularly responsive, issuing detailed procurement guidelines and supporting policies to manage the estimated $733 million per annum spend on software across agencies operating under the Financial Management and Accountability Act 1997. These policies include the ICT Customisation and Bespoke Development Policy and Open Source Software Policy administered by the Australian Government Information Management Office (AGIMO). Despite the presence of these policies, feedback from individual agencies indicates there is a need for a unified approach to software procurement. A unified approach would not only ensure a level playing field for industry, but would provide a clear and simple means by which agencies can achieve the objectives of current software procurement policies, both for traditional and emerging “as-a-Service” solution options. This Practice Guide is intended to help Chief Information Officers, senior ICT professionals, procurement specialists and their equivalents to arrive at the right software procurement outcomes through a disciplined, well-structured approach that balances cost, value and risk amongst all available procurement options.

http://www.finance.gov.au/e-government/strategy-and-governance/docs/ICT_Customisation_and_Bespoke_Development_Policy.pdf

http://www.finance.gov.au/e-government/strategy-and-governance/docs/2010-004_AGIMO_Circular_Open_Source_Software_Policy.pdf


HOW TO USE THIS GUIDE

The guide is composed of three distinct parts designed to lead users through steps of awareness, options and selection of various software procurement strategies.

Part A

An Inventory of Federal Procurement Requirements What you have to deal with: In this part of the guide we outline the 50 whole-of-government requirements which need to be considered by Australian Government Agencies on a regular basis during ICT decision making, including software procurement. What are they and which ones are critical? What do they mean for you and how do they relate to one another?

Part B Establishing a Unified Approach to Software Procurement Pulling it all together: In this part we provide a simplified way to pull all the relevant requirements together in a “unified framework” that enables practitioners to work through the procurement process in a well-structured way that observes all the necessary procurement requirements.

Part C Practical Tools & Checklists Things that will help you to achieve the best outcome: This part provides a set of useful questions, templates and model clauses that ICT managers and procurement professionals can use as insertions in tender documentation and as part of the overall procurement decision-making process. These are based on well accepted cost, value, risk assessment models that are product and technology agnostic.


PART A: An Inventory of Federal Government Procurement Requirements

THE EVOLUTION FROM BUILD TO SUBCRIBE

Since the first generation of closed-ICT platforms was replaced by more open solutions, end-user organisations have been forced to balance the benefits of flexibility and market choice with the overhead of managing diversity. Whether the solution was hardware or software, organisations have sought to balance the benefits of customisation against the cost of increasingly commoditised offerings. In Australia this balancing act as it relates to software solutions now represents a market estimated at $5.8 billion (split between infrastructure software (30.6%), middleware and development tools (34.8%) and end-user applications (34.6%)) and expected to grow to $9 billion by 2015.1 When considered from the end-user organisation perspective it is estimated that the average large enterprise will spend 27% of their software budget on custom software development; that is software languages, application servers, application architecture or testing issues. This compares to an average of 35% spent on packaged application software, and 37% spent on platform and infrastructure software.2 For Australian organisations, in excess of 75% of the overall software portfolio remains tied to on-premise software.3 This profile was reinforced across the agencies interviewed by Business Aspect; with the most common method of procurement being proprietary and custom developed (or bespoke) software (see Figure 1).

Source: Business Aspect

Figure 1 - Software procurement models in Australian Government Agencies

0 1 2 3 4

Never

Very rarely

Rarely

Occasionally

Often

Very often

How often does your organisation use different software procurement options?

SaaS

Proprietary

Open Source

Custom/Bespoke

Base: Six (6) Australian Government Agencies


In light of such significant and diverse spending it is not surprising that most organisations adopt principles or guidelines intended to optimise their software expenditure by first leveraging existing solutions, typically followed by consideration of commercial-off the shelf (COTS) solutions (including both corporately produced and open source) before any decision to invest in a bespoke or custom built solution. This pattern is expressed more commonly in the simple statement form of:

Share before Buy, Buy before Build4 However, due to the emergence of cloud computing as an ICT sourcing and delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (including software), there is a need to move to a more inclusive investment principle of:

Share before Rent, Rent before Buy, Buy before Build

This more expansive statement adds the notion of “as-a-Service” through the inclusion of the rent option. This terminology represents the key notion of subscription, metered or measured usage consumption models inherent in cloud services as defined by the US Government’s National Institute of Standards and Technology (NIST) definition for cloud computing5. Indeed, even in traditional on-premise licensing arrangements by major vendors, including IBM, Microsoft and Oracle, there is an increasing move to amortised and usage-based approaches. The notion of “renting” as the procurement model for Software as a Service (SaaS) is also highlighted in the AGIMO Cloud Computing Strategic Direction Paper: Opportunities and applicability for use by the Australian Government, Version 1.0 which defines SaaS as:

“Offers renting application functionality from a service provider rather than buying, installing and running software yourself.”

The importance of considering “as-a-Service” models as part of any modern software procurement cannot be under stated. SaaS has emerged as a viable delivery model for meeting the needs of enterprise IT services. A fact evidenced by the strong growth in global SaaS revenue which is forecast to rise from $US12.1 billion in 2011 to $US16 billion by 2013 and reach $US21.3 billion by 20156. In addition, SaaS will remain the most mature and largest model in cloud computing. SaaS offers advantages over traditional software implementations of faster return on investment, accelerated deployments, greater focus on core competencies and greater flexibility and scalability. At the same time initial concerns about security, response time and service availability have diminished for many organisations as SaaS business and computing models have matured and adoption has become more widespread7. Faced with this newest, and potentially economically appealing, means of software procurement, Australian Government ICT and procurement professionals should ensure they fully understand how SaaS fits within existing software purchasing policies and guidelines. Without proper and balanced application of the foundation principles of the Commonwealth Procurement Guidelines and domain specific considerations of AGIMO’s ICT Investment

http://www.finance.gov.au/e-government/strategy-and-governance/docs/final_cloud_computing_strategy_version_1.pdf

http://www.finance.gov.au/e-government/strategy-and-governance/docs/final_cloud_computing_strategy_version_1.pdf


policies, agencies may fail to achieve the primary objective of all Australian Government procurement which is ensuring value for money.

CHARTING THE SOFTWARE PROCUREMENT LANDSCAPE

Australian government business operations, like those of their private sector counterparts, are highly dependent upon Information and Communications Technology (ICT) for which software represents a significant component. Indeed, based on an estimated $4.3 billion per annum spent on ICT by Australian Government agencies, operating under the Financial Management and Accountability Act 1997 (FMA)8 17% or $733 million per annum relates directly to software9. When considered in terms of replacement value, existing software represents a core infrastructure investment of nearly $3 billion10. It is this significant spend that has seen the value for money achieved from Government investment in software come under intense scrutiny by lead agencies including the Australian National Audit Office (ANAO), the Australian Government Information Management Office (AGIMO) and the Department of Finance & Deregulation. Recent examples of this scrutiny include:

Failure by Austrade to include the clauses stating that Austrade would consider open source software;11

Revision of a planned tender by the Department of Immigration and Citizenship (DIAC) for web development and hosting that appeared to favour open source over other models;12 and

The need for all agencies to pay close attention to different software asset risks and whole of life costs as identified by ANAO during a review of the Australian Bureau of Statistics, Civil Aviation Safety Authority and IP Australia.13

The Four Procurement Principles

As a result agencies wishing to procure software, irrespective of the type of software, must adhere to the Commonwealth Procurement Guidelines with particular emphasis on the following procurement broad principles:

Australian Government Procurement Principles

1. Value for Money

2. Encourage Competition, including Non-discrimination & Competitive Procurement Processes

3. Efficient, Effective and Ethical Use of Resources, including Efficiency and Effectiveness & Ethics

4. Accountability and Transparency

These principles are then to be applied by agencies to the overall Australian Government procurement process, with a risk-based approach based on consultation with central agencies to identify applicable policy guidance (see Figure 2).

http://www.finance.gov.au/procurement/procurement-policy-and-guidance/CPG/index.html


Source: Commonwealth Procurement Guidelines

Figure 2 - Commonwealth Procurement Process

The nine procurement procedures

Within the Commonwealth procurement process the following Mandatory Procurement Procedures need to be adhered to for procurements with a total cost of over $80,000:

Australian Government Procurement Procedures

1. Procurement Thresholds

2. Valuing Procurement

3. Approaching the Market, including Open Tendering, Multi-Use Lists, Select Tendering, Direct Sourcing, Panels and Cooperative Agency Procurement

4. Request Documentation

5. Conditions for Participation

6. Minimum Time Limits

7. Receipt and Opening of Submissions

8. Awarding of Contracts

9. Notification of Decisions

The procurement lifecycle’s four stages

In the context of the principles, process and procedures that make up the Commonwealth Procurement Guideline, AGIMO has identified four phases of an overall ICT Sourcing Lifecycle. Within this cycle, agencies need to not only apply the overarching Commonwealth

http://www.finance.gov.au/publications/guide-to-ict-sourcing/lifecycle.html

http://www.finance.gov.au/publications/guide-to-ict-sourcing/lifecycle.html


Procurement Guideline, but ICT specific policies and guidelines during a typical ICT project (see Figure 3).

Case for Change

Sourcing Strategy

Procurement

Transition & Manage

CPG - Core Principles

1. Value for Money

Enhanced by “encouraging competition”

Promoting efficient, effective and ethical use

Making decisions accountable and transparent

2. Non Discrimination

All suppliers should have the same opportunity to

compete

3. Efficient and Effective

An efficient and effective procurement process

incorporates rigorous risk management, enabling

issues to be identified early in the process

4. Accountable & Transparent

Process is open and sound

Decisions justified and defensible

Four Phases of

ICT Sourcing Lifecycle

CPG - Mandatory Procurement Procedures (Division

2)

1. Apply to all purchases over $80,000 including GST

2. Requires an open approach to market

3. Comprehensive request documentation (Para. 8.42)

4. Stipulate specifications describe features required &

not prescribe any conformity assessment procedure

5. Conditions of participation limited to – legal,

commercial, technical and financial abilities to fulfil the

requirements

6. Invitations to be open for a minimum of 25 days

Source: Business Aspect based on AGIMO’s ICT Sourcing Lifecycle and

Commonwealth Procurement Guidelines

Figure 3 - ICT Sourcing Lifecycle Phases mapped to Commonwealth Procurement Principles and

Procedures

The seven most critical directives

Today there are 50 whole-of-government ICT directives, policies and guidelines issued by AGIMO which need to be considered by Australian Government Agencies on a regular basis. Almost half of these are required to be considered as part of any ICT procurement, and within this group seven (7) were viewed as being crucial to software procurement during the ICT Sourcing Lifecycle during Business Aspect’s interviews of government agencies (see Figure 4).


Source: Business Aspect based on AGIMO ICT Policies and Guidelines

Figure 4 - Core Australian Government ICT Sourcing Policies relating to software

These ICT policies and guidelines have evolved over time to address the changing needs of the market, including the maturity of COTS solutions, adoption of open source practices by many vendors and more recently the emergence of SaaS as previously discussed.

The impact of AGIMO Circular Number 2010/004

However, it is important to note that within the publication of the revised Australian Government Open Source Policy in 2011 (replacing the earlier 2005 policy) AGIMO has evolved a key principle in relation to the procurement of software by agencies. Specifically, the shift from a position of “informed neutrality”, one that did not favour open source or proprietary software, to one which requires that agencies give appropriate consideration to all available models of software, including alternative models such as SaaS (see Figure 5).


Source: Business Aspect based on AGIMO ICT Policies and Guidelines

Figure 5 - Evolution of Australian Government stance on software procurement models

This requirement for agencies to give appropriate consideration to all available models of software, in effect, increases the discipline with which agencies are expected to apply the Commonwealth Procurement Guidelines and principles of value for money and non-discrimination. It no longer allows them to default to an existing procurement model dominated by on-premise licensed software. Further, the new policy not only requires Australian Government agencies to actively and fairly consider all types of available software through their ICT procurement processes, but also requires suppliers to consider all types of available software (including but not limited to open source software and proprietary software) when responding to agencies’ procurement requests. Indeed, suppliers are directed to provide justification outlining their consideration and/or exclusion of open source software in their response to Australian Government tenders. This latest position therefore allows suppliers the scope to offer a range of alternatives that can be considered in accordance with the Open Source Software Policy Principle 1 - “Australian Government ICT procurement processes must actively and fairly consider all types of available software”. In the context of AGIMO policies and the broader international trends, if agencies are going to meet these high standards of industry engagement they need to be cognisant not only of traditional but also emerging and alternative software procurement options. It is exactly the emerging trend towards cloud computing that has seen AGIMO publish new guidance in relation to cloud computing in the form of the Negotiating the cloud – legal issues in cloud computing agreements and Financial Considerations for Government use of Cloud Computing14.

http://agimo.govspace.gov.au/files/2011/11/Cloud-Legal-Draft-Better-Practice-Guide-November-2011.pdf

http://agimo.govspace.gov.au/files/2011/11/Cloud-Legal-Draft-Better-Practice-Guide-November-2011.pdf

http://agimo.govspace.gov.au/files/2011/11/Cloud-Financial-Draft-Better-Practice-Guide-AGIMO-Blog.pdf

http://agimo.govspace.gov.au/files/2011/11/Cloud-Financial-Draft-Better-Practice-Guide-AGIMO-Blog.pdf


Part B: Establishing a Unified Approach to Software Procurement

ENSURING A SUCCESSFUL SOFTWARE PROCUREMENT JOURNEY

Business Aspect identified, through the review of existing Australian Government and international jurisdiction documentation along with interviews with six (6) individual Government agencies, that despite the desire for increased rigour or discipline in seeking out solutions beyond the status quo, agencies struggle with where to begin. When these same agencies were asked what they felt was a simple means of addressing the challenges of software procurement in an increasingly “as-a-Service” industry, the majority agreed that a framework which pulled together the individual pieces of the Australian Government policy landscape would be of practical benefit. It is with this need in mind that Business Aspect has developed a Unified Software Procurement Framework aligned to the AGIMO ICT Sourcing Lifecycle. The Framework is made up of three perspectives supported by two dimensions. Each of these dimensions contains tools, such as consolidated definitions of available software types and check-lists that agencies can employ to assist them to meet their obligations when navigating the sometimes treacherous waters of software procurement.

Source: Business Aspect

Figure 6 - The Unified Software Procurement Framework

The objective of the definitions, processes and checklists is to provide an actionable framework for use by ICT and procurement professionals. For example, tender specifications need to be written around features required and not prescribe a particular software model. By providing checklists that prompt agencies to question various aspect of a tender, the framework assists them in ensuring that their tender will permit vendors to offer a range of


alternatives in accordance with the principle of “actively and fairly consider all types of available software”. Attachment 1 of this Practice Guide contains the following tools aligned with the perspectives and dimensions of the Unified Software Procurement Framework and the ICT Sourcing Lifecycle: Perspective Dimensions Tool Lifecycle

Phase

Market Identification & Engagement

Definitions to assist in identifying “all types” of available software.

Phase 2

Whole-of-Government

Alignment & Compliance

Checklist for ensuring alignment of procurement strategy with CPGs

Phase 2

Whole-of-Government

Alignment & Compliance

Checklist for ensuring procurement compliance with AGIMO ICT policies.

Phase 3

Agency Review & Assessment Checklist for ensuring completeness of tender non-functional requirements

Phase 3

Agency Review & Assessment Tender clauses to ensure invitations are inclusive of all software types.

Phase 3

Agency Review & Assessment High level risk assessment for various software types.

Phase 3

Applying the Unified Software Procurement Framework is as simple as: 1. Sharing the definitions of the various software types with any business or ICT personnel

embarking on an software procurement effort; 2. Applying the checklists during the procurement process, in particular during

development of the Request for Tender (RFT); and 3. Undertaking the risk assessment during tender evaluation to ensure the agency is fully

informed about the link between a given solution, its risk and financial profiles.

CONCLUSION

Navigating Software Procurement in an “as a Service” industry is complex and with the rapid pace of change in technologies, Australian government agencies need to consider all alternatives to ensure that they are obtaining the best available business solution and optimising their ICT spending. Although it would appear traditional software models will remain dominant for the foreseeable future, new generations of existing licensed software, open source solutions and the emerging SaaS offerings will change agency procurement patterns. This will result in a need to adjust resourcing and funding arrangements in recognition of greater emphasis on legal and contractual arrangements, while at the same time technical skills mix will move to higher value roles and operational expenditure rather than large upfront capital purchases. As illustrated throughout this guideline each software procurement model offers distinct business and technological advantages and agencies need to consider their options carefully. The Unified Software Procurement Framework, and its supporting tools which follow, have been designed to assist agencies to identify the key issues and risks associated with the main software procurement models in the Australian marketplace.


Part C: Practical Tools & Checklists

APPLYING THE UNIFIED SOFTWARE PROCUREMENT FRAMEWORK

The Unified Software Procurement Framework is intended to provide additional support beyond current policies for Australian Government agencies in the context of the AGIMO ICT Sourcing Lifecycle. This additional guidance is based on better practices identified by Business Aspect during previous client engagements combined with the specific findings of consultation with agencies and industry. It is intended that agencies would apply the framework’s supporting definitions, checklists and assessments through Phase 2 – Sourcing Strategy and Phase 3 – Procurement of the ICT Sourcing Lifecycle as shown in below.


IDENTIFYING “ALL TYPES” OF AVAILABLE SOFTWARE (PHASE 2 & 3)

The typical options available in the Australian marketplace today to acquire business software can be summarised as follows:

Implement an on-premise solution by: o Undertaking custom or bespoke development o Licensing proprietary software o Adopting open source software

Utilise an Application Service Provider (ASP) or Outsourcer

Subscribe to a Software as a Service (SaaS) Faced with an increasing breadth of software procurement choice organisations must first ensure they understand what options are available. In addition, Australian Government agencies wishing to comply with the AGIMO requirement to “actively and fairly consider all types of available software” face the difficult challenge of ensuring their Request For Tender (RFT) and other associated documentation is clear about the definitions of the types of software that are being considered. Through secondary research, interviews with government agencies and software vendors, these options can be distilled down to a set of four (4) main software procurement models operating in the Australian public and private sector software market with several minor models also in play. The main-stream software procurement models are:

1. Custom/Bespoke Software 2. Proprietary Software 3. Open Source Software 4. Software as a Service

In addition to the four main-stream software procurement models the following models can also be found in niche markets:

5. Application Sharing (between Agencies both Commonwealth and State)15 6. Application Service Provision16 7. Shareware 8. Freeware

Each of the four main software procurement models are defined below based on existing AGIMO policies augmented by secondary sources and Business Aspect’s market knowledge: Software Procurement Model Definition

Custom/Bespoke Software Custom or bespoke software solutions are those developed by a government agency (in-house), or a commercial entity at the agency’s direction, with the intention of implementation in only one agency. i.e. To satisfy a very specific set of unique business requirements. These solutions include solution components, interfaces, and modules (i.e. hardware, software, technology, or computer products).


Software Procurement Model Definition

Proprietary Software Proprietary software solutions are those where the original development has usually been undertaken by a commercial organisation, and which may be acquired for installation ‘as is’. In this way proprietary software is typically licensed from established software vendors under a pre-determined set of usage conditions. These conditions dictate how the software will be used either by an individual or within an organisation. Licensing arrangements are often based on per seat, whole of enterprise/volume, concurrent usage or number of processors running the software.

Open Source Software Open-source software (OSS) solutions are those where the intent of the producer (an individual or organisation) is available in source code form. The source code is made available with rights normally reserved for copyright holders and provided under a software license that permits users to study, change, improve and at times also to distribute the software with varying degrees of permissiveness depending on the particular OSS license adopted.

Software-as-a-Service Software-as-a-Service are software solutions which can be rented from commercial organisations and delivered to various client devices through either a thin client interface, such as a browser, or a program interface, such as a smart phone applications. SaaS removes the need for consumers to purchase, handle the installation, set-up and often daily upkeep and maintenance of software. However, in many cases consumers are provided with user-specific application configuration settings.

It is highly recommended that agencies include a copy of the above definitions for proprietary software, open source software and SaaS in all RFTs to ensure that responding vendors have a clear view as to what “types of available software” are being considered. Custom/bespoke software should not be sought from the market, in the case of Australian (Commonwealth) Government Agencies without approval as per the ICT Customisation and Bespoke Development Policy.




ENSURING ALIGNMENT OF PROCUREMENT STRATEGY WITH CPGs (PHASE 2)

Does your procurement approach/strategy: 1. Foster value for money by encouraging

competition?

Yes / No

2. Promote efficient, effective and ethical use of

software capabilities?

Yes / No

3. Allow you to make decisions which are

accountable and transparent?

Yes / No

4. Discriminate against a particular software

model or vendor?

Yes / No

5. Allow all suppliers the same opportunity to

compete?

Yes / No

6. Incorporate a rigorous risk management

approach, enabling issues to be identified

early in the process?

Yes / No

NB: Refer to Assess Software Type Risk below.

7. Demonstrate the process is open and sound?

Yes / No

8. Allow decisions to be justified and

defensible?

Yes / No

If you have answered “No” to any of these questions, it is recommended that you seek guidance from the Procurement Division of the Department of Finance & Deregulation.

Need to Procure Software

Does Procurement Strategy encourage

competition?

Promote efficient, effective & ethical use

of software

Accountable & transparent

Does notdiscriminate against particular vendor or

software model

All vendors opportunity to

compete

Incorporates rigorous risk assessmrent

Procurement

Strategy/Approach

Process open & sound

Allows decisions to be justified &

defensible

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Seek advice from AGIMO or the Procurement

Division of the Department of

Finance & Degreulation

No

No

No

No

No

No

No

No


ENSURING COMPLIANCE WITH AGIMO ICT POLICIES (PHASE 3)

If you have answered “Yes” to the core Commonwealth Procurement Principles as outlined above, you can proceed with the software procurement by addressing the following mandatory procurement procedures that apply to all purchases over $80,000 including GST. For each procedure Business Aspect has identified either an existing AGIMO ICT policy or guideline that needs to be considered or provided links to additional tools within the framework that can be used. Procedure Required Action

1. Requires an open approach to market

A public invitation issued via AusTender or other equivalent such as public print media. NB: The above applies unless a direct procurement is applicable.

2. Comprehensive request documentation (see para 8.42)

A comprehensive RFT for the software acquisition is prepared and released inviting all software vendors to respond, if their products can satisfy the requirements. The RFT documentation should comply with Open Source Policy (AGIMO Circular 2010/004) and the incorporate the suggested clauses provided below.

3. Stipulate specifications that describe the features required and not prescribe any conformity assessment procedure

Specification written around required features and does not prescribe a particular software model. This will allow vendors to offer a range of alternative software models that can be considered by agencies in line with the Open Source Software Policy Principles.

4. Conditions of participation limited to legal, commercial, technical and financial abilities to fulfil the requirements (see para 8.54)

Conduct a review of the RFT’s non-functional requirements to determine any capabilities that should be specified as being required using the Non-Functional Requirements Checklist provided below.

5. Invitations to be open for a minimum of 25 days

Ensure invitations are open for a minimum of 25 working days.


REVIEW TENDER CLAUSES (PHASE 3)

The emergence of SaaS means that a software procurement request may now involve both potential products (or goods) in the case of either a proprietary or open source licence AND a pure service in the case of a SaaS offering. Although often a software procurement involving proprietary or open source software would incorporate maintenance services, the pure services nature of SaaS makes it more akin to an outsourcing arrangement than a product purchase. To address the dichotomy which SaaS introduces into the software procurement landscape,

Business Aspect proposes that agencies adopt the following clauses which address the

principle of ensuring all available software types. These clauses are an expansion of the

original samples provided by AGIMO in the Open Source Software Policy, adjusted to take

account of the emergence of SaaS.

Sample clause for inclusion in procurement plan/procurement documentation:

[Agency Name] will actively and fairly consider all types of available software for ICT software procurements.

Open source software and software-as-a-service will be considered equally alongside proprietary software.

Sample clause for inclusion in RFQ/Select Tender Checklists:

Have you considered all types of available software (including but not limited to software-as-a-service, open

source software and proprietary software)?

Sample clause for inclusion in RFTs for covered procurements:

[Agency Name] encourages suppliers to submit and/or develop open source software for this tender. When

responding to this tender, suppliers must demonstrate a willingness to actively consider open source software

throughout all stages of procurement, solution design and implementation in order to produce a product that

demonstrates value for money and is fit for purpose. This may include incorporating open source software

components together with proprietary software components.

In evaluating the tender, [Agency Name] will consider open source software and software-as-a-service equally

alongside proprietary software.

Sample clause for inclusion in RFTs in relation to pricing for covered procurements:

When responding to this tender, suppliers must provide sufficient price information to enable [Agency Name] to

develop an accurate view of the whole-of-life costs of the offer in accordance with the Australian Government’s

ICT Two Pass Review Process. When responding to this tender, supplies must include the transparent

identification of all likely costs associated with licence acquisition, implementation (covering set-up fees, data

migration costs etc) and ongoing costs (covering subscriptions, maintenance fees and support charges). Suppliers

should also include estimates in relation to the expected personnel load on [Agency Name].

Sample clause for inclusion in RFT Assessment Checklist:

Has the supplier sufficiently demonstrated that they have considered all types of available software (including

but not limited to software-as-a-service, open source and proprietary software)?


REVIEW NON-FUNCTIONAL REQUIREMENTS (PHASE 3)

In addition to the mandatory legal, contractual and financial requirements, agencies should

give consideration to the following key non-functional requirements as they relate to the

procurement of software during development of their RFT documentation.

It is crucial that questions relating to an agency’s position on key requirements, such as

treatment of intellectual property or data locale, be determined prior to issuing an RFT. If

comprehensive analysis of non-functional requirements is not completed then potential

suppliers will not be in receipt of all constraints on the potential solutions they may wish to

offer.

Requirement Considerations

Application Design Degree of customisation required?

Complexity integrating with existing environments and business processes?

Degree future proofing being sought? E.g. Can the solution be deployed in a both on-premise and cloud environments?

Architecture Does the offering meet the Australian Government Architectural Framework (AGA)?

Are there particular business process or information handling needs?

Business Continuity Who will be managing disaster recovery capabilities?

How is continuity maintained?

What business continuity plans are available from the vendors? E.g. What plans do vendors have in place for software development? Ongoing service provision?

Contract Period How long is the contract being undertaken for?

What is the likely lifecycle of the solution given marketplace evolution and trends?

Data Locale Physical location of data stores, access arrangements, back-up and recovery in event of service failure?

Is the data stored in Australia and can it be readily accessed and retrieved?

Funding Model What type of funding is available to support the contract? i.e. Capital versus operational expenditure.

Intellectual Property Is there a transfer of rights, patents or other ownership considerations?

Does existing agency intellectual property need to be protected?

Is this an opportunity to make agency intellectual property available?

Legal & Regulatory

Compliance

Does solution comply with Australian legislative and regulatory requirements, including Privacy Act, FOI Act, and Archives Act?



Manageability Does the software require specialist resources and infrastructure to operate?

Can it be managed remotely?

Can it be managed by a third party management tool?

How easy it is to manage the software within the context & resource constraints of your organisation?

Performance & Conformance What service levels are expected?

How will these be measured, monitored and reported

What are the service recovery levels?

Are there expectations of financial restitution and damages?

Privacy Is there a risk of compromise to confidential information or personal information?

Does the software solution comply with the Information Privacy Principles (IPP’s) and the Privacy Act 1988?

Reputation Is there potential for the agency’s reputation to be damaged as a result of a service failure, breach of security or privacy?

Scalability Can it be scaled? i.e. Can the solution grow to meet the agency needs?

What are the increments for growth, both technically and financially? E.g. Small and marginal or large and stepped increases?

Security Do the offerings satisfy Protective Security Policy Framework, the Australian Government Information Security Manual (ISM) and Privacy Act 1988?

Service Provision Reputation, history and sustainability of the vendor?

Portability of the application and data in case of a vendor failure?

Skills Requirements Can the software be supported by the current resource levels?

Are new skills required to manage, operate, support and maintain?

Standards Does the offer minimise the chance of “vendor lock-in”?

Are there any standards for interoperability or data portability that need to be specified?

Are there prescribed platforms within the agency that need to be considered?

Support and Maintenance Are external maintenance and support services available?

Are there the necessary skills available to support the solution internally? E.g. Level 1 support teams?

Transferability Are the licenses transferable – under machinery of government changes?

What about the application and data?

Vendor Capability Local capability/skilled resources available?

Capacity to service and meet obligations?



Whole of Life Costs Have you have considered and included the cost associated with planning, design, construction and acquisition, operations, maintenance, renewal and rehabilitation, depreciation, cost of finance and replacement or disposal as well as environmental and social costs if applicable.

Is the pricing information requested of the vendor sufficient to complete the worksheets required as part of the ICT 2 Pass Review?


ASSESS SOFTWARE TYPE RISKS (PHASE 3)

The formalised management of risks during procurement is a key aspect of the Commonwealth Procurement Guidelines. Therefore agency procurement must incorporate a rigorous risk management approach, enabling issues to be identified early in the purchasing lifecycle. Like any form of procurement, each of the major software procurement models identified and discussed within this Practice Guide present different risk profiles across legal, financial and functional areas. Therefore, when presented with an RFT response containing a particular software procurement model, agencies will need to have: 1. Assessed the risk tolerance for each major risk factor in relation to the major software

procurement types; 2. Determined what, if any, mitigation strategies or treatments the agency is intending to

take in relation to the risks it is not willing to tolerate; and 3. Understood the cost of any mitigation strategy so that these can be taken into account

during the final determination of value for money. The following table provides a high level guide to the implications of different software models across a set of factors arising from various non-functional requirements. Requirement Software Types

Custom Proprietary Open Source Software-as-a-Service

Agency Reputation

Under your control.

Under your control.

Under your control.

Under service providers control.

Business

Continuity

Under your control.

Under your control.

Under your control.

Under service providers control.

Data Security Under your control.

Under your control.

Under your control.

Provided by data escrow arrangements.

Data Sovereignty

Total control. Total control. Total control. May be limited as service provider has control of execution or compute platform.

Development Roadmap

Under your control.

Under vendor’s control.

Under communities control.

Under service provider’s control.

Funding

Requirement

Up front for project, then ongoing internal support staff or support and maintenance costs to a vendor.

Up front for licence, then ongoing maintenance and support.

Ongoing internal support staff or support and maintenance costs to a vendor.

Ongoing fees to the service provider.


Requirement Software Types


Intellectual Property

Agency owns, but may be shared with developer(s) depending on the contractual arrangements.

Vendor owns. Community owns. A potential risk is liability for an intellectual property infringement due to the number of contributors and the fact that they do not need to give any assurances about their contribution.

Service provider owns. A potential risk is the inability to run the software if the service provider becomes insolvent or ceases to trade.

Intended Use Designed and developed for specific application.

Designed to be used as-is, but deployed into the agency’s preferred environment. Customisation is intended to be avoided in favour of configuration.

As is or modified similar to custom or bespoke development.

As is or with pre-defined configurations only.

Interoperability Degree of interoperability dependent on design and standards employed.

Dependent on standards employed by vendor and/or achieved through local customisation.

Dependent on standards employed by community and/or achieved through local customisation.

Dependent on the interfaces offered by the service provider.

License Type Exclusive. Restrictive. General Public License (GNU) with or without restrictions.

Subscription. No actual licence is provided. Instead this is covered by a contract or terms of services / usage.

Outage Management

Your responsibility.



Service provider responsibility.

Security Under your control. Considered as part of the design and development.

Vendor provides some assurance there are no security vulnerabilities or when discovered they will be corrected.

As it is community developed there are no assurances as to whether there are any security vulnerabilities.

Vendor provides some assurance there are no security vulnerabilities or when discovered they will be corrected.


Requirement Software Types


Service Level Agreements (SLAs)

Nil or defined by the agency.

Depending on level of support purchased from vendor.

Open source licenses do not contain the kinds of representations and warranties of quality or fitness for a particular purpose that commercial software vendors sometimes incorporate into agreements.

High level SLA’s typically provided but this area is evolving and specific SLA’s can be negotiated with vendors.

Support and Maintenance

Typically provided by internal resources.

Provided by vendor.

Partly provided by community, mainly provided by internal resources or contracted third parties.

Provided by the service provider.

Upgrade Cycles Under your control.

Under your control, but influenced by the vendor development roadmap and support options.

Under your control, but influenced by the communities development roadmap.

Under control of the service provider.

Vendor Support.

Typically negotiated as part of the development contract.

Usually purchased as an adjunct to the software license. Typically a % of the total license cost.

Nil. Support arrangements need to be made separately with third party who offers support services.

Application support not required. User support usually included as part of service provision.

Contract Medium to long term.

Medium to long term.

Medium to long term.

Short to medium term.


About this Practice Guide

BACKGROUND

This practice guide was commissioned to aid senior IT and Procurement Managers of government agencies understand the evolving software market and how future software purchases can be optimised. Microsoft funded Business Aspect, an Australian business and technology consultancy company, to prepare an independent framework and practice guide in consultation with a range of Australian Federal and State government agencies. Business Aspect’s investigation involved primary data collection, analysis of various secondary research sources, and interviews with technology and procurement executives and service providers – including Microsoft. Business Aspect would like to acknowledge and thank the following organisations who participated in the consultation:

Australian Government Attorney-General's Department

Australian Government Treasury Department

Australian Transport Safety Bureau (ATSB)

Commonwealth Scientific and Industrial Research Organisation (CSIRO)

Fujitsu Australia

Microsoft Australia

Queensland Department of Education and Training

Queensland Government Chief Technology Office

Red Hat Asia Pacific

DISCLAIMER

The information in this document is being provided on an as-is basis. It is intended to provide general information only and has been prepared by Business Aspect Pty Ltd without taking into account any particular organisation’s objectives, financial situation or specific ICT needs. Readers should, before acting on this information, consider the appropriateness of the information having regard to their particular organisational circumstances. Business Aspect recommends readers obtain advice specific to their situation before making any ICT investment decision. Business Aspect Pty Ltd, its directors and employees do not give any warranty or make any representation, express or implied, at law or in equity, with respect to this information or its characteristics, quality or value, including without limitation the implied warranties of merchantability or fitness for a particular purpose. To the fullest extent permitted by law, all representations and warranties expressed or implied by law are expressly disclaimed. Business Aspect warrants that it has used commercially reasonable care in preparing this information which represents Business Aspect’s best collective judgment at the time. The opinions, predictions and forecasts contains in this document are subject to change without notice in response to evolving market conditions.


REFERENCES 1 Griffith, Chris (June, 2011), Software boom ahead for local market. See http://www.theaustralian.com.au/australian-it/software-boom-ahead-for-local-market/story-e6frgakx-1226070446084 2 Hammond Jeffrey (January, 2010), Forrester DataByte: Spending On Custom Software in 2010. See: http://blogs.forrester.com/application_development/2010/01/forrester-databyte-spending-on-custom-software-in-2010.html 3 ARN Staff Writers (April 2010), Statistics: Analyst outlook on business software: Gartner takes readers through software spending. See http://www.arnnet.com.au/article/349965/statistics_analyst_outlook_business_software/ 4 This type of ICT investment principle is actively applied by various public and private sector organisations, including the Queensland and West Australian Government. See respectively: http://www.qgcio.qld.gov.au/SiteCollectionDocuments/Architecture%20and%20Standards/QGEA%202.0/QGEA%20Foundation%20Principles.pdf and http://www.publicsector.wa.gov.au/SiteCollectionDocuments/ICTBusinessCaseCriticalFactorsChecklistfinal28.10.08.pdf 5 The complete NIST definition can be found http://www.nist.gov/itl/cloud/index.cfm 6 Gartner (July 2011), Gartner Says Worldwide Software as a Service Revenue Is Forecast to Grow 21 Percent in 2011. See http://www.gartner.com/it/page.jsp?id=1739214 7 See Note 6 above. 8 Estimate based on the Review of the Australian Government’s use of Information and Communication Technology, August 2008. 9 Expenditure levels exclude internal wages and salaries associated with software, and represent only the direct operating expenses associated with software or capital expenditure for acquisition of software calculated in accordance with the results of the Australian Bureau of Statistics’ report entitled 8119.0 - Government Technology, Australia, 2002-03. 10 Department of Finance and Deregulation Consolidated Financial Statements For the Year Ended 30 June 2009, Note 21, Page 92. See http://www.finance.gov.au/publications/commonwealthconsolidated-financial-statements/2009.html 11 Hilvert, John (July, 2011), Canberra’s open source policy stumbles on compliance. See http://www.itnews.com.au/News/262972,canberras-open-source-policy-stumbles-on-compliance.aspx 12 Tay, Liz (October, 2011), Department of Immigration revises open source tender. See http://www.itnews.com.au/News/277114,department-of-immigration-revises-open-source-tender.aspx 13 The Auditor General, Audit Report No.14 2010-11 Performance Audit – Capitalisation of Software. See http://anao.gov.au/Publications/Audit-Reports/2010-2011/Capitalisation-of-Software 14 These Better Practice Guides were draft when accessed as at November 2011. Readers are advised to check for the final versions when applying the Unified Software Procurement Framework. 15 Also commonly referred to as Shared Services. 16 Application Service Providers (ASP’s) provided businesses with the service of hosting and managing specialized business applications, with the goal of reducing cost by central administration and through the solution provider's specialization in a particular business application. Software as a Service is often considered an extension of the idea of the ASP model, but differs significantly through features such as shared runtime code and cloud-based computing infrastructure.

http://www.theaustralian.com.au/australian-it/software-boom-ahead-for-local-market/story-e6frgakx-1226070446084

http://www.theaustralian.com.au/australian-it/software-boom-ahead-for-local-market/story-e6frgakx-1226070446084

http://blogs.forrester.com/application_development/2010/01/forrester-databyte-spending-on-custom-software-in-2010.html

http://www.arnnet.com.au/article/349965/statistics_analyst_outlook_business_software/

http://www.qgcio.qld.gov.au/SiteCollectionDocuments/Architecture%20and%20Standards/QGEA%202.0/QGEA%20Foundation%20Principles.pdf

http://www.qgcio.qld.gov.au/SiteCollectionDocuments/Architecture%20and%20Standards/QGEA%202.0/QGEA%20Foundation%20Principles.pdf

http://www.publicsector.wa.gov.au/SiteCollectionDocuments/ICTBusinessCaseCriticalFactorsChecklistfinal28.10.08.pdf

http://www.nist.gov/itl/cloud/index.cfm

http://www.gartner.com/it/page.jsp?id=1739214

http://www.finance.gov.au/publications/commonwealthconsolidated-financial-statements/2009.html

http://www.itnews.com.au/News/262972,canberras-open-source-policy-stumbles-on-compliance.aspx

http://www.itnews.com.au/News/277114,department-of-immigration-revises-open-source-tender.aspx

http://anao.gov.au/Publications/Audit-Reports/2010-2011/Capitalisation-of-Software