Microsoft Solution Blueprint Reviews.pdf
- 1. Success by Design Solution Blueprint Review
- 2. An Overview of Solution Blueprint Review
- 3. Solution Blueprint Review Why? • Ensure that the solution scope and details are understood in a structured manner • Ensure that the solution design concepts are sound • Drive communication within the implementation team • Prevent issues and mitigate risks at an early stage of the project • Provide a baseline understanding to plan other Success by Design activities on When? • The Solution Blueprint review should be run at or near the project start or the Initiate phase of the project, just before the primary implementation activities start • At the minimum, the implementation team must be prepared to share the information in the available Solution Blueprint template • If the implementation team pushes back, remind them the Solution Blueprint Review is the first step in process and provides context for all other guidance and offer to discuss the high-risk gaps in the review • Prepare and detail the Solution Blueprint in a common template that the FastTrack team provides • Present and discuss the details of the Solution Blueprint with FastTrack team • Collaborate with the FastTrack team in identifying risks and potential issues existing in the Solution • Take on actionable insights back to the Solution, to reduce the risk and address the issues How?
- 4. KNOW Solution Blueprint Review Process Understand the steps from beginning to end PLAN EXECUTE PRODUCE REVIEW PUBLISH FOLLOW UP 1 2 3 4 5 6 7 Make sure that you are familiar with the review topics, items and questions that you will cover in the workshop. Determine the required inputs, attendees, and execution mode… then get it scheduled. Review the input materials and conduct the workshop to collect your findings. Produce the findings from the review, classify them as issues risks and assertions and provide recommendations. Review a draft of the findings and recommendations with the implementation team. Publish the finalized findings and recommendations Work with the implementation team to ensure risks are mitigated and issues are resolved.
- 5. Breaking down barriers to participation We expect big changes following analysis and solution modeling. Let’s wait until we get through those activities to review the blueprint… We’re not ready to review the blueprint yet…. we just started the project… Most projects have a scope, budget and target go-live date defined as part of the engagement agreement that the customer has with their implementation partner. The presence of these implies the existence of at least a conceptual solution and implementation approach. This forms the basis of the blueprint. • If we are missing scope, budget or target go-live date there we have inherent risk. • If we have scope, budget or target go-live date with out a conceptual solution design we have inherent risk This is another way of saying that we have no confidence in the conceptual solution and by proxy the scope, budget and target go-live date. • It is critical that all parties involved have the same understanding of the state of the solution. Doing a blueprint review will help reinforce that understanding and define non-negotiable constants that cannot change during analysis and solution modeling Solution Blueprint Review is the first step in process and provides context for all other guidance and offer to discuss the high-risk gaps in the solution blueprint review
- 6. Planning for the Solution Blueprint Review
- 7. Solution Blueprint Review Preparation Prepare for the workshop by gathering the details of the solution such as: Process Catalog Data Strategy (Entities / Migration Scope) Deployment Locations Process Block Diagram Integration Strategy (Interface Register) Project Charter Application Diagram Analytical Data Aggregation (Scope) Project Plan / Schedule Key Gaps Environment Strategy Responsibility Matrix ALM Strategy System Usage Profiles Test Plan / Strategy Business Unit / Legal Entity Structure Security Strategy Production Instance Strategy
- 8. 1 Hour 3 Hours 4 Hours 5 Hours 6 Hours 7 Hours 8 Hours How long does a solution blueprint review workshop take? 8 Hours + Time 2 Hours Single CE App Multiple CE Apps Dynamics HR Dynamics Finance Multiple OAG Apps OAG and CE Apps Other Factors How much is known up front? How early in the project is the workshop? How complex is the implementation? How standard is the approach? Workshop Duration Differs By Project On FastTrack engagements for customers investing $100K - $300K, the Microsoft FastTrack architect does not attend this workshop. Microsoft FastTrack spends approximately 45 minutes reviewing the workshop outcomes.
- 9. Solution Blueprint Workshop Execution Modes Delivering the workshop onsite and in person can be a great way of meeting the implementation team and building a working relationship. When done onsite the workshop is generally compressed into a single session with a set agenda to allow subject matter experts to join as needed. Session 1 Program Strategy Test Strategy Business Process Strategy Application Strategy Data Strategy Integration Strategy Intelligence Strategy Security Strategy ALM Strategy Environment & Capacity Strategy When executed remotely via Teams the workshop can be broken up into smaller sessions that can be more flexibly scheduled over the course of a few days. This example shows how you might break down an 8-hour review into multiple 2 hours sessions. Session 1 Program Strategy Test Strategy Session 2 Business Process Strategy Session 3 Application Strategy Data Strategy Integration Strategy Session 4 Intelligence Strategy Security Strategy ALM Strategy Environment & Capacity Strategy Option 1 - Onsite Option 2 - Remote
- 10. Workshop Participants Customer Project Manager Partner Project Manager Partner Architect Customer Architect Partner Subject Matter Experts For $100K - $300K customer implementations, the partner organization should provide both the architect that is responsible for the implementation as well as an architect that is responsible for conducting Success By Design for the implementation. These are not the same person. Customer Subject Matter Experts Mandatory As Needed Team members in implementation leadership roles should plan to attend the entire review. Team members with specialist roles may only attend sessions specific to their role. Workshops that exceed 10- 12 participants may struggle with efficiency.
- 11. Executing the Solution Blueprint Review
- 12. Solution Blueprint Review Execution Tips Go deep enough to find a problem. Don’t solve it in the workshop. Balance Breadth and Depth • Its better to get through each topic at a high level than 1 topic in detail • Once you identify the risk or issue move on • “Parking Lot” large areas of uncertainty for follow deep dives Not covering something is different then asking and not getting an answer “I don’t know” is a Finding • If the team is not ready to discuss a topic at all the assumption should be that there is no plan in that area. • Lack of the ability to make an assertion means there is uncertainty. The solution blueprint is by design a wholistic exercise to establish context No Partial Reviews • The solution blueprint establishes a baseline on which you base the rest of the program • It is risky to provide advice on any topic without context
- 13. Solution Blueprint Content The following section provides examples of key points within each topic and some of the elements that a reviewer might be looking for. These are not an exhaustive list of questions. The baseline questions are meant as a starting point to drive a conversation in which there will be opportunities to discover potential issues and risks. This conversation will be slightly or significantly different depending on the individual implementation. The Workshops The Questions The Patterns Workshops and engagements to create opportunity for impact Inspection points to allows us to activate the opportunities The knowledge that can be shared to drive impact for customer success
- 14. Goals and Objective Governance and Methodology Project Schedule Requirement Gathering Approach Requirement Management Approach Program Strategy What are we talking about? What are we looking for? What does customer success look like? Is there a known methodology in place? Is it realistic? Are we gathering “to-be” requirements from the right sources in the business? Do we have the right process and tools in place to manage requirements and traceability?
- 15. Approach Duration Schedule Responsibility Preparedness Test Strategy What are we talking about? What are we looking for? Are the right types of tests planned? Has enough time been allotted to be successful? Is the testing happening at the right times? Are the responsibilities clear? Are the responsible parties capable of performing testing?
- 16. Scope Structure Management Complexity Business Process Strategy What are we talking about? What are we looking for? Are there risks around what is being implemented? Is the process architecture known and structured? How is process used in the management of the solution? Are there factors that complicate the process architecture?
- 17. New Packaged Components Legacy Components New Developed Components Application Strategy What are we talking about? What are we looking for? Which ones and how are the going to be used? Which ones and how are the going to be used? What and why?
- 18. Master Data Transactional Data Migration Scope Migration Approach Volumes Data Strategy What are we talking about? What are we looking for? Do we know what master data will be managed in the system? Do we know what transactions will be facilitated in the system? Do we understand detailed migration scope (entity & source)? Are responsibilities clear and responsible parties capable? Do we have volumes that require special consideration?
- 19. Interface Scope Interface Technology Approach Throughput and Response Time Middleware Integration Strategy What are we talking about? What are we looking for? Do we understand scope at the interface level? Does the team understand the available patterns and usage? Do we know the key non-functional requirements? Is there a solid design for integration management?
- 20. Scope Requirements Approach Technology Strategy Data Sourcing Intelligence Strategy What are we talking about? What are we looking for? Is there a clear scope of the use of BI in the solution? Are requirements tied to process requirements? Does the design include the use of the latest stable technologies? Do the needs for sourcing data for BI add complexities and risk?
- 21. Authentication Network Access Compliance Data Residency Data Privacy Security Strategy What are we talking about? What are we looking for? Are the capabilities and constraints related to authentication understood? Are the capabilities and constraints related to network access understood? Is the scope of compliance requirements understood? Are the requirements and constraints related to data residency understood? Are requirements and constraints related to data privacy understood?
- 22. Preproduction Instance Strategy DevOps Continuous Updates Configuration Management Application Lifecycle Management Strategy What are we talking about? What are we looking for? Is there a strategy in place that supports the project approach? Does the team have a strategy for the use of DevOps? Have the requirements and constraints of continuous update been considered? Is the team aware of operating schedules and volumes of the solution?
- 23. Production Instance Strategy Business Continuance and Disaster Recovery Location Deployment Scope System Volumes and Operating Schedule Environment & Capacity Strategy What are we talking about? What are we looking for? Has the number of production instances been determined and how? Are the BCDR capabilities of the solution components understood? Are there challenges with in-scope deployment locations? Is there a structured approach to managing configurations?
- 24. Complete the Solution Blueprint Workshop
- 25. Solution Blueprint Outcomes PRODUCE REVIEW PUBLISH $100k - $300k >$300k Partner review architect prepares findings and recommendations and reviews with FastTrack Partner review architect reviews the findings and recommendation with the customer and partner implementation team Partner review architect publishes the findings and recommendations to all implementation stakeholders FastTrack architect prepares findings and recommendations FastTrack architect prepares findings and recommendations FastTrack architect publishes the findings and recommendations to all implementation stakeholders
- 26. Thank you!