Why I Developed Intelligence Engineering Methodology

Over the past 20 years of managing technology projects, I have been motivated to look at data from the angle of where the gap is appearing, and due to advancements in AI — and with the support AI provides — a new methodology was formed.

Personally, in my 20+ year career as a project manager managing IT projects for various organizations — pharma, retail, energy, and financial sectors — when I looked into the reports or presented them to the executive committee, I genuinely felt the gaps whenever critical questions arose from the executives or teams, and I sometimes struggled to answer because there was no data. To put it simply, that is where — now, after 20+ years, with the advancement of AI, where the human brain cannot compare such a huge volume of data — this methodology evolved: why not compare the data with the standard it is supposed to follow, so it fulfills the purpose it is meant to serve? The scale of comparison and evidence analysis this methodology needed would not have been practical for me without AI-assisted reasoning.

The main reason I built this methodology was to test it on my own PMO practice — the process I built from the ground up, and the projects I actually manage, mostly physical security and cyber security, where I fall into these same data gaps myself. It is like testing your own dog food: test it within your own work first, and only then does it genuinely benefit the wider project management community.

I have watched projects, programs, and portfolios all produce data — status reports, RAID logs, schedules, financials — that leadership relies on to make strategic decisions. And what if that data is siloed with gaps? I have seen the decision made on data that has gaps fail to produce the strategic outcome it was meant to, and it hits organizational growth every time.

In my experience, this data gets diluted by these gaps — the 7 gaps I named earlier — and eventually passes on wrong or misaligned information. What I have learned is that these are not purely human errors, system errors, or data-entry errors. They are data gaps that occur when data moves from its point of origin to its destination.

What happens when a decision is made on data that has gaps? I believe the outcome of these decisions does not bring the value it is intended to bring, and that can sometimes become catastrophic. Many technology projects support decisions, services, infrastructure, and systems that organizations and people depend on — and every one of them relies on and trusts the data that is transitioned, transferred, or followed during the data life cycle. This matters most in the industries that touch the day-to-day life of humans, where a concrete decision needs to be made that will resolve a human life-or-death situation.

Here is the mechanism I keep coming back to: all data that is produced is measured against some standard it follows — or, by default, there should be a standard it has to follow. When there is a deviation from that standard, that is when the gap arises, and a decision made based on data with those gaps can become very catastrophic.

Upon analyzing and doing some study through the internet and reading articles on the data lifecycle, I found that the gaps appear as these 7 gaps — and that is the foundational construct of this methodology, where I named it the 7-Gap Taxonomy, and the whole methodology evolves around those 7 gaps. It covers and sits across the entire data lifecycle, from origination to the end of that particular data.

Then these are traced to what I call the root, or origin — where these gaps, or the data, originated. I would say I limited it to 7 origins that were predominantly appearing; there could be more, and that is a question I will dwell on further. But the methodology was framed across the gaps and the origins, with the Gap Taxonomy as the foundational construct.

And that is where the discipline evolves: the systematic practice of measuring delivery data gaps across project, program, portfolio, and PMO systems, tracing discrepancies to their root origins, and engineering corrections at the source.

This methodology can be applied to any industry that produces data. I started by looking at applying it to project management, as that is where my expertise lies.

The architecture is very simple, and to be honest, it did not come from nowhere. I had seen Praxen (open-agent-ai-security.github.io/praxen) use a similar split — judgment on one side, deterministic validation on the other — for a completely different problem, AI agent behavior verification, and it worked. Seeing it work there is what sparked the question for me: why couldn't the same kind of split work for a genuine methodology validation tool, one built for project and PMO delivery data instead of AI agent behavior? IEM-PM is my own answer to that question, not a copy of Praxen's architecture.

The LLM never touches the score, and the code never touches the judgment — that boundary is the whole point. One side varies with reasoning, the other side is the same output every time from the same input, and the Manifest in the middle is what makes both halves honest.

How this differs from Praxen

The underlying idea rhymes, and I do not hide from that — Praxen's LLM judges, then hands off to deterministic code that only validates and renders, never judges. That split is what gave me the idea, not something I copied wholesale. Praxen verifies whether an AI agent's behavior matches its own declared policy; I verify whether project and PMO delivery data matches a declared PM standard like PMI, PRINCE2, or ISO 21502 — a different problem, with my own taxonomy, my own Charter, and no maturity scoring at all.

IEM-PM is:

