Intro
Navigating Power Platform projects is like being a master chef, juggling different ingredients to create a perfect dish. And just like in the kitchen, you wear many hats, one of which is that of a business analyst. But have you ever heard of the metaphor that a "business analyst is the meat in a sandwich”? It may sound quirky, but this culinary metaphor perfectly captures the role of a business analyst as the bridge between business goals and technological solutions.
What does it mean in practice? For a functional consultant like me, model-driven apps, canvas apps, workflows, entities, Power Automate, SLAs, security roles and so on are as familiar to me as spices are in my kitchen... However, communicating this very specific terminology to customers and end-users can be as tricky as balancing flavours in a complex dish. To avoid overwhelming them, start by speaking their language, using plain terms and relatable examples to explain concepts.
How to go about it though? I don’t think that there is a perfect recipe for that, and everyone approaches it slightly differently. However, in this blog, I'll share a few secret ingredients from my business-consultant-Power Platform sandwich recipe, and I hope it will get you inspired.
Replacing jargon
Model-driven apps and canvas apps
When a project scope includes one of each of them, sometimes they will be used as “back office” and “front office” apps. The “back-office app” can be for example D365 Customer Service (CS), or a custom-driven-model driven app based on the D365 CS that will be used to resolve and track cases. The “front office” app can be a simple canvas app allowing front office staff to quickly create a case and pass it for the resolution to the back office. Although the cooking ingredients will include a model-driven app and canvas app, try to avoid calling them like that and use the back office and front office apps as they will be clear and simple for the business.
Another approach is to name the apps – if the customer will not ask for it, try to suggest that and also come up with a few ideas. Why not call a case management app “Casey McCase” and a sales app “Selly McSold”? These names are good for a demo, but for the real app - make a bit of more effort to be creative!
Alternatively, look into the use cases for the apps and who the app is intended for. For example, a model-driven app can be called a “support team app” or “ABC support app”, where ABC is the name of the customer, you’re creating an app for. In the same way, a canvas app that is created for managers to use can be called a “managers app”. Quite simple, but it takes the canvas apps and model-driven apps jargon off the table.
Automation – workflows and Power Automate flows
While model-driven apps and canvas apps are fully associated with Power Platform, the term “workflow” is not technology-specific. It does not always indicate the “classic automation” used in D365 (before even Power Platform was introduced) and the term has much wider use. Therefore, when you say “workflow”, your business stakeholders might understand you, but their understanding will not necessarily be connected to what a “classic workflow” really is in D365. Cambridge Dictionary defines workflow as “the way that a particular type of work is organised, or the order of the stages in a particular work process”.
Once, I worked with a customer where multiple project members were referring to workflows. First, I was impressed thinking – oh, wow, they know that D365 has workflows! But very quickly, I realised that it wasn’t the case, so I simply asked – what do you understand by workflows? As you might expect, the answer had nothing to do with D365 or Power Platform. So watch, that’s a tricky one!😊
So how to refer to it then? I usually go for “process automation” or “automated process”. Also, “trigger” might sound relatively self-explanatory, but you can replace it with “when certain conditions are met." What do you think will be better understood by a business stakeholder? “Workflow will be triggered on field value change” or “automated process will start once certain conditions are met”?
When it comes to the workflows, you also have the “real-time” and “background” workflows. You might not necessarily go to the details like that too often. However, if business stakeholders ask you “What can cause that my app to be slow”, avoid answering “Cause there might be too many real-time workflows”. Explain: “There might be too much immediate process automation that stops users from using the application till those processes are complete. That can result in the application “freezing” or slowing down.”
Yes, that’s so much longer explanation, but remember your audience possibly never heard of “real-time” workflows, let alone understand what that means.
Similarly, Power Automate flows – in theory, you would not discuss details of using workflows or flows with a customer. However, there are scenarios when you need to. For example, a customer gives you a new requirement and asks you to provide with few options for delivering it with all the pros, cons, cost and timeline. In situations like that, you can explain – option 1 is to use classic process automation as it is quicker to build and option 2 is to use modern process automation as it gives you more flexibility. For me, as long as you can differentiate the 2 and simply explain it to the customer, “classic “ and “modern” work perfectly fine.
Plugins, JavaScript, APIs
As a functional consultant, I do not get any close to the “plugins”, “JavaScript” or “APIs” and I only have a very generic understanding of them myself. Nevertheless, when you think about the above scenario again - the customer asking for different options - you might need to "use those terms without using them".
In situations like that, I usually call them a “custom code” to make them more digestible and sometimes I will mix it with the option “requires a developer”. Make sure you do not make that sound too scary though. With the recent hype for the “low-code” approach, some customers might not want to even hear the details of a “custom code” option. However, there are scenarios when that option would be the best to meet the business-specific requirement, so approach it with caution and explain in plain language why “custom code” (e.g. plugin) is your recommended route.
SLAs
I tend to work with D365 Customer Service the most, so all my projects would usually involve SLAs. I eventually do call them SLAs when communicating with the business users as I want to make sure that they are adopting the D365-specific terminology. However, in the early stages, I start by referring to them as “due dates” to make it more understandable.
BPFs
Business Process Flows seem simple in theory, but again –D365 and Power Platform are specific functionalities, so try to avoid using this term, especially at the beginning.
BPFs are used to streamline and guide users through processes defined by the business. They provide a visual representation of the stages and steps required in a process. Therefore, I usually go with “process visualisation of the required stages and steps”. Also, when I can, I would simply show users an example of a business process flow. Similarly, as with the SLAs, I want the users to get familiar with the specific terminology sooner than later. However, even when you use “BPFs”, opt in for the full form and refer to it as a business process flow rather than an abbreviation of it.
Security roles
When customers ask if a D365 app can be limited to only allow certain users to create Accounts and Contacts, you can say that we can configure “security roles”. However, I find a better response to be that “users can have different access permissions” and/or “be able or not to perform certain tasks”.
Entity aka Table
If you are relatively new to the Power Platform, you probably will not have that problem. But for me, as much as I am trying to call Accounts, and Contacts tables instead of “entities”, old habits die hard and I still opt in for an entity. However, when communicating with new customers, I am trying to avoid it as it can cause a lot of confusion at their end and rightly so.
Therefore, stick with the “tables” and if you want to simplify further, you might replace them with “key building blocks” or “record type with columns (fields) to capture specific information”.
Practical approach
The above are just a few examples of possible synonyms to use instead of using the Power Platform-specific terminology. There might be some other terms that might not be clear to the users, e.g. views and dashboards, so think about them before your workshops and meetings with customers and business stakeholders. When it comes to the Power Platform projects, there are a few general rules you can apply to make sure that there is a proper understanding of what’s being said.
Set the scene
Explain at the beginning of the meeting that you might use some of the terminology that can potentially be unknown to those present at the meeting. Suggest that if something is not clear, e.g. pop a question on Teams chat. Also, pause after each presented section to check if there are any questions, especially about the meaning of what was shown.
Analogies and context
When you do use a term that is not clear to someone, try to explain it simply – ideally with a few words only. I find that using analogies and giving some context is the most powerful to quickly gain an understanding.
Glossary
For longer engagements and projects, it is worth creating and sharing a glossary with different terms. Store the glossary in a central location available to everyone and include the glossary in any project-related documentation as well.
Familiarisation session
It is quite common that at the early stages of a D365 project, there will be a demo of the standard, out-of-the-box functionality. Use this as an opportunity to introduce to the business stakeholders various terms and demonstrate how they look and work on the platform.
Audience
Always think about your audience at the meeting. There is no need to call your canvas app a back office app when you speak with e.g. a solution architect. Also, if you have been communicating with a certain business stakeholder for a while and they have started to talk about SLAs and BPFs themselves, keep that in mind and use those terms freely as well.
Conclusion
I hope you will find the above tips and ideas helpful. Communication is a skill that has so many dimensions, from how you speak to what you say and what words you use to say it.
Personally, it’s a skill that I constantly learn and try to improve, but still – I don’t get it right all the time. So don’t worry if sometimes you use too many techy terms too! Think about the opposite situation – when you run workshops to try to understand the business, you will also get a lot of business/industry-specific terms, won’t you?
Therefore, from the early days create an open and honest relationship with everyone involved, where you will freely ask questions about the meaning of the customer jargon. At the same time, be open and patient about explaining what workflows are, even for the 5th time this week to the same user. 😉
Comments