“Can the standard solution do it?” This is the fundamental question that every implementation and solution team must answer when working on a project. The decision to adopt or adapt has far-reaching implications for the success of the implementation, the scalability of the solution, and the long-term value it delivers to the business.
Of course, every customer has their own specific requirements, habits, and existing application environment. So, can “off-the-shelf” standard solutions truly address all of these unique needs? Or is some level of adaptation inevitable?
To answer these questions, I will draw from my experience with Salesforce Energy and Utilities Cloud. However, the approach is generic and can be applied to any solution. My goal is to illustrate the decision-making process.
Can the Standard Solution Meet the Business Requirements?
Hmm, it depends on the business requirements! 🙂 Let’s start by clearly listing all the functional requirements we want to cover. Make sure you fully understand the business objectives and what the end users expect to achieve (remember, requirements are about business needs, not technical solutions).
Once you have this list, you can easily assess whether each requirement can be met. It’s even better if you have a prioritized list of requirements (indicating their importance)—this will be useful later. But if not, that’s okay too.
At this stage, you should be able to determine whether a standard solution can potentially cover your requirements and, if so, in which areas. If the answer is yes and it fully covers the requirements, great! Lucky you—you can implement the standard solution as-is, and that’s fantastic. However, it’s rare for all requirements to be fully covered by a standard solution. The real challenge—and the real value—lies in evaluating what needs to be done to get as close as possible to meeting all the requirements.
Don’t Abandon the Standard Solution Too Quickly
Too often, I’ve seen teams abandon a standard solution entirely just because part of the requirements isn’t met. It might seem like the easy way out, but the real difficulty (and the real satisfaction! 🙂 ) comes from figuring out how to leverage the standard features to meet the requirements effectively.
Addressing Requirements One by One
So basically, you address each requirement individually (those not covered by the standard solution) and search for possible adaptations. If you find one or more options, evaluate them—estimate the effort, and list the pros and cons of each. If there is no option to meet a requirement, make sure to note it as well. The priority of the requirements can also be very useful here to properly manage the effort and focus on what matters most.
Revisit the Analysis with the Business Team
Once this full analysis is done, you should revisit it with the business team to ensure alignment—what is acceptable for them and what is a total no-go. Be careful: users often want everything (and its normal: if you have to choose between “everything” or “something”, what would you take? ), but it’s crucial to find a good way to prioritize their needs. This step ensures that the effort is focused on what truly adds value.
Identifying the Best Solution Scenarios
With your list of options and feedback from the business team, you can identify the best solution scenarios. The final decision should be made by the Design Authority team, who can evaluate whether the effort required is justified by the business value. Present your analysis and recommendations to DA. Be sure to highlight different scenarios and provide all details, such as effort and impact, to help DA make the right decision.
When to Consider a Fully Custom Solution
Of course, if you find that nearly every requirement requires significant customization to adapt the standard solution, then a fully custom solution might indeed be a more viable option. However, this option should always come at the end of the process, after thoroughly exploring and exhausting all possibilities with the standard solution.
The diagram below describes the full decision process. Good luck!