• An evidence-based methodology assurance discipline
• Standards-relative — every finding is measured against a declared baseline (PMI, PRINCE2, ISO 21502, or an organization's own)
• Gap-oriented and root-cause-oriented, built on the 7-Gap Taxonomy and 7 Root Origins
• AI-assisted judgment, paired with deterministic validation and scoring
• Built for project, program, portfolio, and PMO environments

IEM-PM is not:

• A project management methodology
• A maturity model
• A replacement for PMI, PRINCE2, or ISO
• A project-management tool
• An AI project manager
• A generic data-quality framework
• A compliance certification

How I Built This

I did not start by writing code. I started by defining the discipline itself — locking down what Project Gap Intelligence Engineering actually meant, agreeing the closed taxonomy, and getting a full blueprint approved before a single script existed. That discipline came first, on purpose. I did not want the tool to define the method; I wanted the method to define the tool.

One of the earliest real decisions I made was to scrap organizational maturity modeling entirely — not defer it, scrap it. I had originally planned to bridge every gap into something like PMI's OPM3, a maturity score. I looked at it honestly and realized maturity modeling is a different, harder question — it needs cross-project calibration and a licensed instrument, neither of which I had or wanted to fake. So I cut it, and IEM-PM has never modeled maturity since. It measures and traces gaps, and that is all it claims to do.

Once the Five Contracts and the 11-stage engine were written — the Charter template, the findings schema, the validator, the manifest parser, the renderer — I did not keep testing it in theory. I ran it for real, against 29 real PMI standards, and that is where the actual challenges started. Almost every real defect I found only showed up once I stopped inspecting the design and started running it against real evidence.

The first real bug was embarrassing in hindsight: the engine was silently caching an empty result as if it were valid, so 27 of my 29 real standards were frozen at zero extracted content from one earlier failed read, and it never tried again. I only found that by going back and asking why so little had actually been derived. Not long after, a dependency the engine actually needed — openpyxl, to read real client Excel files — had never made it into requirements.txt at all. That one only surfaced when I was asked directly, "did you make any code changes?" Neither of those is the kind of bug you catch by reading code. You catch them by running the thing for real and refusing to trust that it worked just because it did not error out.

The evidence-sufficiency gate exists because of a moment that genuinely worried me: a single, thin CSV file was about to reach full Charter proposal against a six-standard PMI baseline, with nothing in the engine to say "this is not enough evidence to say anything credible." I had to sit with that and design a real gate — seven categories, three hard rules, and a Scope Limitation Notice instead of a report when the evidence cannot support one. That gate has since caught exactly what it was built to catch, on a real, cold Claude Code session with no memory of our conversation, which is the only kind of proof that actually counts.

Principle — No Evidence, No Finding: IEM-PM must distinguish between absence of evidence and evidence of absence. When the supplied evidence cannot support a credible assessment, the engine stops and issues a Scope Limitation Notice rather than manufacture completeness.

Then came the scariest one. During a real audit, the engine reasoned about facts that were never in that audit's own evidence — it had picked them up from an unrelated audit sitting nearby. That is the one that genuinely could have made this untrustworthy, quietly, and I would not have known unless I went looking. I made Evidence Isolation a standing principle after that, not a one-off fix: only the evidence you hand it, nothing it happens to remember from somewhere else.

Principle — Evidence Isolation: An audit conclusion may only be derived from the evidence, standards, Charter, and context explicitly authorized for that audit. Information available to the model but outside the audit's evidence boundary must never influence a finding.

Every one of these was found by actually running IEM-PM against real, non-synthetic data — first the pilot against 29 real PMI standards, then two further audits against my own organization's real delivery data, not made-up examples. Testing your own dog food only counts if you are willing to let it find something wrong in your own kitchen first, and it did. The first audit, measured against seven real PMI standards, found 10 gaps on a real $57,000, twelve-week physical and network security project I was personally accountable for — nine Missing, one Disconnected, and a Reporting Integrity Score of 52.15 out of 100. I re-audited the same project eight weeks later, and the score moved to 63.0: several of the original findings were fully resolved, the one Major finding from the first audit got fixed, and along the way the re-audit caught something new — a real $900 discrepancy between two different Budget-at-Completion figures sitting in the same cost report, one of them already in front of the sponsor for a live funding decision. That is exactly the kind of gap this methodology exists to catch, and it caught it on my own project, not a demo.

I also ran it against a simulated organization, a deliberately harsh crisis-week scenario, to stress-test it against the kind of contradictions a real project only produces under real pressure. Where I stand today: the Five Contracts are fully built and verified end to end, the 11-stage engine is complete with zero placeholder sections, the closed 7×7 taxonomy is locked, and the registry — the part that actually reads and understands each standard in depth — has deep-dived 9 of my 29 real PMI standards so far, growing every time a real audit actually cites one, not from one big upfront pass. It is packaged as a real Claude Code skill today, and I built and validated every bit of it solo.

Where This Goes Next

From September through the end of March, I plan to reach out and ensure this methodology is tested by at least 50 project and PMO professionals, have their feedback recorded, and release an improved version based on it. That number is a validation target, not a guess: enough independent practitioners across project, program, portfolio, and PMO roles to see whether the taxonomy and gate logic hold up outside my own practice. The journey — the maturity of the methodology as it improves — will also be showcased on my website.

The plan is simple: collect evidence, improve on it, and evolve it from where it stands today into what could become a fully adopted methodology within 12 months.

This is not a finished methodology — it is the beginning of a journey. From here, IEM-PM will be tested with a selected group of project managers, and they will provide real feedback: a feedback form is still to be developed and shared with them. Based on what comes back, the methodology itself will go through its own round of improvement, the same way it already improved once, on my own project, between the first audit and the one I ran eight weeks later.

Methodology

The full stage-by-stage procedure — the 11-stage state machine (Baseline → Charter → Define → Measure → Classify → Trace → Engineer & Score → Synthesize → Findings JSON → Render → Final Summary) — lives in skills/intelligence-engine/SKILL.md. I am not reproducing it here; citing it keeps this document and the actual methodology from drifting apart as one gets updated and the other does not.

References Created

Each part of the methodology I have described above has a full reference document behind it — the detail I deliberately left out of this paper to keep it readable:

Glossary

Ramani Viswanathan is a PMO Director and Program Leader with 24+ years of experience across financial services, healthcare, energy, and security services — including building the PMO function from the ground up at Azuris Consulting, and prior program leadership roles at Virtusa, HCL Technologies, Mphasis, and IBM. He is the creator of the Intelligence Engineering Methodology (IEM), a framework combining program leadership, data governance, and cybersecurity to close the information gaps behind hidden project and security failures.

More of his work — including the IEM Roadmap and published articles — is at ramaniv.com, or connect on LinkedIn.