Faro

The project is built as a hierarchy: phases, activities within them and milestones (zero-duration control points). Nesting is not limited to one or two levels: the tree unfolds as deep as the project requires. It can be collapsed to whatever level of detail suits —for management, the major phases; for the site foreman, the specific activities—. The budget lines and the resources are built into this same structure, so the project tree is not only the schedule but also the point of connection with cost and supply.

The activity chart is shown in two modes you can switch between, with a scale of days, weeks or months.

Gantt chart — the classic schedule: activity bars, dependencies between them (what depends on what) and milestones. A separate mode turns on the critical path and float: the system highlights the chain of activities that determines the project's delivery date and shows which activities have time to spare and which do not. It is the direct answer to "what will move the finish date if it slips".

Timeline — a monthly or weekly execution grid, handy both for entering progress and for reading it. Colour indicators of activity status are available, and for each activity three lines are shown: the baseline, the current plan and the actual.

Beneath the schedule runs a calculation core that sets the system apart from a simple chart drawer. Deadlines are not set by hand "by eye": they are calculated.

At the heart of it is the relationship between the quantity of work, productivity, number of resources and duration (how much to do, with whom and how fast). For each activity a calculation method is chosen that defines what is the result and what is the input:

• by duration — the system calculates the deadline from the quantity and the assigned resources, taking the bottleneck (the leading resource) into account;
• by number of resources — you set the desired deadline and the system calculates how many people or machines are needed to meet it;
• by productivity — the required output rate is calculated.

Changing the method does not destroy the data: only which quantity becomes the calculated one changes. On top of this, a scenario for distributing resources over time is defined —uniform or with an intensity curve (ramp-up or ramp-down)—. All activities are joined by dependencies, and on any change the schedule is automatically recalculated along the whole chain.

The calculation takes working calendars into account: working and non-working days, plus individual exceptions. Different activities can have their own calendar, and deadlines are calculated in real working days, not calendar days.

So that deviations have something to be measured against, a baseline is fixed: a reference snapshot of the project's deadlines at the moment of start. After that, the schedule and the activity cards show the difference of actual and forecast against the base: how far the start and finish of each activity have shifted. It is the documentary basis for a conversation about the causes of delays and extensions of time.

Actual execution is entered directly in the timeline —by days and periods, in physical units of quantity—. From this progress the system calculates the percentage complete of each activity, and that same figure serves as the single source for all derived indicators: output, deviations, overdue work. The "one figure for everything" principle prevents progress from diverging between the schedule, the reports and the money.

At the top of the dashboard the project status summary is always in view:

• Completed — what percentage of the work has actually been done;
• Planned to date — how much should have been done by the current date;
• Variance — ahead of or behind schedule;
• Overdue — the number of activities whose deadline has passed without finishing;
• Activities — the total number of activities in the project.

The progress indicators are rolled up across the whole hierarchy as a weighted consolidation, so a phase's percentage honestly reflects the contribution of the activities it contains, rather than a plain average.

For any activity a detailed card opens: deadlines in "base / forecast / actual" terms, planned and actual quantity, execution intensity, assigned resources with their staffing curve (planned vs. actual), dependencies on other activities, the responsible person and the working calendar. It is the complete dossier of the activity in a single window.

The project tree adapts to the task at hand: status filters (my activities, in progress, completed, not started, overdue, critical path), hiding certain row types (resources, budget, milestones) and collapsing to whatever level suits. Each participant instantly gets their own view: management sees the overall picture; the site foreman, only their own work front.

Permissions on the dashboard are separated by role. The project planner manages the whole schedule; the engineer edits the activities in their area of responsibility —their branch of the tree and the activities beneath it—; the observer sees the project but does not change it. Every activity and phase has an assigned responsible person, which makes clear who answers for each front and lets each person filter "their" activities.

