Oct 13, 2022

Corresponds to Chapter 11 ISM

1
Offshoring
• What is “Offshoring”?
• It’s process of engaging a foreign workers to supply the products or services
the firm no longer intends to produce internally,
• or by moving domestic resource responsibilities to offshore resources. What’s the
benefit here rather than outsourcing?
• Offshoring has received much impetus since the commercialization of the
Internet, which significantly lessened the impact of geographical and time
differences on the transaction of information-based services
• Offshoring growth has been fueled by many of the same drivers of
outsourcing:
• Cost and quality

2
Insourcing, Onshoring and Nearshoring
• What is “Insourcing”?
• The practice of using an organization's own personnel or other resources to accomplish a task that was
previously outsourced
•Insourcing has been in the news lately due to things like limitations on visas and hiring of foreign workers
• Onshoring is a variation of this whereby an org transfers a business operation that was moved
overseas back to the country from which it was originally relocated.
• Onshoring refers to the relocation of business processes to a lower-cost location inside the national borders.
• Why would a company do this?
• What is “Nearshoring”?
• The practice of transferring a business operation to a nearby country or geographic region, especially in
preference to a more distant one
• Nearshoring refers to a company contracting a part of its work to an external company located across
national borders but within its own region.
•What are the benefits of nearshoring?
•Time zones, language etc.

3
Learning objectives
• To help you appreciate how complex it is to design and implement information systems (IS) and the stable,
robust, secure technology at their core.
• To articulate the advantages and disadvantages of custom software design and development versus
acquisition of an off-the- shelf product.
• To describe and teach you to use the main methodologies for custom software design and development.
Specifically, you will be able to identify the major phases of the system development life cycle (SDLC) and
discuss its advantages and disadvantages. You will also become familiar with the prototyping, agile, and
development and operations (DevOps) approaches and will be able to identify its principal advantages and
disadvantages.
• To define the term open source software and be able to identify the primary commercial models crafted
around the open source movement. You will also be able to articulate the principal advantages and risks
associated with the implementation of open source solutions in modern organizations.
• To identify the systems selection methodology so you can choose a prepackaged software program for a
specific organization.
• To describe the reasons for the increasing prominence of end-user development in modern organizations
and articulate the benefits and risks of this approach to software development.

4
 Introduction
• Whether the information systems rely on custom-developed technology or
commercial off-the-shelf software, it is critical that managers understand
how information systems come to be
• While managers need to less concerned with hardware decisions, they must
take part in the software design, acquisition, and implementation processes
• Your book says “not concerned” with hardware decisions. I disagree. Why?
• Managers’ involvement in information systems funding and design is
essential because never before has a firm’s success depended so much on
the use of the right software applications.
• Deciding what the characteristics of the “right” applications are is a business
decision

5
Why IS Projects are Risky?
• Interplay of many different actors (often with divergent agendas),
• the sheer size of many organizational systems,
• the myriad of expected and unforeseen organizational conditions the system
must support, and
• the constantly evolving nature of the modern firm make these projects
extremely challenging
• Information systems projects require technical expertise
• They also call for managerial skill and informed involvement by
general and functional managers (and their staffs) who contribute
critical subject matter expertise

6
Fulfilling Information Processing Needs
• Information systems leverage IT at their core to optimize the manner in
which the firm captures, processes, stores, and distributes information
• IS become the enablers and pillars upon which a firm executes its
digital strategy
• How do IS come to be in modern organizations?
• Technology development: generating the IT core is a prerequisite to delivering
the needed information processing functionalities
• Information system development: The firm must successfully integrate the
technology with the other components of the organization (i.e., people,
processes, structure)  implementation process

7
Three Approaches to System Development
• Custom design and development: the organization implements a
software application that is expressly made, whether internally or
through outsourced development, for the unique needs of the firm
• System selection and acquisition: the organization implements a
software application developed by a vendor and available on the
market
• End User Development: the organization uses a software application
created ad hoc by its end users, rather than the firm’s information
systems professionals

8
Make vs. Buy
• Custom developing the software at the heart of a new information
system can be a necessity  the system must enable a new initiative
and no market for such a product already exists
• While this exists, it is in today’s primarily seen as a secondary approach in
many companies. Why?
• However, in general each approach offers some advantages and
disadvantages

9
Custom Development Advantages
• Unique Tailoring: software applications are molded to fit the unique features of
the firm that commissions them
• if the business processes that the software is designed to enable are unique and value
adding (i.e., a source of competitive advantage), off the shelf software may undermine
their uniqueness and be detrimental to the firm
• Flexibility and Control: because the project team builds the system from scratch,
the software can be molded into any form the stakeholders (e.g., management,
end users) would like it to take, and the firm owes no licensing fees to software
vendors
• the system can be evolved, at any time and with the proper resources, in any direction the
firm would like
• This level of control is not achievable with off the shelf software purchased from vendors

