(With apologies to Stanley Kubrick)  We’re about to begin a Salesforce rollout to a new team of users and I thought I’d share the steps I’m taking to prepare everyone for the big change that’s about to happen:

• Communicate early and often! We let people know months ago that this was coming, and kept reminding them every few weeks.  Not in a nagging way, but just to keep it from going completely off their radar.
• Enlist the “difficult” users first! You know who these people are, they’re the ones who won’t want to touch Salesforce with a 10 foot pole.   You’ll get their buy in by making them feel invested in the outcome, and letting them know that you’re really listening to their concerns (by  making changes to your training documents or Salesforce to make their lives easier).   Once the “difficult ones” see the light, they’ll be your biggest evangelists.
• Beta test with a user or set of users first.  That way they can give you feedback on what’s working and what’s not, and you can make changes accordingly.  Don’t forget to REWARD your beta testers too – candy or booze always works well for me.  And thank them publicly too.
• Use help text! Since Help Text on Standard Fields is now coming in Winter 10 (at last!), don’t be stingy with using these everywhere you possibly can.  It’s always easier to mouseover a little help bubble than to open a manual/wiki/screencast/sticky note/etc.
• Create documentation! This could be a Word or Google doc, a Wiki, a Screencast (I love Jing for these), whatever – just make sure this is something easily accessible to everyone who needs it.  I like to create a custom web tab (Called “TRAINING MANUALS” or something descriptive) that embeds links to everything on one page.  And make sure that someone knows how to update it when you’ve hit the lottery and moved to Kauai!
• Have a plan! Make sure that you’ve got all these steps written out, and a timeline to implement!  Salesforce rollouts are not an overnight process, and you should plan on things taking a while.

Stay tuned for a future post about monitoring user adoption.  For more on the topic of managing technology change in your org, I refer you to one of the best sessions at this year’s  Nonprofit Technology Conference, “Technology Ch-Ch-Change: Managing Technological Change in Your Organization” and to Dahna Goldstein’s chapter in the NTEN book.  Enjoy!

On many occasions, I talked to organizations new to Salesforce that were worried about storing their data online. At a very high level, this post presents the security in place with Salesforce.

When it comes to data, Salesforce and the cloud computing model mean that you are not storing your data on your own server and that multiple clients’ data could be stored on the same server. What it does not mean is that you give up control of who can access your data or that your data is more vulnerable. It is indeed the contrary. There are two levels of security in place. The first one comes to you out of the box and ensures the protection of your database. The second level provides you with tools to implement your specific permission requirements.

Level 1: Infrastructure

Because of the shared infrastructure, Salesforce has higher level of security than most organizations are able to implement independently. You can find a great description of this here but know it includes:

• Secure data centers.
• Secure transmission and sessions.
• Network protection.
• Disaster Recovery.
• Security Monitoring

Level 2: Your permissions

Obviously, any level of security requires consideration of different elements: user training, password policy, user permission, backup, etc.  And it is has to do as much with the tool you are using as the policy you put in place (we all know the old story of the monitor with a password written on a post- it).

This is an overview of the basic security controls Salesforce has to offer:

• User control. You decide who has access to your database by creating user logins.
• Application control.  Found in the Salesforce profiles, this helps you control which tabs and applications (the ones you build or the ones you download on the AppExchange) each user can see. For example, all users can see the Volunteer application but only the development team can access the Opportunity tab.
• Object permission control. Also found in Salesforce profiles, this allows the administrator to decide what general permission (Read, Create, Edit, Delete) per objects are available for a given user. For example, you might only allow some users full access to the Opportunity object (traditionally capturing more sensitive information such as donations).
• Record level security Control. Known as the organization wide defaults, this allows you to define who can see what record. For example, all organization records are shared among all staff except organization records created by the executive director.
• Field level security Control. This lets you decide the permission on individual fields. For example, everyone can see all contact records but only some can see the lifetime total amount donated field.

Salesforce provides a secured platform with ways to implement specific permissions which is usually sufficient for most. However each organization should decide whether or not this is adequate and I hope this post will help you understand some of the security controls available. More information can also be found in the Best Practices from Salesforce.

This is my first post after a long hiatus involving a move to a new city (Boston), and to a new job as Technology Manager at Root Cause, a nonprofit in Cambridge, MA.  One of my first and biggest challenges here has been getting our Salesforce database under control.  After 4 years, every user was a System Administrator, and nobody knew what most of the custom fields and objects were being used for!  It was a disaster.

big mess o' computers

Here are some of the things I did to get our database back under control:

• I talked to the currently active users, and got their buy in to make changes as long as they weren’t catastrophic to the way they were currently doing things.
• I formed a “data cleanup” team to start wrangling some of the thorny data issues.  One of the best things we did (thanks, interns!) was use DemandTools to create an Access database backup of our entire Salesforce database, then look at every single field in every single object and report on how much data was there!  We got some very surprising answers for fields we thought everyone was supposed to be using (they weren’t, or the data was inconsistent).
• I formed a “SF Training Team” to create a Salesforce manual and make some screencasts using Jing.
• I started getting definitions for all custom fields, and adding it to the Help Text balloons, so people were no longer mystified as to what went in a certain field.  (By the way, PLEASE give us help text for standard fields, Salesforce!)

Hope this helps any of you out there who are inheriting a database “of a certain age.”  Good luck, and any comments are welcome!

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.

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.

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.

As a CRM consultant, I often get asked the question of what a CRM implementation costs? I typically respond with the standard consultant speak of “it depends” and enumerate some of the factors that can influence the pricing of a CRM implementation. From a client perspective, I understand that it can be frustrating not to get a solid number or even a narrow range estimate. The problem is that a CRM project is kind of like building a house and depends on dozens of factors. Below is a list of some of the items that can influence the price of a CRM project:

