A solution blueprint is the ultimate visual in a project. It's a midway checkpoint, and its acceptance means that the project now changes from the assessment phase to the building phase. A solution blueprint is always best when represented in an end-to-end flow diagram that shows all the solution elements that have been envisioned and agreed to be leveraged from here on out.

A typical business blueprint must cover everything that the business is going to leverage in their future state operations. The solution blueprint is now the central and most important element when making any key decision and adjusting the scope, and going forward, it will be leveraged in almost all the deliverables in the project.

All project stakeholders should have access to it, must have a voice to suggest optimizations, and must be involved in accepting the solution blueprint.

A much more detailed document called the Solution Design Document (SDD) is also recommended for in-depth documentation of the solution details, and the solution blueprint should be used as its foundation.

The following diagram is a sample solution blueprint that spans all the business processes, tools, legacy applications, and top subprocesses:

We, as solution advisors, often take the preceding solution blueprint one step forward and align the Dynamics 365 terminology in order to leverage the fit-gap analysis of requirements.

We recommend the following checklist for a typical solution blueprint:

• Are all the business processes and subprocesses covered?
• Are all the requirements (functional and non-functional) addressed?
• Has any other solution in the solution matrix been depicted and documented?
• Are all the interfaces specified?
• Are all the solution elements or apps specified?
• Are all the pilots or phases in a CRP covered?
• Has a supporting SDD been prepared?

While preparing the solution blueprint and during the requirements analysis, decisions need to be made. We recommend leveraging a key decision log to register them.