PM Articles > Kent McDonald > What Problem Are You Trying to Solve?

What Problem Are You Trying to Solve?

by Kent McDonald

In some cases, your delivery team doesn't know what product or asset they are working on, or it is better not to have them jumping to a solution yet. You may be trying to decide whether to buy an existing solution or build a new one. You may even be trying to decide whether it makes sense to build anything at all. When this happens, it's better to back up a little and consider whether everyone has a good understanding of the problem you are trying to solve. A useful technique in this situation is the problem statement.

The problem statement is a structured set of statements that describes the purpose of an effort in terms of the problem it's trying to solve. I first saw the problem statement in Ellen Gottesdiener's book The Software Requirements Memory Jogger. The components of the problem statement are:

The problem of [Describe the problem]
Affects [The stakeholders affected by the problem]
The impact of which is [What is the impact of the problem]
A successful solution would be [List the critical benefits or key capabilities that the solution, however implemented, must have to be successful]

This format describes things in term of a problem, but also provides some context around who is most concerned about the problem and why. The problem statement also focuses on characteristics of the solution, but without describing the solution itself. That fact makes this technique helpful when a delivery team is dealing with a potential build/buy situation and needs a way to organize their thoughts.

To get an idea of what a problem statement may look like, consider this example for a conference submission system.

The problem ofSelecting conference sessions
Affectspresenters
The impact of which isthey frequently do not receive actionable feedback on their session proposals or know why they were or were not selected
A successful solution would be
  • Open and transparent
  • Provide presenters with actionable feedback on their proposals
  • Allow presenters to revise their proposals to improve their chances of being selected

This technique could very easily become a "check the box" exercise, where people complete it for the sake of completing it. To avoid that, I've found a way to make creating the problem statement an interactive exercise good for sparking a great deal of conversation.

Get the sponsor, stakeholders, and delivery team together, and ask them to grab four sticky notes (or index cards) and a marker. On each card, have them write one of the four parts of the problem statement in their own words. So in the case of the conference submission system, my cards might look like this:

Card 1:
The problem of selecting conference sessions

Card 2:
affects presenters

Card 3:
The impact of which is they frequently do not receive actionable feedback on their session proposals or know why they were/were not selected.

Card 4:
A successful solution would be: open and transparent

Once everyone has written their cards, ask each person to read their statement in order, and then add their cards to the correct column on the wall or table.

After everyone has read their statement, have the group work through each part of the problem statement and come up with a single statement that they can all support. Chances are, you will start with as many different views of the problem as there are people involved in the exercise. Writing the ideas on cards allows a large group to sort, combine, and rearrange the various ideas to aid the discussion and converge on a unanimously supported problem statement. Again, you probably won't end up changing the real problem the effort is focused on (though you might) but you will certainly create a much better understanding of the problem you are trying to solve, assuming everyone in the group is involved in the discussion.

I saw the power of this a few years ago when I was working with a team that was in the midst of an effort to revise their commission system. There were 11 people involved, including the sponsor, a couple of subject matter experts and the majority of the delivery team. I had them do the problem statement exercise partly to build that shared understanding, but also to see where they were in relation to their understanding of the problem.

When I had the members of the group build their individual problem statements—for the same project, mind you—we ended up with 11 different interpretations of the project, ranging from a few changes that would make the commission system easier to maintain, to completely overhauling how the organization paid their agents. The team was surprised by the differences in perspectives, especially considering the project had already been underway for a few months. Everyone just assumed that they were all working toward the same goal. 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. The team members later used this understanding as one way of deciding where they should and shouldn't focus their efforts.

An even better product of this exercise was the conversations they had. Assumptions people had never voiced surfaced and were shared. The understanding they reached included both the resulting problem statement and the information acquired during the discussions. It was easy to tell that some of the team members' firmly held beliefs were proved incorrect during those conversations, because there were a couple of rather heated discussions. That type of thing is healthy. It gets the differences in understanding and perspective out in the open where the team can address them, clear up misunderstandings, and move forward toward a shared vision. In other words, the real power of this technique is that it provides a structure for conducting adult conversations.




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.