Software Development: View From an Intercultural Perspective

1
Software DevelopmentView From an Inter-cultural
Perspective
CFICSE - Oct 2001 Ron Wulf
2
Problem focus
Problem Software projects fail Solutions so
far Multifaceted, BUT there is no Silver
Bullet Causes addressed so far Hardware,
Process, Software Engineering Other
Perspectives? Many studies models emphasize
the human factor What about the inter-human
factor?
Hypotheses Cultural Conflict within Software
Projects is a serious contributing factor in
project failure
3
Vernacular anecdotal explanations of software
project failure
Users dont know what they want Users just
want as may toys as they can lay their hands
on The Users/project/supplier are a bunch of
prima donnas The project office is in bed with
the supplier The project office doesnt have a
clue The supplier is incompetent Project x
is a scam, someones get-rich (or promoted) quick
scheme
Q - What do these statements have in common? A -
Inter-organizational Conflict
4
Software project failure - three official
reasons

• Failure
• Over schedule
• Over budget
• Did not meet quality expectations/requirements
• Cancellation
• one of the above was becoming self-evident
• Force majeure change to one of the above

We will consider all but the last item
5
A recipe for trouble Conflicting, often covert
agendas
Supplier
Acquirer
User

• 1 Max profit
• other agendas
• schedule
• placate acquirer
• repeat biz
• low priority user

• 1 Min cost
• other agendas
• schedule
• low priority quality

• 1 Quality
• other agendas
• schedule
• low priority cost

Even traditional factors are in reality
conflict issues
6
Outside interference
Acquirer
User
Supplier
Corporate issues
Corporate issues
Budget, politics, bureaucracy, doctrine,
loyalties (hat badge), PWGSC, etc.
7
Inside interference (communities)
User
Acquirer
Supplier
IT (coders)
Marketing
Management
Finance
8
Inside interference (communities)

• Identifiable Subcultures potential problems
• IT professionals serious amateurs (geeks)
• Marketers
• Management
• Military
• Civilian
• Trade professional organizations (incl CF
  trades, ranks)
• Officers vs. rank file (including official,
  unofficial, assumed presumed equivalents)

9
Inside interference (communities)
Additional cultural realities which can be
distractors ethnic groups which cross over
primary entities (visible minorities,
anglo/franco, political, lifestyle, etc.) - There
are those who WILL exploit these issues!!!!
10
Inside interference (communities)
Ties to ones sub-culture are often MUCH stronger
than ties to ones primary (or surface)
cultural group
CONSIDER PMO Anglo-Canadian Male Military
ITProfessional Engineer Officer PMO Staff
Project x SupplierAnglo-American Male Civilian
ITProfessional Engineer (Officer) PM Staff
Project x User Italian-Canadian Female
Military Medical NCO Project x
From a DND perspective, the effective dynamic
should be strongest cooperation between User and
PMO, but what will reality be?????
11
A case study

• UseCase (Macro) Manipulate vector AND raster
  graphics
• wanted Corel Draw or equiv
• had to restate requirements in technical terms
• Provided by project MS PowerPoint
• Reasons
• Interpretations of the word basic
• user basic graphic artist vice imagery
  exploitation specialist
• Project basic what comes with the MS suite
  vice graphic artist
• Project staff assumed user wanted more toys
• User decided to be honest ( not play the
  budget game)

Semantics differing world-views root of most
conflicts
12
A case study (contd)

• Issues
• Pride on part of various staffs (a hat badge
  and rank issue)
• Lack of committed resources (e.g. only one member
  of user branch on project staff)
• Politics (MicroSoft only)
• Attrition lack of paper-trail (due to both lack
  of process malice)
• Lack of tact diplomacy
• Sapir-Whorf parties on both sides could not
  comprehend each others reality
• Complexity thresholds exceeded for both parties,
  inter alia
• Long list of requirements,
• Long list of IT process steps (hoops)

13
A Diversion

• Complexity
• 7 /- 2
• This applies to coding.
• As code gets more complex, we demand
  modularization, increased documentation, and an
  increased paper trail (à la 2167)
• But doesnt the 7 /-2 dictum also apply to the
  rest of the process???
• It often appears not to..

14
Real explanations of software project failure
Recall Users dont know what they want Users
just want as may toys as they can lay their hands
on The Users/project/supplier are a bunch of
prima donnas The project office is in bed with
the supplier The project office doesnt have a
clue The supplier is incompetent Project x
is a scam, someones get-rich (or promoted) quick
scheme
15
Real explanations of software project failure
Recall Users dont know what they want The
project office doesnt have a clue The
supplier is incompetent Consider They know
what they want as well as you would they just
cant figure out how to express it to you
16
Real explanations of software project failure
Recall Users just want as may toys as they can
lay their hands on Do they? Or do you
misunderstand their real needs? Or are they more
technologically visionary than you are? A 1998
DND project was told that systems to be delivered
in 2001 would need 1GHz processors, 256 MB RAM,
and 20G HD these reqs were rejected as
gratuitous
17
Real explanations of software project failure
The Users/project/supplier are a bunch of prima
donnas Is there collective one-up-manship going
on??? The project office is in bed with the
supplier Do you understand the supply process?
Do you understand the PMOs negotiating or
procurement strategy? The project office
doesnt have a clue Do you?? Have you really
explained yourself?
In the real world, this would have to be
expressed much more diplomatically..
18
Way Ahead (to-do list)

• Literature Review
• Prove hypothesis
• survey to test whether the difference in
  assessed cause of failure shows strong
  correlation not only to organization but also to
  subculture
• Apply conflict prevention methodologies to the
  Software Process
• Essentially preventative conflict resolution,
  e.g.
• Training in software process for user reps
  (ORM)
• Careful selection of ORM
• Managers must be made aware of potential
  problems, and be on constant lookout for early
  signs
• Time spent on reconnaissance is rarely wasted
  visits etc.
• ESTABLISH AGREE ON SHARED MUTUAL GOALS

19
Conclusion

• The community has considered process, hardware,
  software, and the individual, but has not spent
  much time considering social issues
• Seeing various social groupings as the
  subcultures they are brings to light other areas
  for improvement
• This is not a silver bullet either, but as the
  issue is at the root of much failure and has
  received very little attention, it may lead to
  measurable profitable changes in the rate of
  project failure

20
Select Bibliography
Brooks, Frederick P. Jr. The Mythical Man-month.
Anniv. Ed. Boston Adison Wesley, 1995 Brown,
Donald E. Human Universals. New York
McGraw-Hill, 1991 Heuer Jr, Richard J.
Psychology of Intelligence Analysis. Langley
CIA, 1999 (for perceptual bias issues)
lthttp//www.odci.gov/csi/books/19104/index.htmlgt
Apr 2001 Leutert, Werner. The PM Game,
Datamation Magazine, n.d. Weinberg, Gerald M. The
Psychology of Computer Programming. Silver
anniversary ed. New York Dorset House, 1998
Getting to Yes