Tag Archives: CRM

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?”

13 Lessons On Building Your Nonprofit Technology Culture

This article originally appeared on the Exponent Partners blog on December 19th, 2014. It was written by Kerry Vineburg, based on a phone interview with me.

EXPONENT PARTNERS SERIES: SMART PRACTICES

Is your nonprofit thinking about implementing a large database project like Salesforce? Nonprofit and technology veteran Peter Campbell, CIO at Legal Services Corporation, recently shared his valuable insights on how to prepare your team and culture for long-term success. His organization, the top funder of civil legal aid for low-income Americans in the country, is developing Salesforce as a data warehouse for their grantee information and document management. 

We asked Peter to tell us more about what practices he uses to help ensure a successful technology implementation. As you’ll see, it’s just as much about working with people! 

Embarking On Your Project

1. When beginning a technology project, agree on the problem you’re solving, that all staff can relate to. Organizational readiness is critical. I’ve worked at organizations that didn’t recognize that their casual approach to data management was a problem, and they weren’t looking for a solution. If your staff don’t understand why they need an application, then you’re in danger of installing something that won’t be utilized. When starting a new organizational project, I identify 2-3 core bullet points that will explain the goals of the project, and repeat them often. For example: “The new system will provide one-step access to all information and documents related to a grantee.” That’s the high-level goal. It should be something where the product users all agree, “Yes, I need that!”
2. When planning technology upgrades and projects, schedule the changes. Plan for gradual change. Early in my career, I had to deal with the Y2K bug and replace every system at a mid-sized law firm in a short period. It led me to this philosophy: replace only one major system each year. It’s a myth that people hate change — people hate disruption. Change is good, but needs to be managed at steady level. If you’re doing regular implementations every year, people can get used to that pace. If you do nothing for 3 years, then switch out everything: 1) you’re putting too much of a burden on your implementers to achieve everything at once and 2) you’re making too big of an imposition on staff. Suddenly, everything they know is gone and replaced.

Getting Buy-In

3. Gain full executive sponsorship. There’s a common misconception that a new system will just work for you once it’s installed. To fully realize the benefits of a CRM requires cultural change. Every level of the organization needs to buy into the project. You’ll need to harness a lot of attention and energy from your team to develop requirements, manage the project, learn the new system and adapt processes. Otherwise, you’ll invest in a big database implementation and only one or two people will use it.
The importance of a major system upgrade should be set by the executive director and/or board. Everyone should know that the system is a priority. At nonprofits, our executive directors are often better at fundraising than managing a business, and many are somewhat technophobic. They don’t need to be technology gurus, but they do need to understand what the technology should be doing for them, and to take ownership of those goals. The last thing that I want to hear from my boss is, “Here’s a budget — go do what you think is best.” Without their interest in my projects, I’m bound to fail.
4. If one buy-in approach needs help, try a combo. If you can’t convince your executive director or other leadership to be regular active participants, power users can sometimes help convince your team. I’m not recommending an either/or approach, there should be some of both, but power users can engage staff in cases where management isn’t setting clear expectations. For any project that impacts staff, I will invite key users to be on our evaluation team, help with product selection, and potentially be on our advisory committee during the project. For example, we have a grants department liaison, who is charged with getting the right people in the room when we need input from the staff that know much better than we do what the system should ultimately do for them.
5. Incorporate perspectives from around the table. In addition to power users, I also want feedback from “standard” users. Maybe they don’t love technology so much, and maybe they wouldn’t volunteer for this. But they have an important perspective: you need to understand their reactions and what they’re going to find difficult. As the IT director and CIO, I know important things about managing a project. The users know important things that I don’t. If we don’t have views from multiple sides of the table, the project will fail.

Working With Good People

