1. The
Business
of
Being
a
User:
How
Reference
sites
figure
in
the
new
poli9cs
of
so:ware
acquisi9on
Neil
Pollock
University
of
Edinburgh,
UK
Sampsa
Hyysalo
Aalto
University,
Finland

2. OrganizaCon
wide
InformaCon
systems
(IS):
ERP,
CRM
etc.
• Used
to
be
built
for
an
organizaCon,
sCll
clunky
• “Octopus”
that
spreads
its
tentacles
throughout
an
organizaCon
(AccounCng,
HR,
Manufacturing,
Sales,
Procurement,
R&D…)
• Code
recycling:
packages
– Generic
core
e.g.
SAP
r3
– Higher
educaCon
module
– InstallaCon
…
with
hundreds
of
configuraCons,
customizaCons,
add-­‐on
SW,
bolt-­‐on
SW
– Evolving
and
being
updated
at
each
level

3. Background:
Pollock
&
Williams:
SoXware
&
OrganizaCon.
Routledge,
2008
• AccumulaCon
of
funcConality…
win-­‐win..then
• From
“generificaCon”
by
requirements
workshops
– Management
by
community
• Witnessing
difficulty
and
conflicCng
needs
– Management
by
content
• Process
alignment
• Working
the
Acetate
etc
social
tricks
• …To
generifiers
– To
get
your
requirement
accepted
by
supplier
…
it
needs
to
appeal
to
many
sites
(otherwise
you
need
to
maintain
and
upgrade
it
at
your
own
expense).
– Et
voilá
users
seek
generalizability
in
and
among
themselves
– Those
willing
to
change
their
organizaCon
the
most
to
fit
the
technology
and/or
commission
addiCons
to
become
heard
more

4. Business
of
being
user
– Why
would
IT
users
carry
out
what
are
oXen
highly
burdensome,
Cme-­‐consuming
tasks
on
behalf
of
vendors?
– What
exactly
is
the
role
they
are
performing
in
the
doing
of
these
acCviCes?

5. Findings
in
brief:
what
reference
sites
do
Marketing • writing formal recommendations on behalf of vendors assuring
prospective customers about the abilities, resources, commitment,
and so on, of the vendor
• presenting ‘success stories’ at various industry forums (industry
conferences, user group meetings, and the like).
• providing feedback to the vendor about how its sales efforts are
progressing and how they could be improved
Demonstrating • demo the newly installed software to prospective customers beyond
the system what is mandated by the contract and despite the fact that the
suppliers compensation does not cover the full cost of demos.
• striving to become “flagship” installation that would run the whole
suite of vendors’ modules, despite itself not necessarily having use
for all of them.
Designing parts • providing their own programming as part of the package, many
of the system times without gaining any royalties or other compensation for it
Constructing • helping to construct the value of functions for prospective customer
the value of the organizations
system
• educating (lobbying) the vendor about the market, where they are
located and how the package ought to be further developed within
this market.

6. Data
&
Analysis
• MulCple
data
sources
over
a
ten
year
Cme
span:
– IT
Director
of
‘Big
Civic’
University
gave
us
full
access
to
his
email
for
over
the
period
of
a
year:
ConversaCons
with
the
vendor,
his
university
colleagues,
other
reference
sites
and
prospecCve
customers.
(several
large
ring
binder
folders)
– We
were
also
able
to
interview
members
of
the
‘Big
Civic’
IT
project
team
and
observe
them
in
meeCngs
with
each
other
and
with
vendor
staff
– Focus
group
with
university
managers
involved
in
the
project
where
we
presented
iniCal
findings
from
our
study:
further
debates
about
their
experiences
as
reference
sites.
– Interviews
with
a
number
of
SoXCo
employees
about
their
relaConship
with
specific
customers.
– Interview
other
reference
sites
and
customers
involved
with
SoXCo.
– Ahendance
at
various
industry
forums
&
SoXCo
user
group
meeCngs
&
industry
events
where
SoXCo
was
ahempCng
to
market
its
soluCons.
• Analysis:
– InducCve
data-­‐handling
step
by
step
a
kin
to
open,
axial
and
theoreCcal
coding
in
Grounded
Theory
(Glaser
&
Strauss,
1967;
Clarke,
2005)
– Themes
elaborated
within
the
length
of
the
final
arCcle
a)
illustraCve
of
larger
bodies
of
data
as
well
as
b)
ones
that
were
not
sufficiently
discussed
previously
within
IS
research

