One of the great promises of using CRM for nonprofit program management is the ability to manage by metrics. In theory, if we could track all efforts and all outcomes in a system, then we could uncover those predictive indicators that lead to desired outcomes. We could then make adjustments to the program operations itself to reach those desired outcomes. To a great extent, this is possible, however, it is much more complex than it sounds. One of the root causes of the complexity is the fact that we often are not looking at all of the variables and are only looking at a subset. Making decisions on a subset of variables can sometimes lead to incorrect conclusions. Since I have seen this logic trail unfold a few times, I thought I would share an abstracted example of such a situation.

Take for example, Acme Org, a human services organization that has implemented a robust CRM solution that tracks almost all aspects of it’s program operations. Below is one of the critical reports reviewed by the Executive Team each month:

The organization is considering the use of these metrics for determining promotions, salary adjustments, and bonuses. After initial review, the Executive team expressed concern about Jon’s performance to Jon’s manager. Jon’s manager on the other hand knew that Jon’s metrics were low because he was always thrown on to the toughest cases. Being on the toughest cases each month meant that Jon would have to spend more time with each client and would be responsible for defining new engagement processes for working through complex cases. Unlike the other client service reps Jon spent a lot of time researching and speaking to industry experts to identify best practices that could be used by Acme to help future clients. In short, Jon was expanding the organizational knowledgebase, capacity, and quality of service delivery. Unfortunately, none of this was being recognized in the monthly report. Jon’s manager decided to add a new metric into the monthly report that would help recognize Jon’s efforts. The revised report is below:

The revised report gave the Executive Team more insight into Jon’s efforts and the demands placed on the Client Services staff.

The point of the example is to proceed with caution when using Metrics for Management level decisions. They can be a very powerful tool when well directed; however, there is usually a story behind every piece of data and it is critical that the entire story is understood before program level decisions are made.

If you haven’t already done so, make sure you get deep into Cross Object Formulas. They have fundamentally changed how we think and work with Salesforce.Com configurations. A Cross Object Formula is a Formula field that can traverse object relationships and pull down data into an object.

Take the following example. Let’s say you are using the Opportunities object to track Inbound Grants. Let’s say that you have a Payments object that has a Master/Detail relationship with Opportunities (Payments is the Detail).

You can setup the following Cross Object Formulas in the Payment object to reference elements from the Opportunity and Account.

Payment Made By (Account) = Opportunities__r.Account.Name
Payment For (Opp) = Opportunities__r.Name

The beauty of the Cross Object formulas is that it lifts many of the constraints we previously faced with Salesforce. We can now:
- Create more complex reports including more objects than we could in the past
- Avoid writing Apex for something as silly as replicating a parent or lookup field
- Ease data entry and report building for the end user by making data more accessible

There are some limitations to be aware of:
- Limit of 5 cross object relationships per object
- You can reference up (from detail to master) or sideways (lookup), however, for references from parent to child, you still need to use Summary Roll Ups.

If you haven’t already used these, you should definitely check them out as they can solve many common problems you may have faced in the past.

If you have any interesting use cases for cross object formulas, please post them in the comments.

We have been engaging in a lot of interesting debates in the NPower office about what makes a CRM solution sustainable for an organization. After a typical CRM deployment project, we do our best to leave the nonprofit with enough knowledge and tools to keep them sustainable. Here is a list of a few of the things we do:

Documentation - We initially started with word docs, however, we are more recently moving towards the use of Help Tips, Recorded Screen Casts, and a Help Tab. The idea behind documentation is that it should be complex enough to educate someone on how to use the CRM; however, not so complex that the documentation cannot be maintained.

Training - This is perhaps the most important element for us. We typically provide our clients with two levels of training. We do an end user training session that lasts between 1 and 3 hours depending on the complexity of the client implementation. We also do an administrator training for the Sys Admin level users at a client site. We also encourage the Sys Admin level users at the client site to attend a formal Salesforce training class.

Community - For clients that are in cities where CRM user groups are held, we encourage them to join and attend. This allows them to learn from their peers and get new insights into what is possible with CRM. We also encourage Sys Admin level users to join the NPSF so they can learn through the engaging technical conversations of the online community.

