Redigera

Dela via


An inside look at the evolution of Success by Design

The this article is based on interviews with Dynamics 365 FastTrack solution architects. We hope you enjoy this insider view.

When our solution architects got their start with Dynamics 365, they found themselves hooked on the challenge of effectively aligning an organization's business processes and requirements with the (software) product in hopes of delivering solutions that resulted in actual value for users.

As a result, FastTrack solution architects also know the challenge of working with people, understanding the business, shaping software to meet the needs of the business, and delivering a solution that users will accept. They know that projects don't always go well and often fail.

It's for exactly this reason that the FastTrack for Dynamics 365 team and Success by Design were created.

A shift to Dynamics 365 in the cloud

Dynamics 365 isn't software that is purchased and implemented as is. As such, implementing Dynamics 365 products relies on qualified partners to get the implementation right.

Complicating matters further, the promise of the cloud has been that you can focus on the application and forget about everything underneath. But the reality is that cloud implementations require a comprehensive understanding of how design and build decisions may impact Dynamics 365 cloud performance, scalability, and more.

Accordingly, the shift to implementing Dynamics 365 in the cloud remains challenged by on-premises implementation habits in which the mindset is to overly customize, "because you can," without impact.

The shift to implementing Dynamics 365 in the cloud requires not just technical capability but also a definitive understanding of how to design and build Dynamics 365 solutions within the constructs of the online service.

The evolution of Success by Design

FastTrack for Dynamics 365 was formed to help customers maximize their investment in Dynamics 365 by making sure that they (and their partners) have access to the right information, recommended practices, and a connection to the product group throughout the implementation lifecycle.

When the FastTrack for Dynamics 365 team was formed, these goals were initially achieved without the use of a framework. In other words, FastTrack solution architects used their experience and connection to the product team, but this approach contained too many variables to be consistently reliable.

Over time, Microsoft's experience revealed that Dynamics 365 customers were running into very similar problems. For example, FastTrack would identify that some aspect of the solution was designed and built in a manner that wasn't compliant with recommended Dynamics 365 implementation practices. And too often the solution architects would catch the issue too late in the implementation lifecycle.

As a result, Microsoft began to ask itself: How can we change the FastTrack approach so our solution architects can address problems before they manifest themselves as problems? FastTrack also acknowledged that its approach couldn't be that a single solution architect would be assigned and solve the problems of each customer project. Our solution architects needed to work in a way that would benefit all customers.

To identify and address problems early, our solution architects had to engage with project teams on multiple levels. We needed to understand project plans, how project teams were thinking about doing customization, data migration, and more. This need for early visibility across all dimensions of the project meant aligning to an approach that afforded our solution architects the opportunity to get involved in these conversations from the start, to identify the problems and risks early, and to give the right guidance to the project team before more problems arise.

This required a period of FastTrack experimenting with the right approach. We started a concept that we referred to as checkpoints, which involved using surveys, but we found that this approach kept us in a reactive mode. We kept revising our approach and eventually we got it right.

From this experimentation, Success by Design was born: a proactive practice that invites a purpose-built dialog that touches all levels and dimensions of the project (technical and non-technical) so problems are identified before they impact the project.

Success by Design gets to the heart of how project teams are thinking and what they're doing so that any risks can be identified and mitigated.

With Success by Design, FastTrack joins the customer, our partners, and the product team in a manner that ensures alignment between all three.

As stated earlier, Microsoft recommends that project leaders team up with their implementation partner to enable Success by Design within their project. In addition to the Success by Design guidance available online and in the book, it's highly recommended that project teams ready themselves by enrolling in the Success by Design training on Microsoft Learn.

Success by Design for every Dynamics 365 customer project

At some point during the evolution toward Success by Design, Microsoft asked the question: How can we make sure every Dynamics 365 implementation is successful from the start? The key phrase is every Dynamics 365 implementation.

As this article highlights, the FastTrack for Dynamics 365 team doesn't have a special lease on the practice of Success by Design. Our goal is to democratize Success by Design and make it available to the entire community of Dynamics 365 implementers.

The more project teams invest in Success by Design, the more they'll get out of it.

Next steps

Return to the Succes by Design principles at Introduction to Success by Design