System in practice · Operations
How to represent what a project does not yet know
A task list records what has been agreed and loses whatever is still open, which is usually what decides the project.
Project tools represent committed work well and uncertainty badly. A task exists once somebody already knows what has to be done. What is not yet known lives in minutes, message threads and the memory of three people.
We are testing a representation in which the open question is a first-class object, just like a task. It has an owner, associated evidence, a review date and a state that is not “pending” but “open”, “bounded” or “resolved”. When it is resolved it does not disappear: it stays linked to the decision it produced.
The hypothesis is that this changes two conversations. The first is planning: a dependency on an open question is a visible risk, whereas a dependency on an unestimated task is just an optimistic date. The second is continuity: someone joining the project six months later can read why something was decided and what was unknown at the time.
It is a hypothesis, not a result. We have tested it on reconstructed projects and in an internal prototype. The real obstacle is not technical: it depends on people recording questions, and that habit only appears if the system makes it very cheap.