Project Management in the Fog

I often compare project management to walking through fog.

We know where we want to go. We have a plan, a team and a certain understanding of the path ahead. But we cannot see everything.

Knowledge, experience and technical expertise extend our visibility. An experienced colleague notices a warning sign that others overlook. A technical expert recognises a dependency before it becomes a constraint. A team that has faced a similar situation knows which questions to ask.

The more capable the team, the further we can see. But we are still in the fog.

This is where risk management becomes essential. If we recognise a potential obstacle early enough, we can change our route, prepare a response or reduce the chance of falling into it.

For Building NEXA, this raises a question:

Could an AI project team member help us see further—and take more effective action on what we see?

Extending the team's field of view

We typically identify risks through discussions, workshops and expert assessments. We describe what might happen, estimate its probability and impact, and define responses.

The quality of that assessment depends heavily on the people in the room: their knowledge, experience, perspectives and understanding of the project.

Even a strong team has gaps. Relevant experience may sit with someone outside the project. An earlier failure may be documented somewhere nobody thinks to search. A discussion may contain a warning that never reaches the risk register.

NEXA could help connect these pieces. With access to relevant project information, could it recognise a potential risk in a supplier update, a technical discussion or a change in the plan? Could it connect that observation with experience from previous projects and bring it to the team for assessment?

Yesterday's lesson becomes tomorrow's question

This follows directly from our previous use case, The Living Project Diary.

Consider an illustrative situation in Project Orion. The team is preparing to order a component needed for validation. In an earlier project, a similar order was delayed because responsibility for technical approval was unclear.

NEXA could connect that lesson with the current activity and ask:

Have we confirmed who owns technical approval, and when it must be completed to protect the validation date?

That does not mean the previous problem will repeat. The supplier, design and approval process may have changed. The earlier experience gives the team a reason to check.

For this to be useful, NEXA would need current, project-specific information: requirements, plans, dependencies, technical findings, supplier commitments and decisions. Historical lessons would need to explain what happened, under which conditions, what action was taken and whether it worked.

The recommendation should make that connection visible. Why might this lesson apply here? What is different? What information is still missing?

A documented risk can still leave us exposed

Sometimes, documenting a risk creates a sense of reassurance. We have named it, estimated its probability, assessed its impact and assigned a colour.

The assessment is complete. We feel more comfortable.

But what have we actually changed?

What are we doing to reduce the exposure? Is the response sufficient? Will it happen early enough? How will we know whether it worked?

Imagine Orion records the possibility of a late component delivery. The response says: “Follow up with the supplier weekly.”

That may improve visibility. By itself, it may do little to prevent the delay.

NEXA could ask whether the action addresses the cause of the risk or simply monitors the situation. It could check whether there is an owner, a deadline and a defined result, and surface dependencies that might prevent the action from working.

Depending on the evidence, it could suggest options for expert review: clarify approval ownership, confirm capacity earlier, assess an alternative component or prepare a fallback validation sequence.

Each option has consequences. An alternative component may require additional testing. Reserving capacity may increase cost. Changing the validation sequence may introduce other dependencies. The team needs to assess those trade-offs.

A proposed review framework. These questions support team judgment; they do not calculate mitigation effectiveness.

Is the mitigation likely to work?

Could NEXA also help estimate whether a mitigation measure will be effective?

Similar past cases, test evidence and explicit assumptions may support an estimate. Without that grounding, a confident statement such as “this action will reduce the risk by 60%” would create false precision.

A more useful contribution might be:

This action addresses the approval delay, but the supplier's capacity constraint remains unresolved.

Or:

The fallback depends on qualification being completed before the component is needed. That timing has not yet been confirmed.

These observations help the team judge what exposure remains after the proposed response.

The assessment should continue as the project moves forward. Completing an action does not automatically prove that it reduced the risk.

If the action was to confirm supplier capacity, what did the confirmation establish? If the action was a technical test, did the result support the assumption? If a response is overdue, does the team still have time to act?

With updated evidence, NEXA could help the team revisit the assessment, flag an approaching trigger and identify when an uncertain event has become an actual issue requiring resolution.

Turning a discussion into a usable assessment

Teams do not naturally speak in perfectly structured risk statements. A discussion may mix a current problem, a possible future event, its cause and several potential consequences.

“The specification is still changing.”

“The supplier cannot commit yet.”

“We could miss the validation window.”

“We should check an alternative.”

NEXA could organise that conversation into a candidate assessment:

• Current condition: The component specification remains open.
• Potential event: The order may be released too late.
• Possible consequence: The component may miss the validation window.
• Suggested response: Confirm specification ownership and timing, and assess a feasible fallback.
• Open questions: What is the latest safe order date? What evidence supports the likelihood estimate? Who owns the response?

The team would review the interpretation before it becomes an accepted project record. Missing information should remain visible, and NEXA's suggestions should be distinguishable from actions the team has agreed.

This could reduce the effort spent translating discussions into documentation and leave more time for analysis, problem solving and action.

A proposed workflow: NEXA prepares and supports follow-up; the team validates, agrees and acts. New evidence informs the next assessment.

Applying the same approach to opportunities

The same approach can support opportunity management. By connecting current project information with lessons from earlier projects, NEXA could help identify opportunities to shorten lead times, reduce costs or improve quality. It could suggest actions to realise those benefits, highlight the conditions and trade-offs involved, and help the team track whether the expected value is being achieved. As with risks, identifying an opportunity is only the starting point; it needs an owner, timely action and evidence of results.

What would make this valuable?

We would need to test its value in practice. Did NEXA surface a relevant concern early enough to act? Did its questions improve a weak response? Did the team realise an opportunity it might otherwise have missed? How much review effort did its suggestions require?

Project management will always involve uncertainty. Experience helps us move through it, and AI may help us make better use of the experience available to us.

For NEXA, the ambition is to help the team see further into the fog—and make better-informed choices about the next step.

When you review your project's risk register, which is clearer: the risks you have identified, or the evidence that your responses are working?

Building NEXA explores the role of an AI project team member. Project Orion is an illustrative scenario; the capabilities and benefits described here are hypotheses to develop and validate.