Home · AI
AI in project management
Many people talk about “AI in project management”. I prefer to show it: where it genuinely helps, a real case, a sample output, the method I work with, and the places I deliberately stay away from.
Capability
The value of this capability does not come from the tool. The tool is available to everyone. What is rare is knowing, on an oil and gas EPC project, which question is worth asking, what the right output looks like, and which part of the schedule a wrong answer burns. That judgement comes from twenty years in the field, not from the tool.
Why this combination is rare
Most people who know AI well have never defended a real critical path in front of a client; and most people who know EPC projects have never tried these tools in daily work. My work sits on that overlap: I place the tool at a specific point in the project’s reporting and decision cycle, with a defined output and one person accountable for each output.
Each has a defined input and a defined output. None is a “general analysis”.
Comparing a schedule update with the baseline and extracting the activities that actually drove the critical path change — not a long list of lagging activities.
OutputA short list of delay drivers, with estimated effect on the completion date and the responsible discipline.
Processing weekly meeting outputs and contractor correspondence with a fixed template, so a risk enters the register before it reaches the critical path.
OutputProposed risk register entries — event, likely impact, responsible discipline — for the planner’s approval.
Turning progress data, S-curves and SPI and CPI into a status narrative written the same way every week and comparable over time.
OutputDraft weekly and monthly reports in consistent language with figures traceable to source.
Building a chain of evidence from masses of correspondence: event, date, relevant contract clause and claimed schedule impact.
OutputA chronologically ordered evidence table as input for the claims specialist — not as the claim itself.
Checking inconsistencies between P&IDs, datasheets, line lists and specifications before a document reaches IFC and change gets expensive.
OutputA list of candidate inconsistencies for the discipline engineer to judge.
Tracking vendor document status and delivery schedules of critical items against installation need, with early warning on items losing their float.
OutputA warning list of critical items, ordered by distance to need date.
Writing standard prompt templates and usage guidelines so output is repeatable across the team and not dependent on individual taste.
OutputA ready template pack, with a short introductory and practice workshop.
A real case
An engineering services contract had reached the end of its term, a significant part of the work was still open, and the two parties disagreed about who was responsible for the delay. The file held the contract and its general conditions plus dozens of letters, minutes and attachments — several hundred pages nobody had time to read in full. A decision had to be made and there was no basis for making it.
Normally one or two people read the file piece by piece and each understands part of the story. The problem is not carelessness; the key events are spread across months and hundreds of pages, and putting them side by side is beyond anyone’s memory. What gets lost is rarely a document — it is the relationship between two documents.
A decision memo for management and a draft letter to the client with specific requests, each item referenced to a clause of the same contract. Work that would have taken weeks of reading and cross-referencing produced something decidable within days.
The boundary that didn’t move
No document from this file went into a public AI service. The analysis output was a recommendation, not a decision: every item was read and approved before it went anywhere, and responsibility stayed with its signatory. The tool raised the speed of seeing; it did not move the responsibility for the decision.
Before and after AI
The difference is not how fast a report is typed; it is the gap between an event and its arrival on the decision-maker’s desk.
Typical process
Warnings usually surface in the monthly meeting — weeks after the first signal.
AI-assisted
The tool surfaces the signal sooner; a specialist approves it and the manager decides.
Sample output
Demonstration with fictional data. No figure or name in this section comes from a real project.
| Risk | Signal in the data | Likely impact | Trend |
|---|---|---|---|
| Late delivery of gas compressors | Vendor documents returned twice; shipping date moved in week-32 minutes | About six weeks on installation and pre-commissioning | Rising |
| Shortage of qualified welders | Inch-dia productivity below plan three weeks running | Unit 2 piping front falling behind | Rising |
| P&ID change after IFC | Four open change requests on one system | Rework in instrumentation procurement | New |
| Slow work permits in live area | Average permit time up from one day to three | Tie-in fronts slowing down | Rising |
| Gap between reported and measured progress | Six-percent difference between contractor report and installed quantities | Decisions based on an optimistic picture | Stable |
| Action | Proposed owner | Due |
|---|---|---|
| Expediting meeting with the compressor vendor and fix the shipping date | Procurement manager | Week 34 |
| Re-sequence Unit 2 piping and add one spread | Construction manager | Week 35 |
| Hold procurement of affected items until the P&ID change closes | Engineering manager | Week 33 |
| Review the progress measurement method with the contractor | Project controls | Week 34 |
The boundary that doesn’t move
Tool output is a recommendation, not a decision: every item is traced back to its source in the data and approved by the planner before it reaches the management meeting. Real project data is processed only inside the client’s approved environment or in anonymised form.
From the problem, not the tool
Every engagement follows these five steps; we start from the problem, not the tool.
A boundary that doesn’t move
The tool raises the speed of seeing; it doesn’t move the responsibility for the decision.
No document, drawing, schedule or project data goes into a public AI service.
Five written commitments
A promise of “I won’t publish it” is not enough. In most oil and gas contracts, simply putting data into an external service is a breach of confidentiality, even if it is never published. That is why I have written these five commitments down.
Why this clause sells, not just protects
When an oil and gas client hears that someone uses AI, the first reaction is concern. A manager who says “your data does not go into any external service” before being asked turns that concern into trust. This clause is the one place where confidentiality becomes a competitive advantage.
Clear boundaries
This list is as much a part of my work as the one above. A boundary not stated at the start is broken sooner or later.
AI credentials
Four certificates: three course certificates from the Project Management Institute (PMI) — the issuer of the PMP — and one “AI Consultant” certificate from CPD, Canada. The exact status of each is shown beside it.
The sentence this page closes with
AI does not replace the project manager; the project manager who uses it sees risk sooner. All the value of this line of work is in that word: “sooner”.
Ready text
In this engagement, no project document or data is entered into a public AI service. These tools are used only on anonymised data or within the client’s approved environment, and responsibility for every output rests with the project team before it enters official documents.
One 60-minute diagnostic session is enough to find the right first cycle together.
Usually replies in a few seconds
Replies are written by AI, so your message is sent to that service; please don’t send confidential project documents or data.
