Standard operating procedures
When the answer is a rule,
not a screen.
Procedure the Project Management Office writes and owns. Each one states what it covers, why it exists, and what it stops going wrong quietly.
Adding or changing a tool
Every row on this page is generated from the TOOLS array at the bottom
of this file. Add an entry, and the row, its line in the band, the count in the
filter chip above and its anchor all follow. Nothing else needs editing.
band decides which group a tool sits in — delivery,
portfolio, feedback or structure, defined in the
BANDS array. To move a tool, change that one field. To add a group, add a
BANDS entry; band order there is band order on the page, and it follows
how often people open things rather than the order work happens in. A tool whose band
key matches nothing still renders, in a flagged Unfiled group at the bottom,
so a typo shows up as a red heading instead of quietly losing a row.
tagline is the only line that shows before anyone opens Details, so it is
now the most important field on a tool. Write it so someone who reads nothing else
knows whether this is the tool they want. Everything else — for,
what, why, meta, feats — sits
behind the toggle and can be as long as it needs to be.
short is optional and no longer affects the page, since the masthead
stopped listing tool names. Rows always use the full name.
Written procedure comes from the SOPS array below it. Those are documents,
not applications, so they read as ruled entries with no Details toggle. An SOP with no
href shows a link-needed flag unless its status is planned,
which is how a document that exists but nobody can open stays visible as a problem.
Leave note off unless it stays true indefinitely. Version numbers and
build dates go stale here without anyone noticing, and a stamp nobody trusts is worse
than no stamp — each tool shows its own version when you open it.