Skip to main content

Projects Tend to be Described in Terms of Solutions

In my last article 5 Things I Wish I’d Known When I Started As A Business Analyst I said I wished that I knew that projects are often described in terms of solutions.

I actually realized this fairly quickly, but it didn’t occur to me to do something about it until a couple of years into my business analyst career.

I thought I was set when I started on a new project and was given a solution that just needed the specifics filled in. It was only after working on a few projects that I began to realize things were not as clear cut as they sometimes seem. I didn’t realize that people have a tendency to hang on to the first solution they think of when they face a problem and fail to question whether that first solution is the best one. As a result, when sponsors are asked to describe a project they inevitably describe that first solution they came up with.

One of your primary responsibilities as a business analyst is to dig into that solution and discover the underlying need. I’ve found a simple approach to accomplish this is to guide a conversation with the sponsor of the project and the team working on it around a problem statement.

Explicitly Discuss the Problem

I was working with a team in the middle of a commission system revision project. There were 11 people involved, including the sponsor, a couple of subject matter experts, and the majority of the delivery team. I wanted to get a better understanding of what the project was all about, and I wanted to find out if the team had a shared understanding of why they were doing the project.

I asked everyone to grab four index cards and a marker.

On the first card, I asked each person to finish this phrase: The problem of… [Describe the problem]

On the second card, I asked each person to finish this phrase: affects… [Who are the stakeholders affected by the problem]

On the third card, I asked each person to finish this phrase: the impact of which is… [What is the impact of the problem]

On the fourth card, I asked each person to finish this phrase: A successful solution would… [List the key characteristics that the solution, however implemented must have to be successful]

One set of cards looked like this:

The problem of: completing the monthly commission process in a timely manner affects: agents, commissions staff

The impact of which is: there is a delay for agents to get paid, commissions staff are constantly harassed by agents right at the time when they are the busiest (running the commissions process)

A successful solution would: speed up the commission process, decrease the number of times agents bother commissions staff

The team member actually states a problem, but then identifies multiple stakeholders who are affected, multiple impacts, and multiple characteristics of a good solution. That’s ok because you are primarily trying to generate information at this point.

Once everyone wrote their cards, I asked each team member to read their statement in order and place their cards on four parts of a table, each part corresponding to a section of the problem statement. If you are using sticky notes, you can have people put the sticky notes on four separate sheets of paper hanging on a wall.

When I had the group build their individual problem statements we ended up with 11 different perceptions of what the project was about, ranging from making some changes to the commission system to make it easier to maintain, to completely overhauling how the organization paid its agents. Needless to say, the team was a bit surprised about the differences in perspectives considering that the project had been underway for a few months. Everyone just assumed that they were “all on the same page” regarding what the project was all about until they did this exercise.

We had already gained value from the exercise because it exposed the disconnect between the group on the real need the project was trying to satisfy. We still needed to take the disparate items and condense them together into a single, consistent, agreed upon statement. I had the group start at the “The problem of” set of cards and agree upon a specific problem. Once the team came to an agreement on the problem, and only then, I had them move to the next the set of cards and repeat the process.

The end result was a consistent statement they all agreed to and could use as a guide to refer to when they were trying to remember, or fill someone else in on, what the project was all about. I didn’t keep track of what the actual statement was – the most important outcome of the exercise was the shared understanding between the team members.

That said, the output from the exercise was useful. The stakeholders identified in the “affects” group provided a hint at whose needs you want to satisfy. The “Impact of” identifies specific things you can look to eliminate, and the “characteristics of a successful solution” hint at potential acceptance criteria.

By working through each of the different portions of the problem statement, we were able to converge to a shared understanding of the purpose of the project. Later, the team members were able to use this as one way of deciding what they should and shouldn’t focus on.

Things to Consider

I did this exercise after the team had already started the project because that’s when I started working with them. Ideally, you’d like to have this conversation when the team is finding out about a new project. I’ve started a project with this conversation several times and found the teams are much better aligned with what they are trying to accomplish from the beginning.

The discussions that occur when formulating a consistent problem statement can also help the team focus. When your team crafts individual problem statements and then looks at all the pieces together, you identify several different problems, stakeholders, impacts, and characteristics of a successful solution. The discussions that occur in the effort to go from many problem statements to one raises issues, risks, and assumptions that everyone on the team may not have been aware of. Talking through those issues, risks, and assumptions helps your team build a shared understanding of the problem to solve and things to consider when picking the appropriate solution.

That’s just one approach I’ve used to extract a problem from a solution. I’m curious to hear what techniques you’ve found useful when you are in the same situation. Please share them in the comments.