Early Planning Works. So Why Is It So Difficult to Fund?

May 11 / Mathias Vermehren
Early Planning reduces rework, improves quality, and lowers long-term support costs. Yet it is difficult to fund because project budgets favor visible implementation work, while the benefits of better planning may only appear across future projects.

Traditional delivery creates useful experience and templates, but reuse is often inconsistent and dependent on individuals. Large improvement programs can build a stronger foundation, but they require significant upfront investment and may produce capabilities that are over-engineered, underused, or incomplete.

T5 offers a practical middle path. It breaks improvement into smaller, outcome-defined engagements that address immediate project needs while contributing to a larger architectural direction. Its value is not simply building tools, but helping organizations identify the right next improvement, reuse existing capabilities, validate results, and compound benefits over time.

A practical case for replacing large improvement programs with smaller, outcome-defined T5 engagements—without losing sight of the larger vision

Most experienced software teams recognize the value of Early Planning.

When requirements are understood, responsibilities are clarified, and important design questions are resolved before implementation begins, a project is more likely to deliver the required functionality. Deployment becomes more predictable, late changes are reduced, and the finished system is generally easier to operate, maintain, and extend.

This principle is especially important in industrial software projects, where the consequences of an incomplete requirement or poor design decision may not become visible until commissioning—or even after the system has entered production.

Early Planning supports product quality, predictable delivery, and customer satisfaction. It can also reduce the Total Cost of Ownership by lowering future maintenance, troubleshooting, modification, and support effort.

The principle is sound.

The practical problem is that very few organizations can invest in Early Planning as completely as the principle appears to require.

Projects often begin with tight budgets, committed schedules, and pressure to produce visible results quickly. Planning competes with implementation work that seems more concrete and urgent. Improvement initiatives must compete with production needs, customer commitments, and other investments that promise more immediate returns.

The challenge is therefore not simply to convince organizations that Early Planning creates value.

The real challenge is to make improvement work practical, fundable, measurable, and connected to a larger direction.

Important Questions Are Less Expensive to Resolve Early

The purpose of Early Planning is not to spend as much as possible before implementation begins.

Its purpose is to resolve the right questions before they become expensive problems.

A missing requirement may be inexpensive to clarify during analysis. The same requirement can become much more costly after software has been developed, interfaces have been approved, suppliers have committed to a design, and production schedules depend on the finished system.

Early decisions also influence what happens after deployment.

A system built around clear requirements, reusable structures, consistent engineering methods, and well-understood information is normally easier to troubleshoot and modify. A system built through repeated exceptions and undocumented decisions may continue generating support and maintenance costs for years.

However, there is an important difference between understanding the value of Early Planning and knowing how to implement it successfully.

How much should be invested?

Which improvements should be made first?

Who should pay for capabilities that may benefit several future projects?

How can the organization avoid over-engineering solutions before practical needs are fully understood?

And how can individual improvements contribute to something larger without requiring the entire future architecture to be designed in advance?

Our experience suggests that improvement commonly develops in one of three ways.

1. Traditional Project Delivery: Learning Is Recreated Project by Project

Even without a formal improvement program, every software project creates something that may help the next one.

A project team may develop:

  • specification templates;
  • spreadsheets;
  • software modules;
  • checklists;
  • testing methods;
  • troubleshooting procedures;
  • training materials;
  • small productivity tools;
  • or lessons-learned documents.

Some of these artifacts are reused. Experienced team members also carry knowledge from one project to another.

The problem is not that no improvement occurs.

The problem is that the improvement is often informal, person-dependent, and difficult to reproduce consistently.

The success of the next project may depend heavily on how well the previous team documented its work, whether the same people remain available, and whether the artifacts can be understood outside the context in which they were created.

A template may be copied but not the reasoning behind it.

A spreadsheet may be reused without clear ownership or maintenance rules.

A software library may remain on one engineer’s computer.

A checklist may be modified independently by several teams until multiple conflicting versions exist.

