10 Mistakes & Things I wish I knew as a Salesforce Consultant!

The world of Salesforce consulting is a highly complex and rewarding career path. As my 10 Admin Mistakes post did so well, i’ve decided to do the same, but this time as a Salesforce Consultant. When the first consultancy I worked for was no longer an option I went on the hunt for another role. My options at the time were fairly limited, I was either going to down the Salesforce Admin route working for an end user, or go down the consulting path working with lots of different clients. If you’re unfamiliar with the consulting role in the world of Salesforce, then Trailhead has a great page here which provides an overview. As you can probably tell by the title of this post, I chose to become a Salesforce Consultant. 6 years on, I am going to share with you 10 mistakes i’ve made personally in my career as well as things i’d wish i’d known to date.

In every consultants armoury should be the ability to say ‘No’ to things, especially when the things being requested are not within scope of your project. How many times have you been in a meeting with the client and they’re asking for all sorts of outrageous requests, which will likely take you a lot of time and effort to check if they’re even possible? I can guarantee every consultant has been at least once. It’s very easy to say ‘yes’ to these things, especially if you have a good rapport with your client, you feel bad for saying ‘no’ and this shouldn’t be the case. Clients like to be sneaky, try and squeeze pieces of work in for free, and why shouldn’t they? If you’re saying ‘yes’ to everything then it’s a no brainer. If you establish upfront and early within your project you’re not going to deviate from the deliverables agreed then your client is less likely to even try. You will be the project managers and sales teams best friend if you get in the cadence of saying ‘no’, believe me, you don’t want to be at the wrath of either if you say yes to something which wasn’t agreed!

This is of course dependant on lots of variables, such as contracts, statement of work, which type of project you’re delivering, agile vs waterfall etc, but the point is don’t be afraid of saying no to your clients and your colleagues. Saying yes to everything and then not being able to deliver something is a lot more frustrating than saying no up front, and you’ll get more respect for doing so.

Next time you’re in a meeting, just think to yourself, can I actually do this in the allotted timeframe? and is it within scope? if the answer is no to either, then say no and go about it through a change request or assign it to another sprint (if you’re lucky enough to be on a pure agile project).

This might seem controversial, taking away the one thing we’re delivering and are skilled in, but there’s a reason behind it. Since I had the opportunity to join IBM my eyes were open to a whole different way of understanding clients business requirements and problem statements. Very often when we’re running discovery sessions with a client and trying to understand the business, If you’re like me, your brain is constantly ticking thinking already of the solution, which can sometimes sway designs or the way the client is thinking. Now let’s take Salesforce out and just focus on the client.

There’s a popular method of requirements gathering called ‘design thinking’, which is practised by some of the largest organisations in the world (Apple/Google) to name a few. By doing this, you take away the technology, there’s no limitations, you focus on individuals and their needs/wants/problems which allows you to gain a deeper understand your business challenges in turn allowing you to design a much better solution. Design Thinking is an art in itself, but I have found running these sessions with my clients, you gain a much deeper understanding and get much better outcomes for you to base your use cases and requirements on.

If you’re interested in learning more about design thinking there’s hundreds of articles and content on Google that explain it in more depth for example here. This is a great quote from the CEO of that website:

“Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
— Tim Brown, CEO of IDEO

If you’re implementing smaller projects, this approach may not be as relevant, but for the midsize and enterprise level, it’s great, and a proven success alongside the agile methodology.

As a consultant early in my career I was always afraid to challenge. No, I don’t mean that sort of challenge..

I mean challenging both clients and your colleagues. If you don’t feel that something is right, whether it be the solution being proposed or something your client is suggesting then challenge it. I often felt that because I was inexperienced, people wouldn’t value what I had to say, but this isn’t the case. You’re the Salesforce SME and your clients and colleagues respect that. You’ll appear much more confident if you’re challenging rather than sitting there and not saying anything. It’s all part of the learning process.

As well as challenging you should be asking why? You’ll often find that clients are following process that someone set 20 years ago and they’ve never actually been asked why? So it’s never changed. You’re much more likely to get to the bottom of a requirement or unearth new ones if you’re challenging and asking why. Expect a lot of ‘that’s just the way it is’ answers and ‘I actually don’t know why’ but this will allow you a foot in the door to change that process.

