Section 1:

Section 2:Table of Contents

Step 1:Identifying Business Requirements

3 Steps to Identifying Your Business Requirements

Step #1: Identify Your Stakeholders

Step #2: Identify What You Want the Stakeholders to Achieve

Step #3: Write Out Measurable Business Requirements

Sample business requirements

Step 2:Identifying Technology Requirements

Terminology:

Technical Requirement Questionnaire

Step 3:Engaging Vendors

To RFP or Not to RFP?

How to Write an RFP

Evaluating Vendors

Step 4:Selection Refinement

Developing a Scoring Matrix

Step 1 and 2: List Features and Assign Weight

Step 3: Score Vendors

Step 5:Managing Implementation

Five Essential Stages in I&R Software Implementation

Step 6:Post-Implementation

Where to Go From Here: Ongoing Tasks

SixSteps to I&R Software Selection:

Step 1:Identifying Business Requirements

Goals of this section:

  • To define exactly what you need to be successful
  • To articulate your expectations to vendors

Business requirements are the criteria that any new software must meetto create value. Although you probably have a general idea of what you need, you must also communicate these needs as clearly as possible to others. This process also ensures that you have undertaken an internal analysis of why you are looking for new software and what you are hoping to achieve by this move.

3 Phases to Identifying Your Business Requirements

Phase #1: Identify Your Stakeholders

Stakeholders are the people who will either benefit from the software or who will be involved in the software’s implementation. Typical I&R project stakeholders include: executivemanagement, clients, I&Rspecialists, program managers, IT professionals or system administrators, resource specialists, orstate/province or municipalagencies that might be planning their own implementation of software that might impact your selection.

Phase #2: Identify What You Want the Stakeholders to Achieve

To complete this step, think about all the problems and opportunities that you face. To identify these elements:

  • Review everyday tasks to identify areas for improvement
  • Research available software features and select the ones that you want
  • Isolate problems that create inefficiencies or that affect performance
  • Ask other I&R business leaders what features they most value in their software

Phase#3: Write Out Measurable Business Requirements

Now, write your requirements in complete sentences. Make sure each requirement can be objectively verified, either by setting a numerical limit or a positive/negative indicator.

Here are a few tips for this process:

  • Write what needs to be done, not how to do it.
  • Keep sentences as simple as possible, using as few words as necessary (think of it like a short Powerpoint presentation).
  • Speak plainly and minimize jargon.

Sample business requirements

  • Allow call center managers to create touch-of-a-button reports using real-time statistics
  • Enhance our ability to managesubsets of services that have their own pool of staff, volunteers, and reporting requirements, while still integrating with unified telephony/technology networks
  • Reduce the time it takes I&Rspecialists to create a call report by 50%
  • Allow users to access text-messaging or chat services from our website
  • Ensure that a cloud-based solution has constant or near-constant uptime
  • Ensure that only one IT professional will be needed to maintain, repair, or implement the system
  • Provide call center managers with HMIS case-management capability

Step 2:

Goal of this section:

  • To identify and communicate the current and future technology needs of your organization

Once you’ve got your business requirements hammered out, it’s time to focus on technology. Largely, the business requirements lead to the technological requirements, but therealso needs to be separate thought applied to preferred platforms and applications. Many people find this subject daunting, so we’ve broken the technical requirement-defining process as simply as possible.

Terminology:

The following sections contain the following tech terms that may not be familiar to everyone:

API – Specifies how some software components should interact with each other and with outside components.

On-premises–On-premises software (sometimes abbreviated as "on-prem" software) is installed and run on computers/networks on the premises (in the building) of the organization using the software, rather than at a remote facility, such as at a server farm or a cloud somewhere on the Internet.

SaaS(Software as a Service) –Software distribution model in which applications are hosted by a vendor or service provider and made available to customers over a network, typically the Internet.

Service-oriented architecture (SOA)– Underlying structure supporting communications between services. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. (Source: SearchSOA)

Technical Requirement Questionnaire

The following chart will help you identify what technology optionsyou should consider. This list is not exhaustive, and it is recommended that you carefully analyze your own technology frameworks or consult an expert if you need help with this step:

Page 1

