The project manager who compressed the work, not the thinking
The wrong way to use AI is to outsource the judgement. The right way is to compress the work that prevents judgement from happening, which on most projects is most of the week.
What were the answers to the previous five questions?
1. What is the difference between using AI to make a decision and using it to compress the work that precedes a decision?
Making the decision means the output is acted on. Compressing the work means the professional receives structured, sourced evidence and then decides. The first changes who is accountable. The second changes only how long it took to be ready to decide.
2. A revised programme lands. What should you ask for, and what should you not ask for?
Ask for a structured comparison of the two programmes, naming both and stating the data date and contractual status of each. Activities added and removed; changes to original duration, remaining duration and percent complete; logic changes including relationship type and every lag; calendar and constraint changes; and the scheduling settings, specifically retained logic against progress override, because that one setting can move planned completion by weeks without a single duration changing. Then movement in total float and free float, and the difference between the longest path and the total float critical set, which in P6 are not the same thing. Do not ask whether the project is delayed or what to do about it. The first is retrieval, the second is judgement.
3. Why does a specific, constrained request produce better evidence than an open question?
Because scope is what makes an answer checkable. "Is this a variation" invites a plausible narrative. "Does this scenario meet the definition in clause 4.2.1, and show the clause" produces something with a reference you can open.
4. What is the risk of a structured, authoritative looking output, and what habit counters it?
Automation bias: the more organised the output looks, the less it gets questioned. The counter is routine spot checking. If it says a clause requires something, open the clause. Not every time, but often enough that the habit does not decay.
5. Which decisions in a project manager's week should be explicitly marked as human only?
Giving an instruction. Certifying or notifying a payment. Accepting a programme, or notifying reasons for not accepting it. Notifying, or deciding not to notify, a change event. Certifying completion. Write the list in the vocabulary of the contract you are actually on, because a list written in the wrong regime's words is the first sign nobody has read the conditions, and write it down before somebody needs it.
What is actually in the morning?
A revised programme from the contractor. An email thread from the designer about an ambiguous specification. Yesterday's site meeting minutes, taken by someone without the project context. Three messages from the site manager about progress. A query from the QS about a possible variation. An instruction draft that may or may not be justified. A delay notification. A payment application with supporting documents. A compliance query from the client.
The output required from all of that is a short list of decisions: what the programme movement means for the critical path, whether the instruction is compliant and within authority, what the delay notification does to the forecast, what to approve. None of that can be automated and none of it should be.
What can move is everything that has to happen before any of it can be thought about. That is the distinction the whole module turns on.
What does a good request look like?
The same five part structure every time, which is worth teaching once rather than distributing a library of prompts nobody will type.
| Element | What it does | Example on the revised programme |
|---|---|---|
| Source | Names the controlled documents, so the answer is retrieval rather than general knowledge | The accepted programme and this revision, both attached, with the data date and contractual status of each |
| Task | One operation, stated narrowly | Identify every change to activities, durations, logic, calendars, constraints and scheduling settings between these two data dates |
| Constraint | Sets a stated filter rather than a subjective one | Report every activity with total float at or below a stated threshold, every activity on the longest path, and every activity gated by a possession, consent, seasonal window or Key Date whatever its float. State the threshold used |
| Output shape | Makes the answer checkable | Activity name and ID, what changed, new status, sheet reference |
| Evidence rule | Forces the distinction between fact and inference | Cite the source for each item. Where you are inferring, say so |
What comes back is a list with references rather than a narrative. The follow up is then the question that actually matters, and it is a question only the PM can frame: does this change affect the payment application date or the handover milestone, and show me the logic.
The same structure applies to the specification thread. Retrieve the specification and the correspondence, ask what each email states or modifies with dates, ask what the most recent definitive position is, and ask what contradictions exist. The output is not the answer. The output is a precise question to put to the designer: your email on Tuesday said mild steel would be acceptable if stainless was delayed, and the specification requires stainless. Before precedence, confirm why stainless was specified, whether that is design life, exposure, or bimetallic action with adjacent components, and whether carbon steel meets it here. If it does not, this is a rejection rather than a clarification. If it does, an email does not change the scope: that needs an instruction, and an instruction is a change event.
Where does this go wrong?
In four places, and they are worth naming to the team before they happen rather than after.
- Confinement is not immunity. Retrieval from a controlled source lowers fabrication risk substantially. It does not eliminate it. The clause the system identified still has to be opened occasionally.
- Missing context. The system will not know that a specification clause was overtaken by an email the site team treats as controlling. Only someone who knows the project spots that gap.
- Automation bias. Structured output invites acceptance. This is the failure mode most likely to affect a good project manager, precisely because the output is usually right.
- Scope creep. A tool that compares programmes well invites "just approve this payment". Different question, different verification, different authority. The human only list exists for this moment.
- Documentary answers to technical questions. Which document takes precedence is the easy half and the half a retrieval system is good at. Whether a substitution is acceptable at all is an engineering judgement about design life, exposure and compatibility, and no hierarchy of documents answers it. A system that reconciles a conflict has often concealed the question.
What does the junior get out of it?
Potentially a great deal, and potentially nothing, depending entirely on how the firm sets it up.
The failure case is the one from part three: a graduate who receives answers so quickly they never work through the reasoning, and who five years later cannot challenge the system they depend on. The better case uses the same tool as a challenger rather than an oracle. Ask it not to answer yet, but to list the questions worth considering first. Ask it to identify weaknesses in your interpretation. Ask for three plausible readings and what information would distinguish between them.
That is closer to having a patient senior colleague available at nine on a Tuesday than to having the work done for you, and it is the one use that genuinely accelerates professional development rather than deferring it. More on the training design in training sceptical construction teams and on the tooling in three AI solutions every contractor needs.
Project management is mostly sequential: something happens, you respond. part 9, design management is a dependency problem, not a document problem takes on the discipline where everything happens at once and the expensive failures are the connections nobody spotted.
What five questions should you be able to answer now?
Attempt these before tomorrow. Each has a defensible answer, and each is answered at the top of the next part.
- Why is design management a harder problem for AI than project management?
- What is the difference between a clash and a dependency, and which is more dangerous?
- A client moves a wall by one metre. What are the second order effects, and why do they matter more than the first?
- What information does a system need before it can say anything useful about buildability?
- What can AI not tell you about Building Regulations compliance, however good the retrieval is?
Which sources is this part built on?
Every figure quoted above resolves to one of these. Each was checked before publication.