Intro
At the heart of my role is solving business problems and finding solutions to a variety of business requirements. As much as I love doing it, I cannot help to sometimes face a dilemma of what solution will be the best to achieve the desired outcome and what is more, contribute to the benefits realisation.
The Paradox of Choice
The latest Microsoft offering is like a menu in a gourmet restaurant – all packed with amazing flavours with a mix of different ingredients to choose from. But have you ever heard of the paradox of choice?
The paradox of choice stipulates that while we might believe that being presented with multiple options actually make it easier to choose one that we are happy with, (…) having an abundance of options actually requires more effort to make a decision and can leave us feeling unsatisfied with our choice.
While this phenomenon originated from consumers’ choice dilemma during shopping, it somehow fits nicely with my daily considerations around choosing the right option.
Options, options, options….
When it comes to all possible options, it is best to list them and analyse all the pros and cons. Then, sometimes you will need to make the final decision, sometimes you will be asked to present a few possible options to your customer or team. And usually that will be followed by providing a recommendation about which option is the most suitable and why. But what to consider exactly when making the decision?
In this blog, I would like to share with you my recipe with a list of things to potentially consider when analysing possible options.
Defining a requirement\problem
First, start with a question about what problem or requirement you exactly trying to find a solution for. Do you have all the information from the customer including why are they trying to do something? To save time? To save money? To improve effectiveness and users’ satisfaction? That just a few examples, there might be so many other reasons – try to discover them all.
Also, do you have all the acceptance criteria for the requirements? All the rules for “happy” and “unhappy” scenarios - as known as the exception handling. Does the customer have any constraints? What are they? Once you exhausted all the questions and the analysis, let’s move to finding the possible options.
Finding options
As I have mentioned before, list all the options you might think about. Refer to your knowledge and experience, but also do some research and don’t be afraid to ask for opinion and input from others. You can ask your colleagues or reach out to the wider community – post on one of the Microsoft forums or LinkedIn.
If you haven’t done it before, you will be surprised how helpful and open the community is! They will not make the final decision for you but will give you some ideas and suggestions.
After listing all the options, let’s move on to decide which one is the best one.
Product first principle
Since I am a functional consultant, my golden rule is the “product first principle” – knowing the platform inside-out and advising what feature can be used to deliver a requirement. You can also refer to it as a “fit/gap” analysis as you are mapping a requirement to the out-of-the-box functionality to see what fits and where are the gaps.
For me, any option that is a “fit” is usually a winner.
When undertaking the “fit/gap” analysis, make sure that you know exactly what type of licence your customer has or is planning to purchase.
For example, if a customer already has Dynamics 365 Customer Service and wants to further automate case allocation, Unified Routing can be an option. But if they only have the Professional version, you will not consider that as an option as the feature is only included in the Enterprise version.
It doesn’t indicate that we need to go straight into different routes. The next thing to do, is to check the product roadmap and what is coming in the next releases. Sometimes the immediate advice for a customer is to “wait” for the release of a new feature that will fit the criteria of a requirement.
So what comes next? Even with the “fit” requirements, you still can have the next level of making choices - for example, automation can be delivered using either workflow or a Power Automate flow. (The “workflow vs. Power Automate” can form a separate blog post, so the below definitely will not exhaust the full subject.)
What are the other, more generic considerations before deciding on the right solution? Let’s look at different customers constrains and the wider picture first.
Customer constrains
Before you can start building any solution, the customer needs to commit to it by signing a contract or work order (or whatever it’s called at your organisation). But they will only sign it if it fits their budget and timeline. So always think how much it will take to build a solution and the time will translate into money.
For example, do not recommend a custom integration if a customer has a very limited budget and needs the work done as soon as possible. Check if there are already 3rd party solutions that can be used to limit the required build budget. However, some of the 3rd party solutions might require additional monthly/annual fee. Therefore, when it comes to the customer’s budget, always try to find out the initial spend and if they can afford an ongoing cost.
When organisations consider investments, they will define the budget for OpEx and CapEx. Usually, I would not engage in direct conversations around that. However, if you have an account manager or a salesperson working with the customer, they might know the answers, so ask these questions.
Also, there might be some different, non-flexible, time constraints. I worked on a few projects where the customer has decided not to renew a licence with a different supplier, and they needed a new system before the other agreement would expire. Therefore, the overall timeline was quite tight and as a result, time allocated to deliver individual requirements was challenging.
Wider picture
Another thing to consider is the wider picture of the customer’s organisation goals, mission and roadmap. If they aspire to have a state-of-the-art technological solution that makes them stand out ahead of the competition, more likely that the e.g. bots and massive injection of AI features is the right trajectory. However, if it’s a family business that values its employees and their well-being the most, opt in for solutions that will help them in everyday tasks, but will not aim to replace anyone’s jobs.
IT department
Additionally, have you engaged with the customer’s IT department? There might be some general rules and principles that need to be followed when it comes to building new solutions. Also, there might be some security policies and constraints that might limit your options. The customer’s IT department should be engaged to confirm all of that. Sometimes, they will also need to be involved in the decision-making, so make sure that they are consulted.
Next, consider the standard solution lifecycle - how different stages can be impacted by choosing a particular option.
Development
What aspects are important during the actual development of a solution? Among everything else, consider the individual who will be responsible for building the solution and their skills. It might be you, it might be someone else, so take that into consideration. I have been in situations when for example I would recommend a Power BI dashboard instead of a classic or interactive D365 dashboard. However, I do not have enough skills to deliver it myself. So, is there anyone else at my end who can do it for the customer?
Another scenario: You think that building a canvas app is the best possible option, but you have not built one yet. Would you have enough time to upskill yourself to build it for the customer when you already know that you’ll be delivering the requirement? If you will take that challenge on, is there anyone there to support you, should you need it? I am always open to taking on a new challenge and learning a new skill. And the project experience is the best to do that but is this the right time and appropriate level for the challenge? It’s up to you to make a judgement call and take it on or you can ask to pass it to someone else.
If I know that someone else will be responsible for this requirement, I will reach out to them and check if they have enough experience to do something. If not, I would offer them an opportunity to do it while supporting them if I already have the required skill. Situations like this will allow you to learn new skills, but it will also help you support and teach others.
The level of skills is also quite important – when more junior member of the team is more likely to be tasked with the development, reflect that accordingly when estimating how long it will take to build the solution.
Solution vs requirement
The next thing to consider is how the solution will fit the requirement itself. Does it meet the requirement fully? Partially? Is it even possible to do it? Is there any workaround needed?
Knowing the ins and outs of the requirement is also the key. What are the current volumes to be processed? How complex the logic needs to be if there are multiple rules for exception handling? Why knowing all of this is important? The volumes and complexity will have an impact on the system's performance.
For example:
For smaller volumes, minimum complexity and quick delivery, I would normally opt in for workflows (assuming it’s possible).
For larger volumes and more complexity, potential automation with flows will be the best.
Very large volumes and large complexity are more likely candidates for plugins.
When considering volumes and complexity, look beyond today’s situation. If there is an indication that things might change in the future, make sure that the proposed solution is also scalable and future-proof.
Solution vs application architecture
Although you might be looking at a specific requirement, consider how the rest of the functionality is built, so more holistic view the current application architecture. If the solution is already life and you’re just extending it, analyse the existing build. If it’s still in the development stage and there are other consultants/developers working on the build, liaise with them to ensure the consistency in the approach.
Some examples:
If there are already workflows that are tiggered on a record creation, do not start creating Power Automate flows with the same trigger. Extend the workflows or create a new automation, but also use workflows.
If you are extending the existing process, consider branching what is already used to support the process e.g. Workflow, Power Automate Flow, or plugin.
If hiding/showing fields is handled by business rules, do not start creating JavaScript to do it.
If access to different forms, views or dashboards is controlled by security roles, do not create alternative apps that will be used as separate containers for different teams. Continue using the single app and update the security roles, even when onboarding new business unit or team.
These are just a few possible examples and there might be some exceptions where a different approach is required as the overall solution will work better. Again, consider pros and cons and analyse what are the potential trade-offs and workarounds.
User experience
The user experience is another critical aspect when choosing or recommending the right solution. At the end of the day, you are not building your solutions for yourself, but for the customer’s end users, so do include them in your thinking process.
What will be the most intuitive to use?
What will require the least number of clicks?
What solution will really help the users and bring them value?
When you consider few options, try engaging with the end users and run some ideas by them – you might be surprised with the valuable feedback you can get from some users.
Training
Next one is also connected to the users - training. So, think about what will require the least training and creation of custom training materials. Will you need special guides and videos explaining the functionality? Or is there an option that will need a minimum training? Who will deliver the training and how?
Maintenance and support
One of the last things to consider is the maintenance and support of the solution post-go live. Who will maintain it and troubleshoot in case of any errors? What skills do they have or need to have? If the customer outsources the support, it should not limit you that much. However, if they prefer to support the solutions in house, make sure that they have resources that either already have the existing knowledge or are willing to upskill themselves.
Some consultants might not consider this as important, but personally I believe it’s good to showcase to the customers that you are covering all the angles and that you care about what is “next”. Thanks to that, I tend to build much better rapport and long-lasting relationships and I recommend the same for you.
Conclusion
To finish where I started, let me re-iterate again that the paradox of choice requires from us to put more effort into the decision-making process. However, to avoid the feeling of making a wrong decision or putting a wrong recommendation, it is worth a while to consider all of the above factors. That will help us to make more informed decisions when selecting the right solution to meet the business requirements effectively.
What about are your secret ingredients that you always consider when deciding on the best solution? Anything else you can add? Or is there anything that you do not agree with?
As usual, it is my personal experience and approach, but I am open to hear and learn from you too!
Comments