Earlier this week I sat through a retrospective session for a complex Salesforce Implementation project we just wrapped up. The client gave us the NPS rating of 8.5 out of 10 (which I think is great). However, as we all looked back at the project, the memories of good, bad, and ugly were refreshed. And both sides made recommendations on what we as a Salesforce Development Organization and Client teams could do differently next time to avoid some of the pain points.

First thing first – why Salesforce?

You need to know the reason why do you want to go with Salesforce. Is it ease of maintenance, cost, time to market, etc.? Like any technology selection, do your homework on why do you think Salesforce is the right technology decision for you. Like other technologies, it has advantages and limitations. Make sure that you understand the true cost, benefits, and most importantly limitations of this platform. Discovering the critical limitations and additional costs during the implementation is not a pleasant experience. I have seen clients ended up going with the project because they started it and they have already signed a multiyear licensing deal despite knowing that the end product will always remain short on meeting expectations. Not a great feeling if you are the sponsor or the owner of the program.

How will you use Salesforce and what type of licenses will you need?

Understanding the clear role of the new Salesforce based system is critical like you would do for any enterprise system. It is important to list down the key needs the system should be able to meet. Based on that, figure out what Salesforce solution will make the most sense. There are myriad of choices Salesforce offers and it is not easy to figure out what you should go for. Having Salesforce product expert working with you to sort this out will be well worth the time and money you would spend on this.

Spend time on defining Enterprise Architecture with Salesforce in it

I truly mean Enterprise Architecture in its all-encompassing sense. You should know the impact on operational processes, people, and technology stack. Without knowing how Salesforce will co-exist in your business and IT infrastructure, you are very likely to struggle with the user adoption and the ongoing support that the system will need.

Define your integration strategy upfront

Do not implement Salesforce as an Island of its own. For it to be an effective enterprise application, it needs to share and consume data to/from other systems. It is important to layout the integration framework upfront so there is consistency, efficiencies in integration work the integration solution is built to scale. API integrations without an integration framework will not scale and will create maintenance issues soon after the product goes live.

Keep enough time for product Discovery and learning

It is very common for organizations to go through a slow and long funding and vendor selection process. However, once organizations have done that, they want to start the implementation/development right away. That sets everyone to fail. Not giving your development partner (internal or external) enough time to get to the speed on whatever technical decisions that were made in the past washes out the effort spent on that. The development team needs to go through product discovery and high level design and architecture which takes time. Besides, the product owner needs time to breakdown features into Epics and Stories, sit with the team to do program increment planning, understand the risks, etc. And if you are building a custom solution having the UX team get time on laying out end to end-user experience flows is absolutely a must.

What about enhancement projects?

If you have an existing code base and a new team is working on it for the first time, keep enough time for the team to learn the solution and code.
Bottom line, don’t short change the Discovery period. Those tasks will happen regardless. If you don’t do upfront it is a lot more expensive as you will be burning time and dollars with a fully loaded team.

Vendor Selection Don’t go with the bling and don’t give blind trust to the vendor Salesforce AE brings along

The best feedback we received (informally) was from a client manager involved in vendor selection where we did not receive the project. We made it to the final two vendors. I was told that though our RFP reply and the proposed solution was perhaps far superior to the competing vendor, the other vendor came with over half a dozen salespeople and had a lot more bling factor. The competing vendor was also brought in by the Salesforce AE and said what the client wanted to hear on the schedule. I didn’t blame the client as they didn’t know any better. At the time I told our team not to worry as they wouldn’t be able to deliver what they are saying and the client would come back to us. That’s exactly how it happened.

Here are a couple of takeaways when choosing a vendor:

1. Ignore the AppExchange status and the bling that doesn’t deliver the project. I know it is hard but must do that. All projects are different and the success depends on the expertise of the vendor specific to your area and the team members that will work on it.
2. Ask about the team members who will work on the project. There aren’t many Salesforce technical experts with enterprise application background. It doesn’t matter who the vendor is if they put a Salesforce lead on the project with no experience in an enterprise setting. Even the largest Salesforce partners don’t necessarily have the right guys available for you.
3. Don’t go with the vendor who says what you want to hear on schedule and time. You are likely to pay more and take much longer with those vendors during the life of the project. In fact, don’t twist the vendor’s arm to hear what you want them to say.
4. Client references are useless. Instead, review their case studies in detail and have design/architecture/program management discussion upfront.

Have the people with the enterprise application background for the key roles

I always say that if you are building an enterprise solution on Salesforce, have the guys in program management, product management, architecture, and technical leadership roles that have worked on enterprise application development and rollout. It is true for other technologies and it is indeed true for Salesforce as well. Most Salesforce developers that I come across have limited experience with large applications.