6. Look for partners (vendors and consultants) who understand your mission, not just the technology. In the ideal situation, you want people who not only get database and programming work, but also really understand your mission and business priorities. I’m blessed to have developers on my team who not only understand grants management but are also sympathetic to what the people coming to them are trying to accomplish. When they get a request, they can prioritize with a good understanding of our organization’s requirements. They’re able to answer, “How can I make the most out of what this person needs with my available time?” while being skilled enough to capably choose between the technical options. Getting people that have a broader mindset than just technology is really important.
7. Vary your team and role strategy with your size. At nonprofits, we don’t usually have big internal teams. Someone becomes our accidental techie/database guru. Even large nonprofits are hurting for staff. It’s always been less “here’s the best practice and ideal way to staff this,” and more “let’s see what budget and people I have, and make it work as well as I can.” Not many nonprofits have developers on staff. Hiring can be challenging. It’s a popular skillset, and won’t be cheap. If you’re tiny, you probably won’t hire full-time, you’ll outsource to consultants. But if you have 30 people or more using the CRM, you might benefit from in-house expertise, even if it’s a half-time role.
If you already have developers on staff, that’s great. If they don’t have experience with, say, Salesforce, but they do know database design and a programming language or two, it’s not hard to pick up the concepts. You’re modeling a database, designing it, and then scripting on top of it in a similar language. They can probably adapt.
8. Practice good compensation and retention strategies for your technically savvy (and/or newly trained) staff. I’ve seen a trend over the past 10 years. A nonprofit decides to use a solution like Salesforce and they charge their accidental techie with the task of implementing. The accidental techie gets the implementation done, becomes a guru on it, trains all the users, and then because the organization is paying them an entry-level salary, they leave and go get a much higher paying job as a consultant! It’s a valuable skillset, so don’t be short-sighted about compensating them for what they do for you. You need to be careful and invest properly. Give them raises along with the skillset, to make sure they are fully motivated to stick with you.

Project Management

9. Avoid surprises with good communication. My rule of IT management now is: “No one should ever be surprised by anything I do.” From experience with good mentors, I learned important lessons about communication: if you’re going to make a change, communication is critical. Say it 3 times in 3 different mediums (in email, on the internet, on flyers on the wall on every floor!). Be sure staff know how the technology contributes to the well-being of the organization, rather than being a time-waster, so they are motivated to keep working with it. Communicate well.
10. If possible, hold out for the right team. I put off projects to have the right people in place, rather than hold tight to a project deadline with the wrong people in place. See above for how to find and keep the right people.

Training and Baking The Technology Into Your Culture

11. Don’t reinvent the wheel; take advantage of the ecosystem. It can be really common for staff not to reach out for help. They may feel like their job is to learn the technology on their own. They should know there are many resources available to them! For example, with Salesforce, I recommend making use of peer support in the community, the Power of Us Hub, and local user groups. When they do seasonal updates, they do a lot of webinars and are good about providing information about how the app is growing. Salesforce also offers training (the Salesforce Foundation discounts by half) and every consultant I’ve spoken with is capable of doing some customized training. I know that other technologies offer resources like this also. It also behooves anybody on staff to know the specific implementation that you’ve done.
12. Allocate a training budget. I always push to have a staff training budget. For my organization, we even hired for a role of training and implementation specialist. We wanted to have a person on staff whose full-time job was training and strategizing how users use software and how to involve them in the implementation process. This should be part of your budget. I can’t emphasize enough how important it is to have people in your organization who know how to train on your applications.
13. Engage staff and help them understand the big picture of the technology. It’s good to get your team working with the database early on in the process, learning what it’s capable of and what it looks like. Engage your users: get people involved in every step of the process, from selecting products to implementation to training and rollout. Make the product demos big group activities, so that everyone can envision how similar systems work and what they might do with the product beyond what they’re doing today. Beta-test your implementations, giving staff lots of opportunities to provide input. Take an Agile approach of regularly showing what you’re developing to the people who will be using it, and adjusting your development per their feedback.
With a committed team that understands your mission, great communication, well-allocated resources, and gradual change, your organization can lay the foundations for a successful solution that will actually be adopted!
Thanks to Peter Campbell for these great insights. Peter also blogs at techcafeteria.com
For even more strategies on ensuring that your culture is ready for your system, check out our free report Nonprofit Technology Adoption: Why It Matters and How to Be Successful.

– See more at: http://www.exponentpartners.com/building-your-nonprofit-technology-culture#sthash.QPFll78h.dpuf

Architecting Healthy Data Management Systems

This article was originally published in the NTEN eBook “Collected Voices: Data-Informed Nonprofits” in January of 2014.

tape-403593_640Introduction

The reasons why we want to make data-driven decisions are clear.  The challenge, in our cash-strapped, resource-shy environments is to install, configure and manage the systems that will allow us to easily and efficiently analyze, report on and visualize the data.  This article will offer some insight into how that can be done, while being ever mindful that the money and time to invest is hard to come by.  But we’ll also point out where those investments can pay off in more ways than just the critical one: the ability to justify our mission-effectiveness.