7. Not
asking
requirements,
but
sales
value
potenCal
“What
would
be
the
potenCal
benefits
or
(measurable)
value
in
implemenCng
a
soXware
soluCon
to
address
these
pain
points?
For
example:
Improve
responsiveness
now,
and
retenCon
rates
later,
by
having
a
single
view
of
all
student
data.
• *
Improve
student
experience
by
20%.
Improve
effecCveness
of
recruitment
using
all
channels
(including
self-­‐service).
• *
Enhanced
recruitment
efficiency
&
producCvity
10-­‐20%
• *
Increase
retenCon
by
10%
Improve
compeCCveness
in
the
prospecCve
student
"market"..
• *
Improve
response
rate
by
20%
• *
Reduce
costs
by
10-­‐20%
Maximize
use
of
resources
to
support
insCtuConal
recruitment
and
retenCon
goals.
• *
Enhanced
standing
of
University
(email
sent
from
a
SoXCo
ExecuCve
to
BigCivic
IT
Director).”

8. …and
in
response
within
Bic
Civic
Thank
you
for
delivering
such
a
comprehensive
and
professional
report.
I
would
suggest
a
couple
of
addi9onal
points
should
be
added
on
the
Benefits
sec9on:-­‐
1).
How
much
Time/Resource
was
consumed
in
processing
an
ApplicaCon
under
the
"old"
system.
How
much
Time/Resource
is
consumed
under
the
"new"
system?
I
now
understand
that
50%
of
applicaCons
are
being
received
electronically
now.
How
much
admin
Cme
has
been
saved
across
the
University?
2).
Now
that
consistent
and
accurate
management
informaCon
is
available
immediately
(via
the
BW
reports),
what
is
the
VALUE
of
this
informaCon?
How
much
management/admin
Cme
is
saved
in
the
creaCon
and
distribuCon
of
this
informaCon?
How
can
this
be
quanCfied?
3).
How
can
[BigCivic]
get
a
reasonable
comparison
between
the
numbers/quality
of
the
applicaCons
which
we
are
processing
this
year
compared
to
what
might
have
happened
if
we
were
to
have
conCnued
with
the
"old"
systems?
4).
What
is
the
value
(if
any?)
of
our
new
posiCon
as
the
[SoXCo]
‘lighthouse’
HE
insCtuCon?
Can
we
extract
any
beher
value
from
this
(and
our
IPR
within
the
E2R
applicaCon)?
Please
note
that
I
would
find
it
difficult
to
place
a
value
on
this
or
give
any
evidence
that
it
has/will
be
of
benefit,
but
it
might
have
a
substanCal
payback
if
managed
properly
(email
from
BigCivic
IT
Director
to
BigCivic
accountant).

9. Contradictory Logics: Tensions and games
within user and vendor organizations

10. Selling
vs.
day
job
Although
clearly
we
wish
to
help
other
universiCes
and
[SoXCo],
I
feel
I
need
to
make
the
point
that
if
we're
out
promoCng
e2r
to
others,
we're
not
focusing
on
the
day
job
here,
and
the
consequences
of
this
for
the
University
could
be
significant.
Unfortunately,
there
is
no
evidence
that
our
budgets
will
increase
to
provide
us
with
a
lihle
more
capacity.
Maggie,
for
example,
has
a
huge
job
outwith
e2r
and
she's
had
to
put
a
lot
of
it
on
the
back
burner
for
the
last
few
months.
I
don't
think
it
can
stay
there
in
the
longer-­‐term.
If
we
answered
Malcolm's
[from
So:Co]
queries
in
any
real
depth,
it
would
take
quite
a
lot
of
9me,
and
if
this
request
is
followed
by
similar
ones,
we
could
be
in
some
difficulty.

