6 things to look for in a cloud consultant

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.

This is not a good state of affairs because IT habits and internal policies make a material difference to the likelihood of project success. 

The short list of policy issues below should be part of any screening criteria for cloud consultants, in general, and Salesforce consultants, in particular.  Now, it’s not essential that a consultant comply with every item on the checklist below, 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 it, but if it’s a case of “we’re too lazy to do that every time,” you should know that, too.

• System access – From the first moment of the project to the end, consultants should insist on having a login that isn’t shared with any of your personnel, any other contractor, or any third-party application or data source.  For a myriad of reasons, this policy is good for you and for them, and it helps reduce finger-pointing when something goes awry.  If the consultant doesn’t insist on this, you need to understand why.  Consultants get extra points for asking for multiple logins (e.g., one for development, one for integration and one for system configuration) on each system they touch.
• Data and system configuration backup – Before you let any outsider into your system, you should do a full backup of the system data and metadata.  Whether or not you do that, the first thing consultants should do is make their own backups of each system they touch to speed impact analysis and lower the risk of destructive errors.  If this isn’t part of the discovery phase, you should take serious points off.  However, if consultants will be doing their own backup at the end of each sprint, they get extra points.
• Sandboxes – For system development, integration and migration work of any seriousness, a sandbox (or even multiples) are essential for efficient, safe work.  Yes, this means you must pay the platform vendor, but it will result in lower overall project costs and risk.  Consultants get extra points if they ask for multiple sandboxes (some full of data, some not) and even more extra points if they plan to use GIT or some other configuration management system across all the sandboxes, staging area and production system.
• Configuration Logs – As everyone knows, developers hate to write documentation or comment their code. Salesforce consultants get one point for free because Salesforce tracks some of the configuration and code changes all by itself.  But no system can read minds, so it’s important that each of the people working on the system maintains a personal log of what he or she is doing every hour or so.  This can be done either as annotations to the time card or as a discrete text or spreadsheet document, but whichever medium you use, it’s an essential part of institutional memory. Nobody will remember six weeks from now who did what change, when or why … unless it’s written somewhere. Back-tracking on a design decision or simply justifying a monthly invoice is much harder if this little chore isn’t done, so it’s well worth the 30 seconds out of every hour.  Find out what the consultant’s process is to support this and give extra points if the SFDC log files are backed up every 90 days or so (as these aren’t automatically backed up and fall into oblivion beyond their time horizon). Even more points should be given if the configuration logs are posted in full view of all project participants.
• Project communication media and SLAs – Almost any project will involve both on-site and off-site resources, and many will involve offshore ones.  While phone and email are universal, over the life of a project they are also a lousy way for teams to collaborate across multiple locations.  Consultants need to accommodate client habits, but they should direct everyone to be using the project collaboration platform (whether it’s as primitive as Google Spreadsheets or as sophisticated as a project management portal) for all meaningful communication.  Consultants should also state expected response times for communications on a 7×24 basis (of course, nobody expects instant response to an action item issued at 3 AM on Sunday, but everybody needs to know that they shouldn’t expect any response at all until, say, 3 PM on Monday).
• Signoffs – Most consultants will say that they’ll be looking for a signoff during the project, but the real issues are in the “when” and the “how” of it.  At the bare minimum, there needs to be an explicit signoff for any change orders and at project completion.  The wise consultant also asks for explicit signoff at the end of discovery (to signify “these are the requirements and their priorities”) and at significant project milestones (such as “feature completed” or “data imported”; in Agile projects, at the end of each sprint). 

We hold these truths to be self-evident

This obviously isn’t a comprehensive list of desirable consultant behaviors and habits.  But now that you’ve read it, you are doubtless saying to yourself, “What’s the point here, isn’t this all common sense?”  And the answer to that question is the point of this article: it might be common sense, but it isn’t common practice.