Tag Archives: contracts

Highlights Of The 2015 Nonprofit Technology Conference

I’m back and moderately recovered from the 2015 NTC in Austin, Texas, where, along with plenty of good Texas food and beer, I shared some wisdom and learned a lot.  Here’s a summary, with my favorite pics:

#NTCBeer is a proven formula. Take a decent bar, Nonprofit techies, and a room without blaring music, and everyone has a great time, whether they’re NTEN mavens like me, or first time attendees. We estimate that about 275 people came by this year. Here’s a great shot of the room by Jason Shim:

7th annual ntcbeer - room

 

On Wednesday morning I led my session on contract negotiation.  I’d been hoping for an even mix of nonprofit staff and vendors in the room, as these are the types of topics that we don”t spend enough time discussing together, but we were skewed heavily on the customer side.  All the same, it was a good Q&A. I learned some tricks to add to my arsenal, such as, when buying software from small vendors or developers, arranging for rights to the source code should the vendor go under. One vendor somewhat sheepishly asked if I thought that scoping out a fixed bid discovery phase to be completed before submitting a project bid was a bad thing, and I am with him all of the way. We need to stop asking vendors for fixed pricing when there’s no realistic basis for estimating the hours. My slides, below, are a good read for anyone who is responsible for negotiating contracts; and whomever took the collaborative notes just rocked it, capturing fully the wisdom of the crowd.

On Wednesday afternoon I attended Dar Veverka and Andrew Ruginis‘ session on Disaster Recovery and Backup. A solid session that covered every aspect of the topic, with practical advice for nonprofits that might have trouble budgeting time and funds to do this critical work well. Slides are here.

Thursday morning’s choice was Google Analytics session by Yesenia Sotelo. I was looking for a good overview on what Analytics can do and how to do it, and this fully met my needs. Great news: NTEN recorded this one and the video will be available from them by March 12th! Here’s Yesenia’s inspirational presentation style, captured by official NTEN photographer Trav Williams:

16086373604_c92375bab7_z

 

The afternoon session was a panel by four of my favorite people, Robert Weiner, Tracy Kronzak, Dahna Goldstein and Marc Baizman. What To Do When Technology Isn’t Your Problem focused on the user side of systems implementation, pulling heavy on the mantra of “People, Process, Technology”. The slides are here, and the collaborative notes on this one are pretty good. Even more fun: here’s the quiz they gave us that you can take to see how ready your org is to implement systems successfully.

 

Friday started with an ignite plenary that featured a moving presentation by Debra Askanase on how she overcame vision impairment and unsupportive teachers to beat math anxiety and ace Calculus. Then Johan Hammerstrom of CommunityIT and I did a rambling talk on IT security, policies and Bring Your Own Device (BYOD). I was a little worried that we might have leaned too heavily on the talking head side, with the presentation weighing in at close to an hour.  But it was a crowd of our people (IT staff) and the feedback was positive. Slides are here; collaborative notes here; and, keep your eyes open, because I’ll have a URL for a video of the session later this week.

NTEN gave out a lot of awards. It was great to see Modern Courts, a New York org that advocates for adequate numbers of family law judges, win the DoGooder ImpactX video award. It was also great that friends mentioned in this post, Ken and Yesenia, won “NTENNys”, and very moving that they gave one to the late Michael Delong, a colleague with Techsoup who passed away suddenly, and far too young, last year. Lyndal cairns joined the NTEN Award club. And I was moved to tears when my friend David Krumlauf picked up NTEN’s lifetime achievement award. David’s generous, untiring work supporting the capacity of nonprofits has always been an inspiration.

There were also a couple of pleasant surprises: Ken Montenegro, IT Director at the Asian Pacific American Legal Center and a colleague of mine in the Legal Aid community is the newest member of the NTEN Board. And Karen Graham, recently of the sadly shut-down Map Techworks program has got a new gig: Executive Director at Idealware! Congrats all around.

