The key to a successful project is to elicit the information necessary to write requirements that will meet the business needs. However, gathering information from the various stakeholders can prove to be challenging. Occasionally stakeholders do not have a technical background and what seems like a straightforward question might sound foreign to them. Here’s a look at some techniques you can use to effectively communicate with non-technical clients during requirement elicitation and the project lifecycle.
As a Salesforce Business Analyst, having a baseline understanding of the client’s knowledge level helps avoid unnecessary explanations or assumptions. The goal is to get a feel of their understanding of basic terms pertaining to Salesforce, their experience with the platform, how comfortable they are with technology as a whole, and their familiarity with the topic at hand.
Learn Their Business
The more you know about the company and the role the customer plays, the more effective your requirements interviews will be. Learn the company lingo and culture and what is unique about them compared to their competitors. Being more in tune with their industry and business environment will only strengthen your communication throughout the project.
Should vs. How
When talking with non-technical customers, focus on what the solution should do versus how it will do it. This is where the baseline of the stakeholder’s knowledge level is beneficial. Speak in terms that they will understand. Apex classes and triggers mean very little to someone who just wants an email to fire when a button is clicked. If they try to steer toward the how, redirect with questions such as “If you were already using the solution, what problem would it solve?” Client’s prefer to know more about the results they will see than the process of how it is accomplished.
When explaining a process or certain aspect of the project, it helps if you can relate to the non-technical customer by giving them a frame of reference they will understand. For example, when describing how Salesforce defines a data model, instead of talking in terms of Objects, Fields, and Records, relate it to an Excel spreadsheet. Salesforce thinks about tab as Objects, columns as fields, and rows as records. Most non-technical end users are familiar with Excel.
Of the various requirement elicitation methods, there are a few that prove most effective when working with non-technical customers.
- One-on-one interviews allow you to tailor your questions to that specific stakeholder and their experiences based on the answers given. Ask them questions such as:
- What are the biggest challenges in your role?
- What does success look like for you?
- How would you describe these processes?
- Group interviews give you a glimpse into how those stakeholders work together. One stakeholder may be more knowledgeable in areas that could have been hard to identify in a one-on-one interview. You may uncover a hidden SME and are often able to identify missing stakeholders or gaps in the process.
- Prototyping is invaluable with non-technical customers because visuals help solidify the concepts and also help uncover flaws that could have been missed. Use visuals during one-on-one and group interviews when processes are being described. As the stakeholders are describing the process, draw or write out the different stages and ask questions around both current and future state. At the end of this exercise you will have done two things: 1) validated a visual of the current state process and 2) uncovered areas that will add value to the organization.
- Job shadowing is useful when evaluating the current processes. It helps gather additional information about aspects of the stakeholders role that have become such habit, they have a hard time explaining what and why they do it. This is also beneficial in learning more about the client’s business by having a more hands-on approach to the day-to-day functions.
All of your knowledge and hard earned certifications mean very little if you cannot effectively communicate with your client. When working with non-technical stakeholders, keep it simple. Talk in terms they understand, relate to their experiences, and focus on the end result instead of the detailed process.
By Victoria Cloeren