Portfolio · Major projects · Engineering · ERP · 02 of 17

An engineering consultancy's ERP, redesigned around the two things it does all day: estimate and review.

ClientMuscat Engineering Consultancy

ProductMEC ERP

Where and whenOman · 2023 to 2025

PlatformWeb app

The screen, annotated by hand · scroll

Estimations by project: status, norms override, approval and FRR columns

every ID opens the estimatethe list is the way in; nothing is more than one click from here
copy, print, Excelestimators take numbers out every day, so export sits at eye level, not in a menu
three statuses, side by sideestimate, norms override and FRR move separately, so each gets its own column

The story, in the order I work

Given · why

What was there

MEC runs multi-discipline engineering projects for oil, gas and infrastructure clients. The redesign covered Estimations (cost-time-resource records per project and discipline, norms overrides, approval and FRR status) and Document Management (drawings and reports moving through squad, inter-discipline and client checks, by revision and cycle). Dense tables, bulk actions, column visibility and exports were designed for people who live in the system eight hours a day.

Planted · what I owned

What I took on

User journey mapping with estimators, discipline leads and document controllers
Information architecture for Estimations, document management (DDM / EDMS) and the client portal
Table system: filters, column visibility, bulk edit, copy, print, Excel export
Approval and review workflows: squad, inter-discipline and client checks, by revision and cycle
Four design revisions (R1 to R4) against user feedback
Led a team of five to six, two or three of them on design, for the length of the engagement

Shipped

What went out

Released through 2025 as a web app.

Estimations · Projects Discipline estimates Norms & approvals Document control (SDC / DQC / IDC) Revisions & cycles Issue instructions Client portal Progress statistics Overtime requests Contracts · companies · contacts Reports

The other screens

CTR estimation detail: activities, hours, deliverables, norms, and the approval workflow by discipline

One estimate: activities, hours, norms, and an approval chain per discipline

Document review at the SDC stage: reviewers, check-in and check-out times, approved and rejected, by revision and cycle

Document review: who checked it, when, approved or rejected, by revision and cycle

Issue instruction: the squad check chain before a package goes to the client

Project progress statistics across nine disciplines, with S-curve and resource histogram

Progress across nine disciplines, with S-curve and resource histogram

Bulk edit of document entries with mixed values across the selection

Bulk edit: what happens when forty documents share one field and differ on another

Journey map of the document management system from discovery

Where it started: the document system mapped with the people who run it

2Fewer clicks per intent, on average, after the redesign

5Modules: estimations, documents, client portal, overtime, contracts

4Design rounds with the people who use it, R1 to R4

What I'd do differently

The honest paragraph.

The requirements came in waves, not all at once. We agreed a scope, another wave arrived, and the agreed scope moved with it. Four design rounds is the visible cost of that. What I would do differently is hold the line harder: agree what is in this round, write it down, and make the next wave a new round with its own date, instead of letting it dissolve into the current one.

Scope agreed is not scope held. Write it down, and give the next wave its own date.

field note