Not the ones that make the product look good. These are the objections that come up on calls, and the complaints program managers write about in public when they are not being sold to. Three of the answers below are no.
Where these came from. Public writing by working program managers, plus two independent surveys. The quoted lines are theirs, not mine, and each one is linked. Nothing here is taken from a private conversation with a client.
Six questions about the parts of the job nobody went into program management to do.
Nobody types the status. It is computed at 06:00 from the rows themselves, so the colour on a row comes from its dates, its owner and whether anything evidences it, not from how the week felt. If two dates on the same chain cannot both be true, that is what turns the row, and the reason is attached to it.
The practical difference is latency. A written report is a description of last Thursday assembled on Monday. This is the state of the plan this morning, because it was read this morning.
About half of organizations have no access to real‑time project KPIs, and spend a day or more every month generating reports by hand. Wellingtone, The State of Project Management, 2021 edition, 214 organizations.
It asks, and it asks well, which is a different thing from chasing. At 08:00 each person gets one email containing only their own items, with one line on why each one matters to somebody else. They answer in a tap, from the email, on a phone in a warehouse if that is where they are. The answer lands in the workbook the moment they tap it.
Dependencies are held as a graph rather than a column of notes, which matters for one specific failure that spreadsheets cannot catch: a row with no date never looks late. It has no due date to be late against, so it stays quiet while three things behind it slip, and the first anyone hears is when the last of them hits the go live date.
The agent walks the chain instead of the row. When it finds one, it tells you the chain, not the symptom: this undated requirement, then this item twelve days late, then this cutover at risk, then your date, four days out.
No, and that is deliberate. An outcome with nobody on it is written as unowned rather than filled in with a plausible name, because a wrong owner is worse than a visible gap: it stops anyone looking for the right one. The row then carries a count of how many days it has been unowned, and that count only goes up.
The same applies to evidence. An outcome marked done with nothing attached stays open until something evidences it or somebody says it slipped.
It gives you a dated record you did not have to keep. Every finding is written into the workbook the morning it was found, with what it blocks and who it went to. The escalation counter shows how many mornings running it has been raised, and it does not reset because a week went by or because a meeting happened.
Friday’s steering pack then carries the decisions you are owed as their own section, with who owns each one and what it is holding up. The question stops being whether you flagged it and becomes why it sat for six weeks.
It is aimed squarely at one meeting: the weekly call where people say out loud what they already know, so that somebody can write it down. That one becomes a tap. What it does not touch, and should not, is the meeting where a decision actually gets made. Those get shorter, because the arguing about whose number is right happens less when everybody read the same rows that morning.
Four questions about adding one more thing to a stack that is already too big.
You would not, and this does not ask you to. Jira, Azure DevOps and Monday keep the work moving inside a team. This sits one level above them, at the program: the workstreams, the outcomes across all of them, the dependencies between teams, the stage gates and the date. Nothing here touches your tracker and nobody is asked to switch.
The test is simple. If one team can finish the whole thing on its own, your tracker is enough and you do not need this.
Because nobody has to update it. That is the whole design. The reason the last tool went stale is that keeping it current was a job, and it was somebody’s tenth priority. Here the agent writes the rows, asks the people who owe an answer, and writes their answers back. The plan is current because maintaining it is not a task anyone has been assigned.
The complaint about spreadsheets is correct and it is about the spreadsheet being alone. A sheet nobody reads does not notice a slip, does not know that one row blocks another, and turns into three copies called final. This is that sheet with something reading it every morning, running fifty-two checks over every row, and asking the people whose answers are missing.
It is a Google Sheet for a reason that has nothing to do with technology: you already own it, your team already knows how to use it, and if you stop paying next month you keep the whole thing. There is no export, because there is nothing to export from.
In one Google Sheet, and nowhere else. It is created in a HeyPM folder in Google Drive and shared with you with full edit access from the first day, so you are reading and editing the same file the agent is. No copy of it is stored in a database of mine, because there is no database.
Ownership is transferred to your own Google account when the engagement ends, and sooner if you ask for it. Until then you can read it, edit it, share it with whoever you like and export it whenever you want.
Your team never creates an account, never sets a password and never installs anything; the link in each brief is signed to one person and one item, which is what makes a one-tap answer possible without one.
Stopping takes no notice period. The sheet, the history and everything in it stay exactly where they are, and the file becomes yours.
Three questions, and two of the answers are the honest kind rather than the reassuring kind.
Two things, and neither of them is a promise about the model. First, every number it states is read off the rows rather than generated: when it says forty-one outcomes it counted forty-one rows, and if you change a cell the sentence changes with it. Second, and more importantly, it proposes and does not apply. Anything it wants to change in your workbook is shown to you as a proposal, with what it would write and why, and it waits.
That is a design decision rather than a safety feature bolted on. A tool that edits your plan on its own judgement is a tool you have to audit; a tool that asks is one you can read in a minute.
The concern is a fair one and widely held. Practitioners on what AI still gets wrong, The Digital Project Manager.
No, and I want to be exact about why rather than reassuring about it. What this automates is the part of your week that is clerical: reading every row, noticing what contradicts what, asking sixteen people the same question, rebuilding the deck from numbers that already moved. That is most of the hours and almost none of the value.
What it does not do is decide. It will not tell you whether to hold the date or move it, which of two directors to spend your credibility on, or whether the vendor is telling you the truth. It brings you those decisions named, dated and evidenced, and then it stops. If your role is entirely the clerical half, this is a threat to it. If it is not, this is the half of the week you have been trying to get back.
Agreed, and this does not try. It has no view on whether a workstream lead is overwhelmed or bluffing, cannot tell that the silence from finance is political rather than busy, and will never rebuild trust with a sponsor who has stopped believing your dates.
What it can do is make sure the people part is the part you are spending your time on. The relationship work fails when it is squeezed into the gaps left by admin, and the admin is the bit a machine is genuinely better at: it reads every row, every morning, and it does not get tired of asking.
The argument, made well: The soft science of project management, Association for Project Management.
Three questions, answered with numbers rather than a form.
$24,000 a year for one program, with everybody on it. That is the whole price: the discovery that writes your workbook, the agent reading every row every morning, the briefs, the answers and the Friday pack. Each further program after the first is $12,000 a year, added to whatever you are already paying rather than started as a second account — same card or invoice, same dates.
The year is how the price is quoted, not a lock. It goes on a card through Stripe, and what actually touches the card is small: $923 every two weeks. No approval threshold and no card limit notices an amount that size. Cancel any time and no further payment is taken.
One program, one number, however many people it touches. Nobody on your team has an account, so charging for seats would be a strange way to do this. And if you would rather have a proper invoice with a PO number on it than pay by card, say so and you get one.
That is the intended way round. The live demo is the real agent on six real workbooks, each one with something genuinely wrong in it, and the one thing it does not come with is the answer: you find out whether it catches the problem at the same time you do. No card, no install, and nobody from my side in the room while you poke at it.
If you want me in it rather than just the agent, that is bought separately and priced separately: $300 for forty five minutes on one thing off your delivery, and from $8,000 for thirty days of standing your own program up and handing it over. Neither is a deposit and neither comes off the $24,000. They are a different thing you can buy, not a gate in front of this one.
Sometimes the answer is no, and it is cheaper for both of us to find that out now. This is built for programs where the work crosses several teams and lands on one date: transformation, ERP, platform and cloud, data centre exits, payment rollouts. If one team can finish the whole thing on its own, you do not need this and I will tell you so on the call.
The other honest limit is the shape of the work rather than its size. A program that is one long queue of tasks in one team does not need a dependency graph, and a program nobody has decided the date of does not need something checking the date.
For context on why the multi-team ones are the hard ones: large IT programs run 45 % over budget on average and deliver 56 % less value than predicted, across a study of more than 5,400 of them. McKinsey and the University of Oxford.
If your objection is missing, it is probably the interesting one. Send it and I will answer it the way these are answered, including if the answer is no.