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 second post on The Super User Group, the next strategy to avoid project death is The Design Authority.
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 Design Authority?
A design authority is a community within an organisation responsible for setting standards and principles applied across the D365 & PP implementation. It also reviews scheduled work to ensure that plans adhere to these standards.
Design principles are enduring rules based on an organisation’s values that form the foundation for making architecture decisions throughout the business. The standards that follow dictate how specific aspects of the implementation are achieved, for example how data is stored.
While design authorities are most common in larger organisations, where the D365 & PP implementation is likely to occur across multiple workstreams and functions, they can offer value across any size operation.
The benefits of a design authority
Establishing a design authority supersedes rivalries and friction between different workstreams and how they operate, instead favouring a well understood model based on sound principles.
Delving into an example of the type of standards a design authority might set can highlight the benefits of using one. For example, how are user interfaces laid out throughout the system?
Agreeing a standard approach here will likely involve creating a design pattern checklist so that each user interface has common elements to it. This checklist will make the design process easier. It will also inform the change advisory board (discussed in a later post in this blog series) as to what they should be aware of before signing off any changes to user interfaces set to go live.
The resulting standardisation of interfaces across the system will result in a better user experience, as users won’t encounter different styles of interface as they navigate through the system.
This will aid collaboration and make it easier for new people—both team members and designers—to be brought up to speed on how these interfaces work. Such commonality is also perfect for a more flexible approach to managing people, as users can easily move between workstreams as necessary without a steep learning curve.
The risks of not implementing a design authority
If a design authority isn’t in place to enable people to collaborate, then they often won’t—just expecting people to do it that way isn’t always enough.
It’s not always obvious how damaging it can be to work without a design authority. But small differences in ways of working can quickly snowball, and before you know it, you end up with siloed solutions and duplicated processes that hamper collaboration. This makes onboarding and training users more difficult. As each workstream, team, project, or even individual might have their own way of completing a certain task.
Even having guidelines in place without the structure of a design authority may not be enough. The design authority carries weight across the design and implementation phases. Merely presenting users and designers with a process to follow may not result in compliance, which might then overwhelm change advisory boards (discuss later in this blog series).
While these symptoms are problematic and will erode trust in the system, they aren’t insurmountable. It’s difficult to backtrack and build a set of principles later, but it isn’t impossible, and for some organisations, it may be the only option to prevent project death.
How to implement a design authority
Firstly, we recommend that design authorities exist on the organisational side. They function best when they’re the responsibility of the organisation rather than the D365 & PP team, whether in-house or external. Although, the D365 & PP team should be included for guidance.
There are multiple reasons for this. Firstly, no one’s better placed to lead a design authority than the organisation themselves! Taking charge here will also ensure that they are more in control of their system, aiding understanding and management of the solution in the future.
There are frameworks which can aid the formation of a design authority. The Open Group Architecture Framework (TOGAF) is highly popular and consists of four pillars, also known as architecture domains, which are:
Business architecture — covering strategy, governance, and core processes
Data architecture — which details how data is managed within the organisation
Applications architecture — dealing with how systems are deployed and interact
Technology architecture — encompassing hardware, software, and network infrastructure
These make an ideal starting point for ensuring representation from across the business. By inviting experts from each area, you can cover each aspect of the standards to be set. For example, the technology architecture should be overseen by people familiar with Azure, D365 & PP and so on.
Take the question of data ownership as an example. Do individual teams and departments own their data, or is it an enterprise-wide resource? How is data quality measured and managed?
A company-wide view on this is likely to be beneficial in fostering collaboration. Equally, users will understand the day-to-day perspective of how data is produced and managed. If you’re unsure, we recommend erring on the side of inviting more people to give you complete coverage of the areas in question.
Beyond the TOGAF pillars, specific standards that should be considered include those for:
Architecture vision
Opportunities and solutions
Migration planning
Our Consultant Power-Up Course includes a design authority template as well as general areas to consider, which can help make planning that bit simpler.
The group you build will likely need to meet more regularly to start with, and the frequency of this will depend on the size of your organisation and the solution you’re implementing.
The challenges of implementing a design authority
Striking the right balance can be difficult, but I’d encourage you to start however you can—anything is better than nothing! This can be something that grows over time, so begin with the basics and keep it loose early on. Remember, your aim is to positively influence the solution without being too restrictive.
Microsoft’s own progress towards a ‘citizen developer’ model, where anyone can develop solutions through a low-code approach, further complicates matters. While this certainly has its benefits, it can make enforcing design principles both harder and more essential.
If users are developing solutions with limited technical knowledge, giving them principles to follow becomes critical, or else the resulting solutions could look wildly different from what the wider organisation wants and needs.
With so many users and departments having their own ways of working, mediation is an important skill. Be sure to consider everyone’s viewpoints and opinions when helping establish a design authority. After all, you need those users on your side to eventually adopt the system!
In the next post within the ‘Top 10 Governance Structure to Guarantee Dynamics 365 Success’ series, we will discuss strategy #4, ‘Change Advisory Board’.
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/
Commentaires