Stakeholder Perspectives

1
Stakeholder Perspectives
2
Who Interacts with the Final Product?

• End-user
• The real (actual) user/s of the system.
• Client
• The person or entity that commissioned, that will
  pay for, and that will own the system.
• Developer
• The person or entity that builds the system and
  that is directly responsible for its quality.

3
The End-users Perspective

• What the end-user might say
• What new system? (Vapourware)
• Commissioned, talked about (hyped), never
  delivered!
• Dreadful to use.
• e.g. UI data entry error messaging help
  response reliability etc.
• Nice but what does it do?
• Non-useful systems. E.g. fussy library systems
  slower than existing restrictive to end-users
  etc.

4
The Clients Perspective (1/3)

• What the client might say
• If Id known the real price, Id never have
  agreed to it!
• Typically 1 year late and 100 over budget
• Capers, 1986
• Taurus (LSE) 80m 400m investment from
  securities industry result? Never delivered!
• Drummond, 1996
• We needed it last March not now you might as
  well keep it!
• e.g. Systems to fix Y2K delivered after
  31/12/1999!
• Bennett, 1999

5
The Clients Perspective (2/3)

• It installed so badly, my staff wont touch it.
• Bad reputation is difficult to reverse.
• e.g. Failed backup system on LAN forced staff to
  revert to individual backup even once system was
  guaranteed.
• Bennett, 1999
• Whats this? Its not what I asked for.
• Conflicting policy (ambitions) and power-play.
• e.g. varying standards in multi-national
  companies.

6
The Clients Perspective (3/3)

• Everythings done differently now we need a
  completely different system.
• Serious projects have serious timescales
• Changes in the environment can and usually do
  have dramatic repercussions on the system
• Users will start to demand more from any system
  once its potential is realised
• Initial domain/problem analysis was not complete
  and/or correct.

7
The Developers Perspective (1/3)

• What the developer might say
• We built what we were told to
• Everything starts when developers are told what
  is required
• What is required is distilled from more than one
  source (user, client, etc.) and all must agree
• It is very tempting to change something in the
  requirements
• We were pressed for time and thats the best
  that could be done
• Fixed and unmoveable deadlines
• The demand/need to show anything tangible quickly

8
The Developers Perspective (2/3)

• First time Im doing it this way!
• Developers will have varying backgrounds and
  specialities this can lead to misconceived
  quality expectations
• Teams should have complimentary skills
• Some generic core knowledge is essential to allow
  communication between team members
• Fixt it! How? Whats it supposed to do?
• You cannot fix what you dont understand!

9
The Developers Perspective (3/3)

• We told you so your funeral!
• Forced commitment
• Lack of enthusiasm for the proposed system
• Biased highlighting of reasons why the system
  cannot work
• Justification of initial reluctance
• The system is OK its being wrongly used
• Technocratic approach to problem solving
• Is clearly prejudice
• Remains nonetheless a possibility

10
IS Development Pitt-holes
(Adapted from Flynn, 1998)