Working with a Salesforce consultant: Understanding the process

Before you sign a contract with a Salesforce.com consultant, or any cloud CRM consultant, you need to understand how the project is going to be run. This comprehensive list of questions will help you determine if the consultant you're looking to hire is a fit for your particular situation.

Comments

This set of questions is designed to help you evaluate the suitability of a Salesforce.com (SFDC) consultancy. It is not intended as a questionnaire for the consultancy to fill out in the RFP. Instead, use the questions conversationally so you can see their flinches and know where to probe.

Since client requirements vary, there's no single "correct" set of answers to these questions. Instead, score the vendors on how closely they fit your organizational needs and corporate IT style—and no firm is going to get a perfect score (be happy if you find a “solid B+”).

Salesforce.com consultant project design

You need to understand – before you sign a contract – how the project is going to be run. Sure, the sales slide deck will give you basic ideas and buzzwords, but you need to understand exactly how the consultant will work the project, and what they need from you.

Is there a “Project Overview” document (with timelines, swim lanes, checkpoints) available to review?
If the consultant plans to use agile project methods, is there an “orientation” document or video indicating what is involved, and how things will be managed?
Is there a “Client Responsibilities” checklist available to review?
Is there a “Homework” guide indicating what the client needs to do prior to the project kickoff meeting?
Will the project be following a “cookbook” – if so, can you review it in advance, and if not, when will the project plan be ready for review?
What time needs to be allocated in Client personnel schedules for discovery, validation, prototype reviews, and acceptance testing?
What time needs to be allocated in Client executive schedules for review meetings and escalations?
Will the project leverage subcontractors? Which ones, where are they located, and how will they be managed?
Will the project leverage offshore* resources? In which time zones? How will they be coordinated (particularly if in India)?
What proportion of the work at each major phase will be done on site?
Is the consultant going to use “pure agile,” “hybrid agile,” or waterfall techniques? Can they explain the difference? Can they explain the consequences of the difference for what you, the client, need to be ready for?

See this article and this one and this one and this one for more.

Consultant technical guidance

What is the biggest scalability problem we are likely to face in this project?
What is the biggest user adoption problem we are likely to face in the project?
What is the biggest compliance issue we are likely to face in this project?
One year from now, what areas of the system are we most likely to ask you to remove or rebuild?
Do you recommend using state and country picklists? Why?
To what degree will the project depend on custom code?**
To what degree will the project depend on third-party products? Which ones?
To what degree will the project depend on cloud computing outside of the SFDC platform?

Consultant technical practices

How will consultants access the system? Will they have dedicated users, or share one license?
What data and system configuration backup mechanisms does the consultant use, and when?
What deduping tools does the consultant recommend? What’s the problem with using SFDC’s built-in dedupe?
Does the consultant have a coding standards guide? Can we review it?
When in the project does the consultant start to write test code?
What are the metrics used to evaluate test code?
Approximately how big will the APEX test code be?
How do you automatically test Lightning code?
What is the trickiest governor limit to overcome?
How many sandboxes do you use, and how do you manage configuration changes among sandboxes and the production instance(s)?
If you intend to supply internal staff to the project, ask the consultant what resulting issues need to be managed?
When do you first start using the production system for piloting and testing?
How often do you do deployments during the project?
How do you do a “roll back”?
Do you develop for Lightning first, Salesforce1 first, or SFDC Classic first?
Do you use flows and process builder in conjunction with APEX?
When in the course of the project do you develop APEX test code?
When do you recommend not using validation rules? What do you use instead?
Roughly how large should an APEX trigger be?***
Roughly how large should an APEX method be?****
When importing or exporting data from SFDC, what file format do you use, and why?
Do you use a configuration management system in the project? Which one?
Do you use a deployment automation system in the project? Which one?
What kind of logs do you keep for developers and deployment personnel? Will we have access to those logs?
What kind of “in system” documentation can we expect? When you add a new field to an object, what explanatory text to you add…and where?

IT habits and internal policies make a material difference to the likelihood of project success. It’s not essential that a consultant comply with every item on the checklist above, but wherever policies diverge from these, it’s an opportunity to engage in a healthy conversation … before you sign. If they have solid reasoning for a different policy, you should know about it, but if it’s a case of “we just don’t have a process for that,” you should know that, too. See this article and this one for more.

Project collaboration

In what form will requirements be documented? How will we know when discovery is complete?
Who will perform data transformation, cleansing, and validation? What tools do they recommend?
When does discovery end?
What mechanism do you have for calling us to task if we aren’t performing needed steps fast enough?
What mechanism do you have for determining whether a problem is a bug (that you have to fix for free) vs a new feature (that we have to pay for)?
From your experience with other clients, what about your process is likely to be most easily misunderstood or underappreciated? What are the “gotchas”?
What exactly do you do when we are making an unwise decision?
What parts of the user acceptance test (UAT) and other system validation steps need to be done by the client vs the consultant?
What tools will you use for coordinating tasks, action items, project FAQ, time tracking, progress vs burn rate, and team communication?
Do you recommend using email as the primary project communication mechanism? If so, what do we need to look out for? If not, what do you recommend instead?
How often will there be status reports? Project reviews?
What is the SLA for responding to a request? For fixing a bug?
What mechanism do you use for “guard rails” for budget, scope, and schedule?

Knowledge transfer and change management

At what point in the project should our internal personnel start to get involved in the development, deployment and troubleshooting of the system?
When do you introduce pilot users into the system? What is your recommended approach to getting all users up and running?
What are the key metrics of system readiness in the weeks approaching go-live?
What are the key metrics of system success in the few weeks after deployment?
What is your recommendation for user training? How long should the session(s) be? What about new employee training after the system handoff?

We all know personal hygiene habits that we’re supposed to have, but probably don’t practice consistently (did you really floss three times yesterday?). And there are social behaviors that we really look out for – and probably even judge people on. But when it comes to IT habits, most organizations don’t seem be screening consultants for key behaviors and policies. So…don’t fall into that trap!

-------

* We all know the offsite/offshoring drill by now. Offshoring can work fine for contractors. There's no question that offshoring is cheaper, but that's only in the narrow, hourly rate sense. With consultants , however, it just isn't very likely that those inexpensive offshore resources will be able to provide you valuable advice about best practices in your industry. Further, for agile cloud projects, proximity and frequent contact with your users is critical to success and low cost. Offshore resources are both harder to manage and less productive than those on site, and few offshore teams really know how to succeed with agile sprints.

** We all love to code. Heck, I can barely stop myself. But deeply custom code should be avoided if you can. It's expensive (both initially and with ongoing maintenance), and every module of custom code further limits the flexibility of your application over time. Since one of the towering strengths of Salesforce is its platform flexibility, too much code is a seriously bad thing for any project.

*** This is almost a trick question. The answer should almost invariably be “fewer than ten lines.” No, I won’t explain why.

**** This is also almost a trick question. The answer should be “no more than 15-20 lines.”