When we start an engagement with a PM/CM firm, one of our first requests sometimes surprises people: can our engineers sit in on a few OAC meetings, a schedule review, and a month-end close?
It is not a sales tactic. It is how we figure out what to build.
The problem with requirements documents
Traditional technology projects start with requirements. Someone interviews stakeholders, writes a document, and hands it to developers. The developers build what the document says.
In AEC operations, that approach misses most of what matters. The real workflow is rarely what people describe in an interview. It includes:
- The spreadsheet a PM keeps on the side because the PMIS report is not quite right
- The three emails it takes to get a number from accounting
- The way a superintendent actually talks about progress, which is not how the schedule describes it
- The step everyone skips when they are busy, and the problems that causes later
People do not leave these out on purpose. They are just so familiar that nobody thinks to mention them.
What we learn by being in the room
Where time actually goes. In an OAC meeting, you see which questions take the longest to answer and which numbers people have to go find.
What decisions depend on. A schedule review shows which information leaders actually use and which reports get ignored.
The language of the work. Tools that use your team's vocabulary get adopted. Tools that use generic software language do not.
The handoffs. Most delays happen between people and systems, not inside a single task. You only see handoffs by watching the work move.
What this changes about what we build
Being embedded leads to smaller, more specific tools that fit into existing habits. For example, instead of a new dashboard nobody opens, it might be:
- A plain-English answer in Teams to a question a PM asks every week
- A first draft of the report someone rebuilds every month
- A check that runs before a meeting so the right issues are on the agenda
Preserving the existing workflow is usually the fastest path to real adoption.
What it asks of the client
Embedding is not free for the client. It requires:
- Access to meetings and working sessions, with appropriate confidentiality
- A few people willing to show how they actually work, including the messy parts
- Patience in the first weeks, when we are mostly listening
In return, what gets built solves problems people actually have.
Where this approach does not fit
Forward deployed work is not the right choice for everything. If a firm needs a standard, well-understood tool deployed as-is, embedding engineers is overkill. It earns its cost where the workflow is specific to the firm and the value depends on getting the details right.
How we approach it
This is the core of the InstinctIQ model: a fractional, forward deployed team that learns your workflows from the inside and builds or adapts technology around them, alongside products like IQ-Scheduling, IQ-Pursuit, and IQ-Forecast.
A useful next step
Think about your last OAC meeting. Which question took the longest to answer? Write it down. That question is often the best place to start, and we are happy to talk it through.
Want a forward deployed team inside your firm?
Join hundreds of AEC teams already saving hours every week.