BACCM: Impact on Knowledge Area 6. Solution Evaluation

BACCM: Impact on Knowledge Area 6. Solution Evaluation

This post wraps up this series with a discussion of how the BACCM relates to Solution Evaluation. In its introduction of this knowledge area, the BABOK guide makes an important distinction between Solution Evaluation from either Strategy Analysis or Requirements Analysis and Design Definition – that Solution Evaluation is performed against work that has been done, where the other Knowledge Areas are looking at future work. For this post, when I talk about delivered work, that can be a prototype, beta, product increment, or full release of the product.

Solution Evaluation asks questions such as:

  • Does this do what is needed?
  • Does it perform well?
  • Are changes needed to the work that has been done?
  • Is the need satisfied?
  • Can the need be satisfied?

How does the BACCM interact with Solution Evaluation? The chart below gives a summarized answer to that question.


The Core Concept of Change allows looking at what has been finished and decide that a course correction is needed. That correction could be an adjustment to adjust what has been done, change the future planned work in some way, determine the product meets the need or never will.


All of the analysis is to be measured against the need. There are several factors in this analysis:

  • Changes to the organizational environment, which changes the need.
  • The expense of the solution may be significantly higher than anticipated.
  • The organization may have overestimated their capability to deliver the solution – it may not be possible.
  • The time to deliver may be more than anticipated (likely also reflected in costs).

There are four options which could result from an analysis of these factors:

  • If the delivered work continues to provide hope of meeting the need but has not completely done so, then the project should likely continue.
  • If the delivered work meets the need, but additional features are determined to be valuable, a decision to extend functionality beyond the minimum viable product may be made.
  • Or, if there are no desired other features and the delivered work already meets the business need, the project will end with the delivered work.
  • Finally, if the analysis factors (environment, expense, capabilities, time) are weighed, and the project never will meet the need, it should be discontinued.


It may be a bit redundant, but it is the delivered portion of the solution that is analyzed by comparing it to the need. It may be possible to measure the realized value delivered as compared to the anticipated or potential value that was proposed.

In Agile environments, it is essential not to conflate effort with value as part of Solution Analysis. For example: If I take a job that pays $30/hour and a friend does the same role at another company for $25 – the effort may be the same but the value is not. Value is determined by the benefit received, not the effort used to obtain it.


At some point, the stakeholders will have the opportunity to review the delivered product and determine how well it meets their needs. They will be considering the question of how well it provides value. As an analyst, our job is to help their observations have a voice – determining whether the value is delivered, whether changes are needed, or whether the need cannot be met.


Here again, we need to recognize that need is only half of the value equation. From a financial standpoint, value = benefit – cost, where the benefit is the monetized representation of the need. There may be other ways to determine value based on some non-financial considerations, such as regulatory compliance. Yet still, when we consider value, this goes beyond merely considering the need.

Before the work, there probably was a determination of how much benefit would be received and an anticipated cost. So the Core Concept of Value measures that prediction against reality.


Previously we mentioned that a change in the organization’s environment might also mean that the need has changed. Several organizational factors may be in play. This may include any of the following:

  • External factors, such as changing public opinions or values.
  • Regulatory changes may alter what is required.
  • Organizational changes, such as changing corporate purpose, leadership, structure or viability.
  • Technological changes, such as new publicly available services.
  • Competitive changes where a competitor enters or leaves a market position.

This site uses Akismet to reduce spam. Learn how your comment data is processed.