Dissecting the Design Sprint Event
Step One: Refining the Problem
The first step during a design sprint at AF CyberWorx is refining the problem. Stakeholders have an idea of what problem they want to solve. They may want to save time, streamline or automate processes, fix a system showing bad metrics, or set up a policy for a new requirement. Initial problem statements may reflect this focus, but usually lack the specifics the problem solving team needs to be effective.
Larry Marine, lead UX designer at AF CyberWorx, explains why it’s so important to re-examine the problem statement. As he states, “If you don’t know what problem you need to solve, the best you can hope to do is solve the wrong problem very well.” Just like a mission statement gives direction for a business, an accurate problem statement gives teams a solid visualization of what they need to achieve. Larry gives an example of a poor problem statement from his previous experiences:
"A mortgage company needed to improve their processes to increase efficiency. A common problem in the organization was epitomized by one form which required twenty four separate signatures. Copies of these forms were stored in filing cabinets that took up an entire floor of their building. The solution seemed simple: digitize the forms. However, during problem analysis research, the team found that the form hadn’t been necessary since a procedural change 20 years ago! Though their problem statement in this case included digitizing the form, they ended up cutting costs and regaining resources by simply getting rid of the unnecessary form."
This simple example shows why problem refinement is the first step in every AF CyberWorx event. To help develop solutions that are impactful, meaningful, and effective, facilitators first guide event participants through the process of analyzing the problem to redefine the problem statement to be more accurate to ensure they achieve their desired outcome. Larry explains that some of the most common issues found in an initial problem statement include (1) making a solution the problem statement, (2) fixing symptoms instead of the root problem, and (3) forgetting that a problem can evolve over time.
When the initial problem statement says something like, “we need to digitize...” or otherwise describe a specific action, it’s giving a solution, not stating a problem. People often come into a problem solving event with a solution already in mind. They think, “I know what we need to do,” especially when they have a lot of experience with the problem. A solution-based problem statement supports that and guides the team to do something specific, albeit incorrect. If the team has the solution already, why should they go through the problem solving process? They already have the answer. The mortgage company already had an answer, but the team soon found the answer wasn’t the best solution. Refining the problem statement gives the team a more solution-agnostic goal to encourage the free thinking which finds the right solutions.
Another common issue initial problem statements have is a focus on symptoms instead of a root cause of the problem. For example: when the problem statement says, “We need to reduce the rejection rate from 65%.” The rate is a symptom of a larger problem. A better statement is, “Customers don’t know what information to give us, leading to a 65% rejection rate,” but it’s still focused on a symptom. To avoid creating another band-aid that simply covers a symptom, finding the root cause of those symptoms leads to a more impactful set of solutions. An even more accurate problem statement using root cause analysis might read, “Customers are looking for a tool to tell them what information to give, but can’t find it so don’t give the right documents.” The problem needs to be redefined with root cause analysis to aim at a deeper level than surface symptoms.
A third common mistake with initial problem statements is believing that a “fix” for an old problem will work now with a little tweaking. Larry explains that when a problem is “solved,” that solution tends to change slowly through time, ignoring the fact that the problem itself is changing as well. Basically, “We’ve always done it this way.” The form with the mortgage company is a good example. The problem hadn’t been examined in so long that no one realized the problem source wasn’t even necessary anymore. Refining the problem in this case verifies what the current nature of the problem is to develop an effective solution.
When AF CyberWorx leads a team through re-examining the problem, they aren’t wasting time by rehashing work that’s already been done. They’re refining the problem to ensure it is accurate, correctly identifies what needs to be fixed, removes solution bias, and pinpoints the team’s focus on the most impactful problem. As Larry states, “We look at details that they gloss over or can’t describe. If the refined problem statement looks like the initial one, we’ve likely missed something.” Using specialized experience and best-practice tools, facilitators help teams refine not only the problem statement, but the mindset of the team to make their problem-solving experience more efficient and positive in the short amount of time allotted to a design sprint.
*The postings on this blog reflect individual team member opinions and do not necessarily reflect official Air Force positions, strategies, or opinions.