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

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-most important element when making any key decision and adjusting 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 detailed document called the Solution Design Document (SDD) is also recommended for in-depth documentation of the solution details, using the solution blueprint as the foundation.

Following diagram is a sample solution blueprint spanning all business processes, tools, legacy applications, and top sub-processes:

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

We recommend a checklist for a typical solution blueprint, as follows:

• Are all the business processes and sub-processes covered?
• Are all the requirements (functional and non-functional) addressed?
• Has any other solution being used 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?
• Is a supporting SDD prepared?

While preparing the solution blueprint and during the requirements analysis, decisions are often to be taken. We recommend to leverage a key decision log to register them, which is explained in the next section.