One of the areas that continues to be a challenge for us is Custom Code. Salesforce (and other CRM tools) provide a variety of means to extend the base platform with Custom Code. In the case of Salesforce this would be Apex, VisualForce, S-Control, and API Code. We are always weary of dropping custom code into an organization that has no means of managing or modifying the code. We do our best to avoid code by using as much standard functionality as possible. When it comes to deploying custom code into an organization that is not able to support it, we work through a simple cost/benefit tradeoff. Is this Code performing a high value business function? Is there a high probability the Code will need to be changed within the next 3 years? If the code needs to be changed, can the organization afford the change? If there is HIGH value for the code, LOW probability of the code needing to be changed, and the organization will likely find the funds for a change, then this alleviates our concerns. Custom Code is not to be feared in a NPO CRM implementation; however, a plan needs to be in place to support it over its lifecycle.

I was lucky enough to be invited to attend the Enterprise 2.0 Conference this week and was able to meet with many organizations dealing with adopting these kinds of “2.0″ tools. I saw 2 common themes emerge:

• Almost every organization is struggling with adopting and effectively using these tools.
• Lots of these projects started in somebody’s basement (both metaphorical and literal) and grew exponentially as more people with the organization started to adopt the tools

One of the most interesting presentations was from the CIA’s “Intellipedia” team. Essentially they used the Wikipedia platform within the internal intelligence community to start sharing information better within and across the multiple government intelligence agencies.

Link: http://community.e2conf.com/community/sessions/tuesday/gs03?view=all

Take a look at these terrific points from the OSS Field Sabotage manual (sound like your organization?): http://www.boingboing.net/2008/06/11/sabotage-manual-from.html

As we all know, Visualforce is going to be released this weekend with the full Summer 08 release.  Are you ready and up to speed?  If you have a Salesforce Developer Account (which you should because they are free!), take a look at http://wiki.apexdevnet.com/index.php/Force.com_Tutorial:_An_Introduction_to_Visualforce

Also, there is a free webinar next week which you can register for here:

http://wiki.apexdevnet.com/events/visualforcewebinar/registration.php?d=70130000000E15w

Start kicking the Visualforce tires and post comments about your experiences here!

A colleague of mine (Lisa Glass) recently began using encrypted fields in Salesforce. It turns out they are fairly simple to use. Encrypted fields need to be requested through the “Feature Activations Team” at Salesforce. You can just open a Support Ticket and put in a request for this. As per the documentation, this feature is available to all Enterprise and Unlimited edition accounts, which means all NPO’s should be able to access this.

How it works:

