Dynamics 365 projects fail for many reasons.
In ‘Series Intro - Top 10 Governance Structures to Guarantee Dynamics 365 Success’, we outlined how we define a failure in Dynamics 365 (D365) & Power Platform (PP) projects.
Without the correct governance structures in place, common symptoms start to appear and imminent death, project death, is just around the corner.
This death is avoidable through good governance structures, our best practices for which we’ll be sharing throughout these posts.
Each governance structure identified in our series has its own requirements and impact.
In this monthly series, one of our lead consultants, Richard White, shares his real-world experiences of how these structures affect the organisations that use, or fail to use, them correctly.
Following our last post on the Agile Project Approach, the next strategy to avoid project death is The No Code Rule.
Once again, we will look at what it is, the symptoms you will notice from its absence, how you can go about setting the structure up, and the benefits that come from its existence.
What is a no code rule?
A no code rule is simply a commitment to avoiding the use of custom code wherever possible. Instead, developers rely on out-of-the-box (OTB or OOTB) features and creativity to solve issues and add the functionality that users need.
It’s important to note that a no code rule doesn’t necessarily mean never writing custom code. It’s up to organisations to decide how strictly to implement the rule, and there will be exceptions.
There may be niche functions or critical features for which customisation is essential. But if your default approach is to look for OTB or creative solutions that don’t require code, you’ll soon see the advantages.
What are the risks of not using a no code rule?
Any large migration that requires significant code changes is going to cost thousands and thousands of pounds.
I previously joined an organisation that had just migrated from Microsoft Dynamics CRM 4 to the 2011 offering. As part of that upgrade, they were forced to spend an awful lot of money on changing all their custom code to be compatible with 2011.
These were costs they hadn’t foreseen and they really got burned by them. The truth is, relying on custom code makes systems harder to maintain and upgrade.
Even though this logically makes sense for many, there is any alternative way to work. It’s not just a case of seeing D365 & PP as the ideal blend of OTB features and the ability to add in code for whatever customisations the users require.
The power to add in features is one that requires great responsibility to wield. Without correctly applied restraint, organisations may inadvertently find themselves over-customising and shooting themselves in the foot.
What are the benefits of a no code rule?
Microsoft often change their coding structures which requires consistent monitoring. Conversely, tasking developers with finding solutions to user requirements without writing custom code encourages creativity.
The main logic behind implementing a no code rule is making your systems resilient to change. D365 & PP now has a large feature set that can handle most organisational requirements, and Microsoft reviews use of their product to inform their own development of new in-built features. This is particularly true since Dynamics 2016 and the introduction of Power Platform.
By using this OTB functionality, it’s possible to future-proof systems, such that changes to coding structures don’t affect business critical functions. Microsoft will always ensure that their own OTB features are supported, making upgrading straightforward. This is especially important when you consider that Microsoft has just a 6-month release cycle!
Tasking developers with finding solutions to user requirements without writing custom code also encourages creativity. If the standard response is not to code it the way developers know how, they will find the best way to do it rather than the easiest. Encouraging these sorts of best practices will lead to cleaner, more efficient systems.
Users are also encouraged to think creatively. I remember joining another organisation who’d been burned by the cost of wholesale code changes and finding out that they had implemented a ‘no code rule’.
Initially, I was not impressed! I thought it would limit our ability to tailor the system to precisely what would be of most benefit to the users and the organisation. Whilst I knew code could make upgrades tougher to manage, I had the perspective that the priority was the user experience.
Despite my initial misgivings, this is how things were done there, so I tried to make the most of it. I was hugely surprised to find that one of two things would happen when users asked for a feature and I told them we it required code and thus we couldn’t implement it due to the no code rule:
Often, they’d hit this roadblock and realise that whilst they initially saw the feature as a ‘must have’, they would instead realise the functionality wasn’t essential. As a result, it kept the system clean and streamlined, rather than getting so bogged down by the weight of these ‘nice to have’ features.
Alternatively, we’d find another way to give the users what they needed. Users would suggest other solutions, and my team would buy into finding the best way to solve the problem. We ended up creating a shared sense of ownership over the processes, as well as some really cool creative solutions we were really quite proud of.
How to implement a no code rule
I was so convinced by my experience that I quickly adopted the no code rule as part of my own recommendations to organisations. Implementation will require buy-in from management to ensure it can be enforced. I would recommend discussing this at the steering group and super user group meetings to ensure everyone understands and is behind the rule.
As far as the timing of its introduction goes, it makes most sense to roll it out alongside a new release, having planned for the transition and converted to OTB functionality where possible.
Some flexibility is needed here—there will be systems and organisations that simply can’t do without custom code. That’s fine, as long as the simpler solutions are still pushed towards OTB features as default. Reinforce the principle that the less custom code, the better for the system’s health.
What are the challenges of implementing a no code rule?
The developers might be the biggest obstacle you’ll face in introducing a no code approach. Many are used to doing things in a certain way, and they love to code. By reducing their opportunities to create custom solutions, they might feel that they’re being stifled.
In reality, the opposite is true. The opportunity for creative problem solving, as well as the chance to showcase and own their solutions, goes a long way. Encourage them to be proud of what they develop and of contributing to a system that’s quick to build and future proof.
Explain how the no code rule will help the organisation and encourage them to view the challenges they’ll face as puzzles to be solved. Using only OTB components to make the system work? That could be an interesting challenge!
There’s a key lesson around hiring here as well, since there’s usually a distinction between consultants, brought in to configure, and developers, brought in to develop. Often organisations want the former but don’t realise that—the subtle change in terminology can really help hiring and ensure organisations bring in the right people.
In the next post within the ‘Top 10 Governance Structure to Guarantee Dynamics 365 Success’ series, we will discuss strategy #9, ‘Process Re-Engineering’.
If you want to get these posts straight to your inbox, then be sure to sign up to the mailing list below.
Richard S White
A seasoned Digital Transformation Executive renowned for leading high-performance teams towards innovative and strategic technology solutions. Specialises in steering organisations through complex digital transformations, fostering productive and accountable partnerships. Known for effectively guiding projects to success, aligning them with business objectives, and enhancing organisational self-sufficiency. Skilled in blending technology with business strategy, adept at facilitating candid discussions, aligning stakeholders, and crafting strategic roadmaps, positioned as an invaluable asset for organisations navigating the complexities of digital transformation.
Want help with your specific situation? Connect with Richard on LinkedIn to setup a free no obligation virtual coffee: http://linkedin.com/in/richardswhite/
Yorumlar