Right off the bat, acknowledge that it might be a long-term project to get there.  But, acknowledge as well, that you are already collecting all sorts of data, and there is a lot more data available that can put your work in context.  The challenge is to implement new systems without wasting earlier investments, and to funnel data to a central repository for reporting, as opposed to re-entering it all into a redundant system.  Done correctly, this project should result in greater efficiency once it’s completed.

Consider these goals:

  • An integrated data management and reporting system that can easily output metrics in the formats that constituents and funders desire;
  • A streamlined process for managing data that increases the validity of the data entered while reducing the amount of data entry; and
  • A broader, shared understanding of the effectiveness of our strategic plans.

Here are the steps you can take to accomplish these goals.

Taking Inventory

The first step in building the system involves ferreting out all of the systems that you store data in today.  These will likely be applications, like case or client management systems, finance databases, human resources systems and constituent relationship management (CRM) systems.  It will also include Access databases, Excel spreadsheets, Word documents, email, and, of course, paper.  In most organizations (and this isn’t limited to nonprofits), data isn’t centrally managed.  It’s stored by application and/or department, and by individuals.

The challenge is to identify the data that you need to report on, wherever it might be hidden, and catalogue it. Write down what it is, where it is, what format it is in, and who maintains it.  Catalogue your information security: what content is subject to limited availability within the company (e.g., HR data and HIPAA-related information)? What can be seen organization-wide? What can be seen by the public?

Traditionally, companies have defaulted to securing data by department. While this offers a high-level of security, it can stifle collaboration and result in data sprawl, as copies of secured documents are printed and emailed to those who need to see the information, but don’t have access. Consider a data strategy that keeps most things public (within the organization), and only secures documents when there is clear reason to do so.

You’ll likely find a fair amount of redundant data.  This, in particular, should be catalogued.  For example, say that you work at a social services organization.  When a new client comes on, they’re entered into the case management system, the CRM, a learning management system, and a security system database, because you’ve given them some kind of access card. Key to our data management strategy is to identify redundant data entry and remove it.  We should be able to enter this client information once and have it automatically replicated in the other systems.

Systems Integration

Chances are, of course, that all of your data is not in one system, and the systems that you do have (finance, CRM, etc.) don’t easily integrate with each other.  The first question to ask is, how are we going to get all of our systems to share with each other? One approach, of course, is to replace all of your separate databases with one database.  Fortune 500 companies use products from Oracle and SAP to do this, systems that incorporate finance, HR, CRM and inventory management.  Chances are that these will not work at your nonprofit; the software is expensive and the developers that know how to customize it are, as well.  More affordable options exist from companies like MicroSoft, Salesforce, NetSuite and IBM, at special pricing for 501(c)(3)’s.

Data Platforms

A data platform is one of these systems that stores your data in a single database, but offers multiple ways of working with the data.  Accordingly, a NetSuite platform can handle your finance, HR, CRM/Donor Management and e-commerce without maintaining separate data stores, allowing you to report on combined metrics on things like fundraiser effectiveness (Donor Management and HR) and mail vs online donations (E-commerce and Donor Management).  Microsoft’s solution will incorporate separate products, such as Sharepoint, Dynamics CRM, and the Dynamics ERP applications (HR, Finance).  Solutions like Salesforce and NetSuite are cloud only, whereas Microsoft  and IBM can be installed locally or run from the cloud.

Getting from here to there

Of course, replacing all of your key systems overnight is neither a likely option nor an advisable one.  Change like this has to be implemented over a period of time, possibly spanning years (for larger organizations where the system changes will be costly and complex). As part of the earlier system evaluation, you’ll want to factor in the state of each system.  Are some approaching obsoletion?  Are some not meeting your needs? Prioritize based on the natural life of the existing systems and the particular business requirements. Replacing major data systems can be difficult and complex — the point isn’t to gloss over this.  You need to have a strong plan that factors in budget, resources, and change management.  Replacing too many systems too quickly can overwhelm both the staff implementing the change and the users of the systems being changed.  If you don’t have executive level IT Staff on board, working with consultants to accomplish this is highly recommended.

Business Process Mapping

BPM_Example

