Outsourcing vs' InHouse for the Press Database

1
Outsourcing vs. In-House for the Press Database

• Stanfords Experience

2
Stanford University Press

• 35 employees
• Fully integrated presswide database
• One in-house developer
• Some development by other employees under the
  direction of the main developer
• Portions originated in late 1990s
• Current state for about 1.5 years
• FileMaker version 8.5

3
This presentation

• Summary of our experience
• Helps and Hindrances
• A checklist to help with your decision-making
  process
• Ideas apply more to in-house development, but can
  be applied to both.

4
Save the patient!

• In 2001 there was talk of abandoning our existing
  system.
• We decided to try to stabilize and improve it.
• There were at least six different people
  programming parts of the system. It resided on
  two different servers, a shared drive, and some
  desktops.
• There was very little integration between tables.
• Data integrity and accuracy were huge problems.

5
In the mists of time

• Marketing department developed some modules in
  FileMaker in the mid-late 1990s.
• Press purchased a FileMaker system from Duke
  University Press in the late 1990s.
• Some purchased modules were never used.
• Re-engineered to include a budgeting module.
• Hired dedicated FileMaker Developer
• Integrated with existing Marketing and Accounting
  modules.
• Marketing built dynamic website fed by FileMaker
  data.
• Upgraded to FileMaker 6 and added more modules.
• Substantially rewrote large portions of system.
  At one point I remember dumping over 600 fields
  from one file.
• Upgraded to FileMaker 8 and reworked yet again.

6
Today

• High user satisfaction
• Integration of data across the press
• Track projects from receipt of proposal, through
  budgeting, production, and marketing
• Easily add new reports and modify existing
  screens
• Data feeds out weekly to our website
• Data feeds out weekly to TMM and thus to
  Eloquence
• Two university presses have purchased our system.

7
What Helps?

• Public To-Do list (during first 1-2 years)
• Single developer AMAP
• Train your developer
• Written specs for new features
• Refine specs BEFORE developing
• Volunteer testers
• Overtrain users for new modules/features
• Fairly loose development timetables
• Keep users invested in outcomes

8
What Hinders?

• Leave the system Balkanized (Thats a different
  department anyway.)
• Have multiple developers without central
  authority
• Develop directly from feature requests (Its
  fast! Its what you asked for!)
• Handle feature requests in the order received (Be
  fair!)
• Undertrain or not train users for new
  modules/features (Save time!)
• Mix brainstorming, needs assessment, testing,
  training, and feedback (Hit the ground rolling!)
• Let spreadsheets and pet projects define the
  resulting system (It worked for Bob.)

9
Checklist

• To help with the decision of developing in house
  or outsourcing
• Will place online at the AAUP Wiki
• Will be glad to send this presentation and the
  checklist to you if you give me your email
  address.

10
Which way is best?

• There is no single answer.
• Implementation is most of the game.
• Implementation is iterative.
• Assume you might develop your own system.
• Think like a software developer.
• Systems do not solve problems, people do.

11
Questions?

• Chris Cosner
• Systems Manager
• Stanford University Press
• ccosner_at_stanford.edu