The schedule does not have to be typed from scratch: activities are imported from the familiar Excel and CSV files, and also from MS Project (keeping the dependencies between activities). The other way round, the current view exports to Excel, CSV or MS Project format, and the whole screen (the table together with the chart) is sent to print or to PDF with the official project title block. The system fits into the company's existing document workflow rather than forcing it to be abandoned.

Each project has a record with the site's details (name, address, client, main contractor, contract number), which is also used in the title blocks of the printed documents. The team composition and their roles on the project are configured separately, and that is what determines who can do what on the dashboard and in the related modules.

The budget is kept as a living document, organised into sections and line items, not as a static table. For each line item it stores the quantity, the unit price and the amount, and that price can be broken down into its components: materials on one side and labour on the other. This makes it possible to see later what the project's cost is made of and to calculate advances specifically for purchasing materials.

Data can be entered by hand or loaded from a familiar Excel file: the system walks you through a step-by-step import and sorts the rows into sections and line items on its own. For fields that are not in the standard form (reference, supplier, notes), you add your own columns, so the budget adapts to the way each company works.

On top of the direct costs sit the pricing layers: overheads, the contractor's margin and VAT. With this, the budget automatically assembles the full price chain: direct costs → contract value excluding VAT → contract value including VAT. That chain is shown right below the table and is included in the export.

The budget has two states: draft and approved. Approval locks in the structure and the amounts: from that point it serves as the basis for the certifications, and any later change goes through a separate, transparent mechanism.

The cost of a project almost always changes during the works, and the key is not to lose the history of those changes. That is what a separate change layer is for.

Each change is formalised as a change order (COR): editing an existing line item, splitting one line item into several, or adding new works. The system keeps the traceability of every line item: you can see where it came from and which change affected it. Once changes are approved, they are consolidated into an addendum and the line item is assigned its number.

Thanks to this, at any moment you can see how much the project cost originally, how much it has grown through changes and which documents back that growth. The contract increase is calculated precisely, from direct costs, which settles the eternal argument about "where the difference came from".

The cumulative valuation gives the overall picture of execution: what has been done and to what extent, on a cumulative basis, broken down by the periods already certified and with the current "open" period shown separately. At the bottom, a comparison of planned vs. actual. In practice it is a single window showing the whole progress of the budget without having to piece it together from scattered certificates.

The certification documents are generated directly from the budget and the actual progress, rather than filled in again from scratch.

The executed-work certificate is built on the working table: you mark what has been executed and to what extent during the period, and the system pulls the amount from the budget.

The payment certificate groups the executed-work certificates signed in the period and adds the financial cascade: materials and labour, retentions, advance recovery, VAT and the final amount payable. It is ready to print in its usual official format.

The documents move from draft to signed; once signed, the certifications become the source of data for all calculations: what has been certified, recovered and retained.

The financial relationship with the client is not only "executed": it is also the movement of money — advances and retentions. The system keeps them as a set of accounts where the plan comes from the budget and the actuals are built from the signed payment certificates and from manual operations (receiving an advance, recovering it, retaining and returning the guarantee amount).

An advance can be planned in a targeted way — for a specific line item, including "for purchasing materials" — with VAT calculated automatically. At any moment you can see how much advance has been received, how much has already been recovered through execution and how much is still to be worked off; the same goes for retentions.

The financial module does not exist apart from the site. For each budget line item you can see the planned and actual progress — pulled from the schedule and from the site reports — and the percentage complete. This is the bridge between the money and the real progress of the works: the budget shows not only "how much it costs" but also "how much has already been done", in the same rows.

Any budget can be exported to Excel, with the official project title block, all the relevant columns (including custom ones) and the final contract price chain. The certifications are ready to print in the established format. The company gets its documents in the usual form without leaving the system.

Work with money is separated by role. The project planner and engineer keep and sign all the budget layers; returning an already-signed document to draft is reserved for the planner alone, as protection against accidental changes to approved amounts. The observer sees the full financial picture but does not change it. This preserves both transparency and control over cost changes.