The success of the conversion is less dependent on the platform you choose than it is on the way you configure it.  Systems optimize and streamline data management; they don’t manage the data for you.  In order to insure that this investment is realized, a prerequisite investment is one in understanding how you currently work with data and optimizing those processes for the new platform.

To do this, take a look at the key reports and types of information in the list that you compiled and draw the process that produces each piece, whether it’s a report, a chart, a list of addresses or a board report.  Drawing processes, aka business process mapping, is best done with a flowcharting tool, such as Microsoft Visio.  A simple process map will look like this:

In particular, look at the processes that are being done on paper, in Word, or in Excel that would benefit from being in a database.  Aggregating information from individual documents is laborious; the goal is to store data in the data platform and make it available for combined reporting.  If today’s process involves cataloguing data in an word processing table or a spreadsheet, then you will want to identify a data platform table that will store that information in the future.

Design Considerations

Once you have catalogued your data stores and the processes in place to interact with the data, and you’ve identified the key relationships between sets of data and improved processes that reduce redundancy, improve data integrity and automate repetitive tasks, you can begin designing the data platform.  This is likely best done with consulting help from vendors who have both expertise in the platform and knowledge of your business objectives and practices.

As much as possible, try and use the built-in functionality of the platform, as opposed to custom programming.  A solid CRM like Salesforce or MS CRM will let you create custom objects that map to your data and then allow you to input, manage, and report on the data that is stored in them without resorting to actual programming in Java or .NET languages.  Once you start developing new interfaces and adding functionality that isn’t native to the platform, things become more difficult to support.  Custom training is required; developers have to be able to fully document what they’ve done, or swear that they’ll never quit, be laid off, or get hit by a bus. And you have to be sure that the data platform vendor won’t release updates that break the home-grown components.

Conclusion

The end game is to have one place where all staff working with your information can sign on and work with the data, without worrying about which version is current or where everything might have been stored.  Ideally, it will be a cloud platform that allows secure access from any internet-accessible location, with mobile apps as well as browser-based.  Further considerations might include restricted access for key constituents and integration with document management systems and business intelligence tools. But key to the effort is a systematic approach that includes a deep investment in taking stock of your needs and understanding what the system will do for you before the first keypress or mouse click occurs, and patience, so that you get it all and get it right.  It’s not an impossible dream.

 

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.

Talking Databases For A Change

NTEN‘s new issue of Change is out and I got a chance to sound off to Idealware‘s Chris Bernard about the dream of “one database to rule them all” — doing all of your organization’s Constituent Relationship Management (CRM) in a single system. My interview is on page 22, but the whole issue is a dream for NPO’s struggling with wrangling information.

Suggestion: use a big monitor to view this. Change is a great magazine, but the Bluetoad viewer is somewhat tough to use on small screens.

NTEN Change, Issue 4

NTEN CRM Best Practices Webinar on Tuesday

If you missed the announcement, I’m giving a webinar titled “Preparing for Your New Database: Making the Transition as Painless as Possible” on Tuesday at 11:00 am Pacific time. Registration details are at http://nten.org/webinars (It’s not free). If you saw the announcement, note that Holly or someone at NTEN wrote all of that copy – shame on me for not getting them a description on time! But it’s pretty close. What it lacks is the specification that we are talking about Constituent Relationship Management (CRM) databases, not just any database.

I’ve managed CRM rollouts at two large companies: most recently, Salesforce at SF Goodwill; years earlier, an obscure but awesome CRM called Interaction at Lillick & Charles, a San Francisco law firm. My take on it is that CRM can be business-model altering software. Mind you, it doesn’t have to be — it can be a simple contact and/or donor management system — but maybe it should be. Because properly deployed CRM gives your organization the ability to operate in a relationship-centric fashion. Instead of having isolated departments and functions that, of course, are heavily involved in relationships with other people and organizations, CRM centralizes all of the information and history of your organizational contacts and allows you to far better understand and manage those relationships. Vendors can be donors. Donors can be volunteers. If you have that overlap occurring today, you might not even be aware of it.

Zooming down to earth, my experience is also very hands on when it comes to the actual technical work involved in moving to a centralized CRM platform. I can share a lot about the tools and methods available for integrating and migrating data from other systems.