The last session on Friday was a strong one on User Adoption, led by Tucker MacLean, Norman Reiss, Austin Buchan and Kevin Peralta. Pushing more on the people-process-tech theme, this session really engaged the crowd and offered solid advice on how to help users feel involved in technology rollouts. Bonus: their resource section included my post on Building NPTech Culture. Sadly, they have yet to share their slides. Update! They do have slides.

As usual, I had a blast at the conference, meeting new people and catching up with old friends. It was a little difficult to socialize as well as I have in the past, given that we were staying at a variety of hotels and the convention center was massive. With a little less than 2000 attending, I think we might have been better off in a hotel. But I still had a great time at Box.org’s offices Wednesday night (a party co-hosted by Box, Caravan Studios, Twillio and others); a small Access to Justice get-together with Michelle Nicolet, Jimmy Midyette, and the aforementioned Ken Montenegro on Thursday; a great party at Container Bar, hosted by the Chronicle of Philanthropy; the dinner below on Friday, followed up by Michelle Chaplin‘s karaoke party, where I scratched “singing Randy Newman’s Guilty (best known by the Bonnie Raitt cover) in public” off of my bucket list. What’s going to top that next year?

Iron Works BBQ Dinner

Where I’ll Be At 15NTC

15ntc (1)The 2015 Nonprofit Technology Conference starts on March 3rd and marks my tenth year attending (out of the last eleven). Based on my prior experience, I’m looking forward to highly enriching and rewarding social event, hanging out with about 2500 of the nicest people I could ever hope to know, this year at the Austin (Texas) Convention center.

Huh! So we’re Convention Center-sized now. The challenge — which NTEN pulled off with over 2000 attendees last year — is to host that many people and still maintain an atmosphere of community. Last year, during the Ignite plenary, Susan Reed told a story that was breathtakingly personal and inspirational, displaying an impressive level of trust in the community. I wonder what we’ll see this year, just as I wonder if the sheer size of the facility might daunt us. But what I do know is that the NTEN staff set a tone that is remarkably open and welcoming, and they craft the event in ways that make it more difficult to avoiding meeting a ton of new people than it is to make the new friends. I will literally know hundreds of the people attending, but I fully expect to have at least 25 new friends by the time the Geek Games have subsided and we all head home.

So, where will I be?

Tuesday, 3/3, 7:00 pm: #NTCBeer

This seventh annual pre-conference social event that combines great people with good beer (and other beverages) will be held at The Cedar Door.  In addition to a good beer selection, we’ll have a private room with full bar and plenty of options for good food to eat.

We’ll see if we top the approximately 300 people that showed up in DC last year (with more turned away as the bar hit capacity). Note that, while #ntcbeer is a conference event, we don’t turn away friendly nptechies who just happen to be in town.

Thanks to NTEN for finding the location this year! If you plan on attending, please let us know on the #ntcbeer Facebook event page.

Wednesday, 3/4, 10:30 am: Software and Service Contracts – How to Negotiate Reasonable Terms in the Cloud Era

campbellpeter.img1_Rounding out my wonky trio of tech management topics (Project Management at 13NTC; Requests for Proposals at 14NTC), we’ll talk about the key things to challenge vendors on and the best tone to set in negotiations, with some new thinking on what needs to be addressed for hosted (cloud) systems. I blogged on the NTEN Blog about this session in greater detail, and you can register for it on the Sched page, assuming that you’ve signed up for MyNTC.

Thursday, 3/5, 6:00 pm: Access To Justice Get-together

gavel-145568_640Do you work in legal aid? Join us at an informal drinks and, possibly, dinner meetup at Banger’s Sausage House and Beer Garden. You can RSVP on NTEN’s social events calendar (Thursday tab, row 8)

 