• Business Functions – This is essentially a scope question. Are you trying to solve a specific need with your CRM or are you looking to turn your CRM system into a quasi-ERP system to run all of your internal data needs? The more scope, the more it will cost.
• Business Process Re-engineering – Is your organization fairly confident in existing business processes or are you looking to make some big changes? A CRM consultant can aid in this process, however, this tends to consume a lot of hours and raise costs.
• Iteration Cycles – Most Salesforce implementers will prototype an application. Each round of revisions on the prototype is often referred to as an “iteration”. Limiting the number of iterations can help to manage costs. One of the key ways to do this is to ensure that all stakeholders participate in the review process and that coordinated feedback is sent back to the CRM consultant.
• Training & Documentation Needs – For larger organizations, using a “train the trainer” model can save significant implementation costs. Also, be careful to only get as much documentation as you can maintain. If you are not able to maintain hundreds of pages of documentation, do not request it from your CRM consultant. Static documentation tends to become outdated very quickly on CRM systems.
• 3rd Party Applications – Does your CRM project need 3rd party applications? Sometimes this can help to lower implementation cost (could be at the expense of ongoing cost). However, some 3rd Party apps may require setup or configuration which can add to the implementation cost.
• Consultant – Like in any marketplace there are different types of consultants in the CRM Marketplace. Some thrive on transactional models were they execute a large number of projects and are able to charge lower rates. This is great for organizations that have limited budgets and fairly straightforward needs. Other consultants get deep into an organization and may re-engineer processes in addition to technology. This approach is great for organizations with complex business problems and more flexible budgets.
• Custom Code – If your business requirements cannot be met within the constructs of the CRM platform you are using, then your consultant may need to custom code. In Salesforce this means adding Apex, VisualForce, and S-Control code to your system. Custom code can quickly increase both your implementation costs and your long term maintenance costs.
• Systems Integration – Does your data need to be in synch with other databases or applications with your IT infrastructure? What type of synchronization (manual, bi-directional, uni-directional)? Systems integration can easily increase implementation costs.
• Web Integration – This one is a little more complex because there are some things that are very easy to integrate with a website (Web2Lead, Web2Case). Other items such as building a multi-page application form with save and return functions could be more complex and costly.
• Data Migration – This is the single area that we have seen the highest variance of cost. We will probably need an entire blog article to describe how data migration can influence costs. One thing that you can really do to help keep costs down here is to clean up your data. Remove duplicate records, correct spelling mistakes, and get paper data into electronic form. If you have 100 Excel files, see if you can condense that down to 20 or fewer files. This is one area were doing some prep work can save you substantial CRM implementation costs.
• Reporting Requirements – This is another area where there tends to be high variance among organizations. Some organizations have enormous and complex reporting requirements, while others can survive on basic data reports. A consultant will need to review your reporting requirements to get a sense of where you land on the spectrum. Reporting can get particularly expensive when there are complex business rules and formatting rules for report generation.
• DIY – One way for an organization to lower CRM implementation costs is to take on more of the work themselves. For example, if your organization needs to have 100 reports and 30 dashboards built, have your consultants build out the most complex ones and do the rest yourself. You will save money and also increase your system skills at the same time.

The above list is not everything that goes into CRM implementation costs; however, it does reflect some fairly important items. Also, consider the following when thinking about CRM implementation costs. If you decide to do a lot of the work in house, you are not really lowering the CRM implementation costs. You are just displacing them from an external resource to an internal one. Depending on how your org’s budget is structured, it may be easier to use internal resources. Also, be careful not to take on too many ongoing costs (3rd party apps and services) to lower implementation costs.

If you are a CRM consultant or have done a CRM project for your organization, please shout out some of the other major cost factors you have faced in the implementation process.

I was having lunch with a friend the other day and he told me about a recent horror experience he had within his own organization. His organization just completed a fairly large internal CRM project and was rolling out an application. During a training session with a core group of users, one of the users attempted to move from one screen to another without saving and lost some data. Mortified that her action was a bug in the system, she lashed out at the training staff and soon infected the entire classroom with a negative perception of the application. The training staff was eventually able to regain control of the session and finish it out; however, they all now know that an enormous user adoption hurdle lies ahead of them.

I wanted to bring up this story to illustrate a critical point that we often think about in our CRM implementations. Know your influencers!! It’s easy to fall into a trap where you assume management support equals end user support. This may be true in smaller organizations or organizations that have a very hierarchical organizational structure and culture. However, many organizations are operating in more flat and distributed models. This often means that the loud voice of a peer can be just as influential as that of an Executive Director. Getting insight into who the influencers are and getting buy in from them early on in the process can help to avoid situations such as the one above.

I recently spent some time learning more about Microsoft Dynamics CRM and I must admit the product looks very interesting! For those of you that are more familiar with Salesforce.Com, I will try and draw out some of the similarities and some of the differences. I haven’t had a chance to do a nonprofit implementation with Dynamics CRM, so this is very much just a first look based on information I have read and some online demos.

The first major difference between the two platforms is how they can be run. Salesforce is locked in to the On-Demand model. Microsoft offers the ability to run Dynamics CRM either as an Internal Application or as an On-Demand offering through their CRM Live service. At first glance, it appears as though Dynamics CRM would be more feature rich when run as an internal server based application. It derives its value from making the assumption that end users are most familiar with MS Office Suite of Products. It has very tight integration with MS Outlook and MS Excel. Below is a screenshot of how CRM Dynamics looks in a familiar MS Outlook Environment:
Read the rest of this entry »