Practice ·
The field-experience tax
Why digital-transformation programmes inside EPC and operator organisations keep producing tools the project teams will not use — and what changes when current scars are in the room.
A digital-transformation programme inside a major EPC firm or operator typically follows a pattern. A working group is assembled. Project teams are interviewed. The current state is mapped. The future state is wireframed. A platform is procured. A small army of analysts is hired to populate it. Eighteen months later the project teams are running their actual work in Excel, and the platform has become a reporting destination, not a working tool.
I have watched this pattern play out across multiple operators. Different industries, different geographies, same shape every time. The pattern is the problem — not the tools, not the people, not the platforms.
The reason is upstream of all of that. The people leading the transformation, often, have not run a project in years. Not because they cannot. Because their working week has moved into governance, oversight, and stakeholder management — exactly where senior people are supposed to be. But it means their model of what a project manager does is necessarily a stylised one — built from interviews and current-state workshops, not from the morning of a deliverable freeze when three things are on fire and one of them is the client.
The tools they specify are tools that solve the abstract version of the problem. The abstract version is not the version that needs solving.
The friction shows up in tiny places. The tool requires the PM to log in. The tool requires the PM to navigate three screens. The tool requires the PM to type a fourteen-character project code. The tool requires a discipline classification before it will accept a deliverable. Each of these is harmless on its own. Aggregated across a working day where the PM is solving twelve problems at once, each of them is the reason the PM goes back to WhatsApp and Excel. WhatsApp and Excel cost zero seconds to learn and produce a result the PM can act on immediately. The platform costs ninety seconds per interaction, four hundred logins a year, and produces a number the PM is going to override anyway.
The pattern is not about consultancies, vendors, or any organisation in particular — it is about distance. Distance between the people specifying the tool and the people whose week the tool is supposed to fit into. The further that distance, the more the tool drifts toward the abstract version. The closer that distance, the more it survives contact with a real project.
The fix is structural. Put project people, with current scars, in the room when the transformation is being designed. Not as interviewees. As decision-makers.
What that looks like in practice:
The transformation lead has run a programme in the last twenty-four months. Not “supported.” Not “advised.” Run. They remember what the morning of a deliverable freeze feels like. They have, personally, copied a number from one spreadsheet to another at one in the morning because the system would not.
The tooling decisions are made against the ninety-second test. Will a working PM, mid-week, mid-deliverable, use this tool? If the answer is “if we mandate it” the answer is no. The mandate fails. The shadow Excel wins.
The vendor relationship is constrained. A vendor selling the abstract version of the problem will deliver the abstract version of the problem. Specifications written by people closer to the work narrow the abstract version into the actual one — every time.
Consultancies, EPC firms, operators, vendors — they are all capable of doing this well. The ones that do all share one feature: someone with current programme scars is shaping the tool. The ones that fail all share the inverse: the work is being shaped at distance.
I am writing this as someone who has been in the room when the workshop was run, and who has been in the morning when the deliverable was freezing and the platform was not the answer. The gap between those two rooms is the field-experience tax. The transformations that close that gap succeed. The transformations that ignore it pay the tax — in budget, in calendar, and ultimately in the project teams who go right on running their work in WhatsApp and Excel.
Closing the gap is not a software problem. It is a staffing problem. The people from the morning room belong in the design room. That is the whole argument.