Acquiring software from external supplier

Bespoke system
Created specially for the customer from scratch
Enterprise solutions for complex & unique business processes
E.g. Predictive Shipping by Amazon Inc.
Off-the-shelf - bought as is
Created as a generic product with very limited customization
E.g.: Microsoft Windows & Microsoft Office
Customized off-the-shelf (COTS)

A core system is customized to meet needs of a particular customer

Modules may remain same, but may require customization in both code and
features/applications before usage
E.g. SAP ERP implementation of specific modules like MM, PP

ISO/IEC 12207 processes

23-09-2014

Lecture Presentation | Dr. A. K. Kar

ISO 12207 Acquisition and Supply process

Part of the ISO 12207 standard relates to the process by which software can be
acquired from an external supplier.
There are two parallel and complementary processes.
The acquirer has a set of processes to carry out which interact with the processes
for which the supplier would be responsible.

Initiation

Initiation

23-09-2014

Preparation
of RFP

Response to
RFP

Contract

Planning

Preparation
of Contract

Lecture Presentation | Dr. A. K. Kar

Execution

Monitoring &
Control

Delivery &
completion

Acceptance &
completion

Stages in contract placement

Requirements
analysis
Evaluation
plan
Invitation to
tender
Evaluation of
proposals
5

Types of contract

fixed price contracts

time and materials contracts
fixed price per delivered unit

Note difference between goods and services

Often license to use software is bought rather than the software itself
6

Fixed price contracts

Advantages to customer
known expenditure
supplier motivated to be cost-effective
Disadvantages
supplier will increase price to meet contingencies
difficult to modify requirements
upward pressure on the cost of changes
threat to system quality
7

Time and materials

Advantages to customer
easy to change requirements
lack of price pressure can assist product quality
Disadvantages
Customer liability - the customer absorbs all the risk
associated with poorly defined or changing
requirements
Lack of incentive for supplier to be cost-effective
8

Fixed price/unit
Advantages for customer

customer understanding of how price is calculated

comparability between different pricing schedules
emerging functionality can be accounted for
supplier incentive to be cost-effective

Disadvantages
difficulties with software size measurement - may need
independent FP counter
changing (as opposed to new) requirements: how do you
charge?
9

Fixed price per unit delivered

FP count Design
cost/FP
to 2,000 $242

implementation cost/FP
$725

total cost/FP

2,0012,500
2,5013,000
3,0013,500
3,5014,000

$255

$764

$1,019

$265

$793

$1,058

$274

$820

$1,094

$284

$850

$1,134

$967

Estimated system
size 2,600 FPs
Price
2000 FPs x $967
plus
500 FPs x $1,019
plus
100 FPs x $1,058
i.e. $2,549,300
What would be charge
for 3,200 FPs?

10

Different tendering process

Open tendering
Any supplier can bid in response to the invitation to tender
All tenders must be evaluated in the same way
Government bodies may have to do this by local/international law

Restricted tendering process

Bids only from those specifically invited
Can reduce suppliers being considered at any stage

Negotiated procedure
Negotiate with one supplier e.g. for extensions to software already
supplied

11

Pre Bid Requirements: Content

Introduction
Description of existing system and current environment

Future strategy or plans

System requirements - mandatory/desirable features
Deadlines vs WBS / PBS

Additional information required from bidders

12

Focus while writing Pre Bid Requirements

Functions in software, with necessary inputs and outputs

Standards to be adhered to

Other applications with which software is to be compatible

Quality requirements e.g. response times

Vendor competency statements

13

Evaluation plan
Reading proposals
Presentations to committee
Interviews
Demonstrations
Site visits
Practical tests
Group decision making
14

Evaluation plan - contd.

Need to assess value for money for each desirable feature

15

Terminologies
Invitation to Tender (ITT)

Note that bidder is making an

offer in response to ITT
Communication of the
acceptance of offer creates a
contract
Customer may need further
information
Problem of different technical
solutions to the same problem

16

Memoranda of Agreement (MoA)

Customer asks for technical

proposals
Technical proposals are
examined and discussed
Agreed technical solution in
MoA
Tenders are then requested
from suppliers based in MoA
Tenders judged on price
Fee could be paid for technical
proposals by customer

