How a project knowledge graph helped our team work smarter with AI — and what it cost us to build

Every project I've run has produced an enormous amount of paper — requirements, specs, meeting notes, decisions, risk logs, lessons learned. And every time, once the project closed, most of it quietly disappeared. Not because anyone deleted it. It just became unreachable — buried in a folder nobody opens again, or in an email thread from three reorganizations ago.

We got very good, as a profession, at producing documentation. We got much worse at preserving knowledge. On the TIMI programme — a multi-year AI initiative I led between 2021 and 2024 — that gap became impossible to ignore, and it pushed us to try something different: instead of managing documents, we started managing a knowledge graph.

The Problem We Actually Had

By the second year of TIMI, the project had accumulated the usual pile: business requirements, functional specs, technical architecture, user stories, meeting notes, decision records, training material, and a growing amount of AI-generated content on top. Each piece, on its own, was easy enough to find. Finding any single document took seconds.

What took days was understanding how they connected. A requirement tied back to a handful of user stories. A user story depended on architecture components three different teams had touched. A lesson learned in an earlier phase was quietly relevant to a decision someone was about to make again — and had no way of knowing it. The relationships mattered more than the documents did, and no folder structure was ever going to capture that.

Documents Store Information. Graphs Store Relationships.

That distinction ended up shaping everything that followed. A document answers "what information exists." A graph answers "how does everything connect." Once we started modeling requirements, risks, decisions, and stakeholders as entities with explicit relationships between them — instead of files in a folder hierarchy — the project stopped looking like a pile of documents and started looking like a network we could actually query.

Where AI Made the Difference

Building that graph by hand would have taken more effort than any of us had time for. This is where large language models earned their place — not as a chatbot bolted onto the project, but as the mechanism that extracted entities, classified artefacts, suggested relationships we hadn't thought to draw, and generated the metadata that made the graph searchable in plain language.

The shift that mattered wasn't "we now have an AI assistant." It was that people stopped searching for keywords and started asking real questions: which decisions influenced this requirement, what risks connect to this deliverable, which lessons from an earlier phase apply here. The model was reasoning over connected knowledge instead of guessing at isolated documents, and the answers were noticeably better for it.

What This Looked Like in Practice

Eighteen months into the programme, a new architect joined the team and needed to understand why we'd rejected a particular integration pattern the year before — a call three people who'd since left the programme had made together. Under the old setup, that would have meant a couple of days of asking around, hoping someone remembered, and probably not getting the full reasoning even then.

With the graph in place, she traced the decision, the risk it addressed, and the two alternatives we'd ruled out, in about ten minutes. Nobody had to remember anything. The reasoning was still attached to the decision, exactly where it had happened.

Four Things We Learned

1. Documentation isn't knowledge. Writing more documents doesn't make an organization smarter — the relationships between them usually matter more than any single one.
2. AI gets noticeably better when knowledge is structured. The same model gave visibly weaker answers over a folder of PDFs than it did over the connected graph.
3. A knowledge graph is never "done." Ours kept growing for the life of the programme, and it got more useful — not more cluttered — the longer it ran.
4. Project closure is usually where organizational intelligence leaks out. Lessons learned shouldn't be the last slide of a closeout deck. They should be the first thing the next programme finds.

Practical Advice for PMOs

You don't need a multi-agent AI platform to start this. A more realistic first step is asking harder questions about how your existing project knowledge is organized:

• Are your decisions connected to the business context that produced them, or just filed under a date?
• Could a new team member find out why a call was made, not just that it was made?
• Do your lessons learned actually get reused, or do they sit in a closeout deck nobody reopens?
• Can your AI tools explain a decision's reasoning, or only retrieve the document that happens to mention it?

Most PMOs will find the honest answer to at least one of these uncomfortable. That discomfort is usually the real opportunity.

Key Takeaways You Can Apply This Month

• Pick one closed project and map its five biggest decisions to the requirement or risk each one addressed — a spreadsheet is fine, before you touch any graph technology.
• Next time someone asks "why did we do it this way," write the answer down next to the decision itself, not in a separate retro nobody will reread.
• Before your next kickoff, check whether a comparable past decision already exists in a form the new team can find in under fifteen minutes. If the honest answer is no, that's the first gap to close.
• If you're piloting AI in your PMO, test it against connected information before you test it against a folder of PDFs — the difference in answer quality is the whole argument for doing this work.

Conclusion

None of this made project management easier, exactly. What it did was make the organization a little less forgetful. The graph didn't replace anyone's judgment — it just meant the next person facing a similar call didn't have to start from nothing.

That's really the whole case for doing this. Not smarter AI. A PMO that remembers what it already figured out.

 

---

About the Author

Csaba Csepeli is the founder of Paradigm Digital Kft. and an independent PMO and digital transformation program director with more than 20 years of hands-on program leadership across telecom, banking, insurance, pharma, and media. He led the TIMI programme (2021–2024), the Neo4j-based knowledge graph initiative described in this article, and now leads NEOMI, a multi-agent AI orchestration platform for transformation programs. He is PMI-certified (PMP) and recently spoke on this topic at the PMI Budapest Lunch & Learn.