In our thriving Salesforce ecosystem, there is a strong emphasis on celebrating success. While we revel in these accomplishments, there is an opportunity to foster a deeper understanding of challenges.
I have noticed a scarcity of case studies exploring Salesforce projects that faced challenges. In my professional journey, I’ve observed a tendency to overlook the exploration of failure, and there could be several reasons contributing to this.
Conducting a comprehensive Root Cause Analysis (RCA) demands time and effort, as well as resources that can be perceived as costly. In a fast-paced environment, there’s often a preference for swift transitions to the next endeavor, as it is economically more expedient.
- Admitting failure can be challenging. Discussions around failure may inadvertently lead to blame games and office politics, prompting some companies to discreetly handle failures to sidestep potential job losses or uncomfortable management situations.
- It’s essential to consider that Salesforce projects typically operate on smaller budgets, with many companies opting for a phased approach with a carefully planned roadmap, introducing changes in manageable increments for end-user acceptance. Compare this to colossal endeavors like HealthCare.gov (2013) and the NHS National Programme for IT (NPfIT) in the UK.
Possible Reasons for Failures
Despite the scale and nature of Salesforce projects, acknowledging that failures are inevitable becomes paramount. Engaging in Root Cause Analysis provides valuable insights, facilitating a better understanding of how to avert failures or proactively prepare for potential challenges.
When doing a Root Cause Analysis (RCA), consider the following causes for failure:
1. Underestimating Project Size
In the context of consulting, the delicate balance between ambition and precision is essential. A miscalculation in project estimation not only has the potential to impact project outcomes but can also strain the trust between consulting firms and their valued clients.
When not properly defined, the intricacies of project scopes may result in the necessity for change orders. This topic can sometimes lead to sensitive discussions, and I have seen time and again how the discussion around change orders can be contentious.
This can be fixed by involving the delivery team early during the sales cycle, crafting a statement of work (SOW) with clearly defined boundaries, and gaining alignment on what is in the realm of possibility.
2. No Strategic Vision, Goals, and Roadmap
Zooming out and understanding the value of the project is important. What are the executives expecting from this project?
There will be several metrics that need to be defined as success metrics to ensure that every stakeholder in the project agrees to and works towards. For a call center project, it can be to reduce the call resolution time. For the sales team, it could be measured in faster deal closing time.
An industry-specific example I worked on is to make brokers self-sufficient so that less time is spent by internal resources to help brokers. It takes understanding your business well and what improvement really means to you.
3. ‘Too Many Cooks in the Kitchen’ Doing Too Much at Once
In the intricate landscape of Salesforce implementations, it’s not uncommon to witness a convergence of multiple vendors within the same org, further compounded by the simultaneous involvement of ERP specialists, data lake architects, and other implementers. This synergy, while promising, can inadvertently give rise to bottlenecks and a labyrinth of confusion, ultimately contributing to the departure of key individuals from the organization.
Recognizing the importance of meticulous planning becomes paramount in such multifaceted scenarios, especially when considering the existing workload of your dedicated staff who are diligently managing their day-to-day responsibilities. It’s essential to approach this complexity with a strategic mindset and a well-thought-out communication plan.
Establishing a robust communication plan serves as the linchpin, fostering seamless collaboration among diverse teams and mitigating the risk of inadvertently stepping on each other’s toes. The objective is not just to minimize confusion but to create an environment where each team’s efforts complement rather than conflict with one another.
Embracing a phased implementation approach emerges as a guiding principle for success. By breaking down the deployment into manageable stages, you not only alleviate the burden on your team but also afford the necessary time and space for thorough coordination and collaboration. This measured strategy ensures that each phase is executed with precision, minimizing disruptions and allowing for a more cohesive and efficient implementation process.
4. Company’s IT Acting as Intermediary and Not Granting Access to End Users
This scenario often unfolds when a company’s IT department seeks to influence how Salesforce functions for end users or aims to shield them from direct interactions with Salesforce consultants. While IT teams contribute significant value by providing insights into compliance issues and other company standards, the approach should shift towards acting as a facilitator rather than a hindrance in Salesforce implementations.
Recognizing Salesforce as a pivotal business process tool, integral to daily tasks for end users, is crucial. In this context, IT should serve as a bridge, facilitating effective communication between consultants and business users. Allowing the business to express their challenges and articulate their expectations directly ensures a more streamlined and efficient project workflow.
Inserting an additional layer, such as relying on IT to filter business requirements, can lead to challenges. The translation process introduces delays and may result in a loss of valuable time and resources.
An illustrative example underscores this point: a quote lightning record page underwent numerous changes (20 to 30 revisions) over the course of the project due to a lack of direct input from the business. This not only represents a lost opportunity in terms of time and money but emphasizes the importance of fostering direct communication channels to enhance project efficiency and value.
5. End Users Providing Prescriptive Requirements
It’s not uncommon that your end users have been working with Salesforce either in their prior work or in their current role. With prior Salesforce experience comes baggage that you must be aware of. While implementing Salesforce is totally different from using Salesforce, users are guilty of telling what they want instead of providing requirements.
I’ve had customers tell me they want something solved a certain way, for example, requests for record types or requests for picklists. Then I ask what the requirement is and why they think that they want it solved that way. Often, I hear it’s because they are always used to it being done that way.
So, there is an additional onus on the implementer to challenge and present options that will minimize technical debt as the Salesforce platform is evolving, and something that was done a certain way is no longer the best option for your users.
6. Ever-Changing Requirements
Whether you are a consultant or a solo admin for a company, we have heard this complaint so many times that end users change their minds often. Salesforce seems like an easy tool, and I have heard users tell me they want to change the opportunity stages on a monthly basis.
In a volatile environment, establishing a cadence or educating your end users helps. Telling your end users that some changes will be locked and further changes need to be vetted before making the change may infuriate them, but it is critical to keep the system stable. Imagine constantly changing opportunity stages, then changing everything else that is dependent on the stages, like automations or validations, sharing rules etc.
Educating your end users about what might seem like a trivial change is important. Don’t be an order taker; in fact, putting some guardrails around changes will establish discipline.
7. Failure to Log Risks or Develop a Risk Mitigation Plan
Are you diligently maintaining a comprehensive risk log and actively monitoring it to develop strategic solutions for potential challenges? This crucial step in project management is frequently overlooked but holds immense value in discerning areas where a project might encounter difficulties.
Consider this scenario: there’s a vital dependency on an integration that must be developed before the system can go live. Failing to log this as a potential risk and actively monitoring the integration’s progress means missing a valuable opportunity.
By utilizing the risk log to proactively assess the status of the integration and leveraging this information to communicate effectively with stakeholders, you not only gain insight into potential project roadblocks but also empower stakeholders to influence the project’s timeline and budget.
This strategic approach ensures that you not only identify potential pitfalls but also actively engage stakeholders in a collaborative effort to navigate and overcome challenges, fostering a more informed and resilient project management process.
8. Not Retrospecting After Each Sprint or at Regular Intervals
Retrospecting at regular intervals, such as sprint retrospective in an Agile delivery model or after the end of a phased implementation, is a crucial step to not only understand what could have gone better but also as a way to understand what went well that needs to be repeated to achieve the same level of success.
This can serve as a way to capture any additional risks, action items that need to be followed and a mechanism to improve the overall delivery approach. Use this as a way to encourage team members to speak about what they think can be improved upon. Notice who contributes to these valuable sessions and encourage others to speak up because having an open communication forum is essential to a project’s success.
Summary
What are other reasons you can think of that contributed to your project going sideways? Do you perform an in-depth Root Cause Analysis? Do you have a template to analyze project failures? Learning from past failures is crucial for preventing future ones.
Make sure to share all your thoughts in the comments below!
Comments: