Dynamics 365 – Buried Skeletons

Recently, our contact on a large multi-year customization effort for a customer left. The new person who came in seemed to be of a mind to change things up. What was a highly effective and collaborative effort, suddenly became a battle over every hour billed. I’m on the verge of kicking them to the curb, but…

Screwed by Nature

There is an interesting anomaly in our business, that can ultimately lead to disaster; the seeds are planted as soon as you hire a Microsoft Partner. I don’t think customers think about the end at the beginning. Why would they? They have no idea just how bound to that partner they will become over time.

Houses of Cards

You will ultimately be working with a person who is architecting your solution to meet your described requirements. Assuming they know what they are doing, they still have multiple ways to go about it. “Best Practices” is a bullshit term, don’t get lured by it. While there are many ways to architect something wrong, there are also many ways to architect it right. It will boil down to that person’s opinions based on their knowledge and past experiences. But even the most knowledgeable and experienced people will architect things differently from each other. They are all right!

It’s not intentional. Eventually, all complex deployments become houses of cards. It’s just how it is. Removing any card. without knowing what it may be holding up, can crash everything down. This is why most partners being brought in to replace another, suggest starting many things over from scratch. It would just take too much time in forensics to figure out what the prior partner had done and why, (“What does this card do?“). This is regardless of whether it was done well or poorly. I’m sure some partner will jump on the comments and say they are smart enough to figure out anything. These are the ones that usually come back later and say “Upon further review, the last partner did not know what they were doing, and we need to start over“… convenient.

Transition to Internal Team

The big customization effort is complete! Let’s have our own people take over from here. This is a natural and logical desire. But you better plan on keeping your partner around, and happy, because there will be issues and fires. There always are. They tend to pop up before you can even get clear of your partner. The bigger the deployment, the more dependent you are on the partner who built it, they are only ones who know where the skeletons are buried. The only bigger risk is having one of your employees build it.

Citizens

There is a lot of conversation today about “Citizen Developers”. They will also build houses of cards, but will likely do it poorly, without the deep knowledge and experience, and then suddenly they leave your company. Admittedly, when we are called into these scenarios, starting over is often the only option.

Updates

All platforms go through continuous updates, Microsoft Business Applications included. These can not only bring new features, but occasionally can deprecate features you are using. As a customer with your own business concerns, you will likely not be up-to-speed on these, and will instead discover them one day when things stop working. That would be a fire, and you better have a brigade at the ready. Better yet, if you have maintained a good relationship with your partner, they will give you a heads up, and be there to make sure things continue to go smoothly.

Universal

This is not a Microsoft Business Applications phenomena, this is the same for all platforms that allow for broad customization. The same was true when we were Salesforce.com partners. It’s also not new. The same was true for that Access Database solution Joe built for you ten years ago, and then he was hit by a bus and died. Damn Joe!

Summary

Eventually your partner will have you by your underwear band. Whether they give you a wedgie will have a lot to do with who they are, and how your have engaged with them. The cost of changing them will be very high, and last a very long time. Choose wisely.