To emphasize this point let me share a story from late 1999/2000 where a client spent millions on developing a J2EE portal. The vendor at the time used intelligent, JAVA certified but inexperienced individuals on the project. The end result was that the new portal was developed that wouldn’t even work for 20 concurrent users. A lot of refactoring was needed to salvage the multi-million dollar effort.

I see a parallel now people reaching out for Salesforce Certified developers and Architects. Truth is that anyone can get Salesforce certification like anyone could do JAVA certification back in 1999. It doesn’t mean they are qualified for large system design/development.

Salesforce products knowledge is a MUST but it isn’t everything

It is a must that you have team members (at least the leads) who know Salesforce capabilities and nuisances very well as that is needed when building a solution on Salesforce. However, that itself is not enough. Developers/Leads should have good experience in design patterns and best practices, coding best practices, experience with system scalability, performance, security and other non-functional requirements, integration frameworks/packages, Agile development practices, and DevOps practices.
I see young Salesforce engineers in our team who tell me that they have it all it takes to build any solution on Salesforce. I love their enthusiasm but their confidence reminds me of the multi-million dollar debacle I witnessed in the year 2000. That’s why I make sure that larger implementations have the experienced pros to increase the odds of success.

Use writing code as the last option

In Salesforce much of what you need can be done without needing to code. This is where the experience with Salesforce comes handy. For an engineer coming from traditional technologies like J2EE, every piece of requirements may look like a good candidate for custom code. Avoid the temptation “ ask the team few times why do we need to write code and what are the other options to implement.

Build an Agile way

I strongly believe that there is no better way to manage Software projects than Agile methodologies. You need to be able to build, validate, and correct as you go through the implementation. There is no other way. If you don’t know Agile, contact me and I would be happy to get you started with your Agile learning for FREE.

Don’t over-complicate the project

Simplify your project scope and build it incrementally. I tell myself, my team, and our clients that not everything in a Feature is a MUST have. Knowing what you can live without comes with experience. Don’t try to have feature overload and don’t try to build a seamless end to end solution from version 1.0. You would end up spending quite a bit of money and time and still not get it right.

Simplify your requirements. I would share an experience from my mistakes to make a point. In 2009 I developed a financial planning product that provided all kinds of financial simulations. The most amount of effort we spent was to factor in the impact of income taxes in future net worth due to various tax laws around expenses, types of income, types of accounts, and income itself. Though we tried to make it perfect, consumes didn’t understand it and didn’t care.

Enable communication across different systems teams

If you are working on developing an enterprise solution, treat the project as an enterprise program. You would need a program manager to coordinate the effort across different SCRUM teams. Create slack/skype types of channels for

1. Technical leads working on a different system upgrade teams
2. Test engineers across systems
3. POs. Setup weekly/bi-weekly SCRUM of SCRUMs and management updates meetings These best practices help tremendously with the communication and risk management.

Think about the user experience and adoption from the beginning

Even if you are leveraging the native Salesforce UI experience, engage a senior Interaction Designer/Information Architect to review and recommend the ideas for user experience. For custom solutions, you need to get the right UX roles involved from the beginning.

Accept mistakes, course correct and cut your losses

What is true for other software development projects is also true for the Salesforce Implementation “ team will make mistakes and wrong decisions. The key to success will depend on how you would handle it. Keep an open mind to refactoring, course-correcting your decisions, and even abandoning solutions and vendors that you chose. Have a process that facilitates faster learning and, uses that learning for course correction.

Set-up and follow Code Management Practices

Let’s face it’s most Salesforce developers don’t have a clue on best practices for coding and code management. You need to define the role of different environments, code management practices, and coding guidelines from the beginning of the project. It is critical to do so if you have multiple people working on the same code as its likely to be the case if you are working on large implementation.

Security

Salesforce by itself if a very secure platform. However, it is important to have a data security expert in the team to provide guidance on coding practices to avoid security issues in your code.

Governance, Maintenance, and Data Integrity

Yes, you will need to define application Governance, Maintenance, and Data Integrity process for Salesforce. While the team is working on implementing functional requirements, do think about requirements coming from Governance, Maintenance, and Data integrity point of view. I have seen Salesforce instances where everyone has access to every piece of data and the instance is so full of dirty data that no one takes the reports seriously. Getting into that kind of mess doesn’t take much. Plan for it upfront.

Last Word

I love Salesforce and I also realize that it is not perfect. However, most issues in Salesforce Implementation and Development projects are not due to Salesforce’s limitations. They mostly are from poor planning and inexperienced team. Hope you find this use a good read. Ping me if you have any questions or comments.

Copyright Note: All logos used in the banner, Salesforce, Salesforce.com, Chatter, Marketing Cloud, AppExchange, Sales Cloud, Service Cloud, Chatter, and others are trademarks of salesforce.com, inc.