By the eighth iteration of a project, you can still be using the solution from the first one.
The first time, there was a reason. The timeline was short. The available tools did not quite fit. An approval arrived in a form nobody had planned for. Someone found a method that worked, and the project got delivered.
Then the next project started.
There was going to be time to regroup. To look at what took too long, what could be simplified, and what depended on somebody doing more than the plan acknowledged. But the next deadline needed attention before that conversation happened.
So the team used the method it already knew.
I recognize this pattern because I understand the decision each time it happens. When the work is moving, a method that has already worked reduces the number of decisions you need to make. You know its steps. You know whom to call when a step gets difficult. Reconsidering it takes time and attention the next project already needs.
A temporary solution can become the standard method through repetition, without anyone deciding whether it is still appropriate.
Success makes a method harder to question
People take an idea more seriously once it has been used on a successful project. People remember the deadline, the finished work, the relief of getting it out. The team comes to trust the method because it has worked under pressure.
There are reasons to trust it. The team has used it under actual production conditions and knows something about its limitations. A proposed replacement may not yet have been tested that way.
But a successful outcome does not tell you how much each part of the process contributed to it.
The work may have succeeded because of the method. It may have succeeded because somebody kept repairing the method as the project moved. It may have depended on a particular person being available, a client accepting an unusual sequence, or a volume of work small enough for manual handling.
Those conditions can be omitted when people describe the project as a precedent. What remains is that we did it this way, and it worked.
Over time, that can become an explanation of why it worked.
Repeated delivery can hide the extra work
Consider a team that manually transfers review comments into a separate working document. On the first project, it solves a real access problem. Everyone can find the instructions they need, and the work moves.
On later projects, the transfer stays. The access problem may be gone, but the working document is now familiar. People expect it. The schedule includes a review and a handoff without accounting for the copying, reconciliation, and checking between them.
Then the volume grows. There are more versions, more comments, and more opportunities for the two records to disagree. Someone spends more time keeping them aligned.
The process continues to work because that person keeps checking and reconciling the records.
Managers may see repeated successful deliveries without seeing the extra time needed to maintain the arrangement.
This is one way a workaround becomes difficult to challenge. The person proposing a change has to explain a cost that the finished output does not reveal. Everyone else can point to the fact that the last project shipped.
Continuing feels supported by experience. Changing feels like taking responsibility for a new risk.
Familiarity has practical value
There are good reasons for that hesitation.
A shared method lets people coordinate without explaining every step again. Someone joining a project can learn where to find the work and what happens next. An established check may catch an error that nobody remembers until it occurs again.
Removing a step can remove a protection along with its inconvenience.
Adopting a new tool also takes work. People have to learn it. Existing material may need to move. A faster first pass may create a harder review, or leave more corrections for someone at a later stage.
A replacement deserves scrutiny too. Compare the full effort required to produce an acceptable result, including review and correction. A fast demonstration alone does not establish that the replacement will save work.
A reliable method can remain in use while the team assesses whether it still fits the requirements. Past success can justify confidence without settling every future decision.
What conditions did the original solution depend on?
That question is often more useful than asking whether a process is good or bad.
A manual step may be entirely sensible for three deliverables and too time-consuming for thirty. An approval sequence may be necessary with one group of stakeholders and redundant with another. A method built around a long preparation period may become unsuitable when the people needed for a shoot are available only briefly.
The method may work as designed and still be unsuitable for the current volume or schedule.
New tools can also change which method is practical. A new way to explore or visualize the work can make an earlier decision possible. That can alter the whole production sequence, especially when later access or delivery time is fixed.
Another team may begin with the current requirement and propose a method the established team has not considered. Familiarity with the existing sequence can make alternatives less obvious.
That does not establish that the original team was careless. It does mean the team needs to compare the methods against the current requirements.
Test a specific change
Constant reinvention would make production exhausting. Most projects need a dependable starting point, and many reliable methods should remain in use.
You can start by checking why you are repeating a particular step.
When a workaround solves a problem, keep enough of its reasoning to revisit it: what constraint required it, what extra effort it took, and what would make it unnecessary. A short note in the existing project record can be enough. The useful thing to preserve is the condition, not just the sequence of steps.
On the next project, a changed condition gives you something specific to investigate. You can test whether one handoff is still needed or whether one manual operation can be removed. The test needs a place in the plan; otherwise process improvement becomes another task somebody performs around their actual workload.
And the people maintaining the current method need to be part of that decision. They know which awkward steps are waste and which are doing a job the rest of the team cannot see.
By the eighth iteration, the original solution may still be appropriate. Reassess the conditions that justified it, include the people maintaining it, and make time to test a change when those conditions no longer apply.