Friday, 3/6, 10:30 AM: Crafting IT Policy to Improve Security and Manage BYOD

 invisible-man-154567_1280I’ll be joining Johan Hammerstrom, CEO of Community IT Innovators, in a session that discusses the latest security threats and offers tools and a framework for defending our orgs from them. We’ll start with a talk about securing information when it no longer lives behind a firewall, then move to new ideas about dealing with security breaches, then on to standard IT policies, including Bring Your Own Device (BYOD), assuming that’s still a topic of great interest. You can register for this session here.

 

Other than that, I’ll be all over the place and on Twitter. If you want to meet up, ping me there!

Inking The Deal: What We’ll Discuss at the #15NTC Contract Negotiation Session

This post originally appeared on the NTEN Blog on January 20th, 2015.

For this month’s Connect theme, a number of speakers are previewing the great breakout sessions they are preparing for the 2015 Nonprofit Technology Conference in Austin, TX March 4-6. Following is a preview of one of over 100 breakout sessions.

The 15NTC session, “Software and Service Contracts: How To Negotiate Reasonable Terms in the Cloud Era” is the third in my series of, “How wonky can we get?” information exchanges. At the 2013 Nonprofit Technology Conference in Minneapolis, I spoke on Project Management; and last year, in DC, on Requests for Proposals. While these topics aren’t quite as trendy as data visualization and the mobile web, they are focused on the job skills that allow us to do all of the cool stuff. As a nonprofit technology executive, I’ve bought and deployed a lot of systems. Sharing what I’ve learned along the way is the least I can give back to a great Community like NTEN. What are the things that have to be in place in order to successfully roll out software and systems?

  1. Good project management: in particular, the right methodology for the job
  2. A thorough selection process, one that doesn’t let the desire for a low-fixed bid trump the priority of selecting the right system or partner
  3. A contract with that vendor that fairly establishes the remedies should things with the vendor go wrong

I try and bring a few things to these sessions to make them memorable. In this case, the move from server rooms to cloud-based server farms has changed the dynamic of our customer/vendor relationships. Software contracts need to reflect that. In the cloud, we have new issues to negotiate, such as:

  1. What happens to customer data when a vendor goes out of business?
  2. Do our negotiated terms apply to subcontractors, when, say, the vendor’s service uses Amazon as a storage platform?
  3. Who is responsible when something breaks?

Mostly, I want to impress upon everyone that terms can be negotiated. In these days of shrink wrap software licenses, many nonprofits forget that we can protect ourselves from nasty terms. Here are some quick thoughts:

  1. Vendors should tie termination fees to strong service level agreements, or waive them altogether in cloud contracts, where they should merit your monthly payments by providing a  solid service
  2. Who benefits from automatic renewals? Should you sign a contract that renews automatically at the original term if the original term is three years or more?
  3. The jurisdiction that governs the remedies should be your home state or, at worst, theirs.  Beware: some vendors are fine about choosing obscure courts that they know will protect their interests

And, finally, I’ll offer a few tips on the negotiating process. Some co-workers of mine have expressed concerns that bickering over contract details can hurt the vendor relationship. Done right, the contract negotiation establishes a tone in the relationship that will last throughout the engagement, and it’s one of mutual respect and a commitment to confront key issues, rather than to avoid them.

So don’t be afraid to get wonky! Join me at the 15NTC for a session that might not be the sexiest you attend, but will provide you with the tools you need to protect your technology investments.

About the author:

By day, Peter Campbell is the CIO at Legal Services Corporation, America’s Partner for Equal Justice. At other times, he can be found blogging and talking about all things nptech at Techcafeteria or on Twitter.

Image credit: “The Land of Contracts” by David Anthony Colarusso

Microsoft’s Secret Giveaway

This post was originally published on the Idealware Blog in November of 2009.

Sometimes it feels like the bane of my existence is my office phone. It’s so bad that I rarely answer it, preferring to forward it to Google Voice where I can peruse the barely readable transcripts just well enough to filter out the 90% cold sales calls I receive. So what a pleasure it was to answer my desk phone on Thursday and have an illuminating conversation with my Microsoft Licensing representative. He called to tell me that I own some awesome benefits that come with my Software Assurance program. I’m betting that I’m not the only one who was clueless about these benefits.

