In this series I'm going to  peeling the onion on the real problems that sit behind the problems you face when you own or manage real estate. It's the fact that every time you solve for one problem another can appear. That's especially true the moment you reach for technology.

We all feel this when we try to fix a pain point with a spreadsheet, a form builder, or a custom-built tool. The original problem improves… and suddenly three new ones surface that you never planned for.

That's not automatically bad just as long as the core problem you're solving actually matters to the business.

Capex What Are We Really Trying to Solve?

It might be helpful to start with a shared definition.

Capital or non-routine project: Larger or less frequent work that adds value, corrects a significant issue, adds capacity, or extends the useful life of an asset. It is not the everyday work order or make-ready repair (though those can reveal non-routine needs). It usually requires skill, expertise, or coordination beyond the day-to-day capacity of the onsite team.

The surface-level problem most of us state is:

"I need to successfully complete capital and non-routine projects at my site or across my portfolio."

 "Successfully" is doing a lot of work in that sentence. For our purposes it means:

• Costs stay reasonably close to expectations
• Quality of the finished work is acceptable
• Business disruption is minimized
• Work finishes in a timeframe that actually supports the asset and the ownership goals

Scale matters from the start. A sole proprietor with two duplexes faces far less complexity than a owner or PMC running 15–20 or more properties. The explicit requirements (permits, notices, lien releases) may be similar, but the coordination tax is completely different.

To get a project done you eventually have to answer five practical questions:

1. How do I identify and prioritize the work?
2. How do I plan and budget?
3. How do I procure and put it under contract?
4. How do I manage the work once it starts?
5. How do I close it out cleanly?

This article focuses on the first one — Identify & Prioritize — and watches the onion layers appear.

Identify & Prioritize: Where the Snowball Starts

Some projects self-identify. A roof is torn off in a storm. A resident's grill sets a balcony on fire. A code inspector hands you a corrective-action letter. Those land in your lap. Prioritization often feels obvious in the moment (even if the root cause, like allowing grills on patios, or missing earlier inspection signals, should have been caught earlier).

Most of the time, however, good identification is proactive. You are either executing a repositioning/rehab strategy or you need a reliable way to inspect and track the condition and remaining life of systems and components so you can forecast instead of constantly reacting.

That single shift — from reactive to proactive — immediately creates new problems:

• How do we inspect and keep the information?
• Where do we track not just the inspection results but the underlying characteristic data about the site, its buildings, systems, and features?

At the simplest level you only need knowledge of what to look for, a camera, and a notebook or spreadsheet. For one person running one site, that can be enough. The moment you have multiple people and multiple sites, the questions multiply:

• How do we stay consistent and thorough across different inspectors?
• How do we prompt the inspector so critical items are not overlooked?
• How do we share results so the right people can act on them?

A form is the common answer. Plenty of tools let you build comprehensive checklists. You can be very explicit about what must be checked. But now you have a new set of decisions:

• Will photos be taken? Where are they stored and how are they linked to the findings?
• Is the form fixed or flexible enough to capture site-specific realities?
• Where do the completed results live long-term?
• Who needs access, for how long, and under what permissions?

None of these individual problems is especially hard. The difficulty is the cumulative effect.  Each layer you solve opens two or three more. Multiply that by every functional team (operations, accounting, risk, capital planning) solving similar problems in their own silos and you quickly end up with ten or twenty different "lists of properties," overlapping data, and a permanent data-integrity problem of its own.

This is not meant to discourage you. It is meant to give you pause before you decide to build or stitch together the solution yourself. Purchasing purpose-built software does most of the heavy lifting on these secondary and tertiary problems — but even the best platform is not omnipotent. The real advantage is that the platform has already absorbed dozens of the layers so your team can stay focused on the primary goal: identifying the right work and prioritizing it intelligently.

Looking ahead

In the next articles we'll peel the same onion for planning & budgeting, procurement & contracting, managing the work, and close-out. Each stage has its own cascade of "problems behind the problem." The pattern is consistent: the more sites and people involved, the faster the complexity compounds 

— and the more valuable a purpose-built system that already solved most of those layers becomes.

What layers have you already run into when trying to get consistent condition data or project prioritization across your portfolio? I'd love to hear what's worked (or what still frustrates you) in the comments.