There is a very strong consulting ecosystem that’s developing around Force.com work for non-profits. Ranging from small or independent consultants to companies like Groundwire, Exponent Partners and Heller Consulting who specialize in non-profit work to enterprise consultants like Appirio, Accenture, and Deloitte (note that this is by no means an exhaustive list, so I know that I’ve left many names off). Depending on your organization’s needs, you can generally find a team that can do the work that you need done, and for many non-profits, who don’t have the internal technical talent, this is a perfect solution to get converted, or launch some new functionality (like website integration).
One of my favorite parts of Non-Profit User Group meetings is when people stand up to discuss and demonstrate the cool stuff that they’re doing with Salesforce. It always gives me great ideas for things we can do (and adds to my already long to-do list). One trend that I’ve noticed however, is that when I ask about how something has been done, I often get the answer ‘Oh, our consultant did that, I don’t know how it works’ or something similar. As a technologist (and I recognize that most of those presenters are not technology-focused), this is very dangerous situation, and puts your organization at significant risk in the event that something stops working or if you want to modify what’s already been created, particularly if the consultant that you worked with originally is no longer available.
So what to do? Based on my experience (both good and bad), here’s what I try to do when working with external consultants on our Salesforce.com organization and what I would recommend for your technology staff and Salesforce Administrator(s) to follow. Make sure that you discuss these items with your consultants going into the project, as some of these tasks take time to perform (and are often quick to be dropped if the project is running behind).
Participate in the project as much as possible
Most consultants are going to want you to participate in the solution, but what I mean is really jump in to the project. If there are custom objects to be created and custom fields to be added, do it yourself, don’t rely on the consultant to do it. This will have the double benefit of saving you money on the project, as you’re doing the work rather than the consultant, as well as ensuring that you really understand what’s being done to your setup. There’s (almost) nothing worse than going into your organization one day and saying to yourself ‘why is that field there?’ or even worse ‘I don’t remember that custom object, what does it do?’ Make sure to fill out the description fields on objects, fields, reports and report types so that you and your successors can manage your organization effectively (to be honest, this is more of a do as I say, not as I do recommendation, as we’ve not been disciplined about this and are paying the price currently).
Clicks not Code
This should be second-nature to most Force.com consultants, but in doing your solution design work be really disciplined about evaluating every proposed coded customization through the lens of clicks (workflow, formula fields, summary rollups, AppExchange apps) and process change before going the route of custom coding. The more custom-coding that you do, the bigger the maintenance burden you create for yourself, and the more eventual cost you’ll incur, either in your own staff time or in getting those consultants back in.
In most cases when working with a consultant, you will have come up with some sort of Statement of Work or Requirements document that defines what it is that you want them to do. This document serves to define the scope of the project for cost estimation purposes as well as when the inevitable change requests happen during the course of the project, and it’s a key way to look back at the end of the project to determine if you got what you wanted. What those documents don’t give you, however, is an explanation of how the solution achieves your goal, or even how much and what types of tools they used to create the solution.
- Before the project is completed/signed-off on, make sure that you get a list of every Visualforce Page, Component, Apex Class, Apex Trigger, Static Resource, Report etc. that was created or modified as part of the project. Ideally, you will have specified (or the consultants as a best practice will use) naming conventions/prefixes and namespaces to identify these components at the start of the project.
- Ensure that code has comments embedded which, at a minimum, defines the purpose of the object. More comments are usually better. Comments are critical when another developer has to look at the code and figure out what it’s doing and can allow work to progress much faster. As Salesforce.com Administrators or super-users, you most likely already know how to view, create and modify Custom Objects from within the Salesforce User Interface. What you may not know, is that you can do the same for Visual Force pages and Components, Apex Classes and Triggers, and other elements of custom functionality. Go to the Setup Menu and expand the Develop option (just below Create, where you access Custom Objects). There, you will see entries for each of the different schema types that can be developed. If you click on Apex Classes, for example, you will see a list of each class contained within your organization, whether custom developed or installed from an AppExchange or other package (like the Non-Profit Start Pack). If you then click on a Class name, you can see the code inside the class, which is where you will find comments. Comments are indicated by two slashes for a single line comment (e.g. //This is our seach method that is called every time a character is entered), or if there is a large block comment, it may be indicated within a /*comment here */ block.
- Get or make diagrams which show the flow of a process or navigation of a site/wizard, particularly for complex items. When something isn’t working as expected, or you need to bring someone up to speed, these artifacts are a big help.
At Dreamforce last year, we listened to the song Own It by the Black-Eyed Peas numerous times, and that song has stuck with me since whenever I’m working with Salesforce.com. The platform has given administrators the ability to own their systems in a much more intimate fashion than ever before – don’t give up that control to your consultants!