Microsoft Licensing, as you know, is the little-known tenth circle of hell. It’s a conceptual labyrinth of terms and conditions that was likely conceived by a team of the writers of the original “Prisoner” series with the advice of contract attorneys that graduated from law school 30 years ago and have never since seen the light of day.

Software Assurance is the tax we pay on our MicroSoft purchases that allows us to upgrade to the newest versions without paying upgrade fees (as long as we’ve paid our software assurance fees, of course). I assume that this is of interest to Idealware readers because most of us pick up a lot of our MS software from Techsoup Stock, and the Techsoup Stock donations come with Software Assurance, not without.

But Microsoft isn’t evil; they’re just bureaucratic, and every now and then a few smart people step up out of the morass and do things that I appreciate. These Software Assurance benefits include:

The Microsoft Home Use Program provides staff with ridiculously steep discounts on MS Office. Register this benefit, and the allowed number of users (which I’m unclear as to how they calculate) at your company can purchase MS Office 2007 Ultimate Edition (or Office 2008 for Mac) for $9.95. That’s not a trial edition, and it’s the opposite of crippled — Ultimate is the “everything but the kitchen sink” edition and it comes with a license key.Microsoft ELearning is a series of online classes in standard MS products like Word and Excel, and Server products like MS SQL Server or Windows 2003. I did note that the list of available classes that my rep sent me looked a little behind the times; no 2008 or 2010 products covered, but many of us aren’t on the bleeding edge anyway.

Microsoft Technet gives you access to forums and experts, as well as evaluation copies of new technologies. For example, as I write this, I just learned that I can pick up Office 2010 and Sharepoint 2010 betas via my MSDN or Technet subscriptions to try.

And the Office Multi-Language Packs let you deploy office in additional languages.

This isn’t fluff. We’ve been paying full price for Office at home (more than we do at work) and I’ve purchased E-Training on MS products and an MSDN subscription (fairly equivalent to Technet) because I had no idea that I already owned them. It makes me feel much better about what seemed like a pre-emptive insurance program that makes me commit to the next version of MS products before I’m ready to make that commitment, at times.

Of course, this is smart business for Microsoft. With Google announcing that their Google Apps offering will be on a feature par with Office within a year, and OpenOffice under active development as a pretty comparable alternative, you don’t want your business customers to get too comfortable with those free alternatives at home. It’s just surprising to me that, for years, this was buried in the small print section of eOpen, and not broadcast widely. So I’m doing MS a favor and blowing the horn on this one.

To access these benefits, log onto eOpen (which I hope you’re using to manage MS licenses!) and once you’ve signed in and clicked “unhide licenses”, find your last Techsoup order (or a similar large purchase) and open it up. The very first link in the license detail should be “Start and Manage your Software Assurance Benefits”. Clicking on that will pop you to a paragraph that includes a link to the “Software Assurance Benefits Management Tool”. Click on that to get the benefits. The more MS software you’ve bought, the more tedious this will be: there are benefits associated with each Software Assurance purchase, so you’ll need to register this way for every relevant order. But it sure beats paying for these things at Best Buy!

Both Sides Now

This article first appeared on the Idealware Blog in February of 2009.

Say you sign up for some great Web 2.0 service that allows you to bookmark web sites, annotate them, categorize them and share them. And, over a period of two or three years, you amass about 1500 links on the site with great details, cross-referencing — about a thesis paper’s worth of work. Then, one day, you log on to find the web site unavailable. News trickles out that they had a server crash. Finally, a painfully honest blog post by the site’s founder makes clear that the server crashed, the data was lost, and there were no backups. So much for your thesis, huh? Is the lesson, then, that the cloud is no place to store your work?

