Talent Hub recently spoke with Richard Clarke, a vastly experienced Salesforce Specialist and Principal Consultant of FuseIT to define the common pitfalls of Salesforce.com projects. Richard has been delivering Salesforce implementation since 2007 so has a great understanding of the do’s and don’ts. To find out more about Richard you can view his profile here – https://au.linkedin.com/in/richardaclarke
Here are Richard’s 10 top tips:
Define a Clear Roadmap
- Not knowing where you want the journey to end guarantees you won’t end in the right place.
- When you want to arrive is almost as important and where you want to arrive.
- The end result is usually bigger than “just” CRM (consider all the relationships which need management).
- Be clear about which business capabilities need to be supported or enhanced with Salesforce.
- Don’t transfer fractures in organisational structure into Salesforce – share common customer data.
- Stay abreast of Salesforce’s own roadmap.
Define Clear Program and Project Requirements
- Define strategy (the “why”) and required business outcomes (the “what”) before considering the “how”.
- The “what” has to be measurable as this defines success.
- Having key stakeholders including operational managers express and approve requirements is critical.
- Don’t leave thinking about reporting/analytics until last.
- Consider security upfront – both who can see what data and who can perform what functions.
Don’t do too Much at Once
- Multiple projects at once are hard to coordinate especially when multiple delivery partners are utilised.
- Doing two different things at once is three times harder than doing one thing at a time.
- Doing two different things fast at the same time is four times harder.
- Running multiple overlapped software development projects will increase the need for tight governance (processes and tools) to manage requests for change, development, testing and deployment.
Choose the Right Delivery Model
- Waterfall (all requirements up front), Agile (requirements clarified one short iteration at a time) or Fragile (requirements clarified through repeated experimentation).
- Agile does not mean being continuously vague and discovering requirements by endlessly building the wrong thing then fixing it.
- If you are not sure what you want or how to build it explore options using discardable prototypes.
- Use an internal self-managed agile team if your organisation has adequate software delivery maturity and available resources. Otherwise use an internal partner-managed agile team in preference to using an external remote partner delivering under a waterfall driven statement of work.
- Consider what the team needs to look like when you are finished and the delivery partners leave. Work towards that outcome throughout the project so those responsible for operational management have experience with the implementation details.
Manage Data Architecture and Data Quality
- Data quality will degrade without proactive steps to maintain it. Implement the platform’s tools to minimise duplicate customer data. Use validation rules to enforce a base level of data quality. Calculate a data quality score for key objects and use dashboards to drive behaviour.
- Don’t add data fields to objects unless there is a strategy to populate them.
- Make sure the relationships added between objects are done by someone capable select optimally between master-detail, required lookups and filtered lookups.
- Consider reporting and query/report performance early. Index text/picklist fields which are important for reporting by flagging them as an external ID. Ask Salesforce to add custom indexes to custom date fields if they are important data selection filters.
Know what Success Looks Like
- Develop a testing strategy and direct delivery partners as to what testing you require them to complete.
- Testing has to address the outcomes desired as well as the outcomes to be avoided.
- Recognise Salesforce’s 75% code coverage rule does not necessarily deliver automated tests which usefully determine if the system is working as it should.
- Software engineers usually make poor testers so resource the testing function appropriately.
Maintain Current Documentation
- Documentation needs to capture how the system works and how it integrates to other systems.
- Projects should provide documentation which explains what changed (and why) as well as how to reverse a deployment which causes problems.
- Keep information about system architecture current (what systems different user roles interact with and how systems integrate with each other).
Customise with Configuration Not Code
- There are many ways to achieve the same thing in Salesforce and use a coded solution last.
- Don’t custom code a user interface until you have tried the auto-generated user interface.
Choose the Right Operational Mode
- The composition of the optimal operational team varies depending on the size and complexity of the implementation. Include a developer in the team if they are expected to maintain custom code (vs custom configuration).
- Budget for ongoing training and incentivise team members to achieve and maintain current certifications.
- Use Salesforce Trailhead for self-paced learning which is both fun and easily measurable.
- Leverage operational assistance sourced from Salesforce Premier Support and Salesforce Partners.
Measure and Manage Levels of Adoption
- Define what KPIs matter and measure them.
- Ask executives to lead by example by being visibly active in Salesforce.
- Use Salesforce’s Chatter, Ideas, Q&A, and Portal functionality to keep the conversation alive.