In the initiate phase, the project team is in discovery mode, where they are gathering and validating business requirements, finalizing the high-level solution approach, making inroads to define all in-scope workstreams, and revising the project plan to reflect these updates. When the project team has produced the high-level solution design, and when the related project workstreams are mostly defined, Success by Design begins with the Solution blueprint review. The initiate phase is one of the most important parts of the project because many decisions that are made in this phase will impact the success of the deployment. Occasionally, it might be tempting to rush through this phase so that you can begin building the system, but it’s important to have a plan and design before you start building.

• In the initiate phase, the project is typically in a discovery mode, where you are gathering business requirements, finalizing the high-level solution approach, and planning the scope of work.
• Ideally, the solution architect will engage in this phase and introduce Success by Design, the workshops involved, key success measures, and so on. The solution architect will also propose and schedule the Solution blueprint workshop.
• While in the discovery mindset, the project teams might respond with specific questions that are related to service, tenant management, product fit, and so on. The solution architect can address these questions.
• When the team has produced a high-level solution approach, the key integrations are identified, and a high-level project plan is ready, the Solution blueprint workshop should be planned and implemented.
• The Solution blueprint workshop review should also help highlight areas with higher complexity (such as complex data models, large data migrations, and integrations) so that the respective implementation workshops can also be planned.
• Regardless of the project stage and progress, the Solution blueprint workshop is an important exercise and should be done for all engagements.

In the implement phase, the project team is focused on building the solution according to the agreed-upon solution design and scope. Implementation reviews are introduced in this phase, having been informed by the findings and recommendations of the Solution blueprint review. Implementation reviews are used to thoroughly address questions that are related to the specific aspects of the solution design (data model, security, integration) and implementation practices (ALM and testing strategy). Implementation reviews fully address the risks that are identified during or after the Solution blueprint review but before the solution build is too far along in the process.

• Regardless of the delivery methodology, whether waterfall or iterative, the solution architect should schedule the implementation workshops that are planned during the Solution blueprint workshop. However, while the precise methodology is up to each project owner, Dynamics 365 implementations are best suited for iterative and/or agile delivery methods.
• The implementation workshops should be planned before you finalize the detailed design of the component.
• Some implementation workshops won’t be relevant to or targeted at components that are considered low risk, in which case, the corresponding implementation workshop can be skipped.
• During the implementation phase, you can expect questions that are related to the design of specific components, technology choices, upcoming changes, and roadmap, deprecations, application lifecycle management (ALM), and build.
• Make sure that you proactively work with customers to ensure that the developed solution is in accordance with best practices and is strategically aligned to the product roadmap.

By the prepare phase, the solution has been built and tested, and the project team is preparing for the final round of user acceptance testing (UAT) and training. Additionally, all necessary customer approvals have been granted, information security reviews are completed, the cutover plan is defined (including go/no-go criteria), mock go-live events are scheduled, the support model is ready, and the deployment runbook is completed with tasks, owners, durations, and defined dependencies. At this point, the project team will use the Success by Design go-live readiness review to identify remaining gaps or issues.

• You’re also validating the non-functional requirements of the system (like the form load times, search performance, and integration performance under the realistic production load).
• The customer or partner has gone through all internal approvals, information security reviews, penetration testing, and so on, to ensure the production readiness of the system.
• The support model post go live is defined and agreed with the business.
• The cut-over plan, the go-live date, and go/no-go criteria are agreed on with the business, and the production deployment plan has been created with all tasks, owners, start time, duration, and rollback plan.
• The solution architect conducts the Go-live readiness workshop to review the plan and highlight gaps and issues.
• The solution architect also ensures that the proactive performance checks and the solution checker are implemented.

You’ve now planned, developed, and deployed the application, but you’re not finished yet. The goal of this phase is to validate the success of the deployment, review lessons learned from the project, and plan for the transition to the next phase or provide transitional support to the maintenance team.

• After the customer is live, the solution architect should perform a post go-live review.
• Discuss the transition plan and share the same with the maintenance team.