Resources can be added by hand or brought straight from the budget: the materials and works already budgeted are bulk-loaded into the "Resources" window in a single action. This removes double entry — what has already been valued in money immediately becomes an object of resource planning. Each resource is tied to the schedule activities, and from there the system spreads the need across the days on its own, according to the deadlines and quantities of those activities.

For each material the system keeps a full balance and shows it in one clear picture.

Key indicators — how much material is needed in total (planned need), how much has already arrived at the warehouse, how much has been consumed and how much stock there is now.

Availability traffic light — a visual status: stock is fine, a shortage is coming or a shortage is already here. It lets management see at a glance where the pressure is.

Shortage forecast — the system calculates the date on which the material will run short under the current work plan and flags when the next delivery is needed. Procurement stops being a reaction to a shortage that has already happened and becomes planning ahead.

Balance over time — a chart showing how planned need, actual deliveries and consumption, and warehouse stock move over time. If the balance goes negative, it is highlighted at once.

Need by activity — you can see which activities, and on which dates, "eat up" this material, and how much has already been used.

Supply tracking — each delivery to the warehouse is recorded by date, quantity and document (delivery note). The live stock balance is built from those deliveries and the actual consumption.

People and machinery are a renewable resource: what matters here is not the accumulated total but the level of workload on each specific day — that is, how many people or shifts are needed at once. The module works with crews and trades as well as with units of machinery.

Daily workload — the system calculates how many people or machines are needed each day according to the plan and compares this with the defined capacity (how much of the resource is actually available per day).

Overload control — if on some days the need exceeds the available capacity, it is marked with an "overload" status and the number of overloaded days. Management sees in advance where the plan is physically unfeasible with the available resources and can redistribute the works.

Workload indicators — peak and average workload, the total planned effort (in man-days or machine-shifts), the number of activities the resource is assigned to and its period of engagement.

Workload by activity — you can see which activities, and on which dates, generate that workload.

The resource module turns the work schedule into concrete answers: what to buy and by when, how many people and machines to keep on site, where downtime or an overload will appear. Because everything is calculated from a single plan and linked to the budget, resource, financial and schedule planning speak the same language and do not contradict each other.

Costs — planned and actual costs by period and the cash outflow over time, including cumulatively. Shows how the project is spending against the plan.

Cash flow — receipts and payments by period: advances received, amounts due under the payment certificates, return of retentions against expenditure (payroll and supplies), plus the net for the period and the accumulated net position. It is the direct view of the project's cash and the risk of a liquidity gap.

EVM / earned value — earned value management: planned vs. actual earned value over time. The classic management indicator: "how much work should be done according to the plan and how much is actually done".

Certified ↔ Completed — compares what has actually been executed with what has been certified to the client and with the costs. The gap between these figures reveals over-certification or, conversely, executed work not yet certified — that is, the working capital tied up in the project.

Contract value: price layers — what the contract price is made of: direct costs (materials and labour), overheads, margin, VAT.

Cost structure — the distribution of the budget amount across sections and the most expensive line items. Shows where the bulk of the project's money is concentrated.

Labour movement — average and peak number of people by period, planned vs. actual.

Machinery movement — the same for units of machinery: average and peak need, planned and actual.

Supply schedule — the arrival of materials over time.

Resource workload — the overall picture of the workload of people and machinery across the project, showing the peaks and the troughs.

Deviations from the base — how far actual and forecast have moved from the baseline on deadlines.

Float / critical path — the distribution of activities by their time margin: how many are on the critical path (no float) and how many have margin.

Progress: base vs. forecast — the planned percentage complete per the baseline compared with the current forecast.

Downtime analytics — lost time grouped by cause: how many days the site was idle and why. Because the reason for downtime is mandatory in the site reports, this report rests on real data, not guesswork.

Besides the ready-made templates, there is a custom builder: you choose the data source, the indicators you want, the chart type and the grouping period (by days, weeks or months). This way, for an out-of-the-ordinary management question, a tailored report is assembled without waiting for someone to program it. Any report can be printed.

