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.
Roughly half of organisations report spending at least a full day a month manually collating status, and 47 % say they have no access to real-time project KPIs. Wellingtone, The State of Project Management 2024.
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 departments, 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.
The workbook is a Google Sheet in your Drive, in your name, created there and left there. No copy of it is stored anywhere else. 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.
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.
Two questions, answered with numbers rather than a form.
$8,000 one time for discovery: a working session, then the whole program written into a Google Sheet in your Drive, over two weeks. You keep that workbook whether or not you carry on. Then $1,900 a month for the agent running your program every morning with nobody from my side in the loop, or $3,900 a month with an hour of me in it every week for the calls only a person should make.
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. Month to month, no annual lock, no notice period, and no card is kept on file.
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: the fractional plan is capped at four programs at a time, because an hour a week from me is a real hour. I would rather turn down a fifth than run all five badly.
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.