Woman biting pencil, fretting over work

You Don’t Have Time to Craft the Perfect Plan

Even if you did, it would be a waste of time
By

Let’s see if you can relate with me on this.

You spend an inordinate amount of time meticulously crafting your plan. Something unexpected hits your plan like a tornado and you’re left scrambling to stay on track. To avoid the impact of future disruptions, you spend equal amounts of time thinking through all possible risks and mitigation strategies. Inevitably, you simply cannot anticipate nor mitigate every possible curveball.

It seems futile. You’re right.

Benjamin Franklin once said, “If you fail to plan, you are planning to fail.” I think Yogi Berra agrees as he once said, “If you don’t know where you are going, you’ll end up someplace else.”

Make no mistake — planning is important.

However, according to Mike Tyson, plans easily get disrupted — “Everybody has a plan until they get punched in the mouth.”

So, what do we do?

Dwight D. Eisenhower said it best — “In preparing for battle I have always found that plans are useless, but planning is indispensable.”

Experience tells us that detailed project plans don’t usually produce better results. We also know that the harder we try to stick to the original plan, the more miserably we fail, not to mention delivering the wrong things. So let’s stop doing that.

Even if you could create the perfect plan, is it worth it?

In software product development, the answer is a big no. You’ll lose out on arriving at a better solution and product. Let’s explore why.

People Don’t Know What They Want

Have you ever played the “find me a rock” game? Your boss or client gives you some vague requirement, you take your best guess and deliver something. After seeing it or experiencing it they tell you it’s not what they want, yet they cannot tell you what they do want. So you try again, same results. It’s the “find me a rock” game. You bring back the metaphorical rock and all they can tell you is it’s not the right rock so you bring another one.

This game is frustrating, but it proves a point. Iteration produces the right solutions.

In my experience, people don’t know what they want or need until they see and experience something. Trying to squeeze out more refined product requirements up front won’t help. It’s a waste of time and effort. Why? Because the forced requirements are just guesses that are often found to not be what’s needed once seen and experienced.

I’ve also learned that the problem people think they are solving is often not the right problem to solve, thus the proposed solution misses the mark.

This is why you should never ask users what they want — you will end up building the wrong thing.

Your customers may start with solution ideas. You and your team might be inclined to start there, too. Asking “What problem are you trying to solve?” early in the conversation is a game-changer. The quicker you can pivot the discussion to the problem space, the better.

Great ideas don’t always provide value, nor address the real problem or opportunity. Running with those ideas without fully exploring the problem will often lead to wasted time and effort as the solution fails to address the real issue. The result is missed opportunities and benefits.

Consider this — if you deliver a “requirement” and it’s expected to improve some metric or make life easier in some way, but doesn’t, could you still say it was “required?” Would it make sense to hold anyone to account for that requirement just because it was signed off on up front?

Instead of working from requirements, work from assumptions instead.

The key is to understand that value can only be known post-deployment, through validation. Given that, you should then work from assumptions that need to be validated. The sooner you can test your assumptions, the better.

Anything Worth Doing Is Worth Doing Poorly

I’m not suggesting being sloppy and intentionally doing poor-quality work here. It’s about having a bias for action. Having a bias for action means you’re more inclined to get started than you are to over-analyze. That takes a bit of courage and a shift in perspective.

Not having all the answers is not a good excuse for not proceeding. You will rarely have all the answers up front. You won’t likely figure it all out in planning. There will often be unknowns and some risks. If you try and wait until you have it all figured out, you’ll miss the boat.

If it’s a good enough idea to spend time on, it’s good enough to get started on to see if it really is a good idea. The best way to prove out an idea is to do something. Start with what you know, start small, experiment, and validate. This agile approach reduces risk. It leads to better outcomes.

You’ll learn more and achieve more getting started, even if “poorly” and not fully thought out, than you will by thinking about it incessantly.

As I fleshed out in, “Achieve Better Quality Through Quantity,” the sooner you produce something to assess, the sooner you can learn from it and adjust.

The fact is, you know the least about a situation earlier in the process than you will later on. This is why large up-front plans make no sense. The less you truly know and understand about a thing, the less confidence you should have in the decision. Therefore, making a decision too early is risky and the chances are you may be wrong.

Final Thoughts

People don’t fully know what they want or need up front. Trying to flesh out detailed requirements and plans is futile. Starting here is a recipe for failure.

Every problem-solving endeavor begins with an initial problem definition. It is the current perspective. I often find the first problem statement is not really the root, or best, problem to solve.

When exploring solution alternatives, it’s easy to become married to your ideas, and look for ways to flesh them out and defend them. I recommend you look for ways to disprove them as the best solution. In this process, you will either validate them or find better options.

Taking this approach, you’ll want to gather just enough information to get started. Have a bias for action. Do something, experience it, learn from it, and adjust until the desired outcome is achieved. That’s the power of agile.

Otherwise, if you remain in the trap of detailed requirements and plans, you’ll spend more time analyzing and refining up front only to be wrong anyway. Meanwhile, you’ll lose out on the experimentation, learning, and validation that could have been occurring along the way. You’ll lose out on arriving at a better solution and product.

 
 
Scroll to Top