Terminology: Statement of work

A statement of work (SOW) is a formal document that captures and defines the work activities, deliverables,
and timeline a vendor must execute in performance of specified work for a client.

Typical components of a SoW would be as follows:

Purpose: Why are we doing this project? A purpose statement attempts to answer this.
Scope of Work: This describes the work to be done and specifies the hardware and software involved.
Location of Work: This describes where the work is to be performed, including the location of hardware and software and
where people will meet to do the work.
Period of Performance: This specifies the allowable time for projects, such as start and finish time, number of hours that
can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
Deliverables Schedule: This part lists and describes what is due and when.
Applicable Standards: This describes any industry specific standards that need to be adhered to in fulfilling the contract.
Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or service is acceptable,
usually with objective criteria.
Special Requirements: This specifies any special hardware or software, specialized workforce requirements, such as degrees
or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
Type of Contract/Payment Schedule: The project acceptance will depend on if the budget available will be enough to cover
the work required. Therefore the flow of payments will usually be negotiated in an early stage.
Miscellaneous: Many items that are not part of the main negotiations may be listed because they are important to the
project, and overlooking or forgetting them could pose problems for the project.

23-09-2014

Lecture Presentation | Dr. A. K. Kar

17

Terminology: Service-level agreement

A service-level agreement (SLA) is a part of a service contract where a service is formally defined.

Customer-based SLA: An agreement with an individual customer group, covering all the
services they use. For example, an SLA between a supplier (IT service provider) and the finance
department of a large organization for the services such as finance system, payroll system,
billing system, procurement system, etc.
Service-based SLA: An agreement for all customers using the services being delivered by the
service provider. For example:
A mobile service provider offers a routine service to all the customers and offers certain
maintenance as a part of offer with the universal charging
Multilevel SLA: The SLA is split into the different levels, each addressing different set of
customers for the same services, in the same SLA.
Corporate-level SLA (SLM): Covering all the generic service level management issues
appropriate to every customer throughout the organization. These issues are likely to be
less volatile
Customer-level SLA: covering all SLM issues relevant to the particular customer group,
regardless of the services being used.
Service-level SLA: covering all SLM issue relevant to the specific services, in relation to
this specific customer group.

23-09-2014

Lecture Presentation | Dr. A. K. Kar

18

How would you evaluate the following?

Usability of an existing package

Usability of an application yet to be built

Maintenance costs of hardware
Time taken to respond to requests for software support
Training
Contracts should include agreement about how customer/supplier relationship is to
be managed e.g.
Key decision points - could be linked to payment
Quality reviews and checkpoints
Changes to requirements and how to document it
19

Minicase for discussion Glipkart Inc.

Glipkart is a fast growing online retailer for diverse product categories. Currently, it sells products
ranging from mobiles and tablets, computers and accessories, audio/video entertainment devices,
optical gadgets, cameras, watches, clothing and books. It is fast introducing new products and
expanding its product category range. It has in fact launched its own product range under the brand
name of "DigiGlip", offering camera bags, pen-drives, headphones, computer accessories, etc. Glipkart
sells goods in India through a company called MS Retail. Other third-party sellers or companies can
also sell goods through the Glipkart platform.
Customer satisfaction is of paramount importance in Glipkart. However, with such a fast expanding
customer base, Glipkart is facing problems in managing its information assets. Fulfillment of purchases
is also becoming a major challenge. Further, identifying and managing fraudulent purchases is also
becoming extremely challenging. Also because of such fast accumulating data, Glipkart executives are
finding it a major challenge to address their Customer first moto to manage and exceed customers
expectations.
After deliberating for a significant amount of time, Glipkart decided to implement a CRM system to
track its customers better. Further, the CRM system would be expected to run online campaigns and
analyze customer value. The system is also expected to manage churn. The system is also expected to
identify fraudulent purchases and manage them systematically.
What type of contract should Glipkart contemplate while engaging with the system implementation
firm? Discuss the possible pros and cons with different approaches. What should be the tendering
strategy that the company should adopt?

23-09-2014

Lecture Presentation | Dr. A. K. Kar

20

23-09-2014

Lecture Presentation | Dr. A. K. Kar

21

23-09-2014

Lecture Presentation | Dr. A. K. Kar

22