Well, consider this. Say you start up a Web 2.0 business that allows people to bookmark, share, categorize and annotate links on your site. And, over the years, you amass thousands of users, some solid funding, advertising revenue — things are great. Then, one day, the server crashes. You’re a talented programmer and designer, but system administration just wasn’t your strong suit. So you write a painful blog entry, letting your users know the extent of the disaster, and that the lesson you’ve learned is that you should have put your servers in the cloud.

My recent posts have advocated cloud computing, be it using web-based services like Gmail, or looking for infrastructure outsourcers who will provide you with virtualized desktops. And I’ve gotten some healthily skeptical comments, as cloud computing is new, and not without it’s risks, as made plain by the true story of the Magnolia bookmarking application, which recently went down in the flames as described above. The lessons that I walk away with from Magnolia’s experience are:

  • You can run your own servers or outsource them, but you need assurances that they are properly maintained, backed up and supported. Cloud computing can be far more secure and affordable than local servers. But “the cloud”, in this case, should be a company with established technical resources, not some three person operation in a small office. Don’t be shy about requesting staffing information, resumes, and details about any potential off-site vendor’s infrastructure.
  • You need local backups, no matter where your actual infrastructure lives. If you use Salesforce or Google, export your data nightly to a local data store in a usable format. Salesforce lets you export to Excel; Google supports numerous formats. Gmail now supports an Offline mode that stores your mail on the computer you access it from. If you go with a vendor who provides virtual desktop access (as I recommend here), get regular snapshots of the virtual machines. If this isn’t an over the air transfer, make sure that your vendors will provide DVDs of your data or other suitable medium.
  • Don’t sign any contract that doesn’t give you full control over how you can access and manipulate your data, again, regardless of where that data resides. A lot of vendors try and protect themselves by adding contract language prohibiting mass updates and user access, even on locally-installed applications. But their need to simplify support should not be at the expense of you not having complete control over how you use your information.
  • Focus on the data. Don’t bend on these requirements: Your data is fully accessible; It’s robustly backed up; and, in the case of any disaster, it’s recoverable.

Technology is a set of tools used to manage your critical information. Where that technology is housed is more of a feature set and financial choice than anything else. The most convenient and affordable place for your data to reside might well be in the cloud, but make sure that it’s the type of cloud that your data won’t fall through.

Media and Mediums

 

This post was originally published on the Idealware Blog in February of 2009.

Those of us who actively create internet content — which includes many nonprofits, at this point – were fairly blindsided by a small, subsequently revoked change in Facebook’s terms of service this month. The earlier terms allowed Facebook to use any content that a user publishes to the site in a variety of ways, as long as the user kept the content on the site. The change extended Facebook’s rights to use beyond it’s time on their system. They could keep using it after the user removed it, and they could even keep using it after the user cancelled their account. Facebook’s defense of this action, in a blog post by Mark Zuckerberg, the CEO, was that the intention was to insure that people whom you shared information with, such as emails, links or notes, didn’t lose access to that information if/when you removed it. But, since the policy didn’t isolate that use example from the broader uses, such as Facebook advertising their services with your content, or providing it to third parties, the reassurance left a lot of us cold. A use policy on a social networking site should establish, clearly, what will and won’t happen with the content that you post to it, not leave it open ended to this extreme.

This incident prompted a fascinating post by Dr. Amanda French, comparing the license agreements of a variety of popular social networks. This is an important read, but the upshot is: Google services and MySpace have pretty clear terms; Facebook and LinkedIn claim a broad range of rights to content that we publish on their systems.

To me this is a bit like the separation of church and state. I expect that a social networking site, like an ISP, is a medium that I can use to communicate and share things, including things that i create and hold copyright to; not a magazine that licenses and retains ownership of works that I submit. If that’s not the case, then I want to know that and be very careful about what I’m putting up there. In my case, I’m trying to protect my works and personal reputation; a nonprofit should be just as concerned about how a business like Facebook might portray them as they repurpose their content.

