Implement Success by Design
This unit describes how the Success by Design process should be implemented, from using the template to presenting the findings and recommendations. Success by Design is designed to be flexible; you can adapt it to your delivery style. However, the structure of your delivery should be clear enough for anyone to follow.
Align expectations
Success By Design is intended to help the solution architect be more proactive during their engagement with the project teams, discover the customer's goals, understand what was designed in terms of architecture, and identify and avoid areas where project teams often run into issues during projects.
The solution architect should be considered a trusted advisor who uses the knowledge and experience from working on other projects and shares that experience and best practices to help avoid issues. Accordingly, the solution architect can help ensure that the customer can go live confidently and successfully.
In an engagement, the solution architect needs to make sure that stakeholders understand the goals of the workshop deliverables and why they're important.
In the Solution blueprint workshop, you can expect to gain insights that you can use in the project (plan, milestones, goals, scope, and so on.). This workshop is beneficial for the project team during implementation because it helps them create a plan for what will be built (integrations, interfaces, solutions, and so on.), determine at what stage the project will be delivered, and ensure that the project plan is aligned with all stakeholders and project scope.
The goal of the Implementation workshop is to be proactive by thoroughly examining areas where the most common issues can affect project plans and milestones, and then identify and raise awareness of risks and functionality gaps. By identifying these risks and gaps, you can create a plan to mitigate risks and avoid common deployment problems.
In the Go-live readiness workshop, the goal is to understand and help shape the customer's go-live strategy and compare this strategy with best practices. With this approach, you can help avoid surprises during go live, the most critical phase of the project.
Workshop outcome
After each workshop, the solution architect will prepare a list of findings and recommendations based on what was learned during the workshop. A follow-up meeting should be scheduled to discuss recommendations as needed.
While the solution architect will be thorough in the workshops, it's not expected that every possible concern about the project will be raised and that all project issues will be avoided. The solution architect will only be reviewing the information that is shared by the customer and partner teams, and if any piece of information is not shared (or not shared to a sufficient level of detail), that information won't be included in the review.
The reviews are performed by comparing best practices and experiences from other engagements with your project and business processes. Though you can’t assure attendees that issues won’t arise during a project, you can emphasize the importance of understanding the information that is and isn't assessed during the review.
Considerations that you should be aware of regarding the workshop outcome include:
Quality of the code that the developers have written isn't validated by Success by Design. While ways of checking the code exist, those validations won't confirm code logic.
Solution architecture is reviewed at a high level, but granular details about how it's been built will not be reviewed. For example, if you have a Power Automate flow that was built for a specific purpose, don't review the design of the flow. If the flow uses 10 steps to do what could have been done in only two steps, it is out of the review scope.
The architecture, integrations, interfaces, and design are checked at a high-level view to determine if the solution is best aligned with available options, best practices, and Microsoft roadmap. An example of this situation is if you decide not to use an on-premises virtual machine because it might be in a Microsoft Azure location that is in the same data center as the customer's Dynamics 365 environment.
Prepare
After the customer and partner teams understand why the workshops are needed, you can send them the workshop templates, which are short and simple and provide notes that explain the goals of the questions that are asked in each slide. The short templates help minimize potential resistance that the customer and partner teams might have in providing the information that you are requesting.
The solution architect should send the PowerPoint template to the customer and partner teams at least one week before the workshop is scheduled, which will give them time to receive it and add requested information. Adjust this time recommendation depending on the complexity of the deployment or if new features have been added that you want to investigate first.
When you receive the revised PowerPoint file from the customer, schedule time on your calendar to review the information that they provided in the file and then start preparing the delivery of the workshop.
Workshop preparation starts by knowing the audience. The solution architect should work with the project teams to identify who should attend, which will vary by topic of the workshop.
If the audience is large, and a mixture of many different roles and departments, consider splitting the workshop into multiple sessions. The risk of overrun is high when the audience is too large or diverse.
Prepare and send an agenda to the attendees in advance of the workshop. Include session times and named resources in the agenda. This preparation will allow attendees to provide feedback if they think that more time will be needed and help keep to the agreed-to time for each topic during the workshop.
Deliver
During the workshop, content should be presented by the customer and/or partner as appropriate. While the customer and/or partner deliver the content, you should take notes. A good practice is not to interrupt the presentation and wait until the end of each slide before asking questions or waiting for the presenter to pause.
The workshop delivery should sound like a conversation and not an inquiry. Keep the questions short and relevant. The workshop delivery should always start with the agenda and takeaways and then finish with the next steps. You need to help ensure that everyone understands what will happen next.
After the workshop, review your notes and update them while the information is fresh in your mind. Verify that your notes are complete because they will be the basis of your findings and recommendations.
General guidance for a successful workshop
The following guidelines will help you conduct a successful workshop:
Each meeting might include people who were not in previous sessions, so you should always start a workshop session by introducing yourself and by being prepared to include your background and experience with Dynamics 365 or Microsoft Power Platform.
Make sure that someone takes notes during every session. You might not always be the note taker (especially during face-to-face meetings), but always verify that someone is taking detailed notes, and then get a copy of the notes following the session.
Be confident in your experience and knowledge and share that with the team.
Read the audience to help understand their technical level. Keep to the agreed technical level of the workshop. For example, a solution blueprint review will be high level, and you should stop if it's too in-depth. It's better to schedule a follow-up session than overrun or be tight on time in the current session.
In business sessions, do not focus on the how; you need to understand the why.
In technical sessions, don't forget the why, even if focus is on the how.
Capture all actions and open topics as you go through the session. However, ensure that you have 5-10 minutes at the end of the workshop to summarize the actions.
Follow-up
After workshop delivery, the solution architect should prepare findings and recommendations. This preparation can be time-consuming, so be sure to give yourself enough time when scheduling the follow-up discussion. Meeting notes and agreed-on follow-up actions should be sent to participants and needed stakeholders within 24 hours after the session. Follow-up actions should include the responsible party and deadline. If no deadline has been agreed to, use TBD. In the meeting notes, share issues and risks.
Workshop steps
The workshop involves three key steps:
- Information capture
- Run the workshop
- Create recommendations and findings
The project solution architect, or someone who's not on the project daily, can conduct the workshop. The benefit of having a non-project assigned solution architect conduct the workshop is that it will be similar to how FastTrack projects run. Often, this approach offers a project team additional insights that come from a project outsider.
Information capture
While all projects do have some level of documentation, the level of documentation and format can vary depending on the stakeholders, project scope, and project methodology. The workshop template is designed to collect the information that is relevant to the project's success measures and document them in a structured fashion. Frequently, the project teams have this information handy and they can copy from existing project documents. However, it's not uncommon for information to exist in multiple places and be difficult to consume and share with the teams. As a part of this step, the solution architect can share the workshop template with the customer and ask them to fill out the information and return it at least five days before the workshop is scheduled to happen. This step will allow sufficient time for review.
Tip
Work with your stakeholders closely on information capture. Provide them with the necessary help to fill out the template, and you can prefill the information that you already know. In some cases, stakeholders might also share the complete document, which might require additional time to review and filter out relevant information. The quality of information that is exchanged will impact the quality of recommendation and will set a precedence for other workshops.
Run the workshop
The workshop can be conducted on site or by using an online meeting. Typically, the decision to conduct the workshop on site or online will be based on the complexity of the project, risks, and customer size. As part of this preparation, the solution architect should review the completed templates and prepare additional questions and comments for further clarity.
Schedule the workshop to ensure that the key stakeholders have accepted. The completed template will be the primary workshop artifact.
Adjust or customize the deck for customer or project-specific topics and questions.
During the workshop, review each topic with the customer and share your understanding.
Ask questions to gain further clarity as needed. Review the questions that you captured for each topic while reviewing the workshop template for each topic. The intent isn't to share these questions directly with a customer but to use them during the workshop to drive the conversation and assess the client's readiness on the related topic/success metric.
Create recommendations and findings
After the solution architect has gained an understanding of the client, project scope, and solution, they should be able to highlight the good practices and deployment patterns that should be followed. They should raise visibility for potential risks, such as potential scalability or performance issues. You should document your findings and categorize them as risks or recommendations.
Risks - Require follow-up actions, such as not planning for adequate failure testing of key integrations. Often, risks will also be discovered as review and discussions happen during the workshop.
Recommendations - Include areas that need to be reviewed to make the solution more consistent and reliable and help move the project to a successful completion. For example, frequently, you might discover that adequate configuration isn't available to allow testing integrations in multiple environments. Make sure that your recommendations are actionable and clear.