Salesforce Project Mobilization
The period after a budget decision has been made and before work starts is critical to a project, and I like to call that period mobilization. Here are 5 things you can do to nail mobilization, that will allow you to hit the ground running with your System Integrator (SI) or implementation partner.
1. Project Vision Statement
At a minimum, you need a project vision statement that says in no uncertain terms what you want to get done, when exactly it must be done by, and most importantly why you are doing it. If you can’t state this in 24 words or less (seriously, 24 words), then your vision isn’t clear enough yet, so spend a little time and get down to a statement that will serve as a northern star for your team as they trek through the details of the journey. This must come from the executive level, where the budget decision was made and the original objectives were clearly understood (or should have been).
Example: On Sept. 1, 2019 at 8 am, Salesforce will be our source of truth for Sales and Marketing, in order to increase customer retention.
If I am reading that as an employee, I can easily understand the executive expectations, how it might impact me, and can avoid asking the common speculative questions such as “Are they trying to eliminate my job?” because I can clearly see the why of the project as increasing customer retention. If you are actually hoping to cut costs as part of the why for your project, be transparent about it in your vision statement. But understand the implications of people getting fearful and potentially undermining the project – you will need to address this head-on, and explain a plan for how hiring will slow while growth continues, and over time the cost reduction will be achieved. Don’t leave any room for speculation about your intentions or the plans to achieve those intentions.
2. Team charter
Your project team should be 4-7 people that will represent all stakeholders of the project. Get them together now, before the project starts, and make sure that they all know the constituencies they represent. Ensure they have the time to dedicate to the project each week, so that they can do a good job. Then document the team with the Name of each team member, their role, and the constituencies they represent. This charter should be sent out internally to everyone even remotely touched by the project, so that they know who to go to if they have questions about the project, want to provide important feedback, or need to raise a concern. Ideally, on the team you have one project manager, that is not a member of a specific SI (either someone on your team or a third party) that will own the project. You also have an SI lead for the project on the team. This leaves 3-5 slots to be filled with whoever can best represent the various business units and their needs. The executive sponsor is not a member of this project team, but the project manager reports back to them for any decisions on scope/schedule/budget.
3. Scope Discovery
What do you mean no one planned an integration for us? Turns out marketing has been using a different system to manage leads than the rest of the company. Whoops. Does that need to be integrated? How did we miss this? The answer is no one asked. So how do you avoid this? Good mobilization. You have a project vision statement, so now your project manager needs to ensure all stakeholders hear that vision statement, understand it, and provide feedback on what they believe that means in terms of scope. For example, “On Sept. 1, 2019 at 8 am, Salesforce will be our source of truth for Sales and Marketing, in order to increase retention.” is a pretty clear vision statement. The project manager should ensure all stakeholders hear this, and provide their thoughts on scope. For example, customer service might want to highlight that they play a big role in customer retention and if customer data is in a new location, they will need to be in that system as well or have an integration to the customer support system. The clear vision allows stakeholders to talk about the future state and its implications with the PM, which means when the SI gets involved the PM already has questions to ask them in order to make key business decisions. What is the impact of integrating customer service vs moving them to the new platform? The project manager can then take multiple options back to the executive sponsor and they can decide if they want to increase the scope of the project to include customer service, tell customer service that they will have to live in a silo and ask them to start planning for that reality, etc. But the executive sponsor has the data to make a decision up front about the direction of the project and there will be no surprise later when that decision impacts the project. So many gotchas can be avoided with this simple exercise in good project management discipline, during mobilization.
4. Get your docs in a row
Most companies outside of very early startups have some form of documentation. Even many startups have something. You need to ask all the stakeholders if they have any documents that cover the processes that will be affected by your project, and/or any examples of how it is being done today. So much time is consumed by expensive consultants going around and collecting this information themselves, and if you can provide it up front, consultants can use their costly time to provide much greater value. What documents should you ask for? Process diagrams, schemas from any databases you are using today, training documents that explain how salespeople should work and update leads customer information, slide presentations from an executive retreat where a new commission structure was decided, google docs where a customer service manager has been taking notes on inefficiencies of the current support model, and so on. On most projects, I find these documents after hearing from various parties they don’t exist. Look harder. There is often far more already documented than you realize so ask clearly for any artifacts that will allow your partner to see into the current state of these processes and organize that info by process and stakeholder group. For example, your file should have a folder for “Sales Process” and inside that folder you would have folders for the different stakeholder groups that provided you documentation, with the documents in each group. This way, it is easy to get a picture of the various perspectives on a given process and understand where there are holes that need to be filled. Sales might have on view of the sales cycle, while sales ops might have a very different perspective on what it takes to close a deal. Your SI needs these perspectives, and the less legwork they do collecting that information up front, the more value they can provide.
5. System Access
When you purchase licenses from Salesforce you get a welcome email. You need to use that email to log into the system, and create a user for your partner to access your org. Alternatively, you can ask your partner to create a free trial org and start work there while you finish up the last negotiations with the AE and get everything signed (pro-tip, this can save you a month of subscription cost, just make sure the AE has the org ID for your trial org so they can activate it once you purchase). But not having access to the system will be an immediate roadblock for your team as you try to get the project up and running. Another thing to think about is getting your partner access to legacy systems so that they can see old processes and data structures. You might keep this to a limited permissions structure, but it’s another way to get things rolling fast.
Conclusion
If the above items sound like absolute basics of project management, it’s because they are. And yet through hundreds of implementations, I have rarely seen a company execute on these items effectively, even after being asked to do so. Ideas are praised, but execution is worshipped. Companies that execute on the above items, and don’t disregard them as mere “good ideas” will see vast benefits throughout the rest of the project.