The analytics is designed for the management level: it is seen by the project participants, except the site staff —for that role the cost indicators are hidden, just as in the resource module—. This keeps the project's sensitive economics in the hands of those it is meant for.

The site foreman opens the list of their work orders for the chosen date: which activities are assigned and to what extent they must be done, with the planned figures and the assigned resources. A work order is not a separate document someone has to issue: it is generated automatically from the project plan for that specific day, from the activities this person is responsible for. Work orders are organised by status —active, under review, completed— so the site foreman can see what is still to be done and what has already gone for approval.

If a job was done on site that was not in the plan for that day, the site foreman can add an unplanned report: the work is not lost just because it was not in the schedule.

For each work order a report is submitted, reflecting the reality of the day:

• outcome — whether work was done or there was downtime;
• quantity for the day — how much was actually done, in physical units;
• actual resources — where relevant, the real number of people and machines and the consumption of materials;
• reason for downtime — mandatory if no work was done, so that lost time is explained, not merely recorded;
• comment — any clarification about the situation on site;
• photo and video from the site — visual proof of what was done, straight from the report, with the upload progress shown.

The report is first saved as a draft and then sent for review. Until it is sent, it can be refined at leisure.

Reports do not enter the project directly: they go through an approval step. The engineer of the relevant phase (or the planner) has a separate "Under review" section with the queue of reports awaiting a decision and a counter of those not yet approved, so you can see how much progress is "on hold".

For each report, the reviewer sees the declared quantity, the resources and the attached photos and videos, and makes a decision: approve or reject. On rejection a reason is mandatory, and the report goes back to the site foreman to correct. Processed reports are kept in the history, filterable by date, leaving a transparent trail of who approved what and when.

This two-step scheme ("submitted — approved") is a built-in reliability control: only verified data reaches the project's model, not everything the person on site happened to enter.

The real value of the module is in what happens after a report is approved. The approved quantity automatically becomes the activity's actual progress, and the resources stated become the actual consumption of materials and the actual workload of people and machinery. From there, everything is reflected in the system at once: the percentage complete of the activities and the project's progress are recalculated, the output and variance indicators on the dashboard are updated, the material balance and the resource workload move, and the actual progress flows into the budget.

A single approved report from the site, and the whole picture of the project —from the schedule to the money— comes into line with reality, without re-entering anything by hand in different places. That is what turns individual site reports into a single, permanently up-to-date information model of the works.

Explain the state of the project in plain words. Instead of reading a dozen indicators, a short, clear summary: how the deadlines are going, where there is a delay and what deserves attention right now.

Check the project for typical problems. A built-in audit finds the weak spots —overdue activities, activities without a responsible person or without a quantity, resources without a price— and returns a prioritised list: where to start.

Answer specific questions. About the project: "How many budgets and line items are there?", "Where are we behind?", "What is the contract value?". About the whole portfolio: "Which project is furthest behind?", "Compare the projects by deadline", "Give me an overview". The assistant consults the data it needs on its own —budget line items, schedule activities, deviations from the baseline, resource workload, analytics indicators— and answers to the point.

Help when loading data. When importing a budget or a schedule from a file, the assistant suggests which column of the file matches which field, speeding up the transfer of data into the system.

The assistant does more than answer: it also warns. For each project an AI digest can be turned on: a short, automatic summary of the important signals —overdue items, delay against the plan, differences from the baseline, high-priority audit findings—. The digest arrives in the notification centre, so management learns of a problem without having to open the project on purpose.

The assistant knows where you are: on a specific project's screen it answers about that project; on the general screen, about the whole portfolio. For each screen it suggests ready-made questions to start with comfortably. And the conversation is continuous: it survives the jumps between screens and projects, so you can hold a connected dialogue with the assistant rather than starting over each time.

