Embed Size (px)
Citation preview
Outsourcing vs. In-House for the Press Database
Stanford’s Experience
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
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.
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.
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.
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.
What Helps?
1. Public To-Do list (during first 1-2 years)2. Single developer AMAP3. Train your developer4. Written specs for new features5. Refine specs BEFORE developing6. Volunteer testers7. Overtrain users for new modules/features8. Fairly loose development timetables 9. Keep users invested in outcomes
What Hinders?
1. Leave the system Balkanized (That’s a different department anyway.)
2. Have multiple developers without central authority3. Develop directly from feature requests (It’s fast! It’s
what you asked for!)4. Handle feature requests in the order received (Be fair!)5. Undertrain or not train users for new modules/features
(Save time!)6. Mix brainstorming, needs assessment, testing, training,
and feedback (Hit the ground rolling!)7. Let spreadsheets and pet projects define the resulting
system (It worked for Bob.)
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.
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.