The webinar will focus mostly on best practices for implementing CRM. But we’ll start with some of the high-level, what this means for your org; spend the bulk on the project planning and implementation practices; and, if there’s time and interest, dive into some of the techie stuff. My approach to these things is to have half the session prepared and half of it open to the group interests, and I think I’ll make it worth the $50 ($25 for NTEN members) if moving to new donor databases and CRM platforms is something you’re likely to be involved in.

Salesforce Show and Tell

Day 2 of the Salesforce Non-Profit Roadmap session was focused on refining plans and sharing information. We had sessions and reports from Salesforce Product managers and developers, and we discussed and demoed some of the creative things that our community has developed. The Salesforce guests showed off Apex, the new scripting language that will be available for live use sometime next year; and we had a fascinating (but non-discloseable!) peek at where the reporting is going.

A lot of the talk focused on ways that we can — or will be able — to get around Salesforce’s core assumption that we deal with companies and contacts when, in fact, donation management is about individuals and households. And a big topic was integration, with a lot of questions centered on what can or should be done in Salesforce and what should be programmed on top of it. Two technologies that popped up a lot were Facebook and Ruby on Rails. I learned about (and immediately grabbed) a Salesforce library that has been developed for rails, and Alan Benamer sang the praises of Facebook both as a compelling social network and a fundraising tool, via their new “Causes” feature. Facebook has been in the news for opening up a powerful API, which makes them pretty much the “Salesforce of Social Networks”.

In the afternoon, we got to th fun stuff – showing off what we’ve done. Six of the participant’s showed off projects big and small.

Ben Munat showed us ChipIn, a fundraising widget that currently is available as a wep page plug in, but will soon be integrated with Salesforce, Facebook, and other application platforms.

  • Sonny Cloward showed us a very clean and elegant Salesforce template for fund development created using Salesforce’s Person object. The Person object, which can be used in lieu of Accounts and Contacts, was introduced late last year to a somewhat underwhelming response, the problem being that it’s an either/or choice. If you use Person objects, you can’t use Accounts and Contacts, and, in most cases, you have both companies and individuals among your constituents. All the same, Sonny’s template transformed Salesforce into a clean and simple CRM that would be far easier to teach and support, and maybe quite suitable for small organizations.
  • Rem Hoffman demoed the very sophisticated case management system that his company, Exponent Partners, has put together. This was a real ooh and aaher, as he demoed how a Mental Health agency, swamped in paper, could use it to track cases and print all of the paperwork with about a quarter of the effort that had been required. I’m very intrigued by Rem’s work, as I believe that case management options in the workforce development industry are all pretty painful. As far as I know, Social Solutions is the only company talking about opening up their application; most are the worst examples of grabbing a company’s data and locking them out of it.
  • Ryan Ozimak of PicNet demoed his Joomla/Salesforce integration, which is also very cool and clean, and promising. At present is is likely the fastest and easiest way to develop a web site with Salesforce Contact integration, and the next steps will open up other objects for clean integration. Ryan (who is sitting next to me as I type) has just let me know that this is around the corner.
  • As usual, Steve Anderson of One/Northwest had an amazing demo, showing how he has developed Apex code that completely masks the Account/Contact model so that a user can easily add and remove individuals from households. This was very slick, as his automation made tasks that take multiple screen views and actions today and almost magically integrated them. For example, if you have the household of John Doe and the house hold of Jane Doe, and you want to combine them, then you add Jane Doe to John Doe’s household and – poof! – the household is automatically renamed to “John and Jane Doe” and Jane Doe’s household is deleted. This completely removes the limitation that use of Person accounts involves – you can still have accounts and contacts. The problem being that Apex is only available in the sandbox for now.
  • Finally, Evan Callahan of NPower Seattle demoed a simple translator lookup app that he created for a client. What was cool about this was both that he put together a very intuitive and functional tool for finding a translator with the proper skills and availability, and he did it with some very simple code and a web form. In both Steve and Evan’s cases, they took innovative and undocumented approaches that produced powerful results. Must be something in that moist Seattle air.

Today we dive into how the Salesforce community can better operate as a cohesive support infrastructure and wrap up at noon. If you are a Salesforce license donee, keep your eyes open for a survey that will let you in on this critical input. And look for a bigger event next year — this was a great exercise for all parties.

Mapping NP Salesforce

