I would argue that in today’s world, it is almost impossible for one person to know in detail all aspects of a platform. Take Dynamics 365 for example. With the merger of multiple platforms under one generic marketing name, now we have specialists in Customer Engagement, F&O, Talent, etc. Take it one step lower, inside Customer Engagement, and with Field Service and PSA, you need to catch-up on new concepts, business models, etc. And then there’s always been the xRM part, which is all about the client’s business need outside of the scope of typical standard modules. But that’s not all.
The platform, as we knew it, is growing at an exponential rate. Where does that take us?
I’ve had the opportunity over the last while to participate in designing various enterprise size solutions. What I found is very interesting. Let’s look at a few aspects.
The importance of the team
When designing a solution that spans across various technologies, always leverage the strengths of the team. Bring together experts from all backgrounds.
Start with the business knowledge
Without an understanding of the business model, you are heading for failure before you even begin. This is in line with the concept of breaking up the barriers between business and IT. We’ve all seen too many implementations led by IT, that result in little to no adoption because they don’t do anything for the business, or worse, make it more difficult for business than what was there before. Putting together a shiny new skin on an existing process does not really bring value. Look at your solution as an enabler for change.
Next, move on to technical knowledge
Identify the components making up your solution, and bring in the necessary expertise as needed. One simple example, when working in the Dynamics space, is the ability to leverage the cloud for various things, like portals, or APIs. An understanding of various Azure services, how they relate and how they work together is of utmost importance.
This is another essential aspect. Keep in mind, the solution you are building is for your customer, and your customer’s customers. When your solution services the internal staff of your customer, involve people from all aspects of the business you are touching. Spend the time with the future end-user of the solution, to understand how they work now, and what can improve their experience. Just because one of their managers sais it’s got to happen this way, it doesn’t always mean it will make it easy for the actual user. Change management is an important aspect of this process, where you should bring along the people in the process. Recognize it will be a struggle for some (I would argue most) of the client’s resources, so make sure they understand what will change, and why. Change without a purpose, a why, is oftentimes like a too big/too fuzzy pill, hard to swallow.
From a client’s clients perspective, make sure the customer journeys you are optimizing and re-designing make sense. Take into consideration current trends when determining the value of a specific journey, along with factors like importance, volume and impact. This is a part of the implementation that often-times does not receive enough attention.
Are you working with processes touching partners of your customer, or suppliers? Make sure whatever your solution is, takes into consideration the capabilities available within these groups, and their willingness to adopt the changes you are proposing. There is no point in building a new API for partners, if they do not have the capabilities or the willingness to invest in leveraging it. All that work is throw-away, and brings no value.
Are there external regulatory or governmental pressures? Become familiar with the local landscape, and be aware of major global factors. See the push with GDPR that is shaking the industry at the moment. If you don’t have at least a high level understanding of that, you should. Then, reach out to experts as needed for the details.
Is compliance a requirement? Just because the core platform you are leveraging is compliant, that does not necessarily mean your end solution will be. Let’s be clear, unless you use an out of the box solution, chances are, the moment you start to configure/customize the platform, you can easily break compliance.
Third party tools and modularity
When it comes to this, your design should be flexible enough to allow you to take out and replace one tool with another at any time in the future. Modular design is essential. When optimizing business processes, look for all opportunities to wrap process steps leveraging 3rd party tools in such way that you can later pull it out and replace with another step, leveraging a newer, better tool. Having those tool vendors actively involved in the design process brings the necessary knowledge specific to the tool, but the overall design should take into consideration the most important what if. That is, what if the tool provider disappears, or does not support that tool down the road? And also, what is the impact of such a decision on the overall solution?
The ability of the customer to support the solution going forward
When it comes to this, you could spend a lot of time training those resources, but you have to recognize that without investment from your clients, you will not get too far. Always have a plan for customer supports post-implementation. I hate it when solution providers implement something, and then move on to the next opportunity. Include in your implementation a process to support your clients, whether it’s in the form of a Managed Services offering, a block of support hours, etc. Go past the typical 30,60,90-days bug fixes. What you will find is that, no matter how well you thought you’ve designed your solution, there will be changes required. This is a direct result of the client’s resources now becoming more familiar with the new platform, gaining a better understanding of the possibilities, and improving their processes to leverage this newly acquired knowledge.
There’s been talk in the last few years of adoption. We’ve seen gamification growing into products being sold to customers. And that’s helping sometimes with adoption.
But being able to measure success is a lot more than simple adoption. In a world with shorter success cycles, you have to be able to measure the overall impact of a solution on the business in shorter cycles. And this can be a very complex process. The solution implemented is not the only change happening in the client’s organization. Here, you have to work closely with your customers to identify the best way to measure the impact of your implementation. And always, always, re-measure at timed intervals. Don’t just settle for a 30-day post-implementation measurement, go for the 6 month, 1 year, and further into the future measurements. Continue measuring, don’t stop!
You will find that, at a certain point in the future, when the results are short of what was expected, there could be very little effort needed to reach or surpass the expected. this feeds into the cyclical transformational process. Design, implement, measure, analyze results, begin again.
While there’s a lot more aspects to take into consideration, let’s come back to the original question: how much should you understand outside of the platform?
A lot! Think from the perspective of the customer’s customers, think from the perspective of the customer and their staff, think from the perspective of your team, the platform, etc.
Besides the platform knowledge, have a general understanding of all these moving pieces, but most importantly, leverage the strengths of the many, and bring in expertise as required. It’s very much ok to be honest and say: I’m not the expert at “that”, but I know exactly who to bring in that is.
Ask yourself some questions:
Could I put in the extra effort to actually do that particular aspect? (You should hopefully answer yes to this one, it’s about what you could, not what you should!)
Is it worth me putting in that effort? It depends. Is there no exiting knowledge to tap into that would reduce my risk? Is it a strategic investment in yourself? Are you willing to take a hit, but come ahead with a new skillset?