How Reframing Problems Leads to Better Solutions

Albert Einstein is quoted as saying, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions." I don't know if he was exaggerating a bit to make a point, but I do know that a common theme among similarly famous problem solvers is that it's important to give adequate time to understanding a problem before trying to solve it.

For many A/E professionals, this is advice worth heeding. I've long observed a tendency in our industry to move quickly through the problem definition phase and jump right into scoping the project or identifying a solution. That's probably fine for common problems and routine solutions. But for more complex problems, this approach can lead to less desirable results.

Of course, our industry has earned a well-deserved reputation for providing solid solutions to challenging problems. My point is that we could deliver even better solutions if we gave more attention to what's known as "problem framing." Like most solution providers, we're prone to a particular bias—that is, seeing problems in the shape of the solutions we have to offer.

So what is problem framing? It's the process of properly defining the real problem we're trying to solve. The goal is to make an objective assessment of the facts, considering the breadth of the problem and then prioritizing which aspects of it most need attention. Determining the root cause may be part of the framing process.

How do you remove bias from problem framing? One of the best ways is by reframing it. This involves looking at the problem from a different perspective, or from multiple perspectives. Reframing helps us recognize dimensions of the problem that we often overlook or give too little attention to.

To illustrate, consider this hypothetical scenario I often share in my training workshops: Suppose I'm en route to a client's office when my car breaks down. It's towed to a repair shop in a small rural community where a mechanic goes to work diagnosing the problem. But what's the real problem? Not my car, but my inability to get to my destination.

Since the mechanic was focused on fixing the car, he missed an opportunity to have me ride with his brother who was going to the next town where there happened to be a car rental business. Turns out my car can't be repaired until the next day when the parts arrive. That's too late! And, by the way, the fee awaiting me at the client's office is greater than the value of my car (which would be true given my propensity for driving older, cheap cars).

