Selecting CRM Software II

Transcript

2. 2 •Reasons for a formal selection process •Because it’s easy not to do it •Not always intuitive – easy to skip important steps and not know it (not your job) •You may have to defend the time you need •Step-by-step review of a system, selection process •Review the process, stem-to-stern
3. 3 •Just buy what your friend uses! •It’s not that you wouldn’t, but that can’t be the sole reason •A system should fit you like a suit, do you wear the same size suit as your friend? •How do you know your friend made a good decision? •Your friend isn’t the one who will be evaluated •Make the decision yourself. The internet is so helpful! •A little knowledge is a dangerous thing •I do this for a living and I would still go through the process (in fact, I am right now) •You know ticketing or fundraising, but you may not know best practices in applications •If you fail to plan… •Cliché but very true, if you have 8 hours to chop down a tree, spend the first six sharpening your axe •Projects that fail generally do so because a lack of planning
4. 4 •It’s a big investment, cover your assets! • Software is not cheap – money or time • Your org can go through significant change – it’s not as easy as “we need a new system” • The success (or lack of) can reflect on you •A successful implementation begins now •Discover problems, opportunities early •Set expectations •Empower team working on it •You need to have real ownership, don’t expect the vendor to protect the interests of your organization (trust, but ensure) •Vastly improve you chance for success
5. 5 Self-explanatory…
6. 6 Brief overview of the process
7. 7 •Executive branch of system selection •It’s a decision making body that controls the project, not a group of end users •Pipeline to project sponsor: re: conflicts, money decisions, etc. •Represent the stakeholders, don’t include them all •The more people you have on the project team, the harder it is to get things done •Keep it on schedule •This group creates the schedule and makes sure the project stays on schedule and budget •Eight people or smaller •Much bigger and you will not be effective •I’ve done successful selections with 3 people •Might include: Box office management, marketing leadership, finance leadership, web person, fundraising •Represent the stakeholders, don’t include them all
8. 8 •You don’t know what you don’t know •Without fail, clients will say: I didn’t know you/we did that? •You may not even know what you know •It is easy to do your job day to day and not really have a sense for the total overview of your duties, why you do it this way, and where they fit in the org as a whole •When bad processes marry a good system… •Your problems may not be your system •If you bring it over as it is, you may not be happy •Look at all processes, codes, policies; everything is up for discussion; opportunity for everyone to “vent” •Can be surprising what you find out (real story: copy to Excel, print out, tape the paper together, highlight the rows, hand to a admin for entry back into the system) •Analyze across functions, departments •Processes do not operate in a vacuum; Get groups together from different departments that play a different part of the same overall process – can be enlightening •If it’s not written, it’s not said
9. •Stress this – it is too easy to sit around and have a lot of good ideas that go nowhere or are really not that good, the process of writing them down is magical (you won’t want to do it) •Every idea has a person responsible and a due date •Get buy-in from users •Remember that this is the first step in implementation – start managing change now 8
10. 9 •How do you weight cost, functionality and company? •Before you begin, decided how you will allocate the weighting •Components of an RFP
11. 10 Educate the vendor about your business They should have an idea of who you are as an institution
12. 11 Tell the vendor how you will evaluate them This comes from the weighing you already decided
13. 12 Tell them what you expect them to send you…
18. 17 •Don’t send the RFP to the world •It wastes your time and theirs •Create a qualified shortlist •Goal is to have a list of vendors that you feel can support your business •When in doubt send it (have had multiple experiences where clients made up their minds and ended up picking the vendor they wanted to eliminate) •Research •The internet •Your peers •Conferences (like this one) •Preliminary vendor phone calls •Find out who your sales rep is •Call up and have a long discussion about what makes your needs special, make a go/no go decision
19. 18 •Know what you are going to evaluate before you evaluate it •Before you read a proposal or see a demo, know what you want to measure •Like going to an auction, know what it’s worth or you might make a bad decision •Summarized requirements checklist •The VEG should not be something you invent, it should derive from the work you’ve done – use the checklist to create it •Weight your requirements •Give weight to each functional area •Grade the submissions
21. 20 •Email RFP’s to vendors •Used to be mail, I only email now •Send a nice cover letter •Establish schedule •Let them know the schedule including submitting proposal (3-6 weeks), demos, goal for selection date •Vendor Q/A •Include a time for vendor questions, email only •Send answers to all vendors – keep it fair •Can set up conf call •Read, read, read •Can be a lot of reading, be prepared •Fill out your VEG! •When you are done reading each one, fill out the VEG •Key members of the team should do it
22. 21 •How long should they be? •How long (how much string do you need to tie a package?) ½ day to multi- day •Don’t try to do to much at once, these can be draining; break them up •Scripted •This is a must, you will vacillate without them •Should derive from the RFP, and checklist; should be set up the same way as the VEG •Keep focus •Do not let the shiny things distract you •Do not look at everything, goal is to look at key things •Keep on-schedule •Not easy, but you must control it, not the vendor •Would you show me that? •Make them prove the functionality exists •You are not buying what is in the next release •Update the VEG •Immediately following the demo, get the team together and grade it with the
23. VEG •Follow-up demos •Keep a list of stuff that you are not sure about or areas that you could not cover in the first demo •Can be remote 21
24. 22 •Make your preliminary selection •As a team, make 1st and 2nd choice (your not done until the contract is signed) •Write reference questions in advance •Ask about their program, make sure it’s similar to yours •Remember the VEG? Use that to ask functional questions •Ask about the weaknesses you think you see •Training and support •Query and reports •Staffing •If you had to do it over… •Ask for several references, use a few •Try to get a long list and pick a few of them •Ask you peers that are not on the reference list •Don’t just stick to the list you got from the vendor, they are likely not going to give you bad ones (though you would be surprised!) •No system is perfect •Find out what you need to be prepared for during implementation
26. 24 •Read it •You might be surprised what is in there •They will never love you more than today •Use the leverage that you have •May be willing to deal at quarter end •Don’t be afraid to haggle •It’s like fundraising, you won’t get a gift (discount) if you don’t ask