I once moved to a foreign country without a full grasp of the local language. Then, when working as a Salesforce consultant back home, I needed to translate business challenges into a coherent technical design. Guess which one is harder?
I’ll give you a hint: In business meetings, you can’t get by with hand motions or semi-grammatical bursts of verbs and nouns.
Every project starts with a business challenge, a problem to solve. It usually presents itself as a broad statement like “I need more accurate revenue forecasting” or “Our team is struggling to understand which accounts to prioritize.” And before any build can start, business leaders and technical resources — developers, system admins or implementation partners — must align on the best way to translate that vague problem into specific technological changes or enhancements that can solve it.
In my experience, this step represents the most imposing hurdle in any project, but I’ve learned that these 5 best practices facilitate turning business challenges into the perfect solutions.
Make sure you’re speaking the same language.
One of the most significant barriers to finding solutions involves communication breakdown — lacking a common language. And a language gap often exists between business leaders and technical resources, where leaders speak in challenges, goals and buzzwords while developers may communicate in technical terms, architecture and… well… different buzzwords. That makes it challenging to find center ground.
So for business leaders, the key for communicating with technical resources is to learn the basics of the systems they work with — like Salesforce jargon and architectural terms. For admins and developers, the opposite helps. The more you understand the business implications of your work and pain points of your users, the easier it becomes to adjust to new business requirements.
{{cta('b4cf473b-6782-4d76-9687-04e9b072af0b')}}
Understand the complexity, then align on a scope.
As mentioned above, most business requirements start as overarching goal statements. But the challenges they pose are often much more intricate and nuanced. Take one of the examples above: “I need more accurate revenue forecasting.” Well, forecasting gets more and more complicated with every different type of product you sell: one-time purchases, subscriptions, project work and more. What if you only sell projects but invoice those projects in five different ways?
So the initial requirement can elicit thousands of follow-up questions. You should interview workers with firsthand knowledge of the subject to uncover its nuances. Once the project team grasps the complexity of the problem, everyone can align on a scope: What aspects of the question will the solution account for? Will it disregard any parts of the issue or leave them for a future phase?
Answering these questions will determine the timeline and budget of the project. We certainly don’t recommend building anything until understanding those.
Use process to guide the discussion.
For any projects that force employees to change behaviors, process serves as the middle ground between business requirements and technology. A process can represent the “How” that answers a business challenge, while technology is the “What.”
Another reason the two must work hand-in-hand: Because technology is rigid, while life is fluid. So defining a methodology to standardize how employees should interact with your technology ensures that nobody will break it by using it in a way the architects don't expect.
Map your solution visually.
As mentioned above, words often don’t convey design requirements and specifications the best. Buzzwords, jargon and three-letter acronyms (TLAs) confound intended meanings and cause miscommunication.
You know what’s easier to understand? Pictures. Wireframes, process flows, charts, demos: any way of visualizing ideas for your audience facilitates your solution design. It offers a canvas that technical resources and business leaders can analyze together and collaborate on. Besides, it’s much easier to redesign a mock-up than a fully-built custom-coded page.
The right way to communicate a solution:
And the wrong way:
Iterate, iterate, iterate.
Even once you’ve finished an initial design, the solutioning is far from over. Business requirements change, and technical roadblocks can pop up where you least expect them. So your team must stay flexible and adapt your design over time, following each of the four above principles to keep everyone on the same page.
I would say that the design process is only done once the solution is completed and rolled out, but hey, change requests and phase 2s come up all the time. The work of an architect never ends.
The process of turning business challenges into solutions on Salesforce and other cloud platforms often resembles art more than science. It involves an intricate process of discovery, translating between parties and compromise. The above best practices will help keep technical resources and business leaders aligned throughout this stage of a project, resulting in a solution that everyone can agree on.
For more tips on solving business problems through technology, check out this ebook on foolproof ways to maximize your Salesforce investment.
