When implementing new technology in your organization or expanding your existing system, a little bit of planning can go a long way in ensuring the success of your project. Planning the project well and having subject matter experts and/or experienced project managers can help the project move smoothly. Every project will have bumps in the road, but below are some tips that will help smooth out the bumps.
Caution #1: Run your discovery sessions well.
Now is the time to sit down with the main “sponsors” of the project (whether it’s the executive committee or a small team of people within a department) and your client team to make sure you fully understand what your teams needs. Allow your team to do a “brain dump” of their ideas, pain points, and needs. Don’t focus yet on the technological solution; just allow them to talk about their processes or desires, or even allow them to vent for a few minutes about what simply doesn’t work for them. Allow the conversation to be organic and go in its own direction, but don’t miss an opportunity to ask follow up questions. You may hear a tiny little factoid during a conversation that is crucial to the implementation. Also make sure you have documented those “exceptions” that always pop up every now and then. Sometimes the exceptions aren’t worth planning around, but sometimes they are.
After the “brain dump” is finished, the questions are answered and you have a clear idea of what your project will look like, take some time to categorize the requirements of the project. Categorizing your requirements will be especially helpful if the project has limited resources or you must plan the project as a phased implementation. Categorize your requirements into the following headings:
A) Must Have
B) Like to have
C) “In a perfect world”
After your discovery is done, after the requirements are categorized and phases are discussed and agreed on, work with your project manager to write down your discovery findings. The document can be a written narrative of how the project will proceed or it can be a list of requirements or a statement of work. Make sure to put down as much detail as possible and make sure that the team agrees with the document by having them sign it. The discovery documents can and will become invaluable later on in the project if there is a misunderstanding or confusion about a piece of the project.
Caution # 2: Don’t just add something because someone requested it.
A member of your team has asked you to add a new business process to your Salesforce system because he or she has been tasked with moving a current business process from existing Excel spreadsheets or paper forms into Salesforce. You have conducted a discovery session and the team member is absolutely insisting on a specific design. Time to go to work. Or do you?
Just because something sounds good to a user doesn’t mean it should be in the system. Before you start adding new custom objects, page layouts, fields, workflows, etc, take a step back and make sure that needs are not already addressed in the current system configuration. I worked in an organization that implemented Salesforce on a small scale at roll-out, but during the initial discovery phase had actually talked with several different departments. If this is the case with your current project, check into the following before adding new customizations:
- First and most important, make sure a clear business reason exists for adding the new customizations. Just because someone wants to use Salesforce for their day-to-day business processes doesn’t make it a good choice, especially if you are being asked to add new customizations to an existing system.
- Perhaps Salesforce isn’t the best place to track certain information. The organization I mentioned above actually worked with a legal advisor about some of the information that was going to potentially be tracked in Salesforce. In the end, for clear legal reasons, certain information was kept on paper in file cabinets rather than tracked in Salesforce (even security settings couldn’t hid the information well enough). If in doubt, ask advisors in other departments (i.e. legal, human resources, IT, etc.) if the information should be there or not.
- Make sure that the configuration the client is asking for doesn’t already exist. Were this particular client’s needs or requests actually implemented prior to the current project and the client wasn’t told about it? It doesn’t take long to check and you may save yourself and your system some unnecessary overlap.
- Check into the security settings, especially if the customization being asked for already exists. It’s possible the user just can’t see the object/fields in question or maybe they don’t know where to look (i.e. maybe they are looking for a related list on Accounts and it is attached to Contacts instead). If the customization exists, meet with the user to discuss what’s there and make sure it will meet their needs. Maybe all that is necessary is some minor tweaking.
- Once you decide to go ahead with the project, work with your system administrator to design the system architecture (i.e. page layouts vs. field level security). Design choices that make sense now could be disastrous later on. Make sure your solution is scalable and sustainable long term. It’s also a good idea to document your decisions. A new project later on could make you question why you did something a certain way on a previous project.
Caution #3: Make sure you get the information back out again.
The great thing about a CRM system like Salesforce is that you can pretty much track anything you want; however, getting it back out again may be a problem if you don’t plan the design right. Discovery sessions are the perfect time to ask about any reporting or dashboard needs your team has. Make sure your team has examples of existing reports that they need duplicated or if asking for new reports, make sure to document a design that includes the results they need. Draw out a design on paper of what the report should look like. A conversation about reports/dashboards may yield more design decisions you haven’t previously documented. If the team says they need to report data in a certain way, you may find that some of the fields needed to calculate the report weren’t included in the original design. This could lead to even bigger discussions that may lead to more design decisions that could lead down an infinite number of rabbit trails. In a previous project, the reports were not given to the implementation team until about half way through configuration. Once we saw the reports, we had to halt the project and redesign about half of the configuration we were doing because the original design would not support one report that was most crucial to the client. We spent countless hours doing more discovery, redesigning the system, and changing configuration. Do yourself a huge favor: require the team to provide a list of reports (examples are even better) and settle on the report design as part of the discovery phase. In project management, there is a statistic that for every 10 minutes you spend planning, you save yourself an hour of re-work later on. The Discovery phase of a project can be the most valuable time you spend on a project.
Caution #4: Plan security and workflows before you start configuration.
Sharing rules and workflows rules may be critical to your project design. Perhaps sensitive financial data may need to be protected from the marketing team or the sales team needs to see only Accounts/Contacts in their territory. Salesforce provides may security options (field level security, sharing rules, territory management, just to name a few). Your system administrator will be able to provide you with the pros and cons of each of type of security option and help you plan a solution that is best for your project as well as the overall system architecture. Here is some information about why system administrator profiles may not be for every user and here is more information about security in Salesforce.
Caution #5: Test, Test, Test
I can’t stress this point enough: try your very best to break the system during testing before a the end users get their hands on it. Test the configuration yourself, ask a colleague to help test, test the exceptions you documented in your discovery that you decided were important enough to plan around. Test workflows, security settings, reports, data entry, anything you can think of.
If you have access to a sandbox, always do your configuration/testing in a sandbox. Keep track of Salesforce upgrades. If you are working on a project that will not “go live” prior to a Salesforce upgrade, I think it’s worth it to make sure your sandbox is upgraded during the upgrade preview phase and test your configuration against the upgraded version (a caution within a caution: NEVER push configuration from your sandbox to production during the production upgrade windows. Check with your system admin to get these upgrades windows and account for that when planning your project schedule.) Testing in an upgraded sandbox may yield issues you hadn’t considered previously or the upgrade may contain functionality that may be an asset to your configuration. Sandbox are also great environments to train new staff on. They can try out the system without damaging your production environment.
If you heed these 5 cautions, you may not get a perfect Salesforce project implementation, but you will be light years ahead of where you may have been!
