Conduct the Solution blueprint review workshop

Completed

The Solution blueprint review workshop will be facilitated by the solution architect, but the expectation is that the implementation team will present the solution blueprint information. Each section of the agenda should be assigned an owner within the implementation team. At the beginning of each session, that owner should present an overview or summary of the scope and plans, including designs that apply to that aspect of the solution. The team should plan for that summary to take between 25-50 percent of the allotted time but no more. The remainder of the time should be reserved for questions and answers with the solution architect.

The implementation team leadership should work with the solution architect ahead of the workshop to shape the agenda and timings for each session. Depending on the state and complexity of the solution, different sections might require more or less time. While the baseline plan is to conduct the workshop in eight hours, that time can be flexible to a certain extent to accommodate the implementation.

Time management in the Solution blueprint review workshop is critical. The top priority for the workshop to get through the overall solution, which should be prioritized over going too in-depth in any one session. If the conversation is going too detailed and you are running out of time to cover the breadth of the solution, you should expect the solution architect to discontinue the detailed conversations for follow-up in a more comprehensive workshop.

Note

You should set an expectation that, during each session, discussion about the scope and approach will occur. As part of that expectation, the architect might provide some guidance directly within the meeting. However, these sessions are not intended to be design sessions but rather review sessions. The provided feedback might alter the current plan or design, but the detailed work in those areas will be carried out by the implementation team after the workshop.

Solution blueprint review outputs

The output of the Solution blueprint review workshop is a findings document. This findings document is a response to information that has been provided as preparation for the workshop or during the workshop. These findings will generally be one of three types:

  • Assertions – These findings relate to specific aspects of the solution that the solution architect wants to call out as architecturally significant. These assertions are factors that might not represent a specific risk or issue but are foundational to the solution and should be noted because, if changed, they will have significant impact. These assertions might relate to specific scope items, design aspects of the solution architecture, or implementation approach or technique.
  • Risks – These findings represent an aspect of the solution or implementation approach that constitute a risk that should be tracked on the project. These findings could relate to existing plans, approaches, or designs that have an observed potential for negative outcomes. They could also be related to areas of the solution that have not been adequately explored yet, and as such, represent a risk that something unexpected could come up. These findings will be accompanied by a statement of what the solution architect views as a risk along with recommended mitigation steps.
  • Issues – These findings represent an aspect of the solution or implementation approach that constitute an issue that is negatively impacting the implementation, or if not corrected, will have a negative impact in the future. These findings will be accompanied by a statement of what the impact is or will be, along with recommended resolution steps.

The findings document will be distributed to the customer and partner organizations, and a review meeting will be held to assess the findings in detail. The document will go to the implementation leadership and executive sponsors in both organizations. The findings documents can, in some cases, be lengthy, in which case, an executive summary that highlights key and critical findings is provided for better consumption by executives.

Note

The output of the Solution blueprint review workshop is not a solution blueprint. The expectation is that the materials that the implementation team brings into the review comprises the solution blueprint. The expectation is that the blueprint will continue to evolve and expand as the implementation progresses.

Subsequent Solution blueprint reviews

In most cases, the Solution blueprint review that is performed at the beginning of the implementation, supplemented by in-depth workshops, is sufficient for that implementation. Occasionally, subsequent reviews are required. The following examples are scenarios where additional Solution blueprint reviews might be required:

  • Challenges with the initial Solution blueprint review – In rare cases, the Solution blueprint review workshop is unable to cover all required information. The reason could be that major gaps or conflicts in the understanding of the scope have occurred, and they need to be worked out by the implementation team. Another reason could be due to a significant lack of a conceptual solution design. In these scenarios, going through the initial Solution blueprint review workshop early is valuable because it highlights these issues so that they can be resolved, but it will require the workshop to be repeated.
  • Significant scope change – Occasionally, an implementation is impacted by major changes in scope or approach due to a variety of potential circumstances. This situation could include changes due to external factors, but it could also be related to significant changes that follow detailed requirement analysis. Following such a change, it will make sense to reassess the solution blueprint.
  • Organizational changes – Periodically, organizations will experience significant change during an implementation. Events like mergers, acquisitions, or divestitures can significantly impact a solution architecture and might necessitate reevaluation.