The Problem with Problems: A Problematic Problem Statement.

Warning: this article has several pieces of language that most workplaces have deemed inappropriate. Words like “problem”, “unsolvable”, and “cluster” are going to be used generously.

Despite the titling, this article is going to remain relentlessly positive… first we’ll define what a problem is, then we’ll engage about why businesses generally seek to hide, bury, cover-up, and squash problems… we’ll talk about the knock-on effects, then we’ll close by explaining why most businesses are dumb, problems are pretty awesome, and how we can celebrate them.

Defining the Problems and Types:

First, we should start by acknowledging that contextual fact statements are not, in and of themselves, problems. The statement “my car cannot fly” is simply that, a statement. Perhaps I have some need to go a great distance in a speed faster than the car would allow, and that may well be a problem, but the car not being able to fly is just a fact. Facts are unsolvable, because they aren’t problems to be solved, they’re fixed points to be navigated around. Too often, people get fixated on facts, thinking that those are problems to be solved. Defining your core problem(s) means you’ll need those contextual facts.

Additionally, we should clarify that the goal is not the problem. The problem is how you get from whatever the current status is, to what you want the current status to be. A well-defined goal, with measurability, time components, defined relevance and rationale, in a simple wrapper, will help you better understand the topology of the problem, as will a better definition of your current status, but those are still just statements.

Problems are impediments that interrupt your ability to proceed from your current status to your goal. Though some facts may be need to be navigated around, those are just fixed obstacles, not endpoints. Much has been made of the brick wall metaphor… the thing of walls is that they’re not mobile, and we are. We navigate around walls of steel, wood, brick, and all other manner of material on a regular basis. Occasionally we bump into one or run into one accidentally, but we still end up navigating, even with a bruise.

There is another type of problem… the dreaded “cluster”. Clusters aren’t special, they’re just groups of problems, where sometimes the problem interacts with eachother. Sometimes clusters interact with fact statements too, and it becomes difficlut to disentangle them. The cluster is sometimes the most dreaded kind of problem, because the interactions inherently mean that navigating around it mean that you’re going to either need a bigger workaround, or some unconventional thinking/inspiration. The danger here is that the cluster leads to a special kind of problem, scope creep.

Scope creep is definitely a solvable challenge. Sometimes the best thing to do is to walk away. Sometimes the workaround to solving the problem makes the “solution” worse than the problem itself. Other times, the scope creep simply expands the needs of the project so much that the solution isn’t financially viable. Scope creep is often the default solution, because it requires the least challenging decision making, and if there’s a lack of clear vision/goals. The Iron Triangle (Schedule, Budget, Scope) is a pretty neat set of constraints to work within… that said, the conversations about schedule and budget tend to be the toughest conversations, so there’s temptation to modify scope, but treat the other two things as fixed points. For more about how to manage scope, regardless of what industry you work in, I strongly recommend Ruth Tomandl’s presentation “How Saying ‘No’ Can Make Your Game Better” (https://www.youtube.com/watch?v=r7eHlKBQVQ0). Always be conscious of scope creep, far more than schedule or budget limitations, scope creep can infect projects, make the vision less clear, cause analysis paralysis, and result in an infinitely escalating cycle of scope creep known in the software world as “development hell.”

There is one way to solve the problems or navigate around fact statements without scope creep. This is uniquely challenging though because it requires some disrpution… we’re talking of course, about innovaction and creativity. It is important at this point to figure out whether the inspiration is actually in the scope of the project, many projects get sidetracked with inspiration that isn’t in the scope, and end up with the same or more scope creep as an ordinary workaround. Not all inspiration is good inspiration. The best kinds of inspiration and creativity not only accept the fact statements and problems, but actively embrace them. We’ve visualized how that works below using state-of-the-art rendering and graphics*.

*Nobody said the problem was two-dimensional, most aren’t. When you can’t find a workaround, try going over or under… you may need a ladder on one side or the other, but that’s fine.

So why do businesses and organizations do so much to deny problems existence, or to hide struggles, even though they’re something every person deals with on a daily basis? There’s a weird myth out there that shareholders don’t know that employees of companies face problems and challenges on a daily basis… it’s particularly odd since those same shareholders face problems and challenges of their own. Rather than celebrate how good their employees are at adapting, improvising, and overcoming problems. Where those fact statements are barriers, problems are more like gates… sometimes we get information that’s the key to unlocking the gates/solving the problems and we can simply open the gate, sometimes we batter down the gate in a bit of a brutish, sloppy manner… sometimes we go find another gate, and open it instead. Ultimately though all of this takes time, and there’s reluctance on the part of many companies to admit that they spend time solving problems. If you’re to read investor statements, from manufacturing companies to software, the one thing they all have in common is that there are no problems. There’s opportunities, some of which got taken advantage of, some of which did not… but everyone in the company shows up every day in their hypothetical world, everything is set, and they’re all at maximum productivity all day long. Resources are in place, everyone has the authority they need to ensure the outcomes they’re responsible for, the infrastructure already exists, leaders are so happy with their teams that they can’t stop channeling Emmet from the Lego movie when asked about how awesome things are. No shareholder money gets spent, in most companies reports, on problem solving, simply because they’ve never encountered a problem.

Some of the problems with the lack of problems is that in some cases, some companies simply forget that problems exist. Subsequently they don’t devote any training, resources, or budget to overcoming problems. Ironically, some of those same companies are afraid of how acknowledging problems would affect morale. Rather than “telling it like it is”, they bury their heads in the sand, which can harm morale, and in turn, employee retention, leadership trust, and even recruiting, as word spreads about what it’s like to work there. Additionally, people there are still dealing with those same problems, but when companies stifle talk about problems, it becomes increasingly likely that the conversation about the solution gets stifled too, so a team that encountered the problem and solved it may not get the chance to share that knowledge with other teams encountering the same or similar problems.

So, how should we deal with problems?

1.      Centralize – It’s important to have an easily-searchable central repository of problems, a place where people can write about them to describe the current status, the goal, the problems, the facts, and any information about how problems and facts interact. This way, when solutions are found, they can be applied to all of the various relevant problems.

2.      Elaborate and Separate… figure out which of your problems are individual problems, and which are clusters. Break the clusters down into individual problems. While the cluster may not be solvable as whole, sometimes you can solve parts of the cluster, then bounce off one of those previously inconvenient fact statements and end up at the goal. Breaking problems down into their component pieces also helps task management in identifying scope creep, calendar encroachment, or budget overruns.

3.      Celebrate the problem itself… sometimes we learn a whole bunch of incredibly useful things while working on a problem but fail to reach the goal anyways for one reason or another. Sometimes the very day you figure out how to connect two tools is the same day that one of them is obsolete and no longer in use… but the knowledge you gained from the problem solving may be cross-applicable, even if you never did end up connecting the two tools. Every problem is an opportunity to be creative, to get smarter, and to solve a neat puzzle that might come up again.

By embracing a process of Centralizing, Elaborating, Separating, and Celebrating, we can better focus resources on solutions that work, we can better acknowledge that we understand problems, and we can better enable workforces to work efficiently by ensuring they have a more complete overview of what ideas do work, which ideas don’t work, and why. Creating a culture of open, honest communication has benefits well beyond the productivity gains, including enhanced employee engagement, and creating trust.