Product flowProject flow

The first time I saw it clearly, I was in lending, watching two completely different kinds of work run through the same building. One side ran like a machine, and it was built to. The other side got forced through that same machine and turned into a scramble every single time. Same company, same people, and one of the two was quietly coming apart. You cannot run a project on a production line. You can pretend to, and you can brute force it for a while, but the work fights the machine the whole way.

Six questions, and you can answer every one without pulling a report.

1. Which part of what you sell runs the same way every time, and which part gets figured out job by job?
2. Do both kinds of work run through the same quoting, the same schedule, and the same system, all built when there was only one kind?
3. When a project job hits the floor, does it follow a process or a person?
4. When a project collides with the standard work, who decides what gets bumped, and is that written down anywhere?
5. Which kind of work is your margin actually coming from, and how sure are you?
6. When a project goes sideways, does the review change how the next one runs, or does everyone just remember it and move on?

If the first two were easy and the rest landed somewhere uncomfortable, the rest of this piece is about that gap.

Two different breeds of animal

A consumer loan is a product. A car loan runs one way, a credit card another, a mortgage another, and each one runs the same way every single time. Same application, same checks, same file, the process fixed before the customer ever walks in. The only real variable is how many come through the door. The whole operation is built to move that volume, and because each product repeats, it works.

A commercial loan is a different breed entirely. Almost nothing about it is fixed in advance. The structure gets designed for the deal. The terms get negotiated line by line. The covenants get written to fit one borrower's situation, and the underwriting is a bespoke read of a business that looks like no other. You are not moving an application through a process. You are building something that has not existed before and will not exist again. The one thing you know at the start is that money will change hands eventually, if it all comes together.

Fig. 1 / Two kinds of work

One runs on repetition. The other runs on judgment.

The instinct almost everywhere is to run the second animal through the machine built for the first. The project based product gets forced onto rails built for a linear, standard one. Same pipeline, same checklist, same throughput targets, because that machine is already there, and running everything through it looks like order. It looks like control. It looks like a real process. What it actually produces is a scramble, and the scramble is mostly rework, cleaning up what the wrong process got wrong the first time. The people caught in it are not the problem. The rails are. Talk to anyone who has run commercial lending outside the top national banks and you will hear the same story. The problem is chronic.

It is not a banking problem

You do not have to be in banking to feel this. Almost every business that grows ends up selling both a product and a project, and trying to run them on one set of rails. The contractor whose crews run standard service calls all week and one custom build on the side is running both. One is a route, the other is a project, and it never fits the route. The firm that files three hundred routine tax returns and then takes on one tangled business sale is running both animals through the same office, on the same calendar, with the same tired people. It shows up hardest on a plant floor, where a line that has run to one standard for years suddenly shares its planning with a newer line specified job by job. The bottlenecks migrate, the schedule stops telling the truth, and the floor feels busier than the numbers can explain.

What the scramble costs

Peter Drucker named the whole trap in one line, decades ago. "There is nothing so useless as doing efficiently that which should not be done at all." A fire drill is efficiency aimed at exactly the wrong target, and the bill comes due in four places.

1. The schedule stops being believable. A process built for volume cannot predict work that is different every time, so the dates turn into guesses and everyone learns not to trust them.
2. Quoting inherits the wrong instincts. The project gets priced like a product, and the real number only shows up after it ships.
3. Margin blurs. Run both kinds of work through one set of books and you cannot see which one is paying and which one is quietly bleeding.
4. The best work runs on heroics. The project side gets delivered by a few specific people staying late and calling in favors, which is a countdown, not a plan.

Underneath all of it is usually the fact that no one owns the whole pipeline end to end, but that is its own article. And most of the cost never shows up where you would look for it. Armand Feigenbaum, who built the discipline of measuring what quality actually costs, called it the hidden plant, the share of a company's capacity quietly spent making things twice. It does not land on the schedule. It lands as overtime, missed dates, and a floor that is always busy and never caught up.

There is an older name for the daily version of this. Roger Bohn called it firefighting in work published in the Harvard Business Review, and his list of symptoms has not aged. Too many problems and never enough time. Fixes that patch instead of solve. The same problems coming back around. Urgency always beating importance. Output quietly getting worse while everyone stays busy. Firefighting is not a moral failing of the people doing it. It is the predictable result of a system running work it was never built to run.

Standardize the handling, not the work

The wrong fix is the obvious one. Force the project work to behave like the product. Make it fit the standard box, strip out what makes each job different, and turn it into something the volume machine can swallow. That kills the thing the customer is actually paying for. The variation is usually where the growth is. You do not want to remove it. You want to stop pretending it is not there.

The real fix is quieter. You do not standardize the work. You standardize how you handle it. The project stays bespoke. What gets a process is everything around it. How a project job gets taken in and scoped, so it does not start life as a guess. How it gets quoted, on its own logic instead of the product's. How it gets scheduled, with rules for what it can bump and what it cannot, written down instead of decided in the moment by whoever is loudest. And how it gets reviewed when it is done, so the next one runs on what the last one taught instead of on memory. None of that makes the work less custom. It makes the custom work survivable.

Fig. 2 / Sort it, then handle it

You do not standardize the work. You standardize how it gets sorted.