If there’s one thing I’ve learnt during many of the implementations I’ve completed during my career, it’s that change management is just as important as actually delivering Salesforce. It’s very easy as consultants to go in, deliver Salesforce and then leave, just to find out 6 months later that all your hard work isn’t even being used. Clients are often very reluctant to change, they’re used to their current process and you’re coming in and upsetting that, that’s why we have to be mindful as consultants. User experience is key. You might design the slickest Salesforce solution going, but if clients current process is easier, or does something which your solution doesn’t, they won’t use it.

There’s so many great ways to get users to adopt Salesforce and I’ve been very fortunate to work with some great change management consultants during my career. From gamification, to user champions, to e-learning such as MyTrailhead and many more. It’s important also to have the business buy in. Some clients prefer a bottom up approach in which people lead by example in the hope that management catch on and see the benefit, whilst others prefer the top down approach ensuring that Salesforce is being used at the top level which then filters down. I’ve heard a few times, ‘If it’s not in Salesforce IT DOESN’T EXIST!’.

As consultants it’s often not our responsibility if the client uses the product or not, but it’s something definitely to be mindful of when you’re delivering. You gain much better satisfaction know all that hard work you put in is being used and fulfilling it’s purpose.

When I first started delivering Salesforce, DevOps was non existent. I was deploying via Salesforce changesets and spending countless hours trying to navigate errors etc. If you’ve ever used them you know what I’m talking about.

Now more than ever DevOps is an integral part in delivering a Salesforce implementation. I’ll admit, understanding DevOps fully is still an area in which I am learning, but one which I find so fascinating. If you’re unfamiliar with the term DevOps then Salesforce has some great trails on Trailhead here. It’s essentially all parts of Salesforce development and how everything which we configure is packaged up, tested, and pushed through various environments before ending up in its final production format. DevOps simplifies the deployment process, allowing developers to developer and configure simultaneously without overwriting each other. This is a great info graphic from the above Trailhead:

There are various DevOps tools for Salesforce Copado/Azure DevOps to name a couple. Finding the best tool for you will always be dependant on your needs/wants, but these two are widely used.

So, if you’re unfamiliar with DevOps and are still using changesets to deploy your Salesforce code and config, get familiar, it’s an essential skill I believe every Salesforce professional should at least be aware of going forward. It will be a learning curve but DevOps is a skill which can be applied to all development lead technologies and will be a very valuable skill to have on your CV.

When you become a Salesforce Consultant it’s easy to step back from Salesforce configuration. This may be different depending on lots of scenarios, whether you work for a smaller consultancy or larger consultancy, which type of projects you’re delivering for example. From my personal experience, when you step into a consultancy your role changes, especially if you’re coming from an admin role. Administrator roles are very hands on, you’re working often as an individual or in much smaller teams to delivery Salesforce for your business. But as a consultant you’re working in larger teams, your focus shifts from being hands on to being responsible for the business requirements and dealing with all things delivery, whilst your development team focuses on the hands on pieces.

For this reason, it’s easy to fall behind with the art of the possible. It’s essential as consultants we know what is possible with the Salesforce platform in order to propose the best solution for our clients. In order to do this you have to be prepared to devote some of your personal time/time outside of work to doing things such as taking certifications, getting your Trailhead badges and even just reading the condensed release notes from each new release. By doing this you’re best placed to help your clients. I’ve been in many scenarios where a solution has been proposed and then in the release notes from Salesforce they’re releasing a much better standard solution to the problem. Then you need to decide is it better to wait for that release (if the client is prepared to) or you go ahead with a custom solution (it’s usually better to wait).

Takeaway, keep on top of your configuration skills, it’ll help your career in the long run and you’ll feel more confident as a consultant suggesting solutions.

I have a fairly strong opinion on Salesforce certifications based upon experience working with many Salesforce professionals. But, I had a good conversation with another architect the other day and it made me think. Certifications should act as an acknowledgement of skills which you have experience of. What do I mean by this? There is SO much material out there on each of the current Salesforce certs, which means anyone can begin learning Salesforce and take a cert without ever even experiencing a real scenario of implementation. For example Community Cloud Consultant (picked at random), I could get that cert, having never implemented a single community, and never planning to, but then on my CV it appears i’m knowledgeable in that area.