Day one of the Salesforce Roadmap session was a well-crafted, but fairly standard run at typical strategic planning. Hosted by Aspiration’s ever-able Gunner (who I seem to run into everywhere lately), we had a group of about 40 people: five or six from Salesforce/Salesforce Foundation, five to six NP staff, and an assortment of Salesforce consultants. While I’m a consultant these days, I maintain a bit of a staff perspective, as my primary experience with Salesforce was to roll it out for SF Goodwill. The day consisted of breaking up into small teams and hammering out what works for our sector, what doesn’t, what could be done, and building all of this into a set of possible roadmaps that would address non-profit needs. The most striking thing about the outcome was that we had six groups design those roadmaps, and we largely all came up with the exact same things.

So, what are they?

Templates. In 2005, Salesforce developed a template for non-profits that everyone admits was pretty lame. Most of the consultants advised against using it. In 2006, Tucker MacLean, at the time a Fellow with the Foundation, redesigned it into something far more substantial – but still problematic, the problem being that non-profits are far too diverse in their structure and needs to fit a single template. The template in place transforms Salesforce into a donation management application. But I would argue that deploying Salesforce strictly as a fund development tool is short-sighted, and possibly disadvantageous when there are so many choices for software that is developed to that purpose, not twisted to it. The reason to deploy Salesforce is because it can handle the fund development and do so much more.

So, roadmap 1 is to move away from the one-size-fits-all template to something far more modular.

Road map 2 is around the community, or eco-system that supports the non-profit Salesforce adopters. And I think this is where the most meaningful changes can occur. This is about shared development — should NP Salesforce have an Appexchange of its own, one that acts more like Sourceforge? Can the consultant community adopt standards for how we deploy, and can Salesforce support us in any innovative ways? And can best practice, case studies, and non-profit specific training and documentation be collected in one place?

Third was the product itself, which I really don’t think non-profits can or should influence all that heavily. I don’t believe that our platform issues are unique. But we do want to see that new things (document management, Google Apps integration); we would really appreciate a customer portal and stronger ties to CMS’s and web sites, and stronger integration with our external applications.

What interests me is the dual need for this very open, malleable platform and the dire need non-profits have for out of the box functionality. Currently, Salesforce is a very worthwhile investment, but it’s not a light investment for a tech and cash strapped organization. The integrators working with it are frustrated by how much programming they have to do to support some very basic functionality.

But it says worlds that Salesforce is approaching this by inviting the community to advise them. This somewhat techy gathering will be followed up by a survey for the non-profit users at large. Ask yourself, how often does a large, corporate software company ask you directly to give input into their development? Or, if they do, do you think they actually listen? Once again, Salesforce is modeling an approach to doing business that has far more in common with the open source world than the for-profit. More on this later.

The future of Salesforce

I’m attending a strategic planning session at Salesforce.com this week devoted to planning the roadmap for non-profit use of the product. This should be an interesting event and an exciting opportunity to help steer one of the most exciting applications to hit the industry in some time. I remember walking through the exhibitor booth’s at the “Science Fair” during the 2005 NTEN Conference in Chicago and noting, in the corner, the guy with a shaved head standing at a small booth titled “Salesforce.com” and wondering what, on earth, he was doing there. Wasn’t Salesforce that corporate application used by all those people trying to sell me enterprise software? The next year, in Seattle, Salesforce was a key sponsor of the show, and the whole gang from the foundation was there. I was a lot more educated as to why, as well – in the interim, my former organization had signed up and I had started work deploying it.

Salesforce appeals to me because it lives up to many of the standards I look for in an online database:

  • It’s open. Any Salesforce customer can download their entire database into Excel pretty much at any time. There are no technical or contractual walls separating me from my information as a Salesforce customer.
  • It has a community around it extending, developing and integrating the product. While Salesforce is far from the only commercial application with such a community, it is far more analogous to the open source communities around applications like Joomla and Drupal than it is like their commercial counterparts. Salesforce has provided excellent forums and support, nurturing their partners in ways that most commercial developers are far too guarded to allow.
  • Sharing and philanthropy are part of the corporate ethic, fairly deeply ingrained. I like to joke that their stated policy of “one percent of people, product and profits goes back to the community” is not that big a deal, given that 100% of a non-profit’s revenues are recycled back into their missions, but the truth is that they do a lot more than just give away software, and I’m certain that it ends up being much more than 1%.
  • Salesforce is audacious and ambitious in all the right ways. They want to do away with your infrastructure and change the way that technology is deployed, and they are by far the most sophisticated example of how that can and should be done. And don’t ever mistake them for a CRM company just because that’s what they’ve primarily been – they’re a shard data and computing platform, and the next few years are going to see them break out of the CRM neighborhood into a new role as a data management middleware provider. Store your data and build your processes, they’ll handle the hardware.

