Salesforce Sidekick

Before I took the plunge into the consulting world, I was an internal Salesforce Administrator and Developer working in Sales Operations.  I was in charge of a 200 user Salesforce org.  We used both Sales and Service Cloud, and we even had two Customer Communities.  Since my jump to become a Consultant I’ve noticed that some skills transferred over and others didn’t.  In this post I’ll make 5 comparisons between a Salesforce Admin/Dev to a Salesforce Consultant.

#1 – TIME

When I was an internal employee, I showed up and put in my 40 hour week.  Nobody was standing next to me with a stopwatch to see how long it took me to modify a page layout or create a new Custom Object.  People saw positive results, and (most of the time) that was good enough. No questions asked.

As a Consultant I am now judged in a different light in regards to time.  My company sees every hour that I bill as income.  That means every hour that I bill towards a project is money made for my company.  If I don’t come in at the end of the week with close to 40 hours of billable work, then its lost revenue for my company.  So, as an employee, I’m now judged on how many hours I bill towards my clients – not just how many I work.  Now, where this becomes difficult is when you start to throw in project budgets into the mix.

Lets say that I have an 80 hour project for a small implementation.  If I finish that project 20 hours early (60 hours), I just lost my company 20 hours of billable time.  I don’t think I know of a client that would be upset for coming in under budget, but internally this can mess with your company’s revenue forecasting and resource allocation.  If I come in 20 hours over (100 hours), I just lost my company 20 hours of billable time (or cost my client more money than they budgeted).  Sometimes it seems like it can be hard to win.  Consultants are not only judged by how well the finished project was, but also how much time was spent on it.

#2 – Clients

If you’re working on implementing Service Cloud for an org, typically the client is your Director of Support (or similar title), and there will be input from a few of the top Support team members.  That doesn’t change between Consultants and an internal Administrator or Developer.  The difference is how long this relationship usually lasts.  As an internal Admin/Dev you’re typically stuck with that co-worker for your whole employment at the company.  This means, you’ve got to do a really great job communicating and keeping them as your friend!

As a Consultant your projects come and go.  If you’re on an unenjoyable project, there is an end in sight!  If you’re on a fantastic project where the client is amazing, enjoy it while it lasts!  When you’re a consultant your clients are a constant revolving door.  As an internal Admin/Dev you’re stuck with them.  This could be a blessing or a curse.  In my last job I was lucky enough to have fantastic co-workers to interact with (and learn from)!

#3 – Expectations

As an internal Admin/Dev you have to manage the expectations of your clients just as a Consultant.  You could do the best and technically sound Salesforce implementation, but if your client wasn’t expecting to get what you delivered – they’re most likely not going to be happy with it.  You want to make sure that you set expectations throughout the project so they’re aware of what is being delivered.  This is something that affects both an internal Admin/Dev and Salesforce Consultants, but often times this affects a Consultant more than an internal Admin/Dev due to budgets and time.

#4 – Knowing the Company

We’ve all hopefully seen Michael Farrington’s (aka Michaelforce) video on life as an Admin.  If not, take a look here (you’re bound to get a few good laughs in): https://www.youtube.com/watch?v=Bh6GxBnRImw

In this video there is a constant theme of the Admin seemingly knowing more about Salesforce than their own Company.  I know this was true of me when I worked at a Healthcare IT company.  While I might not have known the Healthcare IT industry as well as I knew the Salesforce, I did know everything inside of our Salesforce org.  I understood how every department and user was using Salesforce, and where their pain points were.

This is an advantage that Consultants don’t have.  When I come into an existing and busy org, I have my work cut out for me.  I am often times working with management, and often times they aren’t the only departments using Salesforce.  This means I’ve got to be extra careful.   The feeling of invincibility knowing how everything inside my org works is long gone!

#5 – Scope Creep

As an internal Administrator I often prided myself in saying yes to almost any increase in scope.  I saw it as a chance to learn how to build a Apex Trigger, Visualforce Page, get another department into Salesforce, or get another process out of Excel.  I would just tell the stakeholder that it would take some more time, but we could do it.  This is something that happens to Consultants every project as well.  Before the project starts you’ve got a signed Statement of Work (SOW) with your client.  This SOW describes in detail what you will do for them.

Where this becomes difficult is when you begin the project and the focus changes slightly.  Lets say we are doing a Sales Cloud implementation.  We start to customize the objects and setup the permissions.  Halfway through the project they realize they want to add additional workflows around their Sales Process that wasn’t on the SOW. Well, lets take a look back to #1 – time!  How many hours do we have in our project?  Are we on track to finish with some spare hours, or are we in danger of going over on the project?  As a Consultant, this is where you have to learn to say NO.  This is not because you are not able to do it, but because within the project’s SOW we aren’t signed up for it.

So, what does a Consultant do in this situation?  Well, if I’m confident we’re coming in under on hours, then it might be okay to fit it into the original project.  This is what I used to do as an Admin, and it lets me avoid having to tell me clients no.  Now, what I should be doing is referring back to our SOW to say that its not part of our scope, and that we will need to get a ‘change request’ for the add-on to the original project.

This can be a grey area when you’re talking about smaller items, because they eventually do add-up over time if you keep saying yes.  I might be comfortable adding in an additional page layout for one department’s view of Accounts.  However,  when I look back a week later and see all of their small request have now amounted to 10 fields, 5 workflow rules, 4 page layouts, and us going over on hours, I realize I can’t always say yes.  As an internal Salesforce Admin or Developer I find scope creep is something to get excited about.  It means more work and responsibility.  As a Salesforce Consultant, scope creep is your worst nightmare!