Today’s Agenda Dealing with Vendors Consultants Contracts The RFP Process Consultants Contracts Justifying your system: Costs/benefits System Implementation

HRIS Vendors Most provide client/server architecture Many provide apps that integrate with other functions Most support a range of platforms All are expensive & require customization

Vendors (Ch 6) Bigger isn’t necessarily better Look at financial condition, market position, etc Look at experience with your situation Look at support, training, etc. Remember: you are not just purchasing a product, you are establishing a long-term relationship!

The RFP Process For larger systems (over $60-80K and up) Text gives EXCELLENT material on this topic Need to communicate broad context AND the important details “Crystallizes goals and requirements” Screen potential vendors

RFP Content Introduction Proposal instruction (what should the proposal contain) Functional requirements (line item criteria) Vendor requirements (client references, support services, etc.) RFP Administrative info. (schedules, etc.)

Support is key to the relationship Hotline support 24 hrs vs. business hrs only WWW site? User groups? Field support education and training software installation account management Consulting planning, implementation, etc.

Consultants (Ch 7): Threat or Menace? Must be neutral (NOT vendors) and have excellent track record/references Usually expensive: $1000/day and up is common Several days may be required even for simple assignments But often worth it: costs of failure are enormous

Consultants can help with. . . Tasks where specialised knowledge or independent judgement are needed assess current system, develop requirements, system/vendor selection, oversee implementation, etc. Not necessarily a long term relationship can help with one phase of a project, such as vendor selection

Contracts (Ch 8): Necessary Evil Software projects are inherently uncertain, so flexibility is required Writen contracts should provide protection against non-performance specific deliverables and milestones acceptance testing is essential: make sure the product meets the specifications What happens if they go out of business? Text has two pages of typical clauses!

Contracts allocate risk Fixed Price financial risk to vendor, but performance risk to customer Time and materials financial risk to customer, but performance risk is minimized Appropriate choice depends on which risks are greater

Selling Your System Internally System benefits are hard to estimate Direct cost reductions staff, facilities, outside services Cost avoidance current system inflation, maintenance, staff, potential lawsuits, etc. Intangible benefits better decisions, quality, flexibility, etc. What are the benefits of the system you are proposing?

Costs are also elusive Initial hardware, software, and personnel are fairly easy to anticipate But there’s always more: conversion and testing, testing, testing poor design --> excessive maintenance documentation (or lack of it) retraining (with turnover) changing interfaces endless upgrades, conversions, training.

What will it take to get your system up and running? Implementation planning Vendor/consultant selection Policy/procedure development Detailed design Customization and Coding (if necessary) Installation

. . . and there’s more Interfaces Conversion Testing, testing, testing Training, training, training Maintenance Upgrades