7+-+Software+Selection+&+Vendor+Analysis

__**Power Point**__ (Stephanie Corbin and Stephanie Hammer)

[|Picture1.emf]
 * Balancing Act:** You can only have 2 of the 3 corners of the balancing triangle. (Now, Cheap, Right)

At this point in the systems development life cycle, attention is given to hardware and software requirements, external software, and feasibility. __Alternatives__ __Buy vs. Make__ Would it be cheaper and/or more beneficial to buy a COTS system, to make your own, or to outsource? __Considering COTS__ COTS meets 70% of the organization's needs straight off the shelf __Customization__ __Build from Scratch__ __Outsourcing__
 * Physical Design:**
 * Do Nothing at all. Keep your System the way it is currently.'
 * Address Non-Technological issues. What can we change without technology?
 * Technology Alternatives: Low end, mid range, high end solution
 * Normally well tested and relatively stable
 * Effectiveness
 * Modifiability: Can you modify/change it? Do we need to adapt business processes to fit with the software?
 * Cost: With many people buying this product, the price is low, rather than a specially made, expensive product. ex: WalMart
 * Documentation
 * Usability
 * Meets the needs of your organization, but upgrades are necessary and expensive. Mistakes are moderately expensive
 * Retains majority of code integrity
 * You can control the look and feel of the system
 * Meets 100% of the organization's needs
 * EXPENSIVE
 * Only utilize this system when there is no other option. ex: You can not buy a spaceship off the shelf
 * In House vs. Outsource
 * Off-shoring: Language barriers. ex: customer service representative speaking to someone in America from India
 * Provides economies of scale
 * Risk of paying more for the market price. If kept internally, you control the costs
 * In house requires organization to get into a new business in which they are inexperienced


 * ||  ||   |||||| **Development Strategy** ||
 * ||  ||   || __In-House__ || __COTS__ || __Outsource__ ||
 * **Business Need** ||  ||   || Unique || Standard || Non-Core Function ||
 * **In-House Skills** ||  ||   || Functional & Technical Expertise Exists || Functional Expertise Exists || Functional & Technical Expertise Not In-House ||
 * **Project** **Management** **Skills** ||  ||   || Project has skilled and experienced project manager || Project has a manager with experience to coordinate and manage vendor relationship || Project has manager with experience to manage an outsourcing relationship ||
 * **Timeframe** ||  ||   || Flexible || Short || Flexible or Short ||

__Working with a Vendor__ Hints for a strong RFP:
 * Vendor:** Companies who have developed pre-packaged COTS software who are looking for clients to purchase their product
 * If you don't know exactly what you need, vendors may take advantage of you. They are only out to make a sale.
 * Vendor Relationship Process:**
 * 1) Develop and submit a Request for Proposal to vendors
 * 2) Analyze Responses
 * 3) Ask for vendor demonstration
 * Request for Proposal (RFP):** A document which outlines your needs and expectations to a vendor. It includes:
 * Information about you:
 * Who you are as a business
 * Your business requirements
 * Technical requirements
 * Delivery time frame needed
 * Information from vendor:
 * Vendor details
 * System pricing
 * System details
 * References (Not just theirs)
 * Sample contract terms
 * Focus on Requirements
 * Be Specific
 * Keep it simple
 * Work closely with your IS staff
 * Evaluating Vendor Proposals**
 * Functionality
 * Does it provide everything you need?
 * Is it a BMW when you need a Ford?
 * IT Architecture and Integration
 * Price
 * Vendor Longevity & Viability


 * Useful for comparing the relative strength of vendors
 * Just because a system has many check marks, doesn't necessarily mean it meets your requirements

__Vendor Demonstrations:__ Vendors will present and demonstrate their product** Benefits:**
 * **Should contain the same information as the RFP**
 * **Script scenarios in advance**
 * **Update matrices as needed**
 * Time to make a final decision!!**
 * **It is critical that a Feasibility assessment be conducted**
 * __Assessing Feasibility:__**
 * **Technical**
 * **Operational**
 * **Legal**
 * **Political**
 * **Human Factors**
 * **Usability**
 * **Training**
 * __Economic Feasibility:__ Assess the cost-benefit relationship of the project and its net value to the organization
 * **Operating**
 * **Decrease HR Staffing and Litigation Exposure**
 * **Increase Efficiency and Morale**
 * Costs:**
 * **Developmental**
 * **Operational**


 * Things to Consider:**
 * **Tangibles are obvious**
 * **Intangibles are harder to assess**
 * **Capital Budgeting Committee will make the final go/no go decision**


 * Typical Approaches to Economic Feasibility:**
 * **Net Present Value**
 * **Return on Investment**
 * **Cash Flow**
 * **Break Even Analysis**

