Data Analyst

Answers questions that span more than one system. A spreadsheet is excellent at one dataset that one person maintains. An analyst pulls from several sources at once: your accounting system, your project tool, your CRM and your time tracking. They join those together and produce something that stays current without being rebuilt each month. They also do the part spreadsheets never do well. Checking whether the numbers are actually right. Documenting what each measure means, and saying when the data cannot support the conclusion somebody wants. Where the need is a better workbook rather than a whole reporting layer, an Excel specialist is the less expensive and more appropriate answer. We will say so rather than sell the larger role. A reporting layer built for a problem a spreadsheet already solves is money spent on nothing.

The ones your systems already have the data for, which is more than most firms realize. In a design or construction business that usually means project profitability by type, by client and by team. Utilization and capacity against the pipeline. Estimate accuracy against actual cost, which is the number that quietly decides whether a firm makes money. Where inquiries come from and which sources produce work that closes. Change order frequency by project type. Cash flow patterns and the seasonality nobody has plotted. What an analyst cannot do is answer a question your systems never recorded in the first place. That gap is usually the first finding of any engagement. Fixing it is a process change rather than an analysis one, and that change belongs to your firm rather than to us.

Consistent enough to trust, which is a lower bar than clean. What matters is that the same thing is recorded the same way: one project code, one client name, one way of categorizing a cost. Where that is not true, the first phase of any engagement is finding and reconciling the differences. That is normal rather than a sign of failure. Data does not need to be in one place, since an analyst can pull from several systems. It does need to be exportable, and it does need somebody who can explain what the fields actually mean. Expect the first month to produce uncomfortable findings about your own records. That is the analysis working rather than the analyst complaining, and it is usually the most valuable output of the first month.

SQL first, because almost everything else sits on top of it. Then a visualization layer. Power BI and Tableau are the most common, with Looker Studio for lighter needs. Excel still does real work in most firms. Python or R appear where statistical analysis or forecasting is involved. Beyond the list, the useful question is where the results will live. A dashboard that nobody actually opens is worth precisely nothing. So the output usually belongs where people already work: a weekly email, a report inside your project system, or a screen in the studio. Licenses stay in your name and the data stays in your systems. Tell us which tools you already pay for before anyone proposes buying a new one. Most firms are already licensed for far more than they use.

An analyst, almost certainly, and this is worth being blunt about. An analyst answers questions using the data you already have. A data engineer builds infrastructure to move and store data at a scale most firms never reach. The mistake we see is a business being sold a data platform when what it needed was somebody to answer five questions well. Start with the analyst. Do they consistently spend most of their time extracting and reconciling data rather than analyzing it? That is the honest signal that engineering work would pay for itself. Until then it is simply infrastructure with no return on it. We would rather tell you that than build it and invoice for it. That would be a short-term win for us and a long-term problem for you.