Do A/E professionals make similar oversights by not adequately framing the problem? Of course; we're human. Like the mechanic, we're going to more readily see the problem through the frame of our expertise and experience. Seeing the core problem (which often isn't technical in nature) requires reframing it—seeing it from a different perspective.

But wait a minute! Is it our responsibility to address a part of the problem that's outside our area of expertise? Should we expect the mechanic in my story to help arrange for transportation to my destination? That depends on what level of problem solving you want to be involved in. Seeing the larger problem can position you to help clients more broadly, stepping outside your normal scope of services when it's reasonable (and often convenient) to do so.

But reframing the problem doesn't require going beyond your typical scope of services. It can certainly help you develop better solutions within the boundaries of your expertise because you have a better understanding of the problem. Plus it helps you reframe your solutions and designs to better enable the outcomes the client needs for success.

I often refer to the project value chain to make a point: Our typical scopes of work only address a portion of the client's larger project. Our work is often completed well before the client realizes its true value (this is, achieves a return on the investment in our services). How then can we increase our value to the client? In large part, by better aligning our work with the client's larger goals.

When you compare the compensation of different professional service providers, it becomes apparent that business solutions are more valuable to our clients than technical solutions. Yet our technical solutions are required to achieve those business solutions. Can we then make the connection between the two more evident? Yes, we can. It starts by reframing the problems we solve. Here are some suggestions for doing that:

Zoom out, then zoom in. In a profession dominated by analytical thinkers, our specialty is zooming in on technical problems. Zooming out enables us to see the big picture and examine the context in which the problem resides, before we get into the details of breaking it down into its constituent parts. Zooming out often reveals other perspectives from which the problem might be viewed. It encourages us to step outside the technical frame in which we're most comfortable.

See the problem from the client's perspective. This advice is commonplace, but we often overestimate how well we understand that perspective. What we usually know is what the client thinks about the portion of the problem we're specifically addressing. Less common is a clear understanding of the client's "larger project"—those business drivers and desired outcomes that ultimately define client success relative to our scope of work. Knowing the client's perspective enables us to understand the why behind what we do.

The diagram below illustrates a common difference between our perspective and that of our clients:

One environmental firm was excited to offer the client a change in their approach that would save over $40,000. But they failed to recognize that the one-week schedule extension necessary to achieve this savings would end up costing the client several times that amount in lost revenue. The firm was focused on their technical solution, missing the client's business-oriented priorities.

Examine the problem at three levels—strategic, technical, people. I've found this an effective way to help technical professionals better align their understanding of the problem with the client's perspective, as well as with that of other key project stakeholders. The technical framing serves as the benchmark. The goal is to explore the strategic and people dimensions of the project to a similar extent as we have the technical.

The strategic level relates to how the problem impacts the success of the client and other stakeholders. This can involve considering business, financial, operational, competitive, and regulatory issues. The people level examines how the problem affects people both within and outside the client organization (e.g., customers, constituents, the public). Ultimately, everything we do is for the benefit of people, so the human aspect of the technical problems we solve should always be properly analyzed.

For example, consider the case of a midsized engineering firm that was suffering from persistent quality problems in the work delivered to clients. In examining the underlying causes, they determined they needed someone to their lead quality improvement efforts, to create a more robust process, and to hold people more accountable. They hired a seasoned director of quality assurance to fill that role—yet the quality problems continued.

I was hired to bring an outsider's perspective and concluded that the problem was more about people than process. Despite increased structure and scrutiny, staff had not really taken ownership of the firm's quality concerns. They hadn't been involved in creating the new process, thought it was overly complicated, and thus followed it as little as they could. Since the focus of the process was on reviews (as typical in our profession), they were inclined to let the reviewers worry about mistakes.

Having reframed the problem, it was decided to overhaul the process with substantial staff involvement. I introduced them to some behavior-based concepts I learned from working in safety, with emphasis on positive reinforcement of quality-creating behaviors. We increased focus on prevention and root cause analysis. With a more human-centered approach, quality improved significantly.

Consider the consequences of the problem. The technical problems we solve all lead to consequences that become part of the client's larger problem. In many cases, these consequences create a greater sense of urgency than the underlying problem. Because these consequences are often not technical in nature, we're prone to not giving them proper consideration in our problem definition.

When a meat-packing plant shut down it's troublesome pretreatment system, the town's wastewater treatment plant couldn't handle the additional untreated influent. But this was just the start of their problems. Negotiations with the State regulatory agency for a permit for land application of the plant's biosolids were sidelined. Farmers who were considering accepting the biosolids were having second thoughts, in part due to the delay.

The State threatened placing limits on recreational use of the plant's receiving river, which had residents and local businesses in an uproar. River-based recreation contributed a significant amount to this small town's economy. Not surprisingly, these developments were not helping the mayor's reelection campaign.

Several engineering firms submitted proposals to fix the treatment problem. But the successful firm outlined a more comprehensive plan to address the consequences as well—including proposing to engage the mayor in leading discussions with local residents about how these problems would be corrected.

Bring different disciplinary perspectives together to reframe the problem. A/E firms commonly assemble multidisciplinary staffs to enable them to offer a fuller range of services to clients. Unfortunately, they too seldom capitalize on the potential for combining these differing perspectives to better frame their clients' problems and provide better solutions. In fact, disciplinary and functional diversity is often more a problem for firms than an asset in their problem solving.

As a consultant, I've worked with many different firms in trying to improve collaboration between different disciplines and departments. I've encountered coordination problems between engineering disciplines. Between architects and engineers. Between different stages of the project delivery process (e.g., planning, design, construction, operations). Between partners on design-build teams (clients, design teams, contracting teams).

A big part of the problem is our preference for a linear delivery process with a series of hand-offs from party to party, with limited prior interaction across disciplines or project stages. What if we gathered those diverse parties together for the purpose of problem framing and project planning? (See diagram below) Could that lead to better solutions? To better projects? I can tell you from experience that it can. Give it a try!

If you've made it this far reading this article, congratulations! Once again, I'm out on a limb, writing about a topic we rarely discuss in the A/E industry. But the practice of problem framing and reframing is hardly untested. It's popular among many of the largest consultancies, technology and IT companies, and other problem-solving organizations. I think it's worthy of consideration in our business. It can be a differentiator. Hopefully I've at least piqued your interest in exploring it further.