10
Purchasing from a Vendor Advantages
• Faster Roll-Out: purchased • Economically Attractive:
software dramatically reduces the purchasing off-the-shelf
time it takes to obtain the applications typically allows the
software and begin the firm to capitalize on the economies
implementation process of scale achieved by the vendor
• Knowledge Infusion: access to • High Quality: large software
the expertise coded in the houses with mature products will
software  an organization that provide evidence of the software
purchases prepackaged software quality by pointing to:
• their sizable testing budgets
also acquires a “way of doing
• large installed base of users
business”
11
What to do?
• The general rule of thumb is that software acquisition should be preferred to
custom development when the off-the-shelf solution meets 80% of the
required functionality
• What happens if that 20% is strategic for your business?
• Organizations may adopt a blended approach, first acquiring a package solution and
then modifying it  emergence of cloud computing helps
• This is a GUIDELINE, not a hard and fast rule
• Organizations are expected to develop custom applications where strategically
needed and leverage the configurability, the inhering possibility to customize
the application, of package software in the other cases
• Custom development for non “Core” applications, or applications that don’t drive
revenue production, is becoming rarer.
12
Build Your Own: Systems Development Life
Cycle (SDLC)
• Detailed justification and planning is the
vehicle to reduce risk and uncertainty in
systems design and development efforts
• Highly structured methodology where the
outputs of one stage become the inputs of
the next and where the project team
strives to keep changes to a minimum
after the project has started
• Articulated in at least 3 phases
• For the purposes of this class, we will use 5,
because it’s the most common
• Different sources will cite different names
and phases. And no one says
“programming” anymore.
13
Phase 1: Requirements and Analysis
• Concerned with clearly identifying the features of the proposed
information system. Critical actors are: prospective end users and
managers
• Three Steps:
• Investigation: proponents of the new system must identify what business issues
and functions the system will address  Informal stage
• Feasibility Analysis: evaluate the technical (whether the proposed system is
viable from an IT standpoint), operational (whether the IS as a whole, not just the
technology component, is viable), and economic (whether the project is financial
viable) feasibility of the project
• System Analysis: identify and articulate the system requirements  outcome is
the systems requirements document
14
Example of the Systems Requirements
Document

User requirements Possible scenarios

16
Phase 3: Build (or Code/Configure)
• The objective is to take the design specifications and produce a
robust, secure, and efficient application  technical stage, domain of
developers
• Coding: the process of translating the abstract software design into a set of
commands or instructions that can be executed by the hardware  include a
clear and detailed documentation of the code
• Unit Testing – that is discreet testing of specific pieces of functionality
performed by the developers who have written the code – is also performed
during this phase.
•A successful unit test is considered a GATE before proceeding to the next phase of testing.
What is a GATE?

17
Phase 4: Testing and Systems Integration
What is Testing?
• Testing: formalized assessment of components and subsequently of the complete applications (alpha and beta
testing)  release the application when it is good enough, not when it is flawless
• What do we mean by “good enough”?
Testing can further be broken down into:
• Systems/QA Testing – testing between modules of the same system and ensuring basic quality of delivery
• Integration Testing – testing between different systems that need to work together to complete a business or technical process.
• Performance Test – testing the speed and scalability of the system. What is SCALABILITY?
• User Acceptance Test – that is sometimes lumped into the next phase, but I’ve seen it both ways. The is when the end users are
ensuring the system works as laid out in the analysis and design phases, and requires business sign off before the implementation
process.

• You may notice compared to the book I have broken out Design and Testing into their own phases. I am very much
against them being combined in a waterfall process.
• Why do you think that is?

18
Phase 5: Implementation, Operations and
Maintenance
• The project team needs to ensure that the software is properly integrated with the
other components of the IS
• Three steps:
• Installation/Implementation: the system is loaded on the production hardware and the
databases are populated
•A migration/conversion of data is required if an existing system is replaced
•Two critical processes: end-user training and change management  pay attention to user resistance and
inertia
•No one use the term “installation” in any system of size? Why?
• Operations: the system is up and running and becomes a permanent asset of the firm to be
maintained and managed
• Maintenance: errors that had escaped the testing phase and enhancements that had escaped
the requirements definition phase are addressed by the maintenance process  the
functionality gap

19
Four Migration Approaches

20
Advantages and Limitations of the SDLC
+ Reduces the uncertainty and risk associated with systems design and
development projects
• Is particularly well suited for large-scale projects where changes that occur
during development or implementation can be very costly
•Maybe
+ Offers a vehicle for communication and negotiation between the
project team and the many project stakeholders
- Creates substantial overhead in terms of time and cost and does not
enable the project team to properly address the inevitable changes
that occur during the life of complex projects