A lessons-learned document may be stored somewhere but never incorporated into the next project’s working method.

The organization therefore accumulates experience, but it does not necessarily convert that experience into dependable organizational capability.

Knowledge continues to reside primarily in the heads of the people who performed the work. It passes slowly from one team or project to another through conversations, personal relationships, copied files, and informal coaching.

Some projects benefit significantly from earlier experience. Others repeat the same analysis, rebuild similar tools, or rediscover problems that were already solved elsewhere.

The result is an irregular cost pattern.

One project may perform well because an experienced person is available. The next may struggle because that person has moved to another role. A template may save time on one project but create confusion on another because its assumptions were never documented. A reusable tool may help several teams until a technical change makes it difficult to maintain.

The benefits of reuse are real, but they are not guaranteed.

2. A Large Early-Planning Initiative: Better Results, but a Bigger Upfront Bet

An organization may attempt to solve these problems through a broad Early Planning or improvement initiative.

Instead of allowing each project to create its own methods, the organization may invest upfront in:

  • common engineering processes;
  • standardized templates;
  • reusable software libraries;
  • central knowledge repositories;
  • governance procedures;
  • training programs;
  • information models;
  • testing frameworks;
  • and new productivity platforms.

This can produce substantially better results than relying only on informal project-to-project learning.

Later projects may have clearer requirements, more consistent documentation, better-trained teams, fewer implementation errors, and shorter deployment phases. Common tools and standards can reduce repeated work and make support more predictable.

The organization creates a stronger foundation before individual projects must solve every problem for themselves.

However, a large one-time initiative introduces a different set of risks.

The organization must make many decisions before enough practical evidence is available.

Some deliverables may be designed for situations that rarely occur. A tool may become more configurable and complex than the teams actually need. A governance process may be theoretically complete but too cumbersome for daily use. Extensive templates may be created for project types that appear infrequently.

At the same time, important needs may remain undiscovered until the new approach is applied to real project work.

The improvement initiative may therefore produce an uneven result:

some capabilities are highly valuable;
some are over-engineered;
some are difficult to adopt;
some require unexpected maintenance;
and some important practical gaps remain.

This does not mean that the initiative was unsuccessful.

The overall outcome may still be significantly better than the traditional case. Projects may become more consistent, and the organization may achieve meaningful long-term savings.

The challenge is that the organization must fund a substantial improvement program before knowing exactly which deliverables will create the greatest practical value.

The financial return may also depend on factors that remain uncertain when the initiative begins:

  • the number of future projects;
  • the types of projects that will be awarded;
  • whether teams actually adopt the new methods;
  • whether the tools and standards remain maintained;
  • and how closely the planned capabilities match future needs.

The organization begins with a large negative investment position and may recover that investment only after the capabilities have been reused across several projects.

3. T5: Incremental Improvement Without Losing the Larger Perspective

T5 applies the principles of Early Planning through smaller, outcome-defined engagements.

However, T5 should not be understood as a method for producing a series of unrelated quick fixes or small tools.

The most important work often occurs before a specific deliverable is selected.

An organization may already have spreadsheets, document templates, software libraries, internal applications, engineering platforms, training materials, checklists, and experienced specialists.

The problem may not be the absence of another tool.

The problem may be that the organization’s existing capabilities are:

  • disconnected;
  • inconsistently applied;
  • poorly governed;
  • difficult to reuse;
  • dependent on undocumented knowledge;
  • or based on information that has never been structured clearly.

Most organizations already have people who can create spreadsheets, scripts, templates, applications, or internal utilities.

T5 is not intended simply to duplicate that capability.

Its principal added value is helping the organization understand the larger improvement opportunity and determine which incremental improvement should come next.

That decision may consider:

  • the immediate impact on the current project;
  • the effort and risk involved;
  • the availability of existing tools or methods;
  • the potential for reuse;
  • the relationship to other improvement opportunities;
  • the information structures that must be clarified;
  • and the evidence that could justify the next investment.

