Beyond-RequirementsI’m excited to announce that the book I’ve been working on for the last three years is available! In celebration (and a little promotion), I thought I would share an excerpt. I chose the excerpt below because it discusses some helpful concepts for analysts, regardless of whether you are working in an agile setting or not.

Needs and Solutions

In the Preface for Beyond Requirements, I describe analysis as the activities involved with:

  • Understanding stakeholders
  • Understanding context
  • Understanding the need
  • Understanding the solution(s)
  • Organizing and persisting solution information

It occurs to me that some key definitions are in order. For that purpose I’d like to refer to the Business Analysis Core Concept Model (BACCM) from the Guide to the Business Analysis Body of Knowledge Version 3 (BABOK v3), which defines six core concepts.

The core concepts that are most relevant here are need and solution as they describe the subject of analysis. It is important to understand the difference between the two concepts, because many IT projects suffer from not having determined the need before charging forward with a solution.

You probably already know that before starting an IT project you should under-stand why you are doing it—in other words, what problem you are trying to solve. If you understand the problem you are trying to solve, or the opportunity you’re trying to exploit—the need—you have a better chance of picking the most effective solution and avoiding needless time and effort creating a solution that is not needed. Yet I suspect you can also name several IT projects you were on where your team skipped understanding the problem and dove into delivering the solution you were handed. I know I have been involved in my fair share of those projects.

Why do teams repeatedly skip understanding the need, even though they generally know it’s good practice? Sometimes it can be pressure from sponsors who have fixated on a particular solution and are suffering from some of the cognitive biases described in Chapter 4. More likely, teams don’t know how to describe needs in a way that helps them determine the appropriate solutions. Fortunately, such techniques exist, and they have been under our noses the whole time: business goals and objectives.

The BABOK v3 provides the definitions of business goal and business objective (which for the purpose of this book I’ve shortened to goal and objective) as shown in Table 2.2. The nice thing about these definitions is that they provide a way to differentiate these two concepts that are easily confused.

To put it more concretely, a goal is what we want to accomplish (the need we want to satisfy); an objective is how we measure how successful we are in accomplishing a goal. In this book, I am very intentional about when and where I have used each term.

TermDefinitionHealth Insurance Example
GoalA state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively.Increase the ability to handle an expected increase in claims.
ObjectiveA measurable result to indicate that a goal has been achievedReduce paper claims from 1,000 per week to 500 per week by 12/31

Since objectives are intended to be measurable, it’s helpful to keep a set of characteristics in mind when you establish them with your team. They are commonly referred to as SMART and are described in Table 2.3. Note that there are different variations of what the acronym stands for, and I chose to use the formulation where A stands for “agreed upon” to reinforce the idea that when your team agrees on what the objectives are and what they mean, there is a better chance they will have a shared understanding of what you’re trying to accomplish.

SpecificYou know exactly what you’re trying to achieve and you have clear expectations.
MeasurableYou need to be able to tell when you are making progress toward your objective.
Agreed UponEveryone involved in meeting the objective needs to agree on what the objective actually is, that it is worth meeting, and how you will know when you have met it. This concept reinforces the idea of shared understanding. It’s no good having an objective that’s attainable if the entire team of people trying to reach it don’t understand it, or don’t think it’s the right objective.
RealisticYou don’t want to frustrate your team by giving them an objective that is impossible to reach. You may have to stretch a little bit, but you’re not doing yourself any favors by setting an objective that has absolutely no chance of being met given the constraints under which the team is working.
Time FramedYou have to know when you expect to be done. Otherwise you can keep going on forever and end up never really accomplishing anything.

To help reinforce the characteristics of good objectives, Tom Gilb in Competitive Engineering suggests the set of attributes shown in Table 2.4, which you can identify for each objective.

NameUnique name for the objectiveReduce paper claims received per week.
UnitsWhat to measure (Gilb refers to this as scale)The number of paper claims received per week
MethodHow to measure (Gilb refers to this as meter)Count the number of claims received per calendar week with a submission type of paper
TargetSuccess level you’re aiming to achieve500 claims/week
ConstraintFailure level you’re aiming to avoid1,000 claims/week
BaselineCurrent performance level1,000 claims/week

