AI Implementation for Architecture and Engineering Firms

A mid-size MEP engineering firm we know runs Unanet as its ERP. Unanet holds every project, phase, timesheet line, and employee record, and the firm still could not get a whole-firm picture out of it, because the built-in reports do not join those tables the way partners ask the questions and setting up custom dashboards means hiring another consultant. So one person on staff built the layer themselves, on Microsoft Fabric, and it took about a month to work out the structure before the dashboards came together.

The structure is the standard three-tier pattern that data engineers use, and it is worth learning the names because every vendor will use them.

Gold holds two kinds of tables. Dimensions are the lists you look things up in: employees, clients, projects, and a date table. Facts are the events: every timesheet line is one person billed to one project for so many hours. The date table was built by hand, 2020 through 2030, with fiscal quarter, week of year, and day of month already filled in, so the dashboard looks values up instead of calculating them. The rule in Power BI is that no calculation happens in the dashboard at all. It only connects tables from gold through a semantic model.

The reason silver exists is that the ERP does not give you clean rows. The employee record comes back with a job title ID rather than a title, and the title, the studio, and the office each live behind a different API call, so one clean employee row takes four calls joined together. Timesheet lines arrive without a project attached, so a timesheet fact table takes the project API, the timesheet API, a project search API, and the organizations API before a line knows which project it belongs to. Unanet grants API access on request, and the request took a phone call. None of this is unusual. It is what most ERPs look like once you get behind the screens.

What the month bought is a project management dashboard the ERP could not produce. Each phase shows budgeted hours against billed hours, next to how much of the schedule has elapsed. On one phase, 58 percent of the schedule had passed and more than 100 percent of the budgeted hours were billed. On another, about 1,700 hours were billed to a construction documents phase with no budget entered at all, so nobody could say whether the project was making or losing money. The dashboard did not fix either problem. It made both visible in the first week instead of at closeout, and the finance team now checks the numbers against the ERP so the two agree.

This is the part firms skip when they think of AI implementation as a software choice. An assistant that writes its own queries against gold gives answers you can trace back to a timesheet line. The same assistant pointed at the raw pull gives numbers nobody can check, and partners stop using it after the second wrong one.

The same firm tested Copilot before rolling it out, and the results were uneven in a way every firm should expect. Asked for a specific reimbursement figure inside a long travel policy, Copilot found it. Asked how the employee handbook defines full-time and part-time staff, it said it could not find the answer, and the definitions were in the document. Asked about a plan detail in the benefits guide, it missed again. A second tool found all three. Same tenant, same files, different retrieval. So the first governance step is a test on ten of your own documents with questions you know the answers to, before anyone buys seats.

The second step is permissions, and in Microsoft it lives in Purview. IT defines security groups by discipline or role, such as all mechanical engineers or all principals, and applies sensitivity labels to files. A file labeled confidential stays out of Copilot results for anyone outside the group that may see it, and a file you have access to shows up for you. That means an assistant can only leak what your permissions already leak, which is the standard a firm's IT and clients will hold it to. Do this before the rollout, because pulling it back afterward means pulling the assistant back too.

To compare options, the firm scored each one out of five on six criteria: data reach, meaning what it can read natively, with setup, with an agent, or not at all; adoption friction; reversibility if it turns out badly; output quality; integration with the systems already in use; and cost. Writing the scores down settled an argument that had been running on demos, and demos always show the moon.

The rollout itself is in waves. An AI council owns policy, two champions per studio answer questions in the studio, and the first wave is 11 to 15 people. The second wave is the 46 staff who marked themselves very interested on an earlier survey, and the rest follow once the champions have a month of answers written down.

The clearest implementation we have run is small, which is why it is a useful model. A customer-facing business with one support inbox was getting the same questions every day and answering each by hand. We built an assistant that reads incoming mail, checks the calendar, looks up the company's real prices and policies, and writes a reply draft in the company's voice into Gmail Drafts. A person reads every draft and sends it. Nothing goes out on its own, and that boundary is what made the owner comfortable turning it on.

Writing and deploying the code took one to two days. The knowledge took longer, and it is the part a firm cannot delegate. The company's knowledge lives in six Google Docs the client edits themselves: hard facts, which is the only place a number may come from and where any unverified value is marked so the assistant refuses to quote it; judgment rules for when a request bumps a limit; response playbooks copied from real past emails; escalation triggers for the situations it must not attempt; a voice file derived from about 600 real sent emails; and a plain-English overview for the team. A nightly job rebuilds the search index from the Docs, so a price change made today is live tomorrow.

The tuning loop is the piece most pilots lack. Every draft is archived, and a weekly report compares each draft to what was actually sent. A draft kept as-is means the docs are right. A draft that was edited shows exactly which line changed, and that line goes back into the docs: a wrong number to hard facts, a missing offer to judgment rules, a tone problem to the voice file. The model never learns from corrections. The documents do, and that is what keeps the output improving after the consultant leaves.

Transpose that to an engineering firm and the shape holds. The inbox is the RFI log, the client inquiry address, or the front desk. The hard facts are your standards and fee schedules. The playbooks are your best past responses. The person in the loop is the project manager who already reviews every outgoing answer. The playbook for running this deployment is on our AI implementation page, and the one-month implementation guide lists four more projects that fit the same pattern.

Days 1 to 30: inventory and access. List the systems and the document sets. Write the three questions partners ask monthly and the one workflow you will implement first, with the number that tells you it worked, such as minutes per response or drafts sent without edits. Request API access from the ERP vendor. Have IT define the security groups and label the confidential set. Run the ten-document retrieval test on the tools you are considering.

Days 31 to 60: build the layer and ship to five people. Build gold tables for the three questions only. Write the knowledge docs for the workflow, from real past responses rather than from memory. Turn the workflow on for five people with a person reviewing every output, and start the weekly comparison of what the assistant produced against what people actually used.

Days 61 to 90: tune, decide, write it down. Fold each week's edits back into the docs. At day 90, compare the success number to day one and decide whether to keep, widen, or stop. If you keep it, write the two-page playbook for how your firm uses it and hand the next workflow to the champions. Firms that add one workflow a quarter are in a different place after eighteen months, and each one gets cheaper because the data layer and the permissions are already there.

In-house, the data layer needs one technical person for about a month, plus IT time for Purview, plus a champion per studio who gets a few hours a week. Tool costs are modest next to that: Fabric capacity and Copilot seats on the Microsoft side, or Google Workspace with a Cloud Run service that costs tens of dollars a month for a small inbox. The expensive input is the staff time to write down policies and review outputs, and no vendor removes it.

Outside help is what an AI implementation consultant does for an engineering or architecture firm: pick the workflow, get the data and permissions in order, build or configure the tool, train the people who use it, and run the review loop until the output is trusted. We do that work in two forms. The AI Implementation Sprint is a fixed-price three to four week build. The AI Strategy Retainer makes us your AI technology implementation consultant on a monthly basis: a working session with leadership each month, next-business-day answers on any tool or vendor question, and hands-on help getting one workflow into production each quarter. Either way, the free AI strategy workshop is the place to start, because an hour on your actual workflows tells you which of the three layers is your gap.