The selected outcome may be a new productivity tool.

But it may also be:

  • a better use of an existing tool;
  • a structured information model;
  • a reusable specification template;
  • a workflow definition;
  • a governance rule;
  • a review checklist;
  • a focused training module;
  • a clearer division of responsibilities;
  • a knowledge library;
  • or a small working example used to validate a larger idea.

The objective is not merely to build the requested deliverable.

The objective is to identify the right next improvement and understand how it can contribute to a more coherent and reusable organizational capability.

The Larger Vision Should Guide the Improvements

Ideally, individual T5 engagements contribute to a larger architectural vision.

That vision may describe how the organization’s knowledge, information, workflows, responsibilities, templates, tools, training, governance, and software capabilities should eventually work together.

However, the complete architecture does not necessarily have to be defined before the first engagement begins.

Attempting to design the entire future state upfront could recreate the cost, uncertainty, and over-engineering risks of a large one-time improvement program.

T5 can instead begin with an architectural hypothesis.

This is an initial understanding of:

  • the organization’s current situation;
  • the capabilities it already has;
  • the recurring problems it encounters;
  • the relationships among information, people, processes, and tools;
  • and the direction in which improvement may be valuable.

The initial vision provides perspective, but it remains open to refinement.

Each T5 engagement tests part of that vision through practical application.

A specification review may reveal that several documents depend on the same information but define it differently.

An improvement to an existing spreadsheet may reveal the need for a common information model.

A training engagement may demonstrate that the real problem is not insufficient instruction but an unclear workflow.

A productivity tool may reveal that ownership and governance are more important than further automation.

A reusable template may expose dependencies that were previously hidden between engineering, operations, project management, and suppliers.

These discoveries do more than improve the immediate deliverable.

They also help the organization understand the larger architecture more clearly.

The architectural vision guides the incremental improvements, while practical evidence from the improvements continuously refines the vision.

Each Engagement Should Produce Value Now and Build Capability for Later

A T5 engagement should normally aim to create two related results.

The first is a defined outcome that is useful within the current project.

The second is a reusable capability or architectural insight that can support future improvements.

For example, a project may fund an improvement to an existing spreadsheet because the spreadsheet is creating delays and repeated manual work.

The immediate outcome may be:

  • a more reliable calculation;
  • a clearer workflow;
  • fewer manual entries;
  • or faster preparation of a recurring deliverable.

During the engagement, the team may also identify:

  • the information model behind the spreadsheet;
  • which source documents provide the data;
  • who owns each part of the workflow;
  • which validation rules are needed;
  • where the same information appears elsewhere;
  • and whether the spreadsheet should eventually connect to other systems.

The immediate result is a better spreadsheet.

The broader result is a clearer understanding of how that spreadsheet fits into the organization’s larger engineering or information architecture.

The organization can then make a better-informed decision about whether to continue using it, improve it further, connect it to other capabilities, or eventually replace part of it.

This is what prevents incremental improvement from becoming a collection of disconnected local solutions.

Smaller Investments Can Be Easier to Justify

A large transformation initiative may require a strategic budget based on projected benefits that will only become visible after several projects.

A T5 engagement connects the investment more closely to a defined outcome.

A current project may be able to justify funding for:

  • reducing specification review effort;
  • creating a reusable project template;
  • improving a recurring engineering workflow;
  • developing focused training;
  • structuring a specific body of knowledge;
  • validating a proposed method;
  • or improving an existing tool.

The engagement remains bounded enough to understand, approve, and evaluate.

Its impact on any one project may be smaller than the impact promised by a major transformation program. However, the outcome is more visible, the risk is more contained, and the evidence is available sooner.

Once the improvement has been validated, it can be applied again.

The next project receives the immediate benefit of the earlier work. It may then fund another improvement that builds on the existing capability.

Over time:

  • templates become more complete;
  • knowledge becomes easier to access;
  • tools become better connected;
  • methods become more consistent;
  • training becomes more relevant;
  • governance becomes more practical;
  • and repetitive work decreases.