Subject / Specific Questions / Your Response
1 / Software Requirements / What is your I&R service model (is it traditional I&R or is there an enhanced case management element with multiple points-of-contact with individuals?) In the latter case, will you need a software capable of tracking these contacts?
2 / Hardware Requirements / Do you have the minimum requirements to accommodate a new software, such as computers, servers, Internet connectivity, etc.?
3 / Multi-location / Is your I&R service operating from more than one location? (For example, are there resource specialists based in five separate counties working for three different organizations plus two staff who work from home).
4 / Multi-organization / Does your multi-organizational management situation require the software to be customized, and can this be budgeted for?
5 / If this is a multi-organization implementation, what challenges might arise? (Standardization of workstations, operating systems, etc.)
6 / Does your multi-organizational system require that there be multiple system administrators who have the same privileges and/or different levels of access?
7 / Multi-organization / How is the cost derived? (e.g. per agency, based on number of concurrent users, or some other way?)
8 / How does the software handle call and resource data created by different agencies?
9 / How easy is it to share resource data? How is the privacy of caller information and call data ensured across agencies? Can they be shared, and at what levels?
10 / Can different agencies use a different customized version of the taxonomy?
11 / Can each agency have its own web portal? Would there be additional cost?
12 / Licenses / How many simultaneous users are allowed on the system? Does this meet your needs? And what are the licensing arrangements for additional users?
13 / Disasters / Are you going to use the same software to respond to disasters that you use in sunshine (normal) hours?

Page 1

Step 3:Engaging Vendors

Goals of this section:

  • To gather critical information about the product
  • To learn about emerging technologies
  • To decide whether or not to RFP

When your business and technology requirements are established, it’s time to start talking to vendors. Knowing how to effectively communicate what you needto know is essential for choosing the best software.

To RFP or Not to RFP?

For many software shoppers, a major concern is whether to go to the vendors or to let the vendors come to you. However, issuing an RFP is not always the best route to take.

There are three methodsof gathering information from vendors, and it is important to know when each option is appropriate:

Method One -- RFP:It’s best to RFP in any of the following situations: 1) You have a basic idea of what, but you need but could benefit from vendor input 2) You have a complex set of requirements for which you need vendor creativity 3) You are required to by either your governing body or your funders.

The RFP process can be a great way to differentiate among vendors who are willing to undertakesome of the planning legwork for you. Also, RFPs create competitive pricing scenarios, driving down overall costs.

For help writing an RFP, refer to the RFP-writing guide following this section.

Method Two -- No RFP:There are some times when an RFP is more trouble than it’s worth. It’s best to not RFP when 1) You have a clearly defined idea of which vendors can meet your needs 2) All you need is simple information, such as pricing, (3) You are not certain of your needs and want to have some open-ended conversations with vendors, or (4) You are looking at some ‘out-of-the-box’ scenarios and again, would like to engage in some open conversations. (Note that any of these situations may still result in a future decision to issue an RFP).

Not using an RFP avoids some of the drawbacks of requesting proposals. For one, you can consider all vendors, not just the ones that respond to the RFP. For another, the RFP writing can easily turn out improper responses or poor pricing structures if the request isn’t worded precisely.

Method Three -- Shortlisting. There is another option that not everyone considers yet is sometimes the best route to take. This option involves narrowing the list of possible vendors to a few and engaging these vendors directly. Afterward, a very specific and less formal RFP can be issued to these few parties.

The advantages to selecting vendors this way is that you are sure to consider the specific vendors you want and are able to start building relationships with these vendors (ideally your ‘vendor’ evolves into a ‘business partner’). Also, you can relay your business requirements directly to a real person and draw knowledge from direct interaction. This can be a labor-saver for both you and the vendor since no lengthy RFP process is involved.

How to Write an RFP

A poorly written RFP can result in a series of improper responses and dissuade important vendors from applying. To avoid problems, ensure your RFP contains the following information:

Organization background: Describe what you do, how you do it, and who you serve in brief but descriptive terms.

Business requirements: Let the vendors know exactly what you need and list measurable success-benchmarks. Use Step 1 of this document as a guide.

Approach Guidelines:Describe the basics of a good project. Keep in mind thatsometimes the more prescriptive you are, the less creative the applicants can be.

Format guidelines. Add specifications that will make the proposals easier to review, such as a maximum length. Ensure that vendors respond to the most important points through explicit directions.

Budget/cost breakdown. Specify whether you require a line-item breakdown or a flat cost. If you require a flat cost, make sure you make it clear what it must include.

Timeline. Describe when you need the project completed and include any milestones that need to be achieved by a certain time.

Essential data. Be sure to include: a due date for the proposal, contact information that vendors can reach out to for questions, and submission instructions.

Evaluating Vendors