21
Build Your Own: Prototyping
• It is impossible to clearly estimate and plan in detail such complex
endeavors as information systems design and development projects.
Instead the team is better served by staying nimble and iterating
quickly through multiple designs to zero in on the optimal one
• Prototyping Life Cycle: a way to elicit user requirements and seek
input into the design of the user interface
• it is simpler for users to react to a prototype than it is for them to envision
and articulate requirements in the abstract
• by involving users in the development of the front end of the application, the
design team can foster their support and increase the chances of acceptance
of the final system

22
Prototyping Life Cycle Steps
• Requirements Definitions: • Revision: the development team designs
requirements are not frozen at this and codes the requested changes  new
point as in the SDLC prototype to be evaluated.
• at any time during these iterations the team
• Initial Prototype: the team develops a and the stakeholders may conclude that no
first iteration of the system  the further investment in the project is
software can be: only a shell, a warranted  stops to the development
effort
partially or a fully function prototype
• Completion: the developers code
• Evaluation: the stakeholders review important features that users typically do
the prototype and provide feedback not request (e.g., security,
on the current design as well as administration). Documentation and
requests for enhancements and new testing follow, prior to the formal release
functionality of the system

23
Advantages and Limitations of the
Prototyping Approach
+ Systems developed this way tend to - Systems released lack from a
be more quickly delivered and security, robustness, and reliability
closer to the users’ expectations standpoint
+ Is best suited to smaller-scale - Systems are less thoroughly tested
projects and those that radically and documented
change the manner in which work is
- The rapid pace of iteration and
done
release of new prototypes can
+ Enables the firm to experiment with mislead stakeholders who
new technologies and new system underestimate the complexity of
functionalities  limiting risk and software development  rampant
sunk costs compared to SDLC score creep
24
Build Your Own: Agile Development
The agile manifesto values: The priorities and key characteristics of agile
methodologies are:
• Individuals and interactions over • adaptability and speed  focus on developing
processes and tools rather than planning
• teamwork in open space offices that facilitate
• Working software over communication
comprehensive documentation • When teams are disbursed, you can use collaboration
tool to facilitate the same interaction. What are
• Customer collaboration over examples of collaboration tools?
• use of small cross-functional teams with a customer
contract negotiation representative and daily face-to-face meetings
• developers “chunk” the work into manageable yet
• Responding to change over self-standing components
following a plan • sets fixed time and resources for delivering the
expected functionalities (e.g., Scrum)

25
Build Your Own: Agile Development

26
Buying Off-the-Shelf Applications
• The systems selection process is important because it enables a
systematic investigation of these applications as well as competing
products, thus ensuring that all issues are considered and that the
firm choose the best solution for its current needs
• The phases are similar to the SDLC for custom development, but
have additional components and focus tends to be less on
architecture and coding and more on configuration and
process/policy change.
• Why would a company choose an off the shelf package for non technical
reasons?

27
Phase 1: Definition and Requirements
• System Analysis Stage: the selection committee • Compile and Distribute the RFP: The RFP should explain
focuses on eliciting the specific functionalities what the selection committee has identified as the
required of the proposed system critical system requirements, the environment in which
the system will be used, and any required performance
• Formulate Evaluation Criteria: develop a set of
metrics and expectations. Upon its distribution to the
metrics that can be uniformly applied to all packages short-listed vendors, those interested will respond to the
under investigation  identify the features that RFP
appropriate applications should have and group them:
• Evaluate Alternatives: The selection committee compiles
• Essential, Value-adding and Nonessential feature
the list of top vendors and seeks any further information
• Compile Short List of Vendors: identify a preliminary needed to make a final decision  creation of a rank-
list of vendors  important stage because: ordered list of the acceptable candidates
• creating targeted request for proposals (RFPs) that yield • Negotiate Contract: Draft and sign a contract that
high-quality responses, and then evaluating those
provides the firm with the needed solution and insulates
responses, is time consuming
it from future risks. Common elements are:
• products that fail to meet necessary requirements can be
• the components and magnitude of costs; the eventual
identified fairly quickly, and vendors will appreciate not
liabilities and service-level agreements; control over the
being asked to respond to RFPs that they have no chance of intellectual property; the extent to which modifications are
fulfilling allowed

28
Phase 2: Design
• Detailed comparison between the requirements and off the shelf
system functionality.
• The analysts will try define whether or not the system can be used “as
is” to meet the desired requirement(s) or if they will require:
• A system change
• A business process change
• A business policy change
•The last two need to be coordinated tightly with the Change Management
function