• It creates a new field type in your instance called “Text (Encrypted)”. This is fairly similar to a regular text field, except that the data is encrypted.
• In order to see data within an encrypted field, the user’s profile must have the “View Encrypted Data” option checked off
• Any user that does not have this permission in their profile will see a value such as “***-**-****” when they view the encrypted field. (Note: You can specify whether you want the Mask to be either a “X” or a “*”. You can also leave a portion of a field unencrypted, such as the last 4 digits of an SSN.

Limitations:

• Max length of 175 characters. (You can’t really use this to encrypt case notes.)
• Field value can not be Unique, External ID, or have a Default Value
• Can not search, filter, roll-up, query, or use the field value in a Formula
• Can not use in workflows and assignments

Overall, this is a very powerful feature and you should consider leveraging it in your instance if your are storing any sensitive data such as Social Security Number, Credit Card Number, Medical Info, etc.

There is a lot more information on best practices and usage examples within Salesforce Help.

At NPower, we have worked on a fair number of CRM projects and we are trying to figure out the question of CRM timing. When is the best time for an organization to implement a CRM solution? I have taken the OLC (Organizational Life Cycle) Model and mapped that against our experiences with CRM success.

Stage 1: Startup Stage - The organization is still figuring out it’s mission and funding streams. Operating procedures are in flux and can quickly change based on grants, board members or funders. Technology is not really a core requirement.
Stage 1 CRM Outlook: Investing in a CRM Solution typically doesn’t yield great results because many of the underlying assumptions will change over the next few years. A very simple fundraising CRM solution can be effective in this environment, however, using CRM for operational purposes may not yield a good ROI.

Stage 2: Growth - At this stage, the organization has proven that their mission is a sound business idea. They have proven that they have the operational know-how to execute on their mission. They have secured a stable base of funders and a good core of board members. Their attention has turned from survival to growth.
Stage 2 CRM Outlook: This is likely the stage at which a CRM solution can have the greatest impact on an organization. Implementing a CRM can provide substantial gains on the fundraising side, while also cataloging a history of all fundraising interactions. On the operations side the CRM can begin to model organizatonal procedures and collect valuable performance data. If the CRM solution is implemented in an intelligent manner, it can scale and flex as the organization grows and evolves.

Stage 3: Maturity - As an organization reaches a certain scale, it’s growth will slow. At this stage, the organization is very good at executing on it’s mission. It has an extensive base of funders and they have very specific expectations of this organization.
Stage 3 CRM Outlook: This is a very tricky stage for CRM deployments and a lot depends on the organizational culture and leadership. If the organization culture is receptive to change, then a CRM solution can serve as a great engine for operational improvements. If the org culture is not receptive to change, then a CRM solution will likely replace some existing systems and only provide marginal efficiency gains.

Stage 4: Decline - The organization begins to lose stable funders and board members. New startups take away fundraising streams and the organization is perceived to be less effective and not as innovative in a modern environment. The organization begins to cut back on programs, staff, and all non-essentials as it seeks to find a way to reach a stability point.
Stage 4 CRM Outlook: Surprisingly, this could be a great time for an organization to move towards a CRM solution. Organizations in this stage are often heading back towards stage 1. This leaves them open to process innovations and funding changes. This willingness to explore new paths can make a nimble CRM solution an effective solution to manage the massive changes that the organization must face. The difference between this type of organization and a stage 1 organization is that they also need to carry forward the massive amount of data and relationships that they have amassed over their years.

The above is not meant to be hard and fast rules about good and bad times to get into CRM. They are just some observations from our years of CRM consulting experience. There will undoubtedly be many organizations that are exceptions to the above rules for a variety of reasons.

It may take years to fully understand the impact of the CRM solution, however, the clear winners so far seem to be those organizations that are in a growth stage.

I’ve been busy writing Apex, so no time to post to the blog. One thing I’m learning is that once you have some useful Apex code, like the lead conversion and payment processing tools we’ve created, it is easy to deploy it to multiple organizations — and that is just what we’re doing. However, in every case there are small tweaks to make, and more test methods to write, and more debugging, so it important not to underestimate the time needed to reuse your solutions.

We currently have two open positions in in our growing CRM consulting practice here at NPower Seattle (and many clients ready for help!). If you have Salesforce expertise or other relevant experience and are looking for a opportunity to work with nonprofits on a great team of developers and implementors, please take a look at these.

NPower Seattle serves over 450 nonprofit clients each year by providing technology consulting, education and training. Our clients include arts and environmental groups, human services agencies, food banks and youth-serving organizations.

Find full job descriptions at http://www.npowerseattle.org/getinvolved/jobs/index.htm. Submit resumes and cover letters to Resumes (at) NPowerSeattle.org.

I was having a great discussion about Salesforce yesterday with Sonja Okun, the Executive Director of Exalt Youth. Exalt Youth, in her words, “acts as a prevention for justice system involvement to youth at risk of getting caught in it, and as a catalyst for integration into our economic mainstream for those who have already entered the system.” Exalt Youth has been using Salesforce for the past few months as part of their daily program operations. Unlike other nonprofit organizations, she isn’t currently using the donor management functionality at all, although she plans to use that in the future.

Sonja and I were specifically talking about all of the fields that she wanted to add to Salesforce once she saw the possibilities of the system and the ease of reporting. Again, in her words, “I just wanted to add everything, and why don’t we track this…and this too!” It’s pretty trivial to add custom fields in Salesforce, so when the project started she had quite a few fields that she wanted to add. However, as the project progressed, it became clear that she wasn’t going to use the data in a structured way. She wasn’t going to report on it to funders or even internally. This led to a simplification of the data model and the creation of extremely useful reports and dashboards (nice job, Lisa!.

The lesson here is to start with the reports that you would like to generate, drill down into each of those reports, and make sure each of those fields exists somewhere in your data model. You can’t get the data out if it’s not in the system. Conversely, don’t put extra data in the system if you’re not going to report it out! This becomes painfully true if you have line staff who have to enter reams of data into a system at the expense of actually serving their clients. If no one is looking at the data that they are spending so much time entering, it can really hurt user adoption of the system, and that’s when you’ll start hearing the “I hate our new database” comments.