The AI in this system is not a "black box". The project's problems are detected by strict rules, and the AI only phrases a clear summary from them, so it does not invent non-existent breaches. It takes the financial figures from the system's trusted calculations and merely quotes them, without recalculating them its own way. The assistant does not see the whole screen or the entire database, but only a carefully prepared extract of the project —exactly what is needed to answer—. Every data query is logged. The result: the convenience of a natural dialogue combined with predictability and control, which is critical when it comes to the money and the deadlines of a construction project.

Communication works the same for three types of conversation, which you can switch between easily:

• Project channel — the project's general chat. Its members match the project team automatically: add someone to the project and they are already in the channel; remove them and they leave. There is no need to set the channel up separately.
• Group chats — created for a task or a subgroup of people, with any members and name you like.
• Private messages — one-to-one conversation; the other person is chosen by searching the staff.

Files are attached to messages —photos, videos and documents, including heavy material from the site—. Images and videos open for viewing inside the conversation itself, without downloading. And that matters on a project: confirm progress, show a problem in situ, pass on a document — all in the same window where the conversation is happening.

In a message you can mention a specific person with "@": as you type, the list of staff is suggested. The person mentioned gets a personal notification, so an important message does not dissolve into the general flow. This way, in a busy channel, you reliably reach the right recipient.

All conversations are gathered in a messages section, ordered by project and with a separate tab for conversations outside the projects. Unread messages are marked with counters —per project and overall— so you can see at once where a reply or a new discussion is waiting for you. The project channel is always first, and the most recent conversations are at the top.

Messaging is not a separate app off to the side but part of a single loop: conversations are tied to the projects, message alerts arrive in the common notification centre along with the other events, and the members are taken from the project team. Communication, tasks, documents and indicators live in one system, and each project's conversations are always to hand for whoever works on it.

The mobile version installs straight from the browser: the icon appears on the phone's home screen and, from then on, the app opens like any other, full screen. It works on Android and iPhone, with no app stores or long installs. Updates arrive instantly, so everyone always has the latest version. The app is built for the real conditions of a site: large buttons for the finger, readability in full sun and a fast launch even on a weak connection —the shell is cached, so the app opens at once and shows the last downloaded data.

The same person can be a site foreman on one project and an engineer on another, and the app takes this into account. You enter a project and the whole app switches to your role in that project, opening the set of screens that matches.

Site foreman — "Today". The day's work orders in large cards: what to do and to what extent. For each one, a report from the phone itself: take a photo or a video with the camera, state the outcome (done or downtime), enter the actual quantity and headcount, close empty work orders, add an unplanned report. This is the main field scenario: progress enters the system from the scene, without going back to the office.

Engineer — "Under review". The queue of reports from the foremen with their photos: approve or reject (with a mandatory reason), plus a brief overview of their area of responsibility —progress, how many reports are waiting, what is overdue—. Progress can be approved on the go, without waiting for a computer.

Planner and management — "Health". The project's key indicators (planned, actual, schedule variance, overdue), the list of activities in progress, the activity cards and a view of the analytics. The quick answer to "how is the project doing", wherever you are.

Observer — "Overview". The same overview, but strictly in read-only mode —handy, among other things, for showing the client the project's progress straight from the phone.

Besides the role-specific scenarios, the app has cross-cutting sections:

• Portfolio — the list of your projects with health indicators and the icon of your role in each.
• Project schedule — an overview of the activities and the progress curve in a light, mobile form.
• Activity card — the essentials of the activity on a single screen.
• Analytics — a view of the project's key charts.
• Chat — the project channel and group and private conversations with photo and video, just like in the main system.
• Notifications — the notification centre, which takes you straight to the right project and screen.

The mobile app deliberately does not drag onto the phone what is awkward on a small screen: the Gantt chart, many-column tables, planning and schedule calculation, the report builder, file import, managing the project team and the calendars. All of that stays on the computer, where it belongs. As a result, the phone handles the field scenarios quickly and without clutter, instead of trying to be "a desktop in your pocket" — and each tool works where it is strongest.