Planning debt can devour projects.

In November 2023, the South Korean government essentially came to a halt. Local community centers couldn't issue a single copy of the resident registration, and the online government service was inaccessible. This was due to the collapse of the local administrative computer network. Do you remember? There was a few days of confusion, and the official reason announced by the government was that "some of the cable connection ports of a network device called a router were defective." (Source: Ministry of the Interior and Safety, 'Causes of Local Administrative Computer Network Failure and Preventive Measures' briefing, November 25, 2023.)

At first glance, this seems like a simple equipment failure, an unavoidable accident. However, we in the IT industry must dig deeper here. As we all know, equipment such as connection ports can certainly fail. Upon further examination, they often fail for truly absurd reasons. Should the entire South Korean administration be paralyzed due to such expected failures? In the Q&A of the briefing, we can find clues to a more fundamental issue: “The configuration for redundancy was in place. However... the anomalies of some modules occurred because a single device did not operate abnormally, leading to redundancy not working properly.”

<Source: South Korean Policy Briefing, November 25, 2023>

I want to translate this statement like this. It means that exceptional situations or problems were not properly defined during the planning and design stage. Assumptions such as "We have a redundancy system in place," and "Redundancy conditions? That must be in a scenario where equipment is malfunctioning," ultimately halted the entire system when the worst-case scenario occurred.

We are very familiar with the term ‘Technical Debt.’ It means that if we leave inefficient code for the sake of fast development, we will pay a greater price later. However, today, I want to talk about an even more insidious and destructive yet often unnoticed invisible debt. This is the root cause that paralyzed the nation: **‘Planning Debt.’**

1. It's not just technical debt; there's also ‘planning debt’

What is planning debt? Simply put, it refers to all uncertainties that were not clearly defined and were passed over during the planning stage.

“This policy is sensitive, so we can't decide it here right now. Let's finalize it in the next meeting.” “There are some exceptions, but… let's just move on for now since they are unlikely to occur.” “This part, please take care of it neatly in the development team.”

Unclear decisions, tacit agreements, and postponed discussions represented by these statements are the principal of ‘planning debt.’ This principal accumulates invisible interest throughout the life of the project, and at some point, it returns as a massive shackle that paralyzes the entire team. While technical debt leaves traces in code, planning debt exists faintly in people's minds or on the margins of meeting minutes, making it harder and riskier to identify.

Source: Generated by Gemini

2. Very specific situations where planning debt accumulates

How does this planning debt torment us in the workplace? Let's take a look at a very specific conversation. Many of you will likely feel a sense of déjà vu.

PM: (while explaining the plan) “When the user clicks the 'Use Points' button here, they will be able to use freely from their available points.”

Developer: “Yes. But is it possible to use coupons in conjunction with points? And what is the minimum unit for using points?”

PM: “Um, that part is still under discussion with the policy team... For now, could you please develop it with the assumption that overlapping usage is not allowed? I will share the policy as soon as it's confirmed!”

Right at this moment, planning debt is created. The developer is now at a crossroads of choices.

• Choice 1 (passive response): Wait indefinitely for the PM’s words to be confirmed. (→ Project timeline delayed)

• Choice 2 (active inference): Design the code with the assumption that 'overlapping usage is not allowed,' considering the possibility of future changes. Anyway, it’s an ‘inference.'

• Choice 3 (the most common case): Think, “I’ll just code it that way for now, and if I have to change it later, I will,” and write the code in the fastest way possible.
   

For reasons unknown, it always seems that policies come down that are different from what we thought. For instance, a final decision might come down stating, “To maximize marketing effectiveness, overlapping use of coupons and points must be allowed.” Now the developer has to modify a significant portion of the code they have already written. What seems like a simple policy change actually involves numerous changes from the database design to the payment logic and UI. This is the moment when dozens or hundreds of hours of rework costs are incurred, which could have been avoided had clarity been ensured during the planning stage with just one more hour of investment.

3. Why does planning debt occur?

So why do we accumulate such debt? Is it because planners are lazy or irresponsible? Or is it due to a lack of capabilities among our company members? Absolutely not. Most planning debt arises from systemic issues.

The PM is always short-handed. Source: Generated by Gemini

