Solution assessment and validation has several objectives:

• - Evaluate organisational preparedness to the proposed change
• - Evaluate performance of existing solutions to support enterprise analysis
• - Assess the proposed solution prior to its selection
• - Validate the designed solution to ensure that it meets the requirements
• - Determine transition requirements for moving from the current state (“as is”) into the target state (“to be”).

Assessment of organisational readiness to changes plays a critical role in a project’s success. The results of the assessment determine the scope of the project in terms of actions to be taken to train personnel, modify business processes, change certain activities and reporting, not to mention changes to behaviour and beliefs. These results also support a definition of transition requirements which describe how the solution should be implemented and released into production with minimal disruption to the existing solutions and processes.

A business analyst performs assessment of the designed solution to ensure that the solution meets the acceptance and evaluation criteria and meets the approved requirements.

When the solution has been constructed, the business analyst validates the solution to ensure that defects are identified, their causes are known and the defects are communicated to the responsible stakeholders.

The business analyst carries out an evaluation of solution performance multiple times within the project. Firstly, an evaluation of performance of the existing solution helps identify weaknesses of the solution and supports the investigation of causes of poor performance. This information feeds into gap analysis conducted within enterprise analysis. Secondly, the business analyst evaluates performance of the solution once it’s ready for deployment in order to ensure that the solution delivers the expected value to the business.

In practice, the business analyst works closely with solution architects, vendors, software developers, testers, technical personnel and change managers, acting a bit like a conductor of a big orchestra to ensure the satisfaction of the listeners.

Acceptance criteria
These define a minimal set of requirements that must be met in order for a solution or a solution component to be considered acceptable to its key stakeholders.   They are defined earl y in the project life cycle and must be met (pass or fail) in order to say that a solution is complete, correct and worth implementing.  Test cases are written that verify the solution against its defined and agreed-upon acceptance criteria.

Evaluation criteria
These define a set of requirements used to choose between multiple solutions to a particular problem.  They are typically built to allow for scoring of the various solutions under consideration.  In order to evaluate potential solutions, this set of requirements is prioritized and ranked by order of importance.  The solutions will then be scored against the ranked set of requirements using a pre-established evaluation scale.  A ‘must have’ requirement that is not met by a proposed solution should remove that solution from consideration.

Elements of this technique include testability and an associated ranking/scoring scheme.  Testable is pretty straightforward – if you build a solution to meet the requirements, you better be able to prove it. Ranking looks at the requirements and their order of importance while scoring determines how well the resulting solution meets those requirements.

This technique focuses on the acceptability of a solution to its key stakeholders.  This includes internal solution users within the organization and external stakeholders such as the solution’s customers. Both acceptance and evaluation criteria may be tied to contractual obligations, which can introduce associated legal and political issues and risks into the project.