There is media — content, that we create — and there are mediums, and in the print world the issues of content ownership are very clearly outlined in contracts. Facebook and their ilk should be applying the same standards, maybe even more so, since they are publishers on a much more massive scale than, say Ms. Magazine or Popular Mechanics.

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.

 

How To Find Data-Exchange-Friendly Software

This article was co-written by Laura Quinn of Idealware and first published on the NTEN Blog in October of 2007.

 Peter Campbell, Techcafeteria, and Laura Quinn, Idealware

This is an excerpt adapted from Idealware’s article, “XML, API, CSV, SOAP! Understanding the Alphabet Soup of Data Exchange“.

Repeat this mantra: I will not pay a vendor to lock me out of my own data. Sadly, this is what a lot of data management systems do, either by maintaining poor reporting and exporting interfaces or by including license clauses that void the contract if you interact with your data in unapproved ways.

The software you choose has an enormous impact on whether you can effectively get data in or pull it out to integrate with other packages. If you only look at the front end features, you’re only conducting half an evaluation. It’s also critical to determine how you can — or if you can — access the data.

To avoid lock-in and ensure the greatest amount of flexibility when looking to buy any new application — particularly the ones that store your data off-site and give you web-based access to it — ask the following questions:

  1. Can I do mass imports and updates on my data? If the vendor doesn’t allow you to add or update the system in bulk with data from other systems, or their warrantee prohibits mass updates, then you will have difficulty smoothly integrating data into this system.
  2. Can I take a report or export file; make a simple change to it, and save my changes? The majority of customized formats are small variations on the standard formats that come with a system. But it’s shocking how many web-based platforms don’t allow you to save your modifications.
  3. Can I create the complex data views that are useful to me? Most modern donor, client/case management and other databases are relational. They store data in separate tables. That’s good – it allows these systems to be powerful and dynamic. But it complicates the process of extracting data and creating customized reports. A donor’s name, address, and amount that they have donated might be stored in three different, but related tables. If that’s the case, and your reporting or export interface doesn’t allow you to report on multiple tables in one report, then you won’t be able to do a report that extracts names and addresses of all donors who contributed a certain amount or more. You don’t want to come up with a need for information and find that, although you’ve input all the data, you can’t get it out of the system in a useful fashion.
  4. Does the vendor provide a data dictionary? A data dictionary is a chart identifying exactly how the database is laid out. If you don’t have this, and you don’t have ways of mapping the database, you will again be very limited in reporting on and extracting data from the application.
  5. What data formats can I export data to? As discussed, there are a number of formats that data can be stored in, such as CSV (Comma Separated Values – a great format for manual imports and exports) and XML (eXtensible Markup Language – better for automatic integration). You want a variety of options for industry standard formats.
  6. Can I connect to the database itself? Particularly if the application is installed on your own local network, you might be access the database directly. The ability to establish an ODBC connection to the data, for instance, can provide a comparatively easy way to extract or update data. Consider, however, what will happen to your interface if the vendor upgrades the database structure.
  7. Can I initiate data exports without human intervention? Check to see if there are ways to schedule exports, using built-in scheduling features or by saving queries that can be run by the Windows Scheduler (or something similar). Don’t allow a vendor to lock you out of the database administrator functions for a system installed on your own network. If you want to integrate data in real time, determine what user actions can kick off a process (for instance, clicking Submit on a web form).
  8. Is there an API? APIs can provide a very useful set of functions for importing, exporting, and moving data programmatically. For some systems, an API may be the only way to get data in or out without human intervention. Don’t assume any API is a good API, however – make sure it has the functions that will be useful to you.
  9. Is there a data exchange ecosystem? Are there consultants who have experience working with the software? Does the software support third party packages that specialize in extracting data from one system, transforming it, and loading it into another? Is there an active community developing add-ons and extensions to the application that might serve some of your needs?

Evaluating software packages for data exchange capabilities can’t be an afterthought. It’s too important. Buying into systems that over-complicate or restrict your access to data will limit your ability to manage your business, both today and as long as you own the package.