One of the most useful pieces of advice I’ve had on analysis is from Tom Gilb, when he talks about separating solutions (which he calls “design ideas”) from the outcomes we want to achieve. He’s primarily addressing the early stage of a project, before the build has begun. But it’s also relevant to the build stage itself if certain low level areas of the system haven’t been specified in detail previously.

It’s easy to fall into the trap of mixing up solutions and outcomes. We often read documents that say “We need a new CRM system”, or “The goal is to introduce NoSQL databases to ensure greater flexibility with our data”. In the first case it’s unclear whether the desired goal is a new CRM system (probably not an end in itself) or whether it’s a solution to a particular problem (more likely, but then what is the problem?). In the second case there is reference to wanting greater flexibility with our data, but it’s mixed up with a (possible) solution, which is to use NoSQL databases.

Separating solutions from outcomes (or means from ends, to put it another way) has advantages both on the solutions side and on the outcomes side.

On solutions: It allows us to evaluate a solution more objectively against the outcome. If we want greater flexibility with our data then perhaps NoSQL databases might help. But other solutions may also exist, and we can discuss them individually, evaluating each one against the desired outcome. Thus we get more options and are more likely to come up with a better solution.

On the outcomes: Separating the outcomes makes it much clearer what the end goals are. We can also then scrutinise the outcomes more effectively. Do we want greater flexibility? In what respect, exactly? What does that look like in practice?

There are advantages, too, when matching the solutions and outcomes. We are likely to draw out a number of desired outcomes if we question the original statement, and that is likely to draw out a few different candidate solutions. Each of these may meet each of the outcomes to different degrees. And that in turn allows us to evaluate a wider range of solutions more effectively.

Overall separating solutions and outcomes is much more likely to lead to an optimal result.