11. Ambiguity
over
influencing
the
vendor
What
I
find
it
hard
to
know,
perhaps
I
should
do
some
more
reading
or
whatever,
is
exactly
how
important
we
are
to
them.
How
that
relaConship
is,
I
know
Paul
is
always
saying
‘this
is
the
market
they
are
moving
into
they
really
need
you
to
know.
But
they
are
a
great
big
global
company
and
Higher
Educa9on
is
a
miniscule
liNle
bit
of
what
they
do.
They
might
just
as
easy
say
‘oh,
we’re
not
going
to
concentrate
on
that’.
I
mean
I
don’t
have
a
grasp
of
that
so
I
am
just
buffeted
around
by
different
arguments
depending
on
who
I
have
just
heard
(taped
discussion
of
BigCivic
project
team
meeCng).

12. Monetizing the Reference Site Relationship: The Standard
Package or a Special Partner in Value Creation?
Please
note
IF
[IvyLeague]
want
to
visit
us
then
I
need
to
see
a
resource
plan
for
the
visit.
I
have
given
an
assurance
to
[the
Student
Registrar]
and
the
Vice
Chancellor
that
we
will
NOT
divert
[BigCivic]
resources
in
[So:Co]
marke9ng
efforts
without
prior
approval.
Therefore
I
need
to
know:-­‐
a)
How
many
FTE
days
will
be
required
prior
to,
during
and
aXer
the
[IvyLeague]
visit
-­‐
note
that
these
days
must
also
include
key
Users
(eg
Maggie…Colin…etc);
and
b)
What
[SoXCo]
will
be
offering
to
us
in
recompense.
Note
that
the
MINIMUM
So:Co
compensa9on
must
be
"one-­‐hour
for
one-­‐hour".
If
they
do
not
agree
then
you
must
inform
[IvyLeague]
that
we
will
NOT
be
available
for
anything
other
than
telephone
conference
calls
(email
from
the
BigCivic
IT
Director
to
the
SoXCo
Account
Manager).

13. The
standard
package
…
binds
the
hands
of
front
line
collaborators
Hi
Paul:…I
appreciate
your
understanding
regarding
the
compensaCon
for
the
customer
references.
I
certainly
appreciate
all
you
do
to
support
us,
but
as
you
can
see
we
have
a
standard
‘package’
for
this
which
we
have
to
adhere
to.
I
will
go
ahead
and
give
the
‘green
light’
to
the
visit
from
the
Norwegian
customer
([LoanFirm])
based
on
our
standard
reference
bonus
(which
I
believe
is
£1,000
per
visit
to
be
paid
on
consulCng
and/or
training)
(email
from
a
SoXCo
ExecuCve
to
the
BigCivic
IT
Director).

14. yet…
user
organizaCon
not
reduced
but
sought
to
enhance
their
role
as
a
reference
site.
….I'm
not
sure
if
this
is
an
appropriate
9tle,
but
the
concept
should
be
that
[BigCivic]
set
up
a
server
containing
ALL
[So:Co]
modules
and
populated
with
real
University
data.
This
would
then
be
useable
as
a
demonstrator
environment
for
any
University
wishing
to
see
So:Co
products
(we
would
also
be
happy
to
undertake
a
support
role
if
[So:Co]
wanted
to
demonstrate
their
products
to
prospec9ve
customers).
We
are
very
aware
that
we
are
disappoinCng
visiCng
UniversiCes
when
we
demonstrate
the
funcConality
which
we
have
bought
and
are
using
but
we
can
not
demonstrate
the
func9onality
which
we
have
bought
but
don't
use
(eg
CRM
and
Business
Warehouse)
and
we
can't
demonstrate
the
func9onality
which
we
haven't
bought
(eg
ESS
and
others).
I
appreciate
that
[BigCivic]
will
need
to
devote
significant
resources
-­‐
I'm
guessing
that
it
may
take
1
Full
Time
Equivalent
person
to
ensure
that
this
system
is
kept
up
to
date,
that
the
data
is
refreshed
and
that
we
know
how
to
use
the
parts
of
the
system
that
we
do
not
have
in
produc9on
(eg
ESS,
Grants
Management
etc).
However,
I
think
that
the
investment
by
[BigCivic]
will
be
well
worthwhile
-­‐
especially
if
it
helps
[SoXCo]
gain
more
Campus
Management
customers
(its
very
lonely
AND
worrying
to
be
the
only
University
in
the
UK
with
CM!).

