Every PMO has a version of the same week. The reporting period closes, the pack is due to the steering committee on Thursday, and on Tuesday afternoon eleven of the nineteen project owners still have not sent anything. So the chasing starts: a reminder to the group, then individual messages, then a message to someone's manager. The updates trickle in. Two arrive after the pack has gone out.
It is easy to read this as a discipline problem — people not taking reporting seriously enough. Usually it is not. It is a design problem, and it is worth being precise about where the design goes wrong.
The process asks the wrong thing of the wrong people
A typical reporting cycle asks a project owner to do four things: remember that reporting is due, find the right place to put the update, recall what has happened since last time, and write it down. Only the last one is actually their job. The first three are overhead the process has pushed onto them.
That overhead lands on the people least able to absorb it. Project owners are usually running delivery, which means their week is already full of other people's urgent requests. A reporting deadline with no request attached to it competes badly against a deadline that someone is actively asking for.
The tell is that chasing works. If reminding someone reliably produces an update within the hour, the problem was never willingness — it was that nothing had put the task in front of them.
Logins are a bigger tax than they look
The common fix is to buy a tool and give everyone an account. This solves the "find the right place" problem and creates a worse one.
An occasional user does not remember a password for a system they open once a month. So the cycle becomes: notice the reminder, try to log in, fail, request a reset, wait for the email, set a new password, navigate to the right project, then finally write two sentences about status. Most people will not do that on a busy Tuesday. They will reply to the reminder email with their update instead, which puts the PMO back to copying text into a spreadsheet by hand.
The tool has not removed the work. It has moved the work to the person doing the chasing, and added a support burden on top.
| Approach | Who does the chasing | Where the update ends up |
|---|---|---|
| Spreadsheet on a shared drive | The PMO | Merged by hand, version conflicts |
| Reporting tool with accounts | The PMO, plus password resets | In the tool, when people get in |
| A request sent to the owner | Nobody | Collected in one place, automatically |
Invert the direction of the request
The change that matters is small and structural: stop expecting owners to come to the reporting process, and send the reporting process to them.
Concretely, that means the system knows who owns what, knows when the period closes, and emails each owner a request for exactly the projects they are responsible for. The request contains a link that opens straight into their update — no account, no password, nothing to remember. If they have not responded after a week, the system follows up, rather than a person doing it.
This is the model Reportoir is built around. Work is organised into themes, initiatives and projects, each project has an owner, and on the reporting cadence each owner gets one email covering their projects. They open a secure link that expires, report, and are done. Reminders go out automatically to whoever has not responded yet.
Three things fall out of that design, and they are the reasons to prefer it:
- The nudge is built in. Following up stops being an act of will by the PMO and becomes something the system does on a schedule.
- The cost to respond is close to zero. Removing the login removes the most common reason an update does not get written.
- Nobody merges anything. Updates land structured and in one place, so the pack is assembled rather than reconstructed.
If you only change one thing, change who initiates. A process where the owner must remember will always leak; a process where the request arrives will not.
What good looks like at the end of a cycle
A reporting cycle is working when the PMO's Tuesday is spent reading updates and spotting the two projects that need attention — not spent finding out which eleven people have not replied yet. The measure is not how many reminders were sent. It is how few had to be sent by a human.
Reporting will never be the most interesting part of running a portfolio. But it should be the part nobody has to think about, and that is achievable with a change in direction rather than a change in culture.