ProjectLens

Project change assurance

Find where a project's written update disagrees with its schedule, then turn the differences into questions for a reviewer.

Runs in your browser. No account; sample schedules included.

Before using this

Evidence review does not establish contractual entitlement, causation or a probability of failure. The board keeps decision authority.

The public example uses synthetic schedules. Its precedent cards are a static fallback; live retrieval requires local setup.

ProjectLens readiness result with three blockers from the synthetic Northstar example

Public Northstar sample: three issues to resolve before a decision.

My contribution Product and AI engineer
Status Live public demo
Focus Project controls and RAG

Why I built it

A change pack can tell a different story from the Primavera schedule it cites. ProjectLens puts the conflicts beside their source dates before the board decides. The public demo uses static context. Newer local retrieval lets a reviewer inspect cited programme status records; these are not records of past decisions or their causes.

What I chose

I compare the schedule evidence before asking AI for help. Every finding keeps its source dates, and a reviewer must decide whether a suggested precedent is relevant. A plausible narrative is not treated as a project decision.

What the example shows

The synthetic Northstar example produces three blockers, including a finish date moving by 73 days without being acknowledged. The reviewer can inspect the dates, prepare follow-up questions and export a decision record.

What I learned

The useful output is a question someone can investigate, not a score that pretends to predict project failure. Separating schedule facts from interpretation makes the review easier to challenge.