61% of project management products now ship AI features. Only 43% of organisations actually use them.
That 18-point gap is the reason QPS Engineering built a different kind of product. Early access to Dr. Project AI opened on 15 September 2026 and is open now. It is a project management system where the AI can perform every action a user can perform, live realtime voice is part of the product, and the multi-project overview takes five minutes instead of thirty.
Disclosure: I work at QPS Engineering, which builds Dr. Project AI, so read the first-party claims below as first-party claims.
The distinction I care about is architectural. Most PM tools kept their data model, their permissions and their workflows, then hung an assistant off the side that can summarise a ticket or draft a status update. Dr. Project AI starts from the assumption that the agent is a first-class actor in the system, with the same capability surface as a human user.
The 18-point adoption gap looks like a design failure, not a training failure
The usual explanation for low AI adoption in project tools is that people have not learned to use them. There is real evidence for that: a PMI chapter survey found over 40% of project managers report lacking AI training. And the 2025 AI in Project Management Research shows usage climbing fast: 66% of project professionals used AI tools to some extent in 2025, up from 41% in 2023. In that same study, only 12% use them extensively.
My read: the distance between 66% trying and 12% depending is the signature of a tool that is pleasant to demo and awkward to rely on. If the assistant can read your project but cannot change it, every useful interaction ends with you doing the work anyway, in a different window. The training argument does not explain why the people who did learn the tool still use it lightly.
There is a second number worth holding onto. McKinsey Global Institute, summarised in this evidence review, found interaction workers spend 19% of working hours, roughly 8.8 hours a week, tracking down information they need to finish a task. Project managers are close to the archetype of an interaction worker. That is the cost being paid before anyone writes a line of a status report.
Capability parity and built-in voice are the two design decisions
According to the team, Dr. Project AI aggregates open points across planning, documentation and follow-up, and presents them as one view instead of three. The brief states that the multi-project overview takes five minutes instead of thirty. That is a first-party figure, not an independent benchmark, and I would treat it as an indication of the shape of the saving rather than a number you can put in a business case.
Two design decisions distinguish it, both from the brief:
- Capability parity. The AI can do everything in the system that the user can do. There is no separate, smaller surface that the assistant is limited to.
- Live realtime voice is built into the product rather than added on. You talk, it answers, it acts.
Voice is the part I expect people to underrate and then change their mind about. Reading a written summary of twelve projects is a scanning task; asking which of them has slipped since Monday is a question. The same 2025 research found 72% of project professionals name scheduling and resource allocation as the area AI improves most, with 64% naming risk management. Both are question-shaped problems, which is why a conversational interface fits them better than a dashboard does.
An AI-native system executes where a copilot only suggests
A copilot observes and recommends. An AI-native system holds the same permissions as you and executes. The practical difference shows up in what happens after the AI is right.
With a copilot, being right produces a recommendation, and you translate it into clicks. With capability parity, being right produces a change to the project. That is more useful and more dangerous in the same proportion, which is why the design keeps the decision with the human: the system executes, the user decides. The AI can do the work. It does not get to choose which work to do on your behalf.
Ask across the portfolio
You speak the question. The system aggregates open points from planning, documentation and follow-up into one answer instead of making you assemble it from three places.
Get the overview in minutes
QPS reports the multi-project overview lands in about five minutes where it previously took thirty.
You decide, it executes
The action is yours to approve. The AI then performs it with the full capability set of a normal user, so the follow-through does not fall back to manual clicking.
That third step is the one I would test hardest as a buyer rather than as someone working on it. Capability parity means the blast radius of a misunderstanding is the same as the blast radius of a confused human with edit rights, which is not zero.
Agents do not reliably raise their hand, and reporting speed is not delivery speed
I have written before about how agentic systems behave when something goes wrong. In a METR review of roughly 1,300 agent transcripts, at most six showed an agent considering warning a human, and none actually did it. That finding covers a different class of task, but the pattern generalises: agents are poor at volunteering that they are out of their depth. A system where the AI has full write access needs the human to stay attentive, because the agent will not reliably raise its hand.
The second thing I would push on is whether speed at the reporting layer converts into speed at the delivery layer. It often does not. A GitLab survey showed 78% of developers coding faster with AI while software delivery did not accelerate. Producing a portfolio overview in five minutes instead of thirty is a real saving for the person producing it. Whether it moves a project’s end date depends on whether the decisions made from that overview were previously late, or merely expensive to prepare.
My take: capability parity is the right bet and it raises the stakes. The honest open questions are audit and recovery, not capability. If the AI can do everything a user can do, teams will want to see exactly what it did and reverse it cheaply, and the voice interface makes that harder, since spoken instructions leave less of a paper trail than typed ones. That is the area I would want independent scrutiny on, and it is also why I think the “human decides” boundary has to be a hard product rule rather than a preference setting.
Several projects at once is the fit, single-project teams are not
Early access is open as of 15 September 2026. The global PM software market was around USD 10.33 billion in 2025 and about USD 12.24 billion in 2026 according to Straits Research, so there is no shortage of incumbents to compare against. What I would not do is try Dr. Project AI as an additional tool alongside an existing one. Capability parity only pays off if the AI has the full picture; running it on a partial copy of your projects tests the interface and not the idea.
I think the fit is strongest for people running several projects at once who feel those 8.8 hours a week of information hunting in their own calendar, and weakest for single-project teams where the overview problem barely exists. If you are in the second group, the voice interface will feel like a nice demo. That is a fair reaction.
One more caveat I will state plainly, since I am on the building side: everything here about what Dr. Project AI does comes from the product brief and the team. The context numbers are independent, the product numbers are not. Early access exists so that changes.
Most PM tools bolted an assistant onto a classic data model. Dr. Project AI gives the AI the same capability surface as a user, with live realtime voice, and keeps the decision with the human. If you run more than three projects at once and the overview costs you half a day, it is worth thirty minutes of your attention. Join the early access →
