Your boss comes up to you and says the Sales organization is implementing Salesforce.com and gives you the standard two step methodology:
- Suck it up
- Get it done
Below are some things to consider to add a bit more detail to the process. A business executive told me once that strategy is easy, but execution is hard, so please consider these as tips rather than a methodology that guarantees success.
Fortunately, your boss has selected Salesforce.com, a technology that does not require a lot of IT knowledge like setting up Windows 2003 and configuring Oracle. Salesforce.com is easier than most systems to implement, but basic project management and business savvy has not been made obsolete.
Work Breakdown Structure (WBS)
Create a Work Breakdown Structure that lists what you are going to do to complete the project. Informally, it can simply be a list in Word or Excel. Formally, there are standard rules and diagrams as described in this Wikipedia article. Here is also a link to a Salesforce.com specific example I created (It’s just an example and not meant to be comprehensive). Unless your project is very large, strict adherence to the rules is not necessary. Powerpoint’s Organization Chart SmartArt object is a very easy way to create WBS diagrams.
Create a schedule or timeline of activities derived from the WBS. I say “derived” because it does not have to be a mirror of the WBS. Informally, it can be an Excel spreadsheet or your favorite calendaring application. Formally, you can create a Gantt chart. Here is the Wikipedia article and a Salesforce.com example. Microsoft Project is probably the most popular tool for creating Gantt charts, but it is expensive. My example was created using easyprojects.net which is a cloud-based online application.
Gantt charts have a feature labeled WBS, but it is not necessarily the same thing as the WBS mentioned above. Very large projects may require them to be identical to reduce confusion amongst numerous team members, but it is probably overkill for smaller projects.
Depending on your corporate culture, the WBS and schedule might be considered a promise or a negotiation. Hopefully, you can set the expectation that they are tools for communicating between team members and can change over time as new issues are identified and prioritized. Your success should be measured on whether the business goals for the project were met and not as much on hitting all the milestones. A bit more on business goals later.
The first thing you probably thought of was about storing sales pipeline data in the system. Salesforce.com uses Objects which is Salesforce.com lingo for database tables and the features that support the tables such as custom page layouts. One technique for identifying the data is by looking at existing reports. Many times they are Excel spreadsheets that the sales people built over time to help manage their efforts. You will need to be selective, however. There is likely all sorts of data that is not being used, but never removed.
So how do you figure out what data you really need? Underlying all of the reports, spreadsheets, and other data sources is some sort of process. Your lucky if someone can clearly articulate what the process is. Processes tend to evolve over time without anyone really looking at the big picture. Now is the time to figure out what your process is. From there, you can identify the data that is needed to support the process. It is iterative, though, because the existing data will contain clues to what the process is.
Salesforce.com supports the sales process with the Opportunity Pipeline Business Process. It is really just a field (called Stage) that contains the steps of the sales process, but has additional support. Specifically, there are pre-defined Opportunity Pipeline reports to determine if you have enough business lined up to meet your sales goals. This field also tracks the date and time of Stage changes. Once you have enough data stored, you can run a report that will show how much time each Opportunity sits in each Stage. This can help identify the bottlenecks in your process and, thus, lead to process improvements. This field also supports Record Types which is a way to define different processes in case you have different sales teams that use different processes.
Somewhere through all this you are going to wonder just what you are trying to accomplish. In an ideal world, the business goals would have been defined at the very beginning of the project. Many times this is not the case. Sales managers are successful because they do their sales and team management roles well. Being a process engineer probably was not a focus for them. But they do realize that something needs big improvement, do not really know how to fix it, but believe some sort of system is the solution.
It is now up to you to figure out what is wrong and how to fix it. Your success will be based on this in two ways. First, if your boss does not see any business improvements, you have failed. Second, if the new system is not better than the old system, no one is going to use the system.
Traditionally, you would do a “business analysis” with lots of diagrams, sketches, and other documents and hash them over in endless meetings. This was necessary because implementing the solution took a long time and was very expensive so it could only be done once, maybe twice. However, it is very difficult for people to visualize a system from diagrams in order to give you the feedback you need to identify what the real business problem is.
Fortunately, your boss chose a system that is very quick to iterate in real time. Salesforce.com’s “clicks, not code” approach makes it very easy to create strawman solutions and get that valuable feedback. To build your first strawman you probably will still need a requirements document (typically a spreadsheet of features and process outlines), but iterating from that will be very quick relative to traditional systems.
Don’t get me wrong about business analysis. The laws of physics did not change just because Salesforce.com came along. Professional business analysts bring:
- Experience in multiple implementations and knowledge areas
- An understanding of the bigger picture for a higher quality implementation
- Project management skills to drive progress
- Learning curve advantages for a faster implementation
Salesforce.com’s ease of use has simply increased the velocity of implementations.
User adoption is probably the best measure of your success. As mentioned before, if you fixed the real problem, most people will use the system. However, sometimes you have to get people out of their old habits. Active executive engagement is one of the best ways to get people to use the system. This means you have to give the executives something to be active with. This usually means metrics.
Before you can achieve improved business metrics like reduced cycle times, you have to get user adoption first. A frequently used metric is number of recent logins. You can also measure the amount of data entered, such as the number of accounts, contacts, opportunities, and activities created. None of these measure the quality of the data. Business results are the true measure of quality, but one technique for something like quality is to count the number of important fields that are filled in. A more labor intensive way is to performed audits of a sampling of the data.
I hope that these tips help you understand the scope as well as the detail of your implementation. On one hand, it is more than simply “setting up the system.” On the other hand, this particular application makes it much easier than in the past.
Please use my Contact page for any private questions.
P.S. Online Training
Also see Salesforce Video Training and Tutorials.