Workshop implementation and follow-up

20 minutes

The following sections describe how to implement the Solution performance workshop and then conduct follow-up sessions for more in-depth information.

Solution performance workshop participants

The Solution performance workshop covers a wide range of areas that will involve many different roles on the project team and those who will be using or supporting this solution. Additionally, you will need resources that manage other systems that have dependencies to this solution. In general, participants will fall under these categories:

Representatives from the business who are subject matter experts and can articulate key business processes and expectations on performance and responsiveness of the system.
Representatives from the business and the technical team who can articulate the non-functional requirements.
Implementation team members (customer and implementation partner) with intimate knowledge of the design and implementation methods that are used for configuration, customization, integration, and other aspects of the solution that will be the focus of the Solution performance review.
The testing team that will conduct the performance tests.
IT administrators who can provide information on the environment/tenant strategy and assist with setting up environments for performance testing.

Even for technical discussions, it might still make sense to have business representation so that participants are aware of the impact on their requirements for performance. Scenarios might exist where non-functional requirements are difficult to meet unless the business scope is changed. Because of these scenarios, it is important for business representatives to understand the technical implications so that they can make better decisions when analyzing the need and priority of requirements.

Implement the Solution performance workshop

The Solution performance workshop will be facilitated by the solution architect, but the expectation is that the implementation team will present the solution performance related 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 to 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 2 to 4 hours, that time can be flexible (to a certain extent) to accommodate the implementation.

Time management in the Solution performance workshop is critical. The top priority for the workshop is to get through all relevant content, which should be prioritized over going too in depth in any one session. If the conversation becomes extensive, and you are running out of time to cover the breadth of the subject, you should expect that the solution architect will table the detailed conversations for follow up in a more in-depth workshop.

During each session, participants should expect discussion about the scope and approach. As part of that expectation, the solution 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 performance workshop outputs

The output of the Solution performance 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. Generally, these findings will 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 to 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 risks 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 is viewed 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 meeting will be held to review the findings in detail. The document will go to the implementation leadership and executive sponsors in both organizations. In some cases, these findings documents can be lengthy, in which case, an executive summary that highlights key and critical findings is provided for better consumption by executives.

Addressing all risks and issues is not a guarantee that the solution won’t have performance issues. This exercise is to mitigate risks and address issues of all factors that are reviewed and true at the time of the review. However, with any project are exceptions or new developments that will have an impact. For this reason, the workshop is iterative so that, as new factors are introduced into the solution, the workshop can be conducted again to address new needs.

Subsequent Solution performance workshops

Solution performance is an aspect that the implementation team needs to be aware of throughout the project life cycle. The team will need to plan for solution performance at the beginning of the project and as they go through development and testing. Therefore, subsequent reviews might be required for the following reasons:

Challenges with the initial Solution performance workshop – The project team might not have had all relevant information to properly assess the risks and issues in the initial workshop. Therefore, areas that might have been tabled in the past can be revisited through subsequent workshops.
Significant scope change – In some cases, an implementation is impacted by major changes in scope or approach due to a variety of circumstances. These changes could be due to external factors, but could also be related to significant changes that follow a detailed requirement analysis. As a result, it will make sense to re-review the Solution performance workshop.
Feedback from team – As the solution is developed and tested, opportunities might become available for you to identify problem areas of the solution that weren’t captured in the initial workshop. Feedback from the users through user acceptance testing or administrators from integration testing can provide more details into the actual end-user experience, which might warrant a subsequent workshop.

Solution performance workshop follow-up

After the solution performance workshop has been conducted and the findings have been reviewed, those items that have been identified as risks and issues, and their associated action items for mitigation and resolution, will be managed to completion as part of the overall engagement.

Issues that are identified will often have an impact on the ability to successfully go live. These issues will need to be resolved prior to the go-live readiness assessment and the deployment of a production environment.

Risks and their associated recommended mitigations can be managed according to the overall strategy of the project, but they will be monitored throughout the project. Risks that are not mitigated might be realized later as issues that could also affect go live.