The improvements compound.

A small engagement that would not justify a company-wide initiative on its own may still create enough project-level value to be funded. Once validated and reused, it also strengthens the case for the next improvement.

This allows valuable work to proceed that might never be approved as part of one large program.
T5 does not require every engagement to be part of a fully defined master architecture.

Some opportunities may remain local by nature. Others may not justify further development after they have been tested.

But the larger perspective should always be considered.

Can the result be reused?

Does it reveal a recurring pattern?

Does it depend on information that should be structured more clearly?

Could an existing tool provide the required capability?

Would governance or training create more value than automation?

How does the improvement relate to other parts of the organization’s workflow?

This perspective is what distinguishes purposeful incremental improvement from isolated tool building.

How Our Own Improvement Process Developed

Our understanding of this problem did not begin as a management theory.

It developed through our own experience designing and delivering industrial software systems.

Our software-development process did not improve through one large transformation initiative.

It improved gradually.

We created a better template and then refined it on the next project.

We developed reusable software components.

We improved checklists and testing methods.

We created small productivity tools.

We documented recurring decisions.

We structured knowledge that had previously existed only in the experience of individual team members.

We learned which improvements produced real value and which ideas were more complicated than the problem required.

Many of these improvements were developed during our own weekends, holidays, and discretionary time because we could see that future projects would benefit from them.

Each individual improvement may have appeared small.

Together, they changed how efficiently and reliably we could deliver future projects.

That experience confirmed the value of incremental improvement, but it also exposed a weakness in the traditional model.

The improvement depended on hidden effort.

Customers benefited from tools, methods, templates, and reusable knowledge created outside the visible project budget. However, the improvement work itself was not always defined as a project outcome.

It was therefore difficult to:

  • fund;
  • measure;
  • prioritize;
  • govern;
  • maintain;
  • and reproduce systematically.

That approach is also difficult to sustain.

An organization should not have to depend on employees, engineers, or specialists donating personal time to create the reusable capabilities the business needs.

T5 formalizes the useful part of this experience.

It turns gradual improvement into a visible engagement with:

  • a defined current need;
  • a justified scope;
  • an outcome that can be applied in practice;
  • a method for validating the result;
  • and a deliberate connection to future reuse and the larger architectural direction.

Architecture Through Evidence

A large transformation program often attempts to define the future architecture first and then asks projects to adopt it.

T5 can follow a more adaptive path.

It begins with enough architectural understanding to avoid isolated decisions, but it does not assume that the complete future state can be designed correctly before practical evidence is available.

The organization identifies a meaningful next improvement.

That improvement is applied in real work.

The result is evaluated.

The reusable parts are retained.

The architectural understanding is updated.

The evidence then helps determine the next priority.

This creates a continuous relationship between vision and execution.

Without a larger perspective, small improvements can become disconnected tools and local optimizations.

Without practical validation, a large vision can become an expensive collection of assumptions.

T5 connects the two.

The Objective Is Not to Plan Everything Upfront

Early Planning remains important.

But the objective should not be to predict, design, and fund every future capability before work begins.

The objective is to resolve the right questions early enough, identify the most valuable next improvement, apply it within a practical scope, and retain what has been learned.

Traditional project delivery may create useful artifacts without ensuring that they are transferred or reused consistently.

A large Early Planning initiative may create a strong common foundation, but it requires the organization to fund and define much of the future before enough practical evidence exists.

T5 occupies the space between these approaches.

It maintains a larger architectural perspective while limiting each investment to a defined, useful, and testable increment.

The objective is not simply to build something small.

The objective is to select the right small improvement, make it useful now, validate its value, and ensure that what is learned can contribute to something larger.

A T5 engagement may produce a tool, template, model, method, training module, governance rule, or structured body of knowledge.

Whatever the immediate outcome, the larger question remains:

How can this improvement solve today’s problem while strengthening the organization’s ability to improve tomorrow?