Don’t get me wrong, I think Salesforce certs are a great thing to get and I appreciate the dedication and time which is required to gain some of them. But, in my opinion you should have at least one real implementation under your belt before attempting an exam. I’m speaking from personal experience, when I first started as a consultant I thought exams were the be all and end all. If I didn’t have certs nobody would hire me or I wouldn’t get put onto projects. This turned out not to be the case. I’m talking more about the specialised area and consulting exams here. Exams do not and cannot focus on all areas of a product, the challenges you will face, which is why I think it’s important to experience it before attempting the exam. As a consultant I felt much more accomplished after doing a Sales Cloud implementation then using that knowledge to contribute towards the certification.

If you’re completely new to Salesforce then I think some of the certs such as Certified Administrator are essential in todays market, and teach you the fundamentals required in order to start gaining that experience of other Salesforce products/clouds. If you’re taking an exam you can checkout my post here. Best of luck.

As a consultant your life goes a little bit like this. Luke we’ve got a 2 month Sales Cloud project coming up would you like to be involved? “Yes sure” Ok, workshops start in a few weeks, the project manager will be in touch. “Great thanks”. Then you begin workshops and get so involved that you don’t actually know what has been sold or promised to your client. I do believe as part of a successful delivery, there should be a handover from Sales team to the delivery team, detailing EXACTLY what has been sold, and what is the scope. Most consultancies follow this pattern, that way your delivery team knows what they should be delivering and if they have to deviate away from that how to handle it. This is also dependant on how your projects are run, as your client may purchase the discovery phase separately in order to build out that scope and timeline before prior committal. In this case you have a lot more freedom.

If this isn’t the case, then you should make it part of your role to speak to the sales team, rather than delivering blind and ending up getting in trouble with them or the PM. This point ties in with the first ‘Yes Yes Yes’ point. You’ll be in a much better place to have those conversations with your client if you know the contract/SOW as then you both know what you have signed up to and there will be less difficult conversations (you hope).

Your role as a consultant is to ensure successful delivery for your client. It’s very easy to get caught up in delivery and forget the fact that people will be using this product, with probably little Salesforce experience. Because we’ve been doing it a while, complex solutions seem a little less complex. You should always have the client in the back of your mind during delivery, if you were to take away your Salesforce experience, how would you find the usability? and this is a difficult thing i’ve found to do personally. Then you come to training your users and you start getting feedback such as “this is so complicated” “this is more difficult than it is now” and these are major red flags, because they simply won’t use it.

Since joining IBM i’ve realised how important UI/UX is in any project, not just Salesforce. With Lightning pages/LWC/Flows this is ever easier to achieve. When I first started using Salesforce it was classic and you had very little control over how things appeared. Luckily, I think Salesforce realised this and is becoming ever greater towards flexibility in that area. One tip I have found very useful in current project is wireframing. I did an article on this here. By wireframing and agreeing UI/UX up front, it ensures delivery is a lot smoother.

Always put yourself in your clients shoes and try understand where they may be coming from. This is a great skill as a consultant.

Every consultants favourite topic. User Stories. I will put money on anyone reading this (thanks for getting this far) if you have worked on a Salesforce project you will have seen some woeful user stories. I mean the ones you look at and go:

I could write about user stories for ages, and they probably warrant their own post, but please for the sake of everyone working on a project, make sure the stories as well as the acceptance criteria are at least good if not excellent. Stories should be technology agnostic and should not include the solution within them. You should be following the simple, As a.. I need (or want).. So that.. for the story and Given.. When.. Then.. for your acceptance criteria. This creates nice clear user stories, which can then be solutioned accordingly. You should be designing these stories with your clients/product owners to ensure that all the basis are covered. There is lots of great content online around User Stories/Acceptance Criteria which go into the subject in a lot more detail. Here is a good article explaining the basics.

As well as ensuring they’re clear, if you have larger stories, split them up into more manageable chunks. This will be a lot easier to manage. Depending on how you’re sizing your stories, if you’re t-shirt sizing for example, a M/L story can likely be split into smaller chunks or if you’re using fibonacci everybody might become a little scared seeing a 34 pointer in the backlog. Just be mindful of your development team.

There we have it. 10 mistakes and things I wish I knew as a Salesforce consultant. All of these points are based upon my own personal experience and opinions, which could very well be different to your own. If at least one of these is relatable or helps you then that’s great. I’d love to hear from you via my socials in the top right if you have any other experiences or found this article useful. Thanks very much for reading.