Project Managers, Don't Solve Every Problem.

The job of a project manager can be described in many ways. One of those ways is “problem solver,” as we are constantly solving problems on multiple levels. In the course of monitoring the progress of our projects, we solve problems to keep them moving. In the course of developing project plans, we solve problems like aligning misaligned stakeholders and finding a way forward amid competing constraints. And the projects we lead are often themselves solutions to business problems.

Most project managers are good problem solvers, and if you’re new to project management, it can be natural to turn every problem that comes your way into a task on your to-do list. But given the sheer number of problems that will find you, trying to solve every one can be crushing.

Fortunately, as years in the field will teach you, solving every problem is not necessary. There’s an art to seeing through the apparent urgency of every issue and determining which issues truly need attention from you, now, and which don’t. Here are some telltale features of problems I might choose not to solve—at least not right away—to free me up to solve the problems where I’m likely to add the most value.

Problems I Wouldn’t Solve

1. When the urgency is false

If a problem is brought to you by a person, often the problem feels urgent to them. They might convey this by requesting a specific date when they’d like it fixed, talking about the negative effects of the problem, or just exuding urgency in their tone or body language.

While you can be kind to them and acknowledge their feelings, take a moment to do your own assessment of the problem’s true urgency, with questions such as the following:

• Is this problem affecting the critical path: will a delay in solving it impact the overall project completion date, or just the timing of a few tasks in the middle?
• Is this project, or its timeline, of high importance to your company? Urgency is less compelling on low-priority projects.
• When will this problem impact a meaningful deadline—one you’ve promised to clients or customers, one where true market opportunity is lost, one where you’ll be non-compliant with regulations—as opposed to a deadline that was simply an internal goal to motivate progress (even if it came from a senior leader)?

If I discover the original urgency isn’t very meaningful, that doesn’t mean I skip solving this problem altogether, but it does mean I’ve gained flexibility to come back to it later if more urgent problems need my attention.

2. When conditions are volatile

Sometimes, before a problem needs to be solved, the environment around the problem or around your project shifts to make the problem irrelevant.

Maybe a senior leader makes a decision that requires a portion of your project to be changed. Maybe an environmental disaster causes a shift in your project’s timeline. Maybe in an active market where competitors regularly roll out competing products, your company might shift the plan for your product so it remains likely to stand out.

Change is constant, and anything CAN happen, but key here is making a realistic prediction: how much change is likely? You can assess this with very simple questions such as:

• How much change has your project been subject to, and had to respond to, so far?
• Are you aware of any changes at your company or in the market that are brewing, even if you don’t yet understand how they’ll impact your project?

Then you weigh the value of solving the problem immediately against the probability it will disappear if you wait for your suspected changes to play out. This decision isn’t necessarily easy as you’re somewhat comparing apples and oranges. But the sooner you start keeping “waiting for a problem to disappear” in mind as an option when conditions are volatile, and the more you practice making this judgment call, the better you’ll get at it.

3. When you lack access

Sometimes you lack access to something or someone you need in order to solve a problem. You may need input, approval, or help from a person who is unavailable. Or you may not have access to information you need—sometimes because the information doesn’t exist yet.

In these scenarios, no matter how important the problem is, if you hit a wall, you hit a wall. There is a time for exploring alternative, creative approaches in the face of apparent blockers. But there is also a time for accepting there’s nothing you can do right now, and you simply need to wait until you have access to the right person or the right information.

It is good for your emotional well-being in these scenarios to accept that you’ve done all you can do, try to let it go, and move on to a different problem where you DO have the ability to make a difference.

4. When there’s a better person to solve it

You are likely a very capable person who can solve many types of problems—even the kind that perhaps should be solved by others. Because we are such good problem solvers, we can be magnets for problems we aren’t really the best people to solve. It’s good for your coworkers and for your own capacity if you take a moment in your mind to assess whether you’re the best person to solve a problem before you get started on it.

Here are some reasons it might be best to pass a problem to someone else:

• Does it fit better with someone else’s role? Might they even feel their toes were stepped on if you addressed it?
• Is someone else simply more skilled in this area? Is their solution likely to be stronger?
• Do you have direct reports or others you can delegate to, who might feel empowered or get a chance to grow if you pass this problem to them?

5. When it’s the first instance

Here I’d like to address problems you’re having less with projects, but more with people.

If somebody makes a mistake, transgresses a boundary, etc. for the first time, I’d certainly deal with any impacts this has on my project. But I wouldn’t go out of my way to have a conversation with the person about the issue or try to put anything in place to prevent the issue in the future. I think doing this after a single instance is almost always too soon. People make mistakes, and in my experience it’s good for your relationship with them if you trust them as somebody who is likely to make their own efforts to avoid repeating errors. Treat mistakes as mistakes, not as major problems.

But I would talk to the person, or put effort into a preventative solution, after the issue starts to look like a pattern. How many instances make a pattern is a judgment call; it may be after the second instance, or it may be more. But I only address these issues as a pattern, because they appear to me to be a pattern. Until then, I give my teams the benefit of the doubt and trust they’re doing their best.  

6. When you don’t yet understand the problem well

A major step in solving a problem well is understanding the problem. And it’s a common error to try to implement a solution to the wrong problem because the problem isn’t understood.

You can save your own capacity, and be a better problem solver, by keeping your eye out for this error and slowing down–or compelling your team to slow down—to understand the problem before a solution is implemented. Maybe more research is needed, or conversations with experts, or tests, or discussions of possibilities. Maybe the best move is simply to observe the situation a bit longer and let things unfold a bit farther.

Regardless of the path to understanding the problem, it’s worth taking, because rushing a solution to a poorly-understood problem doesn’t help anyone.

7. When you’re not in a state to solve it well

How are you feeling today? Are you tired, hungry, burned out, or overwhelmed?

If you’re in a particularly taxed physical or emotional state, even if a problem is important or seemingly urgent, you might not be in a state to identify or implement a quality solution. If that’s the case today, your quickest path to a well-solved problem is to save it for tomorrow or for when you’re better (or if necessary, ask someone else to address it).

Personal obstacles happen. You’re human. Give yourself the space to recover today, and tackle it when you’re feeling like your awesome self again.

Problems I’d Prioritize

I’ve mostly written this blog in the negative—which problems not to solve—because I want to free you from the stress of being overwhelmed by too many problems, and because it’s not always obvious when choosing not to solve a problem is an option.

But this is, of course, to free you to solve the problems that are the best use of your time and the best fit for your talents and role. And which ones are those? I generally prioritize solving problems where the conditions are opposite of those I describe above…

1. Problems with genuine urgency
2. Problems that happen under relatively stable conditions
3. When you have access to what you need to solve the problem
4. When you’re the ideal person to solve it, or there isn’t someone better
5. When a people-problem is growing into a pattern
6. Once you understand the problem you’re solving
7. When you’ve had adequate food, water, and rest

These are the problems where your solutions will add the most value to your projects and your company. Mastering the art of letting all the other problems go (or letting them wait) will help give you the capacity to do your best work.