One of the most common misconceptions I run into in fixed asset management is the belief that there's a correct Construction in Progress structure — one that every organization should be working toward.
There isn't. And I know that's not the answer most people are hoping for.
People want a framework. A template. A checklist. A neat box that says this is how CIP should be organized. It's a reasonable thing to want, especially when you've inherited a process you didn't build and can't fully explain. But after working with organizations of nearly every size, industry, and maturity level, I've come to think of Construction in Progress as less of an accounting topic and more of an organizational behavior topic. And organizational behavior is rarely tidy.
Every company thinks their CIP process is unique. They're usually right.
A health system constructing facilities doesn't think about capital projects the way a manufacturer installing production equipment does. A university managing campus improvements doesn't think about CIP the way a utility managing infrastructure investments does. That much is obvious once you say it out loud.
What's less obvious is that two manufacturers with nearly identical revenue, asset values, and business models can manage capital projects in completely different ways. One centralizes everything through accounting. Another gives each division the keys to its own projects. A third routes everything through engineering. And plenty of organizations are running the whole thing on a network of departmental spreadsheets that somehow reconcile at month end.
The goal of a CIP process isn't to look like everyone else's. The goal is to reflect how your organization actually works, while providing enough structure to maintain accountability, visibility, and control. That's a very different objective, and it leads to very different answers.
The CIP spreadsheet is never just a spreadsheet
When someone opens a CIP workbook and says “this is how we've tracked projects for years,” I know I'm about to learn something useful.
Spreadsheets are organizational archaeology. Every hidden column, every formula nobody can explain, every color-coded tab and cryptic abbreviation and worksheet named DO NOT DELETE is telling you something — usually a story about survival.
Someone retired. Someone left. An acquisition happened. Departments reorganized. A new reporting requirement appeared with a deadline attached, and nobody had a system that could handle it. So someone built a spreadsheet. Then another one. Then a bigger one to reconcile the first two.
Years later, nobody loves it. Nobody fully understands it. And nobody wants to touch it, because somehow it still works. Mostly.
I don't say any of that as a criticism. Those workbooks kept the lights on, often for a decade or more, and the people who built them were solving a real problem with the tools they had. What they cannot survive is being lifted into a new system as-is, which is a separate and expensive conversation about what has to be fixed before a data conversion.
The real CIP problem usually isn't technology. It's turnover.
Every organization has institutional knowledge. The challenge is that institutional knowledge has a habit of walking out the door.
A person leaves. A replacement inherits a process. A custom field gets repurposed. A report gets renamed. A workaround becomes standard practice. Five years later, nobody remembers why any of it exists.
I've heard some version of these hundreds of times, almost always from capable people doing their best with what they were handed:
- “We've always done it that way.”
- “I think somebody set that up years ago.”
- “I wasn't here when that decision was made.”
- “There may be documentation somewhere.”
And the one that gives me the most pause: “I think that's right.”
Those aren't accounting issues. They're governance issues. CIP has a remarkable ability to expose them — not because anything is wrong, but because CIP sits at the intersection of operations, accounting, engineering, purchasing, project management, tax, and leadership. When that many groups touch one process, the weak seams become visible quickly. It is the same pattern I keep writing about from other angles: the fixed asset problem usually isn't in fixed assets.
Capital approval and capital budgeting are not the same process
One of my favorite conversations starts with a simple question: what's your approved capital budget?
Sometimes I get a detailed planning model. Sometimes I get a number. And sometimes I get a shrug — the one that means “if somebody important approves it, we buy it.”
I'm not judging. I've seen successful organizations operate that way for years, and in some of them it's a deliberate choice rather than an accident.
But there's an important distinction worth naming. A capital approval process answers can we do this? A capital budgeting process answers should we do this? Those aren't the same conversation, and one of the more common discoveries during a CIP implementation is that an organization has built one without the other. Where that gap gets closed is upstream, in how capital gets planned in the first place.
Software doesn't create governance. It shines a flashlight on whether governance exists. Sometimes that flashlight finds things nobody expected — which is exactly why automating a broken process only makes it faster.
Four ways organizations structure CIP ownership — all of which can work
Part of the reason there's no universal best practice is that these models are all legitimate. Each one has a real strength and a predictable failure mode.
- Centralized. Accounting owns everything: projects are created, reviewed, and capitalized by a central team. The benefit is consistency. The risk is that accounting eventually becomes the bottleneck for every capital request in the company.
- Divisional. Common in larger manufacturing and multi-entity organizations. Each division owns its projects; corporate accounting sets policy and reporting standards. The benefit is ownership, and decisions stay close to the operations making them. The challenge is holding the line on consistency, so that eight divisions don't quietly create eight different versions of CIP.
- Project-management-led. Often found where construction initiatives are large. Project managers own budgets, operations owns execution, accounting owns capitalization. When responsibilities are clearly drawn, it works beautifully. When they aren't, everyone assumes somebody else is handling it — and nobody is.
- Distributed spreadsheets. Every department keeps its own workbook. Each month, someone assembles a master file, someone else reconciles it, and a third person questions the numbers. Everyone agrees there's a better way, and somehow the process survives another decade. I mention it with affection, because a great many successful organizations started exactly there.
The best question isn't “how.” It's “why.”
Implementation conversations get dramatically more valuable when we stop asking how do we configure this and start asking:
- Why is this project structured this way?
- Why does this approval happen?
- Why is this field tracked?
- Why are two departments doing the same thing differently?
- Why does this report exist, and who reads it?
- Why has nobody questioned it in seven years?
The answers are almost never technical. They're organizational, cultural, operational — human. And that's where the real value of the work lives.
CIP is really about organizational clarity, not software
The longer I work in fixed asset management, the less I believe CIP is fundamentally about depreciation, invoices, or software. Those things matter, obviously. But the most successful CIP environments I've seen weren't successful because the system was configured perfectly. They were successful because the organization finally took the time to understand itself.
Who owns projects. Who approves spending. Who tracks costs. Who moves assets into service. Who's accountable when something drifts. And, maybe most importantly, who's responsible for preserving that knowledge when people move on.
Systems don't create organizational clarity. People do. The software simply reveals whether that clarity is there.
A hundred-plus implementations in, I've yet to find two organizations that manage capital projects exactly the same way — and honestly, that's what keeps this work interesting.
If you're trying to work out which of these models you actually have — or which one you've drifted into — that's the conversation CIP and capital project consulting starts with.
