Anti-PMO · August 20, 2026
How to Move a Software Request From Hallway Ask to Delivery Without a Glossary
I have watched a hallway sentence die in four dialects before lunch. Keep one living record. If the requestor cannot read the page at release, you translated the work away.
Each handoff likes to invent a new dialect. I have lost count of how many times I have seen it.
Intake becomes a form. Discovery becomes a deck. Delivery becomes tickets. Testing becomes the ticket text. Nobody is lying. Each group is “clarifying.” By Friday the person who reported the broken process does not recognize the work. They nod anyway. Nodding is cheaper than starting over.
A PMO used to own that translation. Lean teams still recreate it with well-meaning write-ups. Real English is not sloppy. It is the discipline of not translating. After twenty-eight years, that is the only part I am still stubborn about.
Write a situation, not a system
“Volunteers give up after three days of email scheduling” is definition. “Build a volunteer app” is a solution looking for a problem, and it will find one whether or not it is yours.
Start with the week they are living. What happens today. Who is affected. What better looks like. Attach the next unknown under that paragraph. Do not open a new brief to look official. Official is how the dialect changes. “Who can approve a last-minute facility change?” can be answered by the same person who wrote the first sentence. That is a good sign. If only a certified practitioner can answer the next question, you already left the hallway.
Keep the questions, the yes, and the plan on one thread
Facts should attach. They should not migrate.
Use requirements gathering software so the next questions stay on the same thread the requestor can still read. Record the yes, the no, or the not yet on that page. Write down what was approved and what was left out. A hallway yes spends capacity. A written yes names the first-release result in the requestor’s language, which is the only language that can later tell you whether you finished.
Then software project planning sequences the work. It is not a new dialect. Constraints and busy seasons belong next to the problem. Phases invented so leadership has a picture belong in the drawer with the other pictures.
I have sat through beautiful plans for work that was never written. They photograph well. They do not ship the week the requestor described.
Hand delivery a link, not a cleaned-up cousin
Builders open the original record. If they need a board, the board item points back. It does not replace the page. Testers start from what the business user wrote, not from a description that survived three polite edits. If QA can only see the ticket, they will test the ticket. I have signed off on those tickets. The original complaint was still waiting in the parking lot.
The full thread is in How to move software projects in real English. If the requestor cannot read the page at release, a dialect split happened and the original problem is no longer the spec. Ask the reachable owner whether their week changed. That sentence is the release check.
A closed ticket is a filing event. A changed week is the work.