• First, there is an absolute lack of time to invest in planning. In a culture where “Market conditions are rapidly changing, so let’s just make it quickly and then think about it!” planners do not have enough time to think and validate thoroughly. Even if planners want to think deeply, they often find that the planning deliverables to be sent to the development team, executives, or clients take priority.

  
  

• Second, the personnel responsible for planning are limited. In many companies, it is common for a single planner to oversee multiple projects at the same time. Physically, they cannot attend every meeting and respond to every question immediately. As a result, planners naturally become the 'bottleneck' of the team, leading developers to become exhausted waiting for answers and decide for themselves.

  
  

• Third, there is an inefficient communication structure. Requirements are not clearly documented and are fragmented through verbal or messenger communication. This creates an environment ripe for responsibility disputes, where issues arise later and one might say, “But you said that back then!” or “I don't remember saying that.”
  
  

• Fourth, lack of communication. In fact, it’s fortunate if there is some inefficient communication at all. In many cases, planners are unable to manage details. In such cases, the development/design teams decide and execute things on their own, ultimately leading the whole team to work without a shared plan.
   

In fact, in most companies, investing in development and design capabilities comes before planning. Ultimately, planning debt is more likely a structural problem of an organization that overlooks the importance of planning and postpones investment in planning capabilities rather than an individual’s capability issue.

4. As planning debt accumulates, how should we resolve it?

So how can we break free from this tiresome burden of debt?

Of course, the most ideal solution is to “hire many capable planners and give them enough time.” But as we all know, this is an unrealistic narrative for most companies. Who knows how many companies can choose that solution?

So what are realistic alternatives? I believe we can apply three major solutions step by step.

Solution 1: Formalize 'Question Bomb Sessions'

First, I recommend that before starting development, make 'Question Bomb Sessions' an official culture of the team. When a planner shares a plan, instead of developers and designers pretending to understand by clapping, they should intentionally have a time to become the 'professional discomfort creators' and relentlessly ask questions.

• “What happens if I click this button 100 times in a second?”

• “What if the user nickname contains special characters or emojis?”

• “If the API call fails here, what message will be shown to the user?”

These questions are not attacks on the planner but a collaborative effort to defuse future time bombs together. Through this session, we gain two important things. First, planners can alleviate the burden of having to be solely responsible for everything and leverage the collective intelligence of the team. Second, developers gain a formal channel to express their concerns before the development instead of complaining later with “Why now...?”

Solution 2: Visualize debts through 'Decision Logs'

Nonetheless, there may come a moment when decisions inevitably have to be postponed. The key at that time is to remember that 'debt' and manage it transparently. We call this 'Decision Logs.' When someone says in a meeting, “Let’s decide that later,” we immediately record it in a shared document.

By visualizing these unseen debts so everyone can see, we can at least prevent forgetting them. Additionally, by specifying the “decision deadline,” we can prevent the debt from being left indefinitely and impose a sense of responsibility.

Solution 3: Invest in Planning Productivity

The first two are methods to 'manage' debts through processes and culture, while the last one is about 'preventing' the occurrence of debts and maximizing productivity through technology.

I believe we can learn from the history of development productivity. Think back to when developers were coding in notepads. They have evolved from that to quickly completing code with the help of AI coding tools like GitHub Copilot. This indicates that rather than endlessly increasing the number of people, they have evolved towards maximizing productivity through tools and systems.

The same applies to planning. It is now time to invest in systematic tools and systems to raise planning productivity rather than relying solely on the 'manpower' of planners.

• Automatically draft to complete ambiguous requirements into structured planning,

• Review missing policies or exceptional cases that may come up in 'Question Bomb Sessions',

• AI-based planning tools that automate repetitive planning document tasks that consume planners' resources, such as functional specifications, storyboards, etc.

Just as we invest in numerous tools to increase development productivity, we must now invest in increasing planning productivity as well. That is likely the wisest and most economical choice to prevent dozens of times the rework costs that may arise in the future.

In conclusion: The cheapest investment is the 'preemptive investment.'

Planning debt builds up quietly and very quickly. The moment we realize that debt is always when a project begins to wobble uncontrollably. Regrets such as “I should have paid a little more attention then” always come too late.

Our time and resources are limited. The most efficient way to use those limited resources is not to fix problems after they arise but to prevent them from occurring in the first place. Investing in planning productivity is not an expense but the most certain 'insurance' against bigger costs in the future.

manyfast.io