Engineers’ projects
Engineers’ projects is the working backbone of ENGI: an engineer runs their own projects, every step is recorded, and a manager sees the whole picture without collecting it from chats and phone calls. Here is how it works and why it pays off for the company.
In short: what this structure gives you
- You can see who is busy with what right now — one board for the whole department, updated instantly.
- Every project has a history: when it reached each stage and what exactly was done.
- Finished work is never lost — it moves into an archive that cannot be rewritten after the fact.
- Tasks are assigned remotely, with an email notification to the engineer.
- Rights are separated: viewing, running your own work and assigning tasks to others are different roles.
How an engineer runs projects
Every engineer has a personal projects page. A project is described by three fields:
| PROJECT | TASK | % |
|---|---|---|
| Name of the site or job | What exactly is being done | Progress: 5 / 25 / 50 / 75 / 100 |
There can be as many projects as needed — an engineer usually runs several sites at once. A new project starts at 5 %: the work has only just begun.
Progress moves one step at a time
There are five steps: 5 % → 25 % → 50 % → 75 % → 100 %. Skipping is not allowed: from 5 % you can only move to 25 %, from 25 % only to 50 %. And at every step the engineer must write down what exactly has been done.
This is the central rule of the whole system. Without it a report would collapse into a single line, “100 % done”, which tells you nothing. With it, every project keeps a readable chronicle: what was achieved by each step and when.
A project can be renamed only while it is still at 5 %. After that the name is locked: the history of stages is already tied to it, and renaming would make the report about one project while the history is about another. For the same reason only a project that has not started can be deleted; everything beyond that is already a record.
The archive: 100 % and that’s final
Once a project reaches 100 %, the engineer is offered to move it into the archive — with a plain warning that it can no longer be changed or brought back. Everything is preserved in the archive: the description, all stages, all comments.
The archive is deliberately irreversible. If anything could be removed or touched up in it, it would prove nothing — neither to a client, nor when a dispute is being sorted out. An engineer sees their own archive in full, but read-only.
The workload board
The shared board lists all engineers alphabetically, and in each row — their projects: name, task and progress. Next to them two columns: workload (a coloured dot — fully busy, partly busy, free, away) and time of arrival at the office if the person is away.
The board is meant for a shared screen in the office: it refreshes on its own, without reloading the page, and shows the state of the connection — walking up to the monitor, you can tell at once whether it is live or stalled. Five projects fit in a row; tapping an engineer opens a page with all of their projects.
What it gives management
The director
- An answer to “what is the department working on” in ten seconds, not after a day of phone calls.
- You see movement, not just the result. A project stuck at 25 % for a third week stands out immediately — you can step in on time instead of after the fact.
- A ready-made history for talking to the client. When work started, what was done by each stage, when it finished — with dates and authors.
- Planning based on facts. You can see who is overloaded and who has spare capacity — before a deadline slips.
The administration and the chief engineer
- Tasks are assigned remotely — from home, from a business trip, from a phone.
- A comment is attached to a specific stage: the remark appears exactly at the percentage it refers to.
- Email notification — the engineer learns about a new task at once, not at a meeting a week later.
- A summary for every engineer: how many projects they run, average progress, what is already archived.
The engineer
- The work is visible. What has been done is recorded and will not be forgotten at bonus time.
- Fewer interruptions: the status is on the board, so there is no need to ask “how is it going?”.
- Expectations are clear: the task and the remarks are written down, not said in passing.
Assigning tasks remotely
The chief engineer (or another employee with the matching right) opens the task assignment page, picks an engineer from the list — and sees all of their projects together with the full history of stages. From there they can:
- Assign a new task — PROJECT and TASK, plus conditions and deadlines that go into the project history. The task starts at 5 %: from there the engineer raises the progress themselves, describing every stage.
- Comment on a stage — a remark tied to a specific percentage of a specific project.
- Notify by email — a checkbox next to both buttons. The letter reaches the engineer with the project name, the percentage and the text.
The email deliberately does not affect whether the record is saved: the task and the comment are stored in any case, and if the mail fails the sender is told immediately, in a separate message — nothing is lost silently here.
Access rights
Rights come in two layers: a base role plus a set of specific permissions granted on top of it. That way the same person can, for example, run their own projects without gaining access to other people’s settings.
| Role / permission | What they can do |
|---|---|
| Engineer | Runs their own projects, raises the progress with a description of each stage, moves finished work into the archive, sees the board and colleagues’ summaries |
| M9 — task assignment | Assigns tasks to any engineer, comments on stages, notifies by email, edits other people’s board entries, hides engineers from the shared summaries |
| Administrator | Everything above, plus the board layout, granting roles and permissions, user management |
There are two finer visibility settings: a board entry can be hidden (only its author and management see it) or removed from the board entirely — the projects and the whole history stay intact, only the row disappears. An engineer can also be hidden from the shared summaries so that colleagues do not see their work.
Why this beats “the way it used to be”
| Before | Now |
|---|---|
| Status is learned by a phone call or in a chat | Visible on the shared board, refreshed automatically |
| “Almost done” — for three weeks running | Steps with descriptions: you see what was really done |
| The history of the work lives in one person’s memory | The history belongs to the company and outlives the employee |
| Tasks are assigned verbally | The task is written down, the notification has been sent |
| Finished work gets lost | An archive that cannot be rewritten |
The main value is not reporting as such, but the fact that knowledge about the work stops being personal. Someone goes on holiday, falls ill or changes jobs — the project, its stages and the correspondence stay with the company, and anyone can pick them up.
The working order in brief
- An engineer gets an entry on the board and creates their projects (or the chief engineer assigns a task).
- Work goes on — the progress moves one step at a time, and every step is described.
- Management looks at the board and the summaries, comments on a stage or assigns a new task with an email notification when needed.
- The project reaches 100 % — it moves into the archive and stays there for good as a confirmed result.