15. &
symmetrically
at
SoXCo
Paul,
Thanks
for
this
note
&
the
senCments
embodied.
Your
email
is
helping
me
to
apply
pressure
within
[So:Co]
UK
(and
AG)
to
get
adequate
resources
to:
1)
Compile
a
compelling
CRM/CM
proposal
(I'm
trying
to
get
Joachim
to
[BigCivic]
-­‐
unfortunately
he's
on
hols
at
present
-­‐
watch
this
space);
2)
Sell
Campus
effecCvely
in
UK
HE.
If
we
can
organise
20/21st
I'd
appreciate
the
opportunity
to
meet
up
on
the
20th
to
explain
where
we
are
at
in
resourcing
terms.

16. MulC-­‐level
games
within
and
between
user
and
vendor
organizaCons
• the
BigCivic
pressure
(lehers,
emails
etc.)
had
an
effect.
In
parCcular,
it
was
put
to
use
by
the
SoXCo
Higher
EducaCon
team
to
argue
for
more
resources
within
the
global
SoXCo
organizaCon.
• As
a
result,
SoXCo
has
seemingly
finally
decided
to
direct
more
resources
towards
the
higher
educaCon
sector.
• However,
these
resources
will
in
turn
require
further
effort
by
BigCivic
as
a
reference
site
(in
training
up
the
new
SoXCo
person
on
the
parCculariCes
of
the
higher
educaCon
terrain).
• …
and
even
though
some
within
the
BigCivic
organisaCon
may
be
disgruntled
about
commizng
even
more
Cme
and
resource
to
help
SoXCo,
they
are
seemingly
not
in
a
posiCon
to
refuse
the
offer.

17. Discussion:
why
reference
sites
do
it
• Users
have
relaCvely
lihle
control
over
the
future
evoluCon
of
packaged
enterprise
soluCons,
developed
for
swathes
of
customers
• Even
their
own
addiCons
and
customizaCons
need
to
be
redone
(at
their
expense)
upon
upgrades
and
version
• User
organisaCons
are
increasingly
segmented
according
to
the
size
of
the
market
they
represent
• “Angry
Orphan”
–
“Favourite
relaCon”
• They
can
legiCmate
this
qua
mulCple
modes
of
valuing

19. To
Conclude
• ParCcipaCon
as
a
means
for
a
producer
– Gain
knowledge
it
cannot
access
or
create
– Create
needed
collaborators
in
design
and
markeCng
– Manage
the
diversity
of
user
collaborators
– Educate
/
domesCcate
its
customers,
IT
professionals
in
user
organizaCons
– Gain
legiCmaCon
and
credibility
in
the
market
• ParCcipaCon/cooperaCon
as
a
means
for
users
– To
wield
influence
over
package
development
– Gain
some
programming
effort
– ProacCvely
retain
the
package
more
suited
for
themselves
– Increase
the
say
of
“community”
they
belong
to
– Hamper
some
of
their
compeCtors
requirements
being
met
• MulC-­‐level
games
/
ecology
of
games
…
at
a
cost

20. QuesCons
for
Discussion
• What
other
“grey
zone”
forms
of
parCcipaCon
have
you
encountered?
• What
other
perspecCves
would
be
viable
for
understanding
parCcipaCon
processes?
• When
does
parCcipaCon
cease
to
be
parCcipaCon
?
(re:
e.g.
expoitaCon,
poliCcal
tacCcs…)