Note in this example that the constraint is the same as the baseline. What this indicates is that if this were an objective for your project, and you were not able to make any change to the number of paper claims you receive in a week, the project is considered a failure, but any improvement is at least a step in the right direction. In other cases, you may find the constraint set as an intermediate value between the baseline and the target, meaning the project would be a failure if you don’t accomplish at least some improvement. An important aspect of value that comes out of setting these attributes is the discussion that occurs in order to decide what the target and constraint should be, as it allows the team to get a clearer understanding of what success looks like.

Understanding the need first and being able to describe it via goals and objectives gives you the opportunity to build a shared understanding with your team surrounding why you are considering starting (or continuing) a particular project. It also gives you a basis for asking the question “Is this need worth satisfying?” So in the paper claims example in Table 2.4, the team can ask:

  • Is it worth it to increase our ability to handle paper claims right now?
  • Why do we think there is going to be an increase in claims received?
  • Are paper claims the biggest hurdle to our ability to handle claims?
  • What are we forgoing by increasing our ability to handle paper claims?

Separating consideration of need from solution allows your team to identify multiple potential solutions and have options to pick from when it’s time to deter-mine the specific solution that you will deliver. Having those options increases the chance that your team will effectively deliver a solution that meets the needs of your stakeholders while keeping within constraints such as time and budget.

Separating consideration of need from solution also helps to clarify responsibilities between stakeholders and teams. Needs come from your stakeholders, specifically sponsors, while solutions come from your team. Reality is not that clear-cut. Your team certainly helps your stakeholders describe the need in a useful fashion, and your team certainly needs to collaborate closely with your stakeholders to identify potential solutions.

Finally, separating need from solution also ties in nicely with a change in mindset that comes along with a focus on delivering value—the move from being concerned about output to being concerned with outcome, which is dis-cussed more in the next section.

Outcome and Output

When your team builds a shared understanding of the need your IT project intends to satisfy, you effectively understand the intended outcome of the  project. Outcome is the change in the organization and changes in the behavior of stakeholders as a result of an IT project. You don’t know what the outcome of your IT project is until you deliver something—the output—and observe how that output impacts the organization and your stakeholders. Output is anything that your team delivers as part of your IT project. This includes software, documentation, processes, and other things that tend to be measured in order to gauge how the project is going.

The problem is, the goal of IT projects, or any efforts for that matter, is not to produce output; it’s to reach a specific outcome. In fact, as mentioned in the section on “Deliver Value” in Chapter 1, a successful IT project seeks to maximize outcome with minimal output. Why do you want to do that? Well, you want to maximize outcome because that represents the change you want to see in your organization and your stakeholders’ behavior (or as Jeff Patton says, in his book User Story Mapping, the change you want to see in the world). At the same time you want to minimize output, because that means less work to pro-duce the output, and less work to maintain the output, freeing you up to deliver other outcomes. It ties into the agile principle “Simplicity—the art of maximizing the amount of work not done—is essential.”

As mentioned in the section on “Deliver Value” in Chapter 1, you want to change the way you define and measure progress and ultimate success. You no longer want to measure progress based on how much output you’ve produced (i.e., features delivered, velocity, and the like). Rather you want to measure how you are doing on reaching the desired outcome. This can be more difficult because outcome is not always as easily measured. Goals and objectives certainly help, as do leading indicators, discussed in the “Metrics” section in Chapter 3.

To look at it another way, satisfying the needs of your stakeholders is the outcome you seek, and the solution you deliver to satisfy those needs is the out-put you use to reach your desired outcome.

– Kent

This was an excerpt from Beyond Requirements: Analysis with an Agile Mindset from Addison-Wesley, ISBN 9780321834553, published in September 2015. Available wherever fine technical books are sold (InformIT or to name a couple of places). Get Your Copy Today!

Pin It on Pinterest

Share This