The Use Cases Your Vendor Will Never Ship

Every PMIS client has had this experience. The question you genuinely need answered is not on the report menu, and nothing on the menu is close enough to adapt.

So you raise an enhancement request. It is scoped, prioritised against everyone else's, scheduled, and arrives two releases later in a form that is not quite what you asked for. By then the commercial situation that prompted the question has resolved itself one way or the other.

The nine articles before this one dealt with capability supplied by a vendor or a partner. This one deals with the part nobody sells you, and it is the part where organisation-specific advantage actually accumulates.

The question you genuinely need answered is not on the report menu, and the enhancement request arrives two releases later in a form that is not quite what you asked for.

An architectural fact with commercial consequences

PMWEB holds project data in a dedicated MS SQL database with a documented relational schema. That sentence sounds like an implementation detail and it is not.

Compare it with the alternative. A multi-tenant platform where every client's data shares infrastructure cannot generally expose that data directly, so it offers an interface instead — an API, usually rate-limited, returning what the vendor decided to expose in the shape the vendor decided to expose it. That is a reasonable engineering response to a real constraint. But the consequence for the client is specific: every question you want answered has to be expressible through somebody else's interface.

A dedicated relational database with a known schema does not impose that. Your commitments, change orders, certifications, correspondence and workflow history are in tables you can read, with relationships you can traverse, in a query language that has been standard for forty years.

Your project history is either queryable by you, or it is queryable by permission. That is an architectural fact, not a feature comparison.

What that makes possible

Point a general AI tool at properly governed structured data and the economics of analysis change completely.

You describe the question in plain language. The tool works against your actual schema, proposes the query, returns the result, and shows you the logic it used. You look at the answer, realise the question was slightly wrong, and refine it. Three iterations later you have something correct. The elapsed time is an afternoon.

What makes this work is not the sophistication of the AI. It is that the data underneath it is structured, validated and related — the argument this series opened with, arriving at its practical conclusion. Value lists mean a category means one thing. Validation at entry means the dates are dates. Defined relationships mean a change order knows which commitment it varies. An AI given that substrate produces a query it can explain, and a query you can check.

An analysis that proves useful stops being an experiment and becomes something the PMO runs monthly. It never went through anyone's roadmap.

Where this must be governed

This capability is powerful precisely because the vendor is not supervising it, which is exactly why the client has to. Four conditions, and they are not optional.

Read-only access. Analysis reads; it does not write. A client-built analysis layer that can modify records has bypassed every control this series has spent twelve articles arguing for.

A reporting replica rather than the production instance. Analytical queries and transactional workloads compete, and the first time an exploratory query degrades performance for two hundred users the capability will be withdrawn and will not come back.

Permission equivalence. This is the one most often missed and it is the most serious. If the PMIS restricts a commercial manager to their own programme, an analysis layer that reads the whole database gives that person a view they were deliberately denied. The analysis layer must not become a route around the access model, which means access to it is governed as carefully as access to the platform.

A defined data boundary. Establish before you start what may leave the organisation's approved environment and what may not. Commercially sensitive positions, personal data and anything under a confidentiality obligation to a counterparty need an explicit position, taken by someone with authority to take it.

These four conditions are the client's version of the questions buyers now put to vendors. PMWEB's own checklist asks whether AI respects the permissions already in place, whether it reads your data or trains on it, whether there is an audit trail a dispute would survive, and who signs. When the organisation builds the layer itself, nobody else answers those questions for it. Permission equivalence answers the first. The data boundary answers the second.

A log of the analyses run, the queries behind them and who acted on the result answers the third. And any output that informs a decision should be treated like any other submission: a named person reviews it and owns what follows. AI advises, the operator decides, and in this layer the organisation is both the vendor and the operator.

What to establish first

Before any of this, one practical question needs a specific answer from your provider: what form of access do you actually have to your own data? own environment is workable. Scheduled exports are weaker but usable. API-only access means Layer C exists for you in a much reduced form, and you should know that before you plan around it.

Ask the question explicitly, get the answer in writing, and establish it before you need it rather than during the quarter when a board question makes it urgent.

The point of the layer

None of this replaces what the platform ships or what a partner adds. It sits alongside them and it answers a different class of question — the ones specific enough to your organisation that no vendor would ever build them, and valuable enough that you would have paid for them if anyone had offered.

The organisations that will get the most from AI in project delivery over the next five years are not the ones that picked the platform with the longest AI roadmap. They are the ones that can ask their own data their own questions, and the difference between those two groups is being decided by architectural choices being made now.

The organisations that will get the most from AI in project delivery are not the ones that

picked the platform with the longest roadmap. They are the ones that can ask their own data their own questions.

Next week: what those questions actually look like, for four different kinds of organisation.