According to John A. Hinojos (at one time, President of Triangle Business Solutions -- Now Director of Consulting Services for [|HRchitect]): The [|Society for Human Resource Management] has generated a list of suggestions, as well, entitled "18 Steps to Selecting a Human Resource Information System." The list recommends: The main difference between Hinojos' list and the SHRM's is that Hinojos list requests more specific detail. Please keep in mind these are recommendations; some may not apply to your company. Add and subtract to this list as you see fit.
 * Chapter 6: "The RFP: RIP?" (Amanda Svoboda and Jamie Tesedco)**
 * Requests for Proposal (RFPs):**
 * Decide what you are looking for from vendors -- Formulate into a document
 * Send the document to numerous vendors
 * Wait and see who responds
 * Recommended Components of an RFP:**
 * Data You Should Provide:**
 * Size, annual sales, and all locations of the company
 * Overview of the project
 * Technical requirement
 * Project scope
 * Training, staffing, and maintenance requirements
 * Timelines and critical success factors
 * Documentation requirements
 * Data to Request from the Vendor:**
 * Length in business
 * Annual sales and number of employees
 * Ratio of income to R&D (research & development)
 * Product information
 * References
 * Cost proposal -- which you many not always receive
 * Technology supported today and in the future
 * An overview that describes your company
 * A description of your software need and the employee population it will support
 * Desired system functionality
 * Required technical environment/ specifications
 * A request for pricing
 * A request for customer references
 * Details on customer service/ support available from the vendor
 * A request for sample contract terms

1. __Asking for Too Much Detail__: If you ask for too much detail you might scare away the best suppliers. Only ask for detail that is critical to your business. Keep in mind that the RFP is an initial screening, not a final screening.
 * Ten Common Errors in RFPs:**

2. __Not Asking for Enough Detail__: If you are too vague, suppliers will most likely give you a general response in the proposal and count on going into further detail during a product demonstration. It's not a lot of detail that matters, but the right detail. Not knowing what is the right detail to request is discussed later in #9.

3. __Bashing Them with Boilerplate__: Boilerplate is formulaic, standard units of texts used often. An example would be items of a sales contract; certain aspects can be used for numerous contracts, like a cut and paste. -- The main point if you can barely get through reading it your audience will have even more trouble.

4. __Not being Organized__: Keep everything simple. Create headings for yourself to use as a guide. Only discuss what the label specifies. PROOFREAD!

5. __Not Having an Open Mind__: One of the main reasons for the selection process is to get a wide variety of opinions. Approach this process as objectively as possible; keeping in mind that personalities of sales people aren't always key.

6. __Relying Too Much on the Numbers__: Using a matrix can be misleading. They naturally weigh certain attributes more favorably than others. A matrix should be an aid in helping you make your final decision, not the decider. Conversation and qualitative information is crucial.

7. __Not Knowing Your Priorities__: You are not trying to find the right product in general. Your trying to find the best product for your needs. You need to look for key features that matter to you.

8. __Asking for Information You Don't Care About__: Know what you mean in the questions you ask. If the IT department supplies you with questions make sure you understand them.

9. __Not Really Knowing What Your Looking For__: Do a thorough needs analysis so that you can decide what's missing. To do that, get advice from multiple vendors (preferably ones with different styles). Use them to jump start yourself while you sit down and develop your needs analysis.

10. __Making an RFP at All__: It may be a better idea to avoid making an RFP at all.

If you decide to do an RFP you should:
 * Ten Useful Guidelines For an RFP:**

1. Work from your needs assessment. 2. Ask IT for advice, but don't put IT in charge. 3. Ask top management for its requirements. 4. Ask how the vendors will meet your business needs. 5. Get organized. 6. Ask about the price. 7. Ask for reference accounts. 8. Be fair. 9. Be objective. 10. Be willing to look beyond the RFP.


 * The Argument for a Short RFP:**

Hank Riehl, CEO of SkillView Technologies, Inc., feels that long RFP's aren't the way to go. He feels that by cutting evaluation time from months to weeks evaluation costs are cut by thousands of dollars.

He suggests the following steps for a short RFP:

1. Make a short wish list of the strategic business objectives for the software. (about 3-5 entries) 2. Make another list of the general, high-level attributes/modules/features the software should have. (about 8-20) 3. Research the market for alist of potential vendors. (5-8) 4. Research these vendors and their offerings. 5. Have the short list of 2 to 4 vendors make presentations and demos. Share your criteria with them. 6. Make your vendor selection on a pilot or trial basis.

The most important things to take into account are: 1. Does the software serve our strategic needs? 2. Does it deliver all/most of the attributes/features we desire? 3. Is the vendor behind the software one we can see ourselves doing business with?


 * Why You May Not Need an RFP**

The RFP is a formal process for collecting information in a systematic fashion and tracking it. In order to do that you: This can waste a lot of time. A lot of time it isn't necessary to send out a request in order to narrow down companies.
 * Send out and RFP document to a list of vendors.
 * Vendors respond.
 * Compile and compare responses.
 * Make a list of top candidates to meet with for a demo.

For a large company an RFP may be essential. But for a small to mid-sized companyit may just complicate things. The software for small companies also costs less than it would cost the company to develop the RFP.

F. Jay Fox, a consultant with the firm Working Concepts, Inc., recommends "skipping the RFP process and contacting the top three of four vendors that have the best chance of fulfulling your needs."

If you bypass the RFP in the right way, you can save weeks of frustration.
 * Conclusion**

[|Sample RFP] [|YouTube Video: Is An RFP Required?]**
 * Useful Links: