Tag Archives: vendors

Year-end Reflections

This post was originally published on the NTEN Blog on December 24th, 2015.

As years go, 2015 was a significant one in my career. The work of a CIO, or IT Director, or whatever title you give the person primarily responsible for IT strategy and implementation, is (ideally) two parts planning and one part doing. So in 2015—my third year at Legal Services Corporation—we did a couple of the big things that we’d been planning in 2013 and 2014.

First and foremost, we (and I do mean we—I play my part, but I get things done with an awesome staff and coworkers) rolled out the first iteration of our “Data Portal.” The vision for the Data Portal is that, as a funder that works primarily with 134 civil legal aid firms across the U.S. and territories, we should be able to access the relevant information about any grantee quickly and easily without worrying about whether we have the latest version of a document or report. To reach this vision, we implemented a custom, merged Salesforce/Box system. This entailed about a year of co-development with our partner, Exponent Partners, and a move from in-house servers to the Cloud. We’ll complete our Cloud “trifecta” in early 2016, when we go to Microsoft’s Office 365.

This was particularly exciting for me, because I have been envisioning and waiting for technology to reach a level of maturity and… collegiality that makes the vision of one place where documents and databases can co-exist a reality. Integration, and one-stop access to information, have always been the holy grails that I’ve sought for the companies that I’ve worked for; but the quests have been Monty Python-esque through the days when even Microsoft products weren’t compatible with each other, much less compatible with anything else. What we’ve rolled out is more of a stump than a tree; but in the next year we’ll grow a custom grants management system on top of that; and then we’ll incorporate everything pertinent to our grantees that currently hides in Access, Excel, and other places.

I’m working on a much more detailed case study of this project for NTEN to publish next year.

Secondly, we revamped our website, doing a massive upgrade from Drupal 7 to… Drupal 7! The website in place when I came to LSC was content-rich, navigation-challenged, and not too good at telling people what it is that we actually do.The four separate websites that made up our entire site weren’t even cross-searchable until we addressed that problem in early 2014. Internal terminology and acronyms existed on the front page and in the menus, making some things incomprehensible to the public, and others misleading. For example, we often refer to the law firms that we fund as “programs.” But, in the funding world, a “program” is a funding category, such as “arts” or “environment.” Using that terminology. along with too buried an explanation that what we actually do is allocate funding, not practice law ourselves, led many people to assume that we were the parent office of a nationwide legal aid firm, which we aren’t.

The new site, designed by some incredibly talented people at Beaconfire-RedEngine (with a particular call out to Eve Simon, who COMPLETELY got the aesthetic that we were going for and pretty much designed the site in about six hours), tells you up front who we are, what we do, and why civil legal aid is so important, in a country where the right to an attorney is only assured in criminal cases. While civil cases include home foreclosures, domestic violence, child custody, and all sorts of things that can devastate the lives of people who can’t afford an attorney to defend them. This new site looks just as good on a phone as on a computer, a requirement for the Twenty-Teens.

My happiness in life directly correlates to my ability to improve the effectiveness of the organizations that I work for, with meaningful missions like equal justice for all, defense against those who pollute the planet, and the opportunity to work, regardless of your situation in life. At my current job, we’re killing it.

RFPs GOOD. Fixed Bids BAD.

It occurs to me that my signature rant these days is not clearly posted on my own blog. Let’s fix that!

As I’ve mentioned before. Requests for Proposals (RFP’s) are controversial in the nonprofit sector. Vendors hate them. dollar-163473_640Nonprofits struggle with developing them. I’ve been on a multi-year mission to educate and encourage the community to rethink RFPs, as opposed to throwing them out. In particular, nonprofits need to break away from fixed bid requests when hiring web developers, programmers, and people who implement CRMs. Here’s why:

Done correctly, RFP’s are an excellent practice. A good RFP informs potential vendors about the organization, their current condition, and their project goals. A questionnaire can focus on vetting the expertise of the consultant, examples of prior work, stability of the company, etc. All good things to know before investing serious time in the relationship. The RFP can also request billing rates and the like, but, in my experience, the cheaper rates don’t always correlate with ultimate project cost. Some higher hourly consultants do the work in half the time of some moderately priced ones.

The problem is that many nonprofits want to get that fixed bid and then hire the lowest bidder. But, for a web design or CRM project, the odds that the nonprofit knows how many hours the project is going to take are practically nil and, what’s more, they absolutely shouldn’t know. With a good consultant, you’re going to learn a lot in the process about what you should be doing. With a wild guess-based fixed bid, you are likely to suffer from one of two problems:

  • The project will be seriously underbid (very likely) and the vendor relationship will get worse and worse as they keep expending more hours without being compensated;
  • Or the vendor will finish up in half or two thirds of the hours and there you’ll be, donating to their charity.

You can vet the fiscal competence of a consultant.  Check their references and ask good questions like:

  • “Did the project come in at or under budget?”
  • “Was the vendor able to scale the project to your budget?”
  • “Can you tell me about a time that you had a billing disagreement with them, and how well it was resolved?”

Also, check their reputation in the nonprofit sector, because we have lots of mailing lists and forums where you can do that.

I hire consultants based on their expertise, reputation, and compatibility with my organization’s goals and work style. I stress that vendor interviews should be with the staff that I will most likely be working with. I’ll often break a project into two phases, one for discovery and then another for implementation. With the great consultants that I work with, this does not result in over-budget implementation bids. Instead, it helps us define what we can do and stay within budget. Because this is all about taking away the guess work.

So, RFPs are good things, as long as they are making realistic requests of the vendors. The crisis with them in our sector is based simply on the fact that most of our RFPs ask questions that can not, and should not, be answered, such as “how much will you charge me to do this undetermined amount of work?”

How I Spent My 2015 Technology Initiative Grants Conference

I’m back from our (Legal Services Corporation) 15th annual technology conference, which ran from January 14th through the 16th  in San Antonio, Texas.  It was a good one this year, with a great location, good food, great people – nearly 300 of them, which is quite a record for us. There were plenty of amazing sessions, kicked off by a fascinating keynote on international access to justice web app partnerships. Slides and videos will be up soon on LSC’s website. But I did want to share the slides from my sessions, which all seemed to go very well.  I did three:

Are You Agile

I kicked off the first morning doing a session on agile project management with Gwen Daniels of Illinois Legal Aid Online. My slides provided a basic overview of project management concepts, then Gwen did a live demo of how ILAO uses Jira and a SCRUM methodology to develop websites and applications. Having studied agile more than actually practicing it, I learned a lot from her.  The combined slides will be up on LSC’s site. I pulled my intro from this broader presentation that I did at the Nonprofit Technology Conference in 2013:

Shop Smart: How A Formal Procurement Process Can Safeguard Your Investments

On Thursday, I summarized everything I know about software and vendor selection, writing proposals, and negotiating contracts into this dense presentation on how to purchase major software systems.

Security Basics

And on Friday, usual suspect Steve Heye and I led a session on security, factoring all of the things that we think orgs should know in an era of frequent, major breaches and distributed data.

I’ll hit some of these same themes in March at the Nonprofit Technology Conference, where I’ll be speaking on contract negotiations (cloud and otherwise) and information policies (with Johan Hammerstrom of CommunityIT. See you there?

Does Your Request For Proposal (RFP) Ask The Right Questions?

This post was originally published on the Community IT Innovators Blog in November of 2014.

foler-29373_640Requests for Proposals (RFPs) are a controversial topic in the nonprofit sector. While governmental and corporate organizations use them regularly as a tool to evaluate products and services, their use in our sector is haphazard. I spoke recently about the RFP process and how it could work for us at the 2014 Nonprofit Technology Conference. My slides from that talk are here, along with this blog post outlining my key arguments in favor of RFPs. But a recent conversation on NTEN’s DC community list really summed up the topic.

A member posted an RFP for CRM consulting and asked why he was getting scant responses from the vendors. I looked over the RFP, and saw that it requested a fixed bid quote for work that was not well defined. I popped back into the forum with some comments:

“This five page RFP contains about a tenth of the information that a decent consultant would need in order to propose a meaningful bid for the work. If you’ve received any such bids already, I would advise you to throw them out, because those bids are wild guesses, and you will either be paying more than you need to, or setting yourself up for a combative relationship with a vendor who is angry that the project is taking far more hours than they guessed that it would. Decent consultants are passing on the RFP because it lacks so much specificity. There are two ways you could address this problem:

  1. Significantly beef up the RFP. If I were to go this route, I might hire a consultant to help me write the RFP, because they can better communicate the requirements than I could.
  2. Stop asking for a fixed bid. Query their expertise in the areas that need it, and request ample examples of work they’ve done. Also, ask for their hourly fees by role. The RFP can provide a fairly high-level overview of the project, as you won’t be asking them to generate a meaningful estimate. Instead, do reference checks and ask specific questions about their billing in order to vet that they are honest and sensitive to nonprofit budgets.

Many consultants would pop in here and say “forget the RFP – let us come talk with you and get a sense of the project and we can go from there.” As a customer, not a consultant, I wouldn’t go for that. A good RFP, sent before any face to face meetings, can tell you a lot about the professionalism, insight and care that a company will bring to your project.  Rapport and relationship are also critical, but assessing those elements is the second step. (And when it comes to that step, insist that you are meeting the people who you would almost certainly be working with). An RFP response can also be attached to the contract to make sure that the vendor is obliged to live up to their claims.

I do fixed-bid quotes for phone systems and virtualization projects, where I can tell them exactly what the project would entail. I don’t for websites and software development, because not only do I not know what the ultimate product will look like or require, I shouldn’t – a lot of learning takes place during the project that will shape the requirements further. Once I’ve hired a good consultant, we can do a defined discovery phase that will allow them to provide a fixed quote — or reasonable range — for the rest of the work.  It’s a much better way to set up the relationship than by basing it in unrealistic projections.”

Subsequently, a consultant posted a reply suggesting that RFPs are a pain, and they should really just hire a consultant they like and see if it works out, perhaps after doing a small Request for Information (RFI) to learn more about the consultants available. I replied:

I did say that consultants will often dis the RFP process and say, “just hire us and see if it works out.”  It certainly is easier on the consultant. As Clint Eastwood would say, the question is, “do you feel lucky?” Because if you feel lucky, then you can just find a suitable-looking consultant and hope that they are ethical, not over-booked (and therefore liable to under-prioritize your project), experienced with the technology that they’re deploying, etc, and do a discovery phase that will cost you x thousands of dollars, and then find out if they are the right consultant for you. Or you can do an RFP, throw out the responses that clearly don’t match your requirements, throw out the ones that don’t seem interested or well-resourced enough to respond fully, and interview the two to four consultants that look like good matches. It’s more work up front than hiring someone and hoping they’ll work out, true, but, here’s what it gets you:

  1. Focused. Just writing the RFP gets you more in touch with the goals and requirements for the project.
  2. Informed. The RFP review and interviews are a chance for the project team to explore the project possibilities with various experts.
  3. Confident. Without investing thousands of dollars into a “vendor test,” you will know who has the right experience and a compatible approach. For me, it’s often less about the skill and experience than the approach (e.g., we want a collaborative partner that would teach as they go, rather than experts to outsource the work to).
  4. Accountable. The RFP can be a contractual document, so if the vendor lied about what they can do, they can be held responsible for that lie. And, not all consultants lie, but some do. I’ve caught them at it.  😉
  5. Documented. In the future, after you’ve left the organization, your successors might wonder why you selected the partner that you did. The RFP process leaves a knowledge management trail for key organizational decision making.

And finally, RFI vs RFP is a question of scale.  For smaller projects, without much associated risk, RFI. The investment in doing a full RFP does have to be justified by the cost and complexity of the project. For big projects, doing an RFI in order to identify who you want to include in an RFP can be helpful.

——————–

Community IT Innovators are a DC consulting and outsourcing firm located in Washington, DC.  Their blog is a great source of good tech advice, with similar themes (but more expert advice, less over-indulgent opinion) as mine.

How Easy Is It For You To Manage, Analyze And Present Data?

apple-256262_640I ask because my articles are up, including my big piece from NTEN’s Collected Voices: Data-Informed Nonprofits on Architecting Healthy Data Management Systems. I’m happy to have this one available in a standalone, web-searchable format, because I think it’s a bit of a  signature work.  I consider data systems architecture to be my main talent; the most significant work that I’ve done in my career.

  • I integrated eleven databases at the law firm of Lillick & Charles in the late 90’s, using Outlook as a portal to Intranet, CRM, documents and voicemail. We had single-entry of all client and matter data that then, through SQL Server triggers, was pushed to the other databases that shared the data.  This is what I call the “holy grail” of data ,entered once by the person who cares most about it, distributed to the systems that use it, and then easily accessible by staff. No misspelled names or redundant data entry chores.
  • In the early 2000’s, at Goodwill, I developed a retail data management system on open source (MySQL and PHP, primarily) that put drill-down reporting in a web browser, updated by 6:00 am every morning with the latest sales and production data.  We were able to use this data in ways that were revolutionary for a budget-challenged Goodwill, and we saw impressive financial results.

The article lays out the approach I’m taking at Legal Services Corporation to integrate all of our grantee data into a “data portal”, built on Salesforce and Box. It’s written with the challenges that nonprofits face front and center: how to do this on a budget, and how to do it without a team of developers on staff.

At a time when, more and more, our funding depends on our ability to demonstrate our effectiveness, we need the data to be reliable, available and presentable.  This is my primer on how you get there from the IT viewpoint.

I also put up four articles from Idealware.  These are all older (2007 to 2009), they’re all still pretty relevant, although some of you might debate me on the RSS article:

This leaves only one significant piece of my nptech writing missing on the blog, and that’s my chapter in NTEN’s “Managing Technology To Meet Your Mission” book about Strategic Planning. Sorry, you gotta buy that one. However, a Powerpoint that I based on my chapter is here.

Working With Proposal Requests Collaboratively

Okay, I know that it’s a problem worthy of psychoanalysis that I’m so fascinated with the Request for Proposal (RFP) process. But, hey, I do a lot of them. And they do say to write about what you know.

The presentation that I gave at NTEN’s conference in March focused on the process of developing and managing RFPs. I made the case that you want to approach a vendor RFP very differently than you would a software/system RFP. I pushed for less fixed bid proposals, because, in many cases, asking for a fixed bid is simply asking for a promise that will be hard to keep. ROI involves far more than just the dollars spent on projects like CRM deployments and web site revamps.

In the session, I learned that Requests for Information (RFIs), which are simpler for the vendors to respond to, can be a great tool for narrowing a field.  It’s important that clients are respectful of the fact that vendors don’t get paid to respond to proposals; they only get paid if they win the bid, and showing respect on both sides at the very glimmer of an engagement is a key step in developing a healthy relationship.

Since the conference, I’ve gotten a bit more creative about the software that we use to manage the RFP process, and I wanted to give a shout-out to the tools that have made it all easier.  There are alternatives, of course, and I still use the Microsoft apps that these have replaced on a daily basis for other work that they’re great at. But the key here is that these apps live in the cloud and support collaboration in ways that make a tedious process much easier.

Google Docs is replacing Microsoft Word as my RFP platform software. The advantages over Word are that I can:

  • Share the document with whomever I choose; the whole world or a select set of invitees. Google’s sharing permissions are very flexible. With Word, I had to email and upload a document; with Google Docs I only have to share a link.
  • I can share it as a read-only document that they can comment on. This simplifies the Q&A portion of the process, while maintaining the important transparency, as all participants can see every question and response.

We recently did an RFI for web development (it’s closed now, sorry!) and here’s what it looked like, exactly.

Smartsheet is replacing Microsoft Excel as my response matrix platform.

Example of a Smartsheet matrix

The first step upon receiving responses to a request is always to put them all in a spreadsheet for easy comparison.  Smartsheet beats Excel because it’s multi-user and collaborative. Since Smartsheet is a Spreadsheet/form builder/project management mashup app, I can add checkboxes and multiple choice fields to my matrix.

For simple proposals, you can also easily use Smartsheet to collect reviewer comments and votes. Just add a few columns (two for each reviewer). This puts the matrix and evaluation criteria all in one place, that can easily be exported to spreadsheet or PDF in order to document the decision.

Surveymonkey has replaced Excel for cases when the evaluation criteria is more complex than a yes/no vote. Using their simple but sophisticated questionnaire builder, you can ask a number of questions with weighted or scaled answers. The responses can be automatically tallied and, as with Smartsheet, exported to Excel for further analysis or published as charts to a PDF.

Consultant Selection Chart

As I’ve ranted elsewhere, making a good investment in software and vendor evaluation has a big impact on how successful a project will be.  Working with staff who are impacted by the project in order to choose the partner or technology increases buy-in and the validity of the initiative in the eyes of the people that will make or break it. And a healthy process insures that you are purchasing the right software or hiring the right people.  These tools help me make that process easier and more transparent.  What works for you?

Three Ways To Make Sure that Your Next Big Software Project Is A Success

This post also appeared on the Cloud for Good Blog in April of 2014.

Buying a new fundraising CRM or replacing your finance and HR systems are big investments with critical outcomes. These are the types of projects can have a huge impact on your ability to accomplish your mission. Poorly planned, chosen and deployed, they will do the opposite. If you’re grasping for a cautionary tale, just look at the recent Healthcare.gov rollout, or the worse related stories in Maryland and Oregon. But successful implementations happen every day as well, they just don’t grab as many headlines.

How can you make sure that big software projects succeed?  Here are three recommendations:

1. Know what you need

All too often, the decision to replace a system is based more on frustrations with your current system than identified improvements that a new system might bring.  And, far too often, those frustrations aren’t really based on the capabilities of your existing system, but, instead, on the way that it was configured.  Modern software is highly configurable.  In nonprofit environments, where administrative staffing is low and people are juggling multiple priorities, the proper investment in that configuration is sometimes skipped. It’s important that you take the time to thoroughly catalogue your current processes and goals; clearly identify your reporting needs; and establish your core requirements before you embark for this sort of project.

Technology automates processes. If you automate bad processes, you get bad technology.  So making an investment in business process mapping, and taking the time to streamline and enhance the way you work with information today will insure that you know what your new system should be doing for you as you configure it.

2. Be prepared to change the way you do things

Ideally, you’ll invest in software that does exactly what you want it to do for you. In reality, there will be limitations in the way that the software was programmed, or the way that it has to be configured in order to integrate with your other applications, that will be out of sync with your preferences. Software doesn’t have a mind of it’s own; instead, it inherits the assumptions and biases of the developers that created it. They might assume, for instance, that you collect donations from individuals and have no need to recognize households in your system. Or they might assume that your average employee turnover is less than 20%, whereas, at a workforce development agency that hires its clients, 50% is more on the mark.  If the best system you can find suffers from some of these limitations,. you will have to either work around them, or buy the second best system, if it requires fewer workarounds, because you do want to minimize them.

Regardless, you’ll want to understand the underlying assumptions in the application and have a strategy for working around them. Some companies will go so far as to commission or design their own systems (commonly called “build” vs “buy”), but you need to weigh the cost of having a supported system vs. a homegrown one, because, unless what you do is truly unique, those will not be worthwhile trade-offs.

3. Hire a consultant for their expertise and compatibility, not their billing rate

We all want to get these projects done for as little money as possible. So there’s a tendency to hire consultants based on the lowest bid. I’d caution against this. major system configuration projects are generally open-ended — determining the exact configuration and number of hours that it will take to get there before the project starts is akin to inviting the whole city to a dinner party and determining the number of plates that you’ll require before anyone RSVPs. So you want to work with consultants who are very efficient at their work, and very conversant with your needs. What you don’t want to do is hand your project to a consultant who doesn’t really understand your requirements, but has their own idea as to how it should be done.  You could well be left with a system that met the budget, but not your needs, or one that exceeded the budget while being reworked to satisfy your requirements. A good consultant will work closely with you.  they’ll spend more time meeting with staff to learn about your needs then they will setting up the project, but they’ll set it up quickly and correctly based on their thorough understanding of your goals and needs. The hourly rate might be double the low bid, but the total cost could be equivalent, resulting in a usable system that will compensate for the initial dollar outlay all that much faster.

Here are slides that I developed for a talk/discussion on creating Requests for Proposals that vendors will appreciate at the recent Nonprofit Technology Conference.  These include some key strategies for making sure that you hire the right person or firm.

In conclusion, how you go about a software project has far more to do with how you conduct your business than it does with the actual technology.  Make sure that you’re investing wisely by taking the time to understand your needs, know where you can compromise, and hire the best partners.

How I Learned To Stop Worrying and Love The RFP

This article was originally posted on the NTEN Blog in January of 2014.

Requests for Proposals (RFPs) seem like they belong in the world of bureaucratic paperwork instead of a lean, tech-savvy nonprofit. There’s a lot that can be said for an RFP when both sides understand how useful a tool an RFP can be – even to tech-savvy nonprofits.

Here’s a safe bet: preparing and/or receiving Requests for Proposals (RFPs) is not exactly your favorite thing. Too many RFPs seem like the type of anachronistic, bureaucratic paperwork more worthy of the company in Office Space than a lean, tech-savvy nonprofit. So you may wonder why I would pitch a 90 minute session on the topic for this year’s Nonprofit Technology Conference. I’d like to make the case for you to attend my session: Requests for Proposals: Making RFPs Work for Nonprofits and Vendors.

The problems with RFPs are numerous, and many of you have tales from the trenches that could fill a few horror anthologies regarding them. I’ll be the first to agree that they often end up doing more harm than good for a project.  But I believe that this is due to a poor understanding of the purpose of the RFP, and a lack of expertise and creativity in designing them. What a successful RFP does is to help a client assess the suitability of a product or service to their needs long before they invest more serious resources into the project. That’s very useful.

The mission of the RFP is two-fold: a well written RFP will clearly describe the goals and needs of the organization/client and, at the same time, ask the proper questions that will allow the organization to vet the product or consultant’s ability to address those needs. Too often, we think that means that the RFP has to ask every question that will need to be asked and result in a detailed proposal with a project timeline and fixed price. But the situations where we know exactly, at the onset, what the new website, donor database, phone system or technology assessment will look like and should look like before the project has begun are pretty rare.

For a consultant, receiving an RFP for a web site project that specifies the number of pages, color scheme, section headings and font choices is a sign of serious trouble. Because they know, from experience, that those choices will change. Pitching a  fixed price for such a project can be dangerous, because as the web site is built, the client might find that they missed key components, or the choices that they made were wrong. It does neither party any good to agree to terms that are based on unrealistic projections, and project priorities often change, particularly with tech projects that include a significant amount of customization.

So you might be nodding your head right now and saying, “Yeah, Campbell, that’s why we all hate those RFPs. Why use ’em?” To which I say, “Why write them in such a way that they’re bound to fail?”

The secret to successful RFP development is in knowing which questions you can ask that will help you identify the proper vendor or product. You don’t ask how often you’ll be seeing each other next spring on the first date. Why ask a vendor how many hours they project it will take them to design each custom object in your as yet un-designed Salesforce installation? Some information will be more relevant — and easier to quantify — as the relationship progresses.

At the RFP session, we’ll dive into the types of questions that can make your RFP a useful tool for establishing a healthy relationship with a vendor. We’ll learn about the RFPs that consultants and software vendors love to respond to.  We’ll make the case for building a critical relationship in a proactive and organized fashion.  And maybe, just maybe, we’ll all leave the session with a newfound appreciation for the much-maligned Request for Proposal.

Don’t miss Peter’s session at the 14NTC on Friday, March 14, 3:30pm -5:00pm.

Peter Campbell is a nonprofit technology professional, currently serving as Chief Information Officer at Legal Services Corporation, an independent nonprofit that promotes equal access to justice and provides grants to legal aid programs throughout the United States. Peter blogs and speaks regularly about technology tools and strategies that support the nonprofit community.

Sleazy Sales Tactics and Social Networks

usedcar
Image courtesy bonkedproducer

This is a public service announcement (aka rant) intended for IT product and service reps. In a nutshell:

If your spam and cold calls haven’t resulted in a business relationship, tracking me down personally on LinkedIn, Twitter or Facebook won’t work either.

Let’s be clear: it’s not a secret that I have purchasing responsibility for IT at my company, and my business contact info is easy to find (or purchase). Mind you, I don’t hire companies based on their ability to locate that information and email or call me. I hire consultants and purchase products based on the recommendations in my communities. So cold contacting me might be inexpensive and easy for you to do, but all it tells me is that you don’t respect my time or privacy and you can’t sustain your business based on quality and word of mouth. Two strikes against you, whereas, before you cold-contacted me, you had none.

But, in failing to spam me into a relationship, taking it to LinkedIn or the contact form here is taking your pathetic and unprofessional approach to marketing into a whole new realm of sleaziness and creepitude. Cold-contacting me at my business email or on my business phone is annoying and pathetic, but far more appropriate that tracking down my personal, non-business addresses and contacting me at those. It’s called stalking.

I’m looking at you, Server Technologies. The fact that you’ve spammed me in the past does not mean that we have an established business relationship, as your LinkedIn invite falsely indicates.

And local IT Recruiters 58 and Foggy — you take the cake. Within two minutes, out of the blue, you cold-called my work number, emailed me personally via this blog, and sent me a LinkedIn invite. That was so over the top annoying that I not only will never do business with you, I’ll make sure that all of my professional acquaintances are warned away.

Because I seriously question what a company that violates my privacy as a means of introduction would do if I actually relied on them and dealt with them financially. Ethical behavior? Not a safe thing to assume. Professionalism? Already in the toilet.

Social networks offer a great avenue for the type of business promotion that works for me — word of mouth. Sincere recommendations from people who think you’re good at what you do because they’ve used your products or services. You can foster my business by doing well enough with your current customers that they will speak well of you online. You can also demonstrate your expertise by publishing materials and distributing them on Slideshare and other public repositories (including your web site, of course). If you put your energy into establishing your credentials, instead of shoving your uncertified opinion that you’re great into every channel that you can reach me through, you’ll get a shot at my business. But using these networks to harass and annoy potential customers is incredibly stupid and short-sighted.

The Perfect Fit: A Guide To Evaluating And Purchasing Major Software Systems

This article was originally published at Idealware in September of 2008.

A major software package shouldn’t be chosen lightly. In this detailed guide, Peter Campbell walks through how to find software options, evaluate them, make a good decision, and then purchase the system in a way that protects you.

cd-437723_640 A smart shopper evaluates the item they want to purchase before putting money down. You wouldn’t shop for shoes without checking the size and taking a stroll up and down the aisle in order to make sure they fit, would you? So what’s the equivalent process of trying on a software package will size? How can you make sure your substantial software purchase won’t leave you sore and blistered after the cash has been exchanged?

That’s the goal of this article—to provide some guidance for properly evaluating major software investments. We’ll walk through how to find potential software options, gather the detailed information you need to evaluate them, make a solid decision and purchase a package in a way that protects you if it doesn’t do what you hoped it would for you.

Is it A Major Software System?

The evaluation process described here is detailed, so it’s probably not cost effective to apply it to every software tool and utility you purchase. How do you know if the package you’re considering is major enough to qualify? Major systems have a dramatic impact on your ability to operate and achieve your mission—they aren’t measured by budget, they’re measured by impact.

To help identify a major purchase, ask yourself:

  • Will the application be used by a significant percentage of your staff?
  • Will multiple departments or organizational units be using it?
  • Will this software integrate with other data systems?
  • If this software becomes unstable or unusable once deployed, will it have significant impact on your nonprofit’s ability to operate?

Giving significant attention to these types of major purchases is likely to save your organization time in the long run.

 

Taking Preliminary Measurements

Prior to even looking at available software options, make sure you thoroughly define your needs and what the application you select should be able to do for you. Nonprofits are process-driven. They receive, acknowledge, deposit and track donations; they identify, serve and record transactions with clients; and they recruit, hire and manage employees. Technology facilitates the way your organization manages these processes. A successful software installation will make this work easier, more streamlined and more effective. But a new system that doesn’t take your processes and needs into account will only make running your organization more difficult.

So it’s critical that, before you begin looking for that donor database or client-tracking system, you clearly understand the processes that need to be supported and the software features critical to support that work.

This is an important and complex area that could easily be an article—or a book—in its own right. We could also write numerous articles that delve into project management, getting company buy-in and change management—all critical factors in organizational readiness. However, for the purposes of this article, we’re focusing on the process of evaluating and purchasing software once you’ve already identified your needs and prepped the organization for the project.

Finding the Available Options

Once you know what you need and why you need it, the next step is to identify the pool of applications that might fit. An expert consultant can be a huge help. A consultant who knows the market and is familiar with how the systems are working for other nonprofits can save you research time, and can direct you to systems more likely to meet your true needs. While a consultant can be more expensive than going it alone, money spent up front on the selection and planning phases is almost always recouped through lower costs and greater efficiency down the road.

If a consultant isn’t warranted, take advantage of the resources available to the nonprofit community, such as Idealware, Social Source Commons, Techsoup’s forums or NTEN’s surveys. Ask your peers what they’re using, how they like it and why. Ideally you want to identify no less than three, and probably no more than eight, suitable products to evaluate.

Considering an RFP

With your list of possible software candidates in hand, the next step is to find out more about how those packages meet your needs. This is traditionally done through a Request for Proposal (RFP), a document that describes your environment and asks for the information you need to know about the products you’re evaluating.

Well-written RFPs can be extremely valuable for understanding the objective aspects of large software purchases. For example, if you are looking for a Web site content management system (CMS), questions such as “does the blogging feature support trackbacks?” or “Can the CMS display individualized content based on cookie or user authentication?” are good ones for an RFP.

What you want from the RFP is information you can track with checkboxes. For example, “It can/can’t do this,” “It can/can’t export to these formats: XML, SQL, CSV, PDF,” or “They can program in PHP and Ruby, but not Java or Cold Fusion.” Questions that encourage vendors to answer unambiguously, with answers that can be compared in a simple matrix, will be useful for assessing and documenting the system capabilities.

An RFP can’t address all the concerns you’re likely to have. Subjective questions like “How user-friendly is your system?” or “Please describe your support” are unlikely to be answered meaningfully through an RFP process.

Certainly, you can arrange for demonstrations, and use that opportunity to ask your questions without going through an RFP process. But while the formality of an RFP might seem unnecessary, there are some key reasons for getting your critical questions answered in writing:

  • You can objectively assess the responses and only pursue the applications that aren’t clearly ruled out, saving some time later in the process.
  • A more casual phone or demo approach might result in different questions asked and answered by different vendors. An RFP process puts all of the applications and vendors on a level field for assessing.
  • The RFP responses of the vendor you select are routinely attached to the signed contract. An all-too-common scenario is that the vendor answers all of your questions with “yes, yes, yes,” but the answers change once you start to implement the software. If you don’t have the assurances that the software will do what you require in writing, you won’t have solid legal footing to void a contract.

Structuring Your RFP

RFPs work well as a four section document. Below, we walk through each of those sections.

Introduction

The introduction provides a summary of your organization, mission and the purpose of the RFP

Background

The background section provides context the vendor will need to understand your situation. Consider including a description of your organization—for instance, number of locations, number of staff and organizational structure, the processes the system should support, and such technology infrastructure as network operating system(s) and other core software packages. Include any upcoming projects that might be relevant.

Questionnaire

The questionnaire is the critical piece of the document—you want to be sure you ask all of the questions that you need answered. In preparing these questions, it’s best to envision what the vendor responses might look like. What will have to be in those responses for you to properly assess them? Consider asking about:

  • Functionality. In order to get answers you’ll be able to compare, ask your questions at a granular level. Does a CRM support householding? Does a donor database have a method for storing soft credits? Can multiple users maintain and view records of donor interactions? Can alerts or notifications be programmed in response to particular events? Use the results of your business requirements work to focus in on the functions that are critical to you and your more unusual needs.
  • Technology specifics. Make sure the software will integrate properly with other applications, that the reporting is robust and customizable by end users, and that the platform is well-supported. Ask which formats data can be exported to and imported from, how many tables can be queried simultaneously and what type of support is available—both from the vendor and third parties. Ask for a data dictionary, which a technical staffer or consultant can review, because a poorly designed database will complicate reporting and integration. And ask for a product roadmap. If the next version is going to be a complete rewrite of the application, you might want to rule out the current version for consideration.
  • Company information. Think through what you’ll want to know about the company itself. How big is it? Do they have an office near you? How long have they been in business? Are they public or private? Can they provide some documentation of financial viability? Who are the staff members that would be assigned to your project? References from similar clients with similar-scope projects can also be very useful. For more information on this area, see Idealware’s article Vendors as Allies: How to Evaluate Viability, Service, and Commitment.
  • Pricing and availability. What are their hourly rates, broken down by role, if applicable? What are their payment terms? What is their total estimate for the project as described? How do they handle changes in project scope that might arise during implementation? What are their incidental rates and policies (travel, meals)? Do they discount their services or software costs for 501(c)(3)s? How long do they estimate this project will take? When are they available to start?

 

While it’s important to be thorough, don’t ask a lot of questions you don’t plan to actually use to evaluate the systems. Asking questions “just in case” increases the amount of information you’ll need to sift through later, and increases the possibility that vendors might decide your RFP isn’t worth the time to respond to.

Instructions

Close with a deadline and details about how to submit replies. For a sizeable RFP, allow a minimum of four to six weeks for a response. Remember that this isn’t a confrontational process—a good vendor will appreciate and want to work with a client that has thought things out this well, and the questionnaire is also an opportunity for them to understand the project up front and determine their suitability for it. Respect their schedules and give them ample time to provide a detailed response.

Include an indication as to how additional questions will be handled. In general, if one vendor asks for clarification or details, your answers should be shared with all of the RFP participants. You want to keep things on a level playing field, and not give one vendor an advantage over the rest. You might do this via a group Q&A, with all the vendors invited to participate in a meeting or conference call after the RFP has been sent to them but well before they are due to respond. With all vendors asking their questions in the same room, you keep them all equally informed. Alternatively, you can specify a deadline by which written questions must be submitted. All participants would then receive the questions and answers.

Evaluating the Answers

Once you receive RFP responses, you’ll need to winnow down your list to determine which packages you’d like to demo.

If you asked straightforward, granular questions, you’ll now reap the benefit: you can set up a comparative matrix. Create a table or spreadsheet with columns for each vendor and rows for each question, summarizing the responses as much as possible in order to have a readable chart. You might add columns that weight the responses, both on the suitability of the vendor’s response (e.g. 1, unacceptable; 2, fair; 3, excellent) and/or on the importance of the question (for instance, some features are going to be much more important to you than others).

Going through the features and technology sections, you’ll see the strong and weak points of the applications. In determining which fit your needs, there will likely be some trade-offs—perhaps one application has a stronger model for handling soft credits, but another has more flexible reporting. It’s unlikely that any will jump out as the perfect application, but you’ll be able to determine which are generally suitable, and which aren’t.

For example, if you’re looking for software to manage your e-commerce activities, inventory management might be a critical function for you. If a submitted software package lacks that feature, then you’ll need to eliminate it.  As long as you understand your own critical needs, the RFP responses will identify unsuitable candidates.

You might rule out a vendor or two based on what the RFP response tells you about their availability or company stability. Take care, though, in eliminating vendors based on their RFP pricing information. RFP responses can be very subjective. Before determining that a vendor is too pricy based on their project estimate, dig deeper—other vendors might be underestimating the actual cost. If you feel you have a solid grasp on the project timeline, use the hourly rates as a more significant measurement.

The RFP responses will tell you a lot about the vendors. You’re asking questions that are important to your ability to operate. Their ability to read, comprehend and reasonably reply to those questions will offer a strong indication as to how important your business is to them, and whether they’ll consider your needs as the software is implemented and into the future. If they respond (as many will) to your critical questions with incomplete answers, or with stacks of pre-printed literature—saying, in effect, “the answers are in here”–then they’re telling you they won’t take a lot of time to address your concerns.

Keep in mind, though, that a weak sales representative might not mean a weak vendor, particularly if they’re representing a product that comes recommended or looks particularly suitable on all other fronts. It’s acceptable to reject the response and ask the vendor to resubmit if you really feel they have done you, and themselves, a disservice—but temper this with the knowledge that they blew it the first time.

Trying It All On for Size

At this point the process will hopefully have narrowed the field of potential applications down to three-to-five options. The next step is to schedule software demos. A well-written RFP will offer important, factual and comprehensive details about the application that might otherwise be missed, either by too narrow a demo or by one the vendor orchestrates to highlight product strengths and gloss over weaknesses. But the demos serve many additional purposes:

  • Evaluating look and feel. As good as the specs might look, you’ll know quickly in a demo if an application is really unusable. For instance, an application might technically have that great Zip code lookup feature you asked about in the RFP, but it may be implemented in a way that makes it a pain to use. Prior to the demo, try to present the vendors with a script of the functions you want to see. It can also be useful to provide them with sample data, if they are willing—evaluating a program with data similar to your own data will be less distracting. Be careful not to provide them with actual data that might compromise your—or your constituents’—privacy and security. The goal is to provide a level and familiar experience that unifies the demos and puts you in the driver’s seat, not the vendor.
  • Cross training. The demo is another opportunity for the vendor to educate you regarding the operating assumptions of the software, and for you to provide them with more insight into your needs. A generic donor management system is likely to make very good assumptions about how you track individuals, offer powerful tools for segmentation and include good canned reports, because the donor-courting processes are very similar. But in less standardized areas—or if you have more unusual needs—the model used by the software application can differ dramatically from your internal process, making it difficult for your organization to use. Use the demo to learn how the software will address your own process and less conventional needs.
  • Internal training. Even more valuable is the opportunity to use the demos to show internal staff what they’ll be able to do with the software. Demos are such a good opportunity to get staff thinking about the application of technology that you should pack the room with as many people as you can. Get a good mix of key decision-makers and application end-users—the people who design and perform the business processes the software facilitates. The people who will actually use the software are the ones who can really tell if the package will work for them.

Making the Decision

With luck, your vendor selection process will now be complete, with one package clearly identified as the best option. If key constituents are torn between two options or unimpressed with the lot, senior decision-makers might have to make the call. Be careful, however, not to alienate a group of people whose commitment and enthusiasm for the project might be needed.

If none of the applications you evaluated completely meets your needs, but one comes close, you might consider customizations or software modifications to address the missing areas. Note that any alterations of the basic software package will likely be costly, will not be covered in the packaged documentation and help files, and might break if and when you upgrade the software. Be very sure there isn’t an alternate, built-in way to accomplish your goal. If f the modification is justified, make sure it’s done in such a way that it won’t be too difficult to support as the software is developed.

Before making a final decision, you should always check vendor references, but take them with a healthy grain of salt. An organization’s satisfaction with software depends not only on how well it meets their needs, but how familiar they are with their options—there are a lot of people who are happy using difficult, labor-heavy, limited applications simply because they don’t know there are better alternatives.

If you still have a tie after RFPs, demos and reference checks, the best next step is to conduct on-site visits with an existing customer for each software package. As with demos, bring a representative group of management, technical staff and users. Assuming the reference can afford the time to speak with you, the visit will highlight how the software meets their needs, and will give you a good, real world look at its strengths and weaknesses. You’ll also likely walk away with new ideas as to how you might use it.

Signing on the Dotted Line

You’ve selected an application. Congratulations! You might be tired, but you aren’t finished yet. You still need to work with the vendor to define the scope of the engagement, and an agreement that will cover you in case of problems. A good contract clearly articulates and codifies everything that has been discussed to date into a legally binding agreement. If, down the road, the vendor isn’t living up to their promises, or the software can’t do what you were told it would do, then this is your recourse for getting out of an expensive project.

Contract negotiations can take time. It’s far more dangerous to sign a bad contract in the interest of expediency, though, than it is to delay a project while you ensure that both parties—you and the vendor—completely understand each other’s requirements. Don’t start planning the project until the papers have been signed.

A software contract should include a number of parts, including the actual agreement, the license, the scope of work and the RFP.

The Agreement

This is the legal document itself, with all of the mumbo jumbo about force majeure and indemnity. The key things to look for here are:

  • Equal terms and penalties. Are terms and penalties equally assessed? Vendors will write all sorts of terms into contracts that outline what you will do or pay if you don’t live up to your end of the agreement. But they’ll often leave out any equivalent controls on their behavior. You should find every “if this happens, customer will do this” clause and make sure the conditions are acceptable, and that there are complementary terms specified for the vendor’s actions.
  • Reasonable cancellation penalties. If there are penalties defined for canceling a consulting or integration contract, these should not be exorbitant. It’s reasonable for the vendor to impose a limited penalty to cover expenses incurred in anticipation of scheduled work, such as airfare purchased or materials procured. But unless this is a fixed cost agreement, which is highly unusual, don’t let them impose penalties for work they don’t have to do—for example, for a large percentage of the estimated project cost.
  • Agreement under the laws of a sensible state. If the vendor is in California, and you’re in California, then the agreement should be covered by California laws rather than some random other state. In particular, Virginia’s laws highly favor software companies and vendors. In most cases, you want the jurisdiction to be where you live, or at least where the vendor’s headquarters actually are.

The Software License

The license specifies the allowed uses of the software you’re purchasing. This, too, can contain some unacceptable conditions.

  • Use of your data. A software license should not restrict your rights to access or work with your data in any way you see fit. The license agreement will likely contain conditions under which the software warranty would be voided. It’s perfectly acceptable for a commercial software vendor to bar re-engineering their product, but it’s not acceptable for them to void the warranty if you are only modifying the data contained within the system. So conditions that bar the exporting, importing, archiving or mass updating of data should be challenged. If the system is hosted, the vendor should provide full access to your data, and the license should include language providing that client shall have reasonable access for using, copying and backing up all customer information in the database. There should be no language in the contract implying that the vendor owns your data, or that they can use it for any additional purposes.
  • Responsibility avoidance. Software warranties should not include blanket “software provider is not responsible if nothing works” statements. This shouldn’t need to be said, but, sadly, there are often warranty sections in license agreements that say just that.
  • Back doors. The license should not allow for any post-sale reversals of licensing, such as language stating that the contract will be void if the customer uses the software in perfectly reasonable ways they don’t anticipate. For instance, if you want to use the CRM functions of your donor database to track contacts that aren’t potential donors, you shouldn’t sign a contract limiting use of the software to “fundraising purposes”. Also, there should not be any “back doors” programmed into the application that the vendor can maintain for purposes of disabling the software.

The Scope of Work

The Scope of Work (SOW) describes exactly what the project will consist of. It’s an agreement between the vendor and the customer as to what will happen, when, and how long it will take. Good scopes include estimates of hours and costs by task and/or stage of the project. The scope should be attached as a governing exhibit to the contract. Usually, this is negotiated prior to receiving the actual contract. By having it attached to the contract, the vendor is now legally obligated to, basically, do what they said they would do.

The RFP

Like the Scope of Work, the RFP should also be attached as a governing document that assures that the software does what the vendor claimed it would.

In Conclusion

For big ticket purchases, it’s well worth having an attorney review or assist in negotiations. Keep in mind that the goal is to end up with a contract that equally defends the rights of both parties. True success, of course, is a solid contract that is never revisited after signing. Litigation doesn’t serve anyone’s interest.

Bringing It Home

There’s a lot of talk and plenty of examples of technology jumpstarting an organization’s effectiveness. But if someone were to do the tally, there would probably be more stories of the reverse. All too often, organizations make decisions about their software based on uninformed recommendations or quick evaluations of the prospective solutions. Decisions are often based more on expediency than educated selection.

Rushing a major investment can be a critical error. Learn about the available options, thoroughly assess their suitability to your needs and prepare your staff to make the most of them. Then, sign a contract that protects you if, after all else is done, the application and/or vendor fails to live up to the promises. Finding the right application and setting it up to support, not inhibit, your workflow is a matter of finding something that really fits. You can’t do that with your eyes closed.

 

For More Information

Vendors as Allies: How to Evaluate Viability, Service, and Commitment
An Idealware article on how to think specifically about the less-concrete aspects of software selection.

How To Find Data-Exchange-Friendly Software
An overview of how to ensure you’re going to be able to get data in and out of a software package. (For much more detailed considerations, see our Framework to Evaluate Data Exchange Features.)

 

Peter Campbell is the director of Information Technology at Earthjustice, a nonprofit law firm dedicated to defending the earth, and blogs about NPTech tools and strategies at Techcafeteria.com. Prior to joining Earthjustice, Peter spent seven years serving as IT Director at Goodwill Industries of San Francisco, San Mateo, and Marin Counties, and has been managing technology for non-profits and law firms for over 20 years.

Robert Weiner and Steve Heye also contributed to this article.