Why The Impact/Effort Matrix Is The Best Planning Tool

Tools meant for dealing in abstractions don’t like to get their hands dirty. You don’t have that luxury.

Kinser's Law: “About the time you finish doing something, you know enough to start.”

Every project I’ve worked on has been harder than initially expected.

Last year I wanted to build a shed on some rural property with my grandfather. I needed to dig holes for the foundation piers.

With a tractor auger, that should be quick work!

Imagine this

We put the auger on tractor. We realized we didn’t have the right bolts—we went to the hardware store

We set up the connection. We realized we needed shear pins—we went to the hardware store

I drove the tractor. The auger arm fell off—we went to the hardware store.

If I’d known that I needed 3 separate things from the hardware store, I could have made the project 1/3 as long.

But there’s no way to know that in advance.

---

In this post

We’ll walk through why projects are systematically harder than they look in retrospect.

We’'ll also cover how you can avoid the rose-colored glasses view of a project when planning.

---

The same is true for work projects

It might start out as “a simple data integration”—But it never stays that way.

It will inevitably spiral into something like a full re-creation of the data infrastructure.

You thought a microservices architecture would make you more flexible? Ha! Instead, the API you need can only provide time (in seconds) since the developer’s birthday when the moon is full.

How do you find an enterprise-scale “Moon Phase to Developer Age” validation tool?

Obviously this is a joke example. But it feels true.

Even when I collapse across the finish line of a big project, it instantly looks easy in the rearview mirror.

“Wow, if we had gone from A to B directly, it would have been much easier”

Why is that?

Known vs Unknown

Former U.S. Secretary of Defense Donald Rumsfeld said the following at a press conference in 2002.

“…there are known knowns; there are things we know we know.

We also know there are known unknowns; that is to say we know there are some things we do not know.

But there are also unknown unknowns — the ones we don’t know we don’t know.”

– Donald Rumsfeld

After a project is complete, you only have known knowns—e.g. you know how everything works out.

And it’s tempting to think that a project could have been done in 1/2 the time with 1/3 of the budget after you know how it went.

But when you start a project—even a well-planned one—your knowledge is broken into 4 categories.

1. Known Knowns: What you know that you know

   1. You know what tools you’re currently using and who manages them. You also know that this will be important

2. Known Unknowns: What you know that you don’t know

   1. Before you’ve done discovery, the use cases everyone cares about would be here. You know that you’ll need them, and that you don’t know them now.

3. Unknown Unknowns: What you don’t know you don’t know

   1. A vendor’s whole development team takes a month off every March to celebrate Texas history month, but you didn’t know to ask about that before setting your go-live Feb 27th

4. Unknown Knowns: What you know, but don’t know is relevant

   1. Someone on your team knew that March is Texas history month. And he knew the vendor team took off a month—but didn’t think it was relevant to bring to your attention, that goes here.

Throughout the project, all information collapses¹ into Known Knowns

When you look in hindsight—with all of the knowledge needed—any project looks easy.

Those rose-colored glasses really distort reality.

“Wow that wasn’t really that hard” Yes it was

---

How Uncertainty Affects Planning

It's tempting to start with detailed measures in project planning².

Starting projects with detailed quantitative measures can seem appealing, but they often end up being meaningless.

Detailed project plans are like pinning down a cloud—as soon as you think you have your arms around it, it’s moved.

Projects are inherently unpredictable.

Unexpected issues arise, dependencies shift, and priorities change. Detailed plans become rigid.

Rigidity kills projects.

Agile methodologies have gained popularity because they embrace change and focus on delivering value immediately. Agile teams adapt to evolving requirements instead of sticking to a fixed, detailed plan.

Instead of getting stuck in the details, focus on the big picture.

Set clear objectives, define milestones, and allow flexibility in how you achieve them.

Trust your team’s ability to manage the inevitable uncertainties.

Effort / Impact Matrix 🥰

The best way to stay flexible without missing the forest in project planning is by using an impact/effort matrix.

This tool helps prioritize tasks based on their business impact and the effort required to get there.

It’s easy to read, easy to make, and keeps you focused on what matters.

The impact/effort matrix is a four-quadrant chart.

Tasks fall into one of four categories:

1. Quick Wins (High Impact, Low Effort): These tasks should be prioritized as they provide big benefits without being hard.

2. Big Bets (High Impact, High Effort): These tasks are important but require substantial resources.

3. Fill-Ins (Low Impact, Low Effort): These tasks are nice to have but not critical. Address them when you have spare time.³

4. Time Wasters (Low Impact, High Effort): Don’t do these projects. They consume resources without significant benefits.

Using this matrix helps prioritize.

It keeps your eyes on the forest instead of the trees.

It’s also an excellent tool for getting buy-in.

It’s easy to do a live prioritization meeting where you move circles around in powerpoint. More advanced visualizations usually can’t be edited on-the-fly, and certainly not in any collaborative way.

If you’re ever in doubt, turn to the effort vs impact matrix.

Conclusion

“No real blood flows in the veins of the knowing subject constructed by Locke, Hume, and Kant, but rather the diluted extract of reason as a mere activity of thought.”
― Wilhelm Dilthey, arguing that natural sciences shouldn’t be used on human phenomena

While detailed planning measures might seem like a good idea, they fail in practice.

Tools⁴ meant for dealing in abstractions don’t like to get their hands dirty. You don’t have that luxury.

Embrace simplicity, speed, and flexibility.

Use tools like the impact/effort matrix to prioritize effectively, get buy-in, and keep your project on track without getting bogged down in unnecessary details.

Understand that plans are just starting points, and the real value comes from your ability to adapt and respond to the real world.

1. I really tried to make a joke about wavefunction collapse to look clever, but couldn’t make it work :(

2. Cough Cough: SAFE, MoSCoW, PERT, PRINCE2,

3. I’ll go into more detail on my opinion of this category in another post.

Because everything is harder than you think, consider avoiding these tasks entirely as well.

In real life, I think the matrix looks like this:

4. Even things as common as statistical models rest on assumptions that may not be true for human behaviors. I’m not convinced the central limit theorem can always be true for human phenomena