Almost every bank has run this experiment. An associate sets up a Trello board for the live process. A chief of staff builds an Asana project with a template per deal stage. Or, most commonly, someone maintains an Excel checklist with a tab per workstream. For two weeks it looks like order. By week three the board is stale, the checklist disagrees with the CRM, and everyone has quietly gone back to email and the MD’s personal tracker.
The usual diagnosis is discipline: the team just did not keep it updated. That diagnosis is wrong, and it matters that it is wrong, because it leads firms to try the same tool again with sterner emails. The real reasons generic project management fails deal teams are structural, and they point at what a tool built for this work actually has to do.
Deal state is not a checkbox
In software project management, a task is done when the person doing it says it is done. The checkbox is the truth because the team is the only authority on its own work. Deal state is different in kind. Did the buyer sign the NDA? That is not an opinion or a status update. It is a claim about the world, and it is either true or false depending on whether an executed document exists. Is the buyer really at IOI? Depends on what their email actually said. Has management met them? Depends on a calendar.
A generic tool stores the assertion and throws away the evidence. When a VP drags a card to “NDA signed,” the board now says something about the world with nothing behind it but the drag. That is fine for sprint planning. It is not fine when a partner walks into a management meeting armed with the board’s version of reality. The board can never be more trustworthy than the last person who updated it, which is exactly the property that made everyone distrust the CRM.
Status entry is unpaid work
The second failure is economic. Generic tools assume the team will feed them, but a deal team already owes status to the CRM and already keeps the tracker the MD actually reads. A Trello board is a third surface demanding the same manual update, and it pays the banker nothing for the effort. Under deal pressure, unpaid work loses. Every time. This is not a banking quirk: it is why CRM data everywhere is in the state it is in. None of this is a knock on the tools themselves. Trello, Asana, and Monday are genuinely great software. They simply have no concept of buyers, stages, or evidence. Nothing in Asana knows that a sell-side process is 40 parallel buyer conversations, or that “CIM sent, no questions for nine days” is a warning light.
What IB native process management actually needs
Take the two failures seriously and the requirements write themselves. A process tool for deal teams needs:
- Stages with receipts. A buyer does not move to “NDA signed” because someone dragged a card. It moves because the executed NDA arrived and a banker approved the change, with the document attached to the stage forever.
- Quiet buyer detection. The dangerous buyers in a process are the silent ones. The process view should sort buyers by days quiet and surface the silences a busy team stops noticing.
- Approval gated writes. The system drafts every update from evidence, and a human approves before anything changes. Nothing writes itself, and every write is auditable.
- Projections, not another surface. Approved state should flow into the CRM the firm owns and into the banker’s own Excel tracker, in the banker’s own format. The tool adapts to how the team works instead of demanding migration.
- A Monday pack rendered from the record. The weekly status picture should be generated from current, evidenced state, not assembled by an analyst on Sunday night.
Notice the common thread: status stops being something the team produces and becomes something the record produces. That is the shift that killed status meetings in software, and it is only possible in banking if the record underneath is evidence backed rather than vibes backed.
What we are building: the Process Room
This is the design behind the Process Room, which we are building now. To be precise about status: the Process Room is in development, not shipped. It sits on a foundation that is live today: buyer trackers, weekly updates, pre-call briefs, a Notetaker that writes to the CRM with receipts, and approval gated writeback to DealCloud and Salesforce. The Process Room extends that record into process management proper: stages with receipts, quiet buyer detection, documents that file themselves, watermarked CIM distribution, and one diligence request list instead of five competing ones.
The full picture is at /process, and the failure modes it exists to fix are cataloged at /problems. If your firm has buried a Trello board or three and concluded that project management does not work for deals, the conclusion is half right. Generic project management does not work for deals. Process management built on evidence is a different product, and it is the one this industry never got. If you want to see where it stands, call us.
