Guesswork and the Path Ahead: Why Planning Matters

If you take away the nice documents, the Gantt charts and the impressive meetings, a plan in IT is mostly a structured guess. Sometimes a well-researched guess, sometimes closer to wishful thinking. But still a guess.

In software projects things change all the time: new requirements, new tools, new risks. So planning is less like drawing a fixed route on a map and more like deciding how you want to move through a landscape which you only partially see. You still need a plan, without one you just drift along with whatever other people decide. But it helps to be honest what a plan can do and what not.

It also matters why you plan in the first place. Not every plan has the same purpose and not every approach fits every project.

Two styles

In tech you mostly meet two styles of planning. Predictive planning tries to chart the whole path in advance: plan, document, execute. Adaptive planning assumes that you can't know everything from the start, so you move in small steps and adjust while you learn.

Both have their fans who defend them strongly, and for both you find success stories and horror stories. Which one is "right" in theory matters less. What matters is whether the style fits your project and how much uncertainty you can realistically live with.

Predictive: order, control and a big "if"

Predictive planning is close to the classic engineering mindset. You write down requirements, design the solution, cut it into phases, estimate costs and then try to follow the sequence. The waterfall model (requirements, design, implementation, testing, release) is the obvious example.

It feels reassuring. Clear milestones, fixed budgets, the feeling that everything is under control. Managers and stakeholders like to point at a document and say "this is what we agreed". Where you have contracts, regulation or strict deadlines, predictive planning fits naturally.

From my experience though, especially in bigger or more open projects, it rarely works without trade-offs that you see only later. One thing you can count on is that something will change. The market, the user expectations, the technology or just the internal priorities. Six months after the first plan you often follow a route that doesn't really match reality anymore, only because it's written down and everyone committed to it.

Predictive planning is very good in getting everybody to agree and commit. The flip side: when you need to change course, it becomes heavy and awkward. Specifications start to feel untouchable. Documentation that should make things clear suddenly makes every change look like a failure. Admitting that the project is off course can mean reopening contracts, budgets and political discussions, so people hesitate. I have seen teams continue in a direction they knew was not ideal. They knew better, but changing direction simply became too expensive, socially and politically.

There are areas where predictive planning is still the right tool. Data center migrations, regulatory compliance, standard rollouts, all the situations where the goal is well understood and the path is known. If you know what you want and the steps don't move, it can work very well. For new products, complex systems with many unknowns, or problems nobody solved exactly like this before, the feeling of safety is often misleading.

Adaptive: try, learn, adjust

Adaptive planning came out of frustration with the rigid approaches. It starts with a simple admission: we don't know everything at the beginning. So instead of pretending, you build something small, look what happens and adjust.

This is the mindset behind Agile, Scrum, Extreme Programming and similar methods. You cut the work into smaller pieces and try to produce something usable in short cycles, often every one or two weeks. You show it to users or stakeholders, collect feedback and then decide what to do next.

Here the plan is not a fixed script, it is more like a direction of travel. You still have goals and constraints, but you accept that details will shift. You don't try to predict every step months ahead. You make the next few steps clear, take them and look again.

The advantage is that the project stays closer to the current reality. You react on what you learn and don't cling to what you guessed before. The cost is that you can give less strong promises early on. Timelines and budgets are ranges and scenarios, no exact commitments, and for people used to certainty on paper this is uncomfortable.

Still, if you work on something really new or complex, it is often the only honest way. You can't remove uncertainty by planning harder. You can only decide how you want to live with it.

Somewhere in between

Most real projects are somewhere between pure waterfall and pure Agile. Some parts are stable and some are very much in flux. Completely unstructured work gets chaotic fast, but too rigid planning can block you as well.

Hybrid models try to give a stable frame with room to adapt inside. One example I like is the Unified Process (UP). It organizes the work in four phases but still encourages iterations:

1. Inception. The basic questions. Is this project worth doing at all? What problem do we actually solve, and who cares about the result? You sketch the business case and rough scope, find the key stakeholders and get a first idea of the risks. It's not about a perfect specification, only about deciding if it makes sense to invest more.
2. Elaboration. Now you look closer at the system. You explore options, define the overall architecture and find the riskiest parts that need attention early. You don't freeze every detail. The aim is enough understanding and structure so the project doesn't fall apart once you go into full construction.
3. Construction. Most of the building happens here. You implement, test and integrate in iterations, and every increment is a chance to learn. Priorities change, features get added or dropped, the design gets refined, as long as the core architecture still carries it. Structure and adaptation together.
4. Transition. The focus moves to delivery: preparing users, documentation, fixing deployment issues, stabilizing the product. Usually more predictable, because the big design questions are already answered.

Why does this work in so many environments? You can be precise where it matters, for example architecture, interfaces and risk management, and stay flexible where things naturally change, like features, user experience or pricing.

You still document and keep a roadmap, but these are tools and not rules. When reality changes, you update them. The structure gives everyone a shared view where you are and where you might go next, it shouldn't stop you from changing course when the situation clearly asks for it.

I like to think about it as a tree. The trunk (core architecture, main goals, your understanding of the risks) has to be stable and well rooted. The branches, meaning features, priorities and release strategies, need more freedom to grow depending from what you learn.

Let the context decide

What becomes clear over time: strong opinions about "the one right way" to plan are rarely helpful. Projects are very different in clarity, risk, regulation and speed.

So before you pick a style, look at the terrain. How well do we understand the problem? How stable are requirements and constraints? How bad is it if we are wrong? And how fast is the environment changing?

If you work in a well understood domain with fixed rules and clear outcomes, for example implementing some standard interface for a regulator, a more predictive and structured plan makes sense. If you build a new product in a moving market, adaptive is usually the better fit. Many teams mix both: predictive for the parts that must not move (compliance, interfaces, safety) and adaptive for user facing features or experiments. Important is to make this choice consciously and not out of habit.

What a plan is for

In the end a plan is a tool for alignment, not a guarantee about the future. It helps people to build a shared picture of what they are trying to do and why. It makes assumptions clear and trade-offs visible.

Good planning is less about filling templates and more about staying in touch with reality. Revisiting decisions when new information comes, admitting that an assumption was wrong, adjusting without treating it as personal failure.

You will make mistakes in planning, almost for sure. The question is not if you can avoid them, but if your process makes it easy to notice and react when things drift. Take care of how you work, the communication, the feedback loops, how decisions are made, and keep this flexible and honest. Then you usually end up in a much better place than with a rigid plan you follow only because it exists.

Strong roots, flexible branches and the willingness to adjust while you learn. This ages much better than an impressive but brittle plan.