When dealing with vendors, keep in mind the following categories of essential questions:

  1. Vendor Stability: Is this a high-performing potential partner that will stay in business for the long run?
  2. Essential Functions: This software looks and feels good, but what’s “under the hood,” particularly in relation to emerging requirements? (This will be outlined in more detail later)
  3. Data Ownership: Will I have to worry about privacy or legal issues regarding my data?
  4. Resource Database: Does this software offer the features and customization options we want?
  5. Taxonomy: Does this vendor understand the Taxonomy requirements of I&R and can they accommodate these?
  6. Search and retrieval: Does the vendor offer sufficient search options?
  7. Call handling. How does the system manage calls?
  8. Reporting. What reporting functionalities are there, how customizable are they, and how easy is the process?
  9. Public website. Does the solution give the public the ability to search your resource database? Can you customize guided category searches and keyword options?
  10. Customer service. What are your impressions of the vendor in terms of addressing your needs, and what ongoing commitments do they make to you as a client? What do existing users have to say?
  11. Accessibility. Is the product usable by everyone, including persons with disabilities?

Each of these questions has a series of sub-questions. The chart on the following pages contains a breakdown of questions related to the topics above. Go through the list and decide which are pertinent to your organization. Afterwards, it may be helpful to develop a template with these questions that you can use when meeting with vendors.

Page 1

Specific Questions / Vendor Response
Vendor Stability: Is this a high-performing business partner that will stay in business for the long run?
1 / What is the company name, software name, and current version of software?
2 / What is the history of the company and its current product range?
3 / How is the company incorporated and who are the principle owners?
4 / How long has the company been involved in I&R?
5 / How many full-time staff are employed and in what positions?
New Essential Functions:This software looks and feels good, but what’s “under the hood”?
6 / Does the record structure of the resource database component of the software reflect the latest version of the AIRS XSD data structure (3.1)? Are there any parts of that structure (including elements and attributes) that are not included?
7 / Is there is an Application Programming Interface (API) enabled system that will allow for seamless data sharing and app-enabling for future projects?
8 / Can the software handle mobile-app development, and will it be able to integrate seamlessly with the mobile systems of other partners? Maybe “Can the software be accessed on mobile applications? And will it … “?
9 / Is the software built on a service-oriented architecture that connects it to other systems, users, and applications?
10 / Does the software have a chat component?
11 / What security and privacy security and privacy features are present?(e.g., HIPAA Compliance, 128 bit encryption, Verisign Secure Site SSL Certificates)
12 / What is the vendor’s “road map” for product development look like? Do they intend to add new features and functionalities in the next 6-12 months? Are they open to client requests for new features?
Versions and upgrades: Will the vendor support the system and improve it over time?
13 / What is the current version of the software? When was it released and what were its major improvements?
14 / What is the typical frequency of upgrades and enhancements, and how are upgrades released to customers?
15 / What are the general pricing policies for new versions and upgrades for existing users?
16 / What support is provided to previous versions and for how long?
17 / What future developments will likely take place in the next 12 months?
Data Ownership: Will I have to worry about privacy or legal issues regarding my data?
18 / Who owns the software source code and are there any escrow-type arrangements to cover users in case the software company goes out of business?
19 / What are the vendor’s data ownership policies? Specially, what are the I&R’s rights regarding the resource and client data entered into the software?
Resource Database: Does this software offer the features and customization options we want?
20 / Can the software generate reports showing the last “update” date of all resource database records and/or a listing of all records whose date of last update is older than a specific date?
21 / Does the software includean audit trail feature so resource specialists can trace/review recent changes to individual records?
22 / Can a user insert additional fields in a resource database record?
23 / Can users hide/not display data fields? If yes, can users specify activation of fields for display for various levels of users (for example, can a user specify to turn off a field for public website display but turn it on for internal users)?
24 / Do confidentiality flags exist for agencies, sites, programs that restrict their viewing to specific users?
25 / Does the software allow agencies to directly submit online changes that are then subject to an internal verification process (that is, can they be placed in a ‘holding pen’ before going live)? Can this occur both by the I&R pushing out the request and the agency pro-actively invoking it?
26 / If yes to the above, how does the ‘holding pen’ function? Can changes that affect all records related to an agency be simultaneously implemented or easily identified for manual changes?
27 / Does the software maintain a ‘change log’ of resource database activities for reporting purposes? (For example, numbers of records that had been modified, number of new programs added and deleted).
Taxonomy: Does this vendor understand the Taxonomy requirements of I&R and can they accommodate these?
28 / Does the software accommodate the AIRS/211 LA County Taxonomy for indexing purposes?
29 / Does the software search the Taxonomy by full words as well as full words beginning from the start of the term? (For example, searching for “abuse” would retrieve the Taxonomy terms “Abused Children” and “Elder Abuse Prevention”).
30 / Does the vendor have an up-to-date license allowing them to incorporate the Taxonomy into their software package?
31 / Does the software display the following data information for each Taxonomy term within the resource database module: Term Code; Term Name; Term Definition; Use References; See Also References; Related Concepts?