Running a Project
Known issues and constraints
Recording the gotchas and limitations the team has to work around, so nobody rediscovers them the hard way.
Last updated September 2, 2026
Every project has things that cannot be changed and things that do not work the way you would expect. Written down once, they save everyone else discovering them at the worst moment.
What belongs here
- Technical limitations — for example, menu items pulled from a till system are read only, so they have to be changed at source.
- Things outside your control — a supplier lead time, a platform rule, a deadline set by somebody else.
- Decisions already locked — a brand rule, a budget ceiling, a system that must stay.
- The traps — anything where the obvious approach turns out not to work.
Write them as the team will meet them
A constraint written as a sentence of context is worth ten times one written as a heading. Say what the limitation is, what it means in practice, and what to do instead.
THE HOUR THIS SAVES
Every constraint you record is somebody not spending a morning trying to do something that was never going to work.
Keep the list live
Add to it as you find things, and edit an entry when the situation changes. A constraint that has been lifted and left on the list is as misleading as one that was never written down.