MIS 648 Presentation Notes: Lecture 11

1
MIS 648 Presentation Notes Lecture 11

• The Challenges of Developing Systems
  Internationally

2
AGENDA

• Introduction to the lecture
• Goal of the Lecture
• Challenges of International IT Development
• Strategies for IT Development

3
Basic Ideas

• Developing global systems is risky
• There are solutions, but costly
• Managing global development teams is risky
• Designing and operating global systems are risky
  ventures
• Certain kinds of systems (ERP mostly) are likely
  candidates with their own problems

4
Basic Ideas

• Developing global IS is difficult
• Strategies are needed to lower risk (which is
  significant)
• Most of what we have to choose from is modeled on
  existing development strategies
• The basic domains of choice are core vs.
  periphery, custom vs. package and internal vs.
  external.

5
Basic Ideas -2

• Selection of strategy depends on four sets of
  characteristics
• Organizational
• System
• Core/Periphery match
• IS Department

What else other than the weather could have an
influence anyway?
6
Global IS Development Strategies

• Development with a multinational design team
  (MDT)
• Parallel development (PD)
• Central development (CD)
• Core vs. local development (CL)
• Best-in-Firm Software adoption (BIF)
• Outsourced custom development (OD)
• Unmodified package software acquisition (UP)
• Modified package software acquisition (MP)

-- in practice all acquired packages are
modified to some extent
7
Why This List?

• These eight strategies actually overlap
  significantly and do not include all possible
  strategies
• Classification scheme is arbitrary, but useful
• Primary tensions affect strategic position of
  organization
• Coherence of team and alignment with co. goals
  are primary quality and cost factors
• In fact, organizations evolve through these
  strategies over time anyway.

8
Evolution of Global IT Development
Next, the firm either adopts best-in-firm (BIF)
or puts together a multinational design team
Which is really just another way of exercising
core control
9
Evolutionctd

• Central development first countered by
• Peripheral parallel development compromised by
• Core vs. local development then negotiated
  through either
• Best-in-firm or multinational design team
• But solution might best be brokered through an
  outside outsourcer or by buying modifiable
  packages

10
Categorizing and Selecting GIS Development
Strategies
Orgl Characteristics Attitudes,
constraints structure
System Characteristics Commonality, size,
technology appln type, criticality

• Domestic vs. International Team
• Package vs. Custom Approach
• Internal customization
• External customization

HQ/Subs. Diffs Technical, requmts, culture
IS Dept. Charstics Maturity, staff skills
Source AkmanilgilPalvia, Strategies for
Global Information Systems Development A
Critical Analysis, 2002
11
Risk Assessment
Risk S (risk factors) Risk Factor Probability
of harmful event Probability that event will
cause harm Cost of harm.
12
Risk Assessment
Risk Factor Probability of harmful event
Probability that event will cause harm Cost
of harm.
Our exposure this year to this particular risk
factor is the product of 0.5, 0.03 and
1,000,000, which is 15,000. Hence we should
spend up to 15,000 to counter or reduce this
risk.
Note These numbers and values are not static
and may change abruptly or over time. All
estimates are controversial and subject to debate.
13
McFarlans Risk Analysis

• Risk is due to three factors Size of project,
  technology gap and project definition stability.
• Global projects are all large
• Global projects are all subject to strong
  technology strains thus increasing gap
• Global projects are generally fluid and have
  multiple parties and interests and are subject to
  many stresses
• Thus global project risk is always High.

14
So What to Do?
Know what might happen and its causes

• If Risk is High, we need to counter one or all
  of the three risk factors
• P(harmful events) managed via planning
• P(harm from harmful events) managed via
  toughening,skilling, control
• Recovery costs managed by contingency planning,
  redundancy, control
• McFarlan describes these along two dimensions
  integration and formalization

Take action to prevent harm from event or failure
to react appropriately
Have plans in place to repair damage, recover
operations
15
Management Solutions (á la McFarlan)

• Integration (implicit structure)
• Internal team meetings, professional leadership,
  mutual familiarity
• External user leadership, user communication and
  direction
• Formalization (explicit structure)
• Planning Formal planning methods
• Control Status reviews, change management,
  organizational learning

16
Architectural Solutions Global Software Teams

• One implementation is to create global software
  teams that work using technology as an
  intermediary for collaboration.
• These are a form of virtual teamwork
• Barkhi, Amiri and James investigated factors that
  lead to successful virtual teams, teams without
  social presence

17
The challenges
IT culture has characteristics that both enhance
and disable trust-building traits and activities

• Coordination problems
• Free Riding
• Process losses
• Dysfunctions such as role overload, role
  ambiguity and low individual commitment
• Trust is important to persuade individuals to
  participate in risky activities where they see
  forces beyond their control (or rather cant see
  forces and thus believe them to be beyond their
  control)

18
The Nature of Software Development

• Unstructured
• Non-routine, individualistic, modularized
• Intangible
• Highly equivocal (confusing, multiple meanings)
• Negotiated rather than blended individual work

19
The Nature of Communication Channels

• Media Richness Theory (Daft Lengel)
• Defined on the basis of feedback cues, language
  variety and personal focus
• Rich channels reduce confusion
• Non-routine tasks require richness
• Unstructured tasks require flexible, agile
  channel use, with high information content
• Intangibility requires richness of expression

20
Hence

• P1 Software development team participants are
  more likely to collaborate with co-located
  members than remote members
• P2 Software development team participants are
  more likely to break communication links with
  remote members than with co-located members.

21
Coordination Needs
Lack of understanding of what is intended based
on what is noticed.
Lack of understanding what is causing what based
on messages.
Work executed at different sites is likely to
have different a lot of variety

• Coordination is critical in software development
  otherwise there can be inconsistency due to
  divergence, causality violation and intention
  violation.
• Coordination can be mechanistic (formal,
  centralized, controling) or organic (informal,
  decentralized, cooperative)
• Thus CMC environment poses consistency challenges

22
Hence

• P3 Software development team participants
  perceived more difficulty in coordinating their
  activities with remote members than co-located
  members.

23
Life-Cycle Effects

• Groups go through forming, storming, norming and
  performing stages.
• Consensus is important for productivity
• Early and latest stages require rich channels for
  the negotiation, without which there can be
  individualistic, un-trusting behavior.

24
Group Life Cycle
Actually getting business done effectively
Developing agreed rules for process to meet goals
Putting the group together, learning about
function
Adjusting to one anothers styles, determining
diffs
25
Hence
No surprise here!

• P4 Participants are more likely to shift blame to
  their remote members than co-located members.
• P5 But participants who work effectively with
  their remote members become satisfied with the
  work process

Even less surprise here!
26
The Research

• Teams of four students from two universities
  developed database applications and manuals
  (N82 number of groups was unreported)
• Groups either worked only F2F or F2Fremotely.
• Research was interpretive and qualitative.

27
Results

• P1 supported by comments
• P2 supported by comments
• P3 supported by comments
• P4 supported by comments
• P5 supported by comments
• Additional insights An intense need for quick
  response, high-quality information, and valuable
  information.

28
Recommendations

• Use F2F early and late in the project
• Modularize, provide rapid feedback to prevent
  dropping communication
• In addition, develop team leaders, structure
  teams well, populate intelligently with knowledge
  of social norms and standards.
• Undepersonalize through small teams, some F2F
  contact, be aware of social context.