29
Phase 3: Build and Coding/Configuration
• The build phase in the system selection process mirrors that of the SDLC
• The book will tell you that when the software program is to be installed
without configuration or customization, as is the case with simple
applications, the firm can move directly to formal testing and
implementation
• This NEVER, EVER happens in any application of size. NEVER.
• When customization is necessary, the firm will engage in system design
and programming of the required enhancements  important to have a
contract that specifies who is responsible for customizing the
application and the conditions of the customization effort

30
Phase 4: Testing
• The book says “The testing stage is mostly concerned with system
performance rather than with the identification and correction of
bugs”
• Not really accurate. Testing in this phase for Packaged Software follows the
same testing steps:
•System Testing/Quality Assurance
•Integrations Testing
•Performance Testing
•User Acceptance

31
Phase 5: Implementation, Operations and
Maintenance
• Even within the same class of software applications (e.g., ERP), a firm may
choose different approaches to move from the old to the new system
• The degree of process change and training required to get buy-in from
users is typically greater when implementing off-the-shelf applications 
a prepackaged program is not designed with the idiosyncrasies of your
organization in mind
• Plan to invest considerable resources during the implementation phase to
set up the application, train employees, and finalize change management
• Ask for stakeholders input during selection and evaluation to reduce rejection risks
and involve them in CM activities from the beginning

32
Summary
The astounding progress that has characterized information technology (IT) over the last 40 years
often misleads general and functional managers. Being mostly familiar with personal computing,
they underestimate how much time and how much money it takes to build a stable, robust, and
secure system that will work under a wide array of organizational conditions. In order to avoid these
misconceptions, managers must become familiar with the process by which IT-based information
systems come to be in modern organizations
Introducing an organizational information system is a two-step process requiring technology
development and the implementation process. These two processes, while often described
separately, are complementary and intertwined. More recently, development and operations
(DevOps) has emerged as a practice in the context of agile software development to attain shorter
response times when it comes to the delivery of features or bug fixes utilizing continuous integration
and continuous deployment
Summary
Modern firms introduce new information systems using one of the following approaches: custom design and
development, system selection and acquisition, or end-user development. The critical difference among
them is the manner in which the software applications at the core of the information system are developed.
In the first approach, IT professionals within the organization or those who are contracted develop uniquely
tailored software for the firm’s needs. In the second approach, the selection committee chooses an off-the-
shelf application. In the third approach, it is the firm’s end users, rather than the IT professionals, who
create the software
The main methodology for custom system development is the system development life cycle (SDLC). The
SDLC, predicated on the notion that detailed up-front planning is the vehicle to reduce risk and uncertainty
in systems design and development efforts, is best suited for the development of large, complex software
applications. The SDLC is articulated over five main phases. The primary limitation of the SDLC is the
creation of substantial overhead and rigidity that limit the project team’s ability to address the inevitable
changes
Summary
The prototyping methodology has emerged as a viable alternative to the SDLC. Prototyping is rooted
in the notion that it is impossible to clearly estimate and plan in detail such complex endeavors as
information systems design and development projects. Instead the team is better served by staying
nimble and iterating quickly through multiple designs to zero in on the optimal one. Prototyping’s
advantages include user satisfaction (particularly for small-scale applications or those that
dramatically change work practices), rapid development, and experimentation. The drawbacks
include the risk of lower-quality systems than those developed using a more structured
methodology and scope creep
Agile methods place emphasis on the development team and user involvement. Each iteration
introduces features or changes into the product, and these are reviewed by the development team
and the users. Agile methodologies provide the ability to change development direction later in the
development
Summary
The software industry has grown to a point where almost any application a firm needs is available off
the shelf. When building information systems around prepackaged software applications, the firm must
engage in a formal systems selection and acquisition process. Doing so ensures that the selection team
evaluates all possible solutions and acquires the one that is best suited to the firm’s needs. The
selection and acquisition process mirrors the SDLC, with some important variations during the phases
The advent of powerful and easy-to-use computer languages, software development tools, and cloud
services and infrastructure has enabled an unprecedented degree of software development by end
users (i.e., non-IT professionals). The benefits of end-user development include increased speed, end-
user satisfaction, and a reduced pressure on the IS function to develop new applications. The risks of
end-user development include unreliable quality standards, high incidence of errors in the
applications, continuity risks, and increased pressure on the IS function to support development and
management of end-user applications
What we learned
• To help you appreciate how complex it is to design and implement information
systems (IS) and the stable, robust, secure technology at their core.
• To articulate the advantages and disadvantages of custom software design and
development versus acquisition of an off-the- shelf product.
• To describe and teach you to use the main methodologies for custom software
design and development. Specifically, you will be able to identify the major phases
of the system development life cycle (SDLC) and discuss its advantages and
disadvantages. You will also become familiar with the prototyping, agile, and
development approaches and will be able to identify its principal advantages and
disadvantages.
• To identify the systems selection methodology so you can choose a prepackaged
software program for a specific organization.