A case for custom development in Dynamics

A few days ago I was talking to a prospective client, and, once again, the question of how to approach custom development came up.

My immediate response was more along the lines of having as little custom development as possible on the Dynamics projects since, more often than not, those customizations are implemented by the consultants who come and go, and, once they are gone, there is very little knowledge left of how to tweak such customizations and how to maintain them. From that standpoint, it’s much easier for a non-developer to work with the “visual” design tools to configure workflows and business rules.

However, what struck me a little bit is that a few years ago I would have answered differently. It’s just that I’ve seen it on a few projects lately that a proper customizations governance strategy is rarely implemented once the project goes live. Come to think of it, it is not that surprising at all, since not every company will have an on-site developer to properly maintain the customizations.

But that made me thinking of something else.

Dynamics has been evolving quickly – we now have business rules, lots of out-of-the-box custom actions, real-time workflows, calculated fields, rollup fields. None of that was available not so long ago. However, all those new features, while being very useful, have limitations. Sometimes we know about those limitations when we are starting to work on a project, and sometimes we don’t. 

So we may think, for example, that we might use a calculated field to get the first day of the month based on the datetime value stored in a specific field. Or that we might start a workflow for a calculated field. Or that we might use some complex conditions for rollup calculations. But we can’t.

Look at it from the project management standpoint, though. You’ve collected the business requirements; you got an idea of what should be done first, and what should be done later; you’ve prepared the estimates, you’ve got a sign-off.. The team starts working on the project, and, then, you start discovering those technical limitations of the out-of-the-box functionality. For each of those discoveries, you will likely have to adjust the estimates, to renegotiate the requirements.. you may even have to re-design the whole solution at some point.

In other words, the main problem that comes with those limitations is that we do have some uncertainty. When there are limitations, you can never be certain that a specific requirement can be achieved using those out-of-the-box features.

Now what if you opted for the custom development? If you had chosen that route, you would probably have a lot of other problems – you would have to find the developers, you might have to train them, you might have to figure out how to manage the code.. But, with all that, you would likely have a very good and accurate idea of what’s possible, what’s not, and what it’s going to take to develop those javascripts/plugins.

Which is why if I had that conversation again, I would probably say that custom development on Dynamics projects still makes a lot of sense. It’s the most reliable and the most advanced customization technique that we can fall back on when everything else fails, and we should likely include certain amount of custom development, especially on the more complex tasks,  into all the  estimates and project plans.