• SalesforceChaCha
  • Posts
  • πŸ’ƒ Salesforce Consultants - Tips and Tricks For Onboarding to a New Project πŸ•Ί

πŸ’ƒ Salesforce Consultants - Tips and Tricks For Onboarding to a New Project πŸ•Ί

It Doesn't Happen Often, So Do It Right When It Does!

Good morning, Salesforce Nerds! Are you a Salesforce Consultant (or want to be a consultant)? Are you getting onboarded to a new-to-you project? Congrats πŸŽ‰ ! It’s exciting and every consultant will go through this!

It can be a scary πŸ‘» experience too . Unfamiliar people, unfamiliar processes, unfamiliar Salesforce org.

But it doesn't happen too often. The Salesforce Implementation Partner's size has a lot to do with it. If you are with a big shop, you will have big clients and may not change projects for a year or more. At a small shop, an engagement may only be a few months. Changing projects is not a super common occurrence, so it's good to have a reference.

Well, that's what we do here at the ChaCha! Sit back, relax, and allow us to do the thinking for you! 🧠 

salesforce

Agenda for today includes

  • Salesforce Consultants - Tips and Tricks For Onboarding to a New Project

  • Daily Principle

  • All the Memes

Quick Note - Please be sure to refer your fellow Salesforce Professionals. You do this by scrolling to the near bottom of the email, then copy/paste the referral link, then send to your friend!

Please, be SalesforceChaCha's Oprah! You receive a FREE 2019-2023 Salesforce Professional Salary Guide with just ONE referral!

salesforce

Salesforce Consultants - Tips and Tricks For Onboarding to a New Project

Let's get the easy ones out of the way first, 3 of them, but give them a shot of those tasty ChaCha insights -

1) SOW

Duh. The SOW gives us our guardrails, defines deliverables, and states the original timeline and budget agreement (so maybe you can check the current state and not ask embarrassing questions about a blown budget/timeline.....). The SOW. What better to start with πŸ™Œ !

2) Status

This can apply to a lot of things. For this situation, let's make it simple and binary - Pre-Prod or Post-Prod

Pre-Prod - users are not ❌ using the solution. It is in a state preceding LIVE .

Post-Prod - users are using the solution βœ…. Everything slows down 🐒 for the project team. EVERYTHING. You do not want to be the person responsible for negatively impacting users in a live environment ☠️. You don't wanna be the person who caused a flood of trouble tickets and angry managers 😑 looking for someone to throw under the bus 🚌 .

The considerations you must make in a Post-Prod environment are so numerous and wide-ranging....maybe someone should write about that....πŸ€” 

3) Project Docs and Artifacts

Who owns these, client or partner? (should always be client, but...clients gonna client 🀷 )

Are they visible and accessible? To who, and why, or why not?

What is the intent for the docs? Are they actually being used to document design decisions and client validations? Are they 5 iterations behind, and useless as design specs? What is the plan to update them? Is documentation billable work for the consultant?

Alright, let's get to the juicier πŸ§ƒ items and with that same 3 count and shot of insightfulness!

1) Is the Client Nice?

This is a good one to lead off with (internally, obviously). How the person responds is very telling about the environment you are about to be in.

The nice-ness of the client matters. It matters a lot. A nice client provides slack and buffer. They nurture good sleep for the consultant. It makes long engagements tolerable and even enjoyable. If you have a nice client, count your blessings and treat them like the saints πŸ‘Ό that they are.

2) Client's Technology Stack

We are here to implement Salesforce solutions. Rarely does a client have a standalone CRM with no integrations or manual business processes that are impacted by a Salesforce project. We must consider the client's tech stack.

It can be as complicated as Eloqua, Sales Cloud, Mulesoft, a BI tool, a payment app, and an ERP πŸ˜΅β€πŸ’«.

Or it can be as simple as Pardot and Sales Cloud πŸ˜ƒ .

Not only will they be entirely different experiences for the project team, you will need more knowledge, skills, and abilities to do well in the more complicated stack.

3) Who is Responsible For Data Work?

Need we say more? If you are reading this and have not experienced the job of deep data work, you are a have-not. You should jump on the next opportunity, it will change your perspective on data and you will be a better Salesforce professional.

Anyway, ensure this is either decided or being discussed. It's always the client's choice, and it's gonna cost the client money either way. It is important not to avoid this tough convo. As a new project team member, it is important to know who is responsible for doing the data work πŸ™ .

Daily Principle

"The man who does not read has no advantage over the man who cannot read." - Mark Twain

and now....Your Daily Memes

salesforce
salesforce
salesforce

What did you think about today's newsletter?

Login or Subscribe to participate in polls.