Finally, in this era, when internet business is shaking up traditional business models in dramatic fashions — just ask the RIAA, or the telecoms, or your local newspaper’s classifieds editor — Salesforce is the disruptor in our community. Blackbaud, Kintera and Convio, along with the other established donation-based business support vendors, are all rapidly changing their models to more closely match the open approach. And Social Solutions and the case management crowd are well aware that they’re next. This bodes well for the customers.

I’ll be blogging from the conference (as allowed) and hope to spread exciting news.

Seven Questions For Peter Campbell On Open APIs

This interview was conducted by Holly Ross and first published on the NTEN Blog in July of 2006.

What’s an Application Programming Interface (API)?

APIs are the code in any application that allows for the customization and migration of information in and out of the program’s data store.The API allows your application to interface with other systems in the same manner that a door or data line allows your home to interact with the world around it. APIs were originally developed in the telecom industry, as the need to have computer applications that integrated with telephone systems arose.The concept quickly expanded as a method for companies to merge information in their major systems, such as Finance, Human Resources Constituent Relationship Management (CRM).Common examples of APIs include: importing and exporting data in and out of donor databases; and merging data from multiple sources via the Web, such as gas prices overlapped with Google Maps.Sites that use Google or Yahoo!’s API to merge data are commonly called “web mashups.”

Why would a nonprofit use an Open API?

If you want to do a mailing and your constituents’ addresses lie in multiple systems (donor database, Outlook, Excel, Access), then an API could be used to quickly merge them into one address list.As grant reporting requirements become more stringent, funders want to know what percentage of labor goes into direct service versus overhead, what portion of supply expense is put directly to mission-related use, and what percentage of volunteer time was put to field versus office work.Generating this report requires integrating data from multiple data sources.An API can help automate that task.

What is an Open API, as opposed to a closed one?

An Open API is one that does not restrict you.It gives you full access to your data and the application interface to support your customized needs. A closed API restricts your ability to work with your data.The difference between open and closed APIs is one of degrees, not either/or.The less an application allows you to do with your data, the more closed it is.

Are Open APIs features of Open Source Applications?

Not necessarily.Open Source software comes with code and a license to modify it.An API is an intermediary set of rules that allows you to do customization and integration, even if the source code is encrypted, as with most commercial applications.

Why are Open APIs controversial within the software industry?

Customers often want software that will not lock them out as organizational needs grow and change.Software selection has to be tied to strategic planning, and products need to be adaptable to unforeseen needs.This doesn’t rule out purchasing Microsoft or other (relatively) closed systems, as there can be strategic and economic advantages in standardizing on a vendor.But you need to do so in full awareness of how that software platform will limit your integration and reporting.There are commercial products, such as Salesforce.com, that have wide open APIs, because Salesforce operates on the philosophy that they should not restrict their customers from using their own data as they choose.

How does a nonprofit use APIs if it doesn’t have technical staff with API skills?

There are many programming resources in the nonprofit technology community who will develop low-cost or free applications that work with the API (again, see Salesforce as an example – the AppExchange is a rich collection of free, low-cost add-ons, with many targeted at our community).Look at the work being done with CivicSpace/CivicCRM to support APIs and integration.Even if the actual use of the API is not an in-house function, the existence of an API for a product or web service is still critical.

Should nonprofits advocate for the availability Open APIs among software firms that serve the nonprofit sector?

As funders and constituents demand more accountability from nonprofits, and as nonprofits want to better operate our businesses, it’s more important than ever to have commercial applications that are open to integration with APIs.In the nonprofit community, standardizing on one platform and developing it (the Enterprise Resource Planning (ERP) approach) is often far too ambitious – we lack the funding and resources to make that huge an IT investment.So key to our ability to operate in the information age is our ability to integrate data between our various applications.It’s important that nonprofit leaders encourage software firms that serve the nonprofit sector to make Open APIs available.

Peter Campbell is the Director of Information Technology at Goodwill Industries of San Francisco.