Early in a hardware program, the process changes every day. The second prototype doesn't get built the way the first one was, and the fifth one won't either. A manufacturing system that requires a reviewed, released procedure before anyone can pick up a wrench is asking for something the team can't give yet.
So the team routes around it. The build happens in a spreadsheet, a chat thread, and someone's notebook. That works until a unit fails test three months later and someone asks which lot of fasteners went into it, who torqued them, and whether the other two units on the bench got the same ones. The answers were never written down, because writing them down was too much ceremony for the stage the program was in.
We think that's backwards. The record is the part worth keeping from day one. The ceremony can wait until the process is stable enough to deserve it.
Two ways to do work
Factorial has two ways to execute work.
- A work order runs a procedure: a versioned, reviewed model of repeatable work. A procedure revision goes through review and approval, and once released it becomes the default for new work orders.
- A project is a one-off execution that does not require a released procedure. It is built for prototypes, experimental builds, corrective work, and anything else whose process has to develop while the work is underway.
Both live in the same system, against the same parts, inventory, queues, and people. Choosing a project instead of a work order changes how much control the process is under. It doesn't change whether the work is recorded.
Editable and actionable at the same time
A project is editable like a procedure and actionable like a work order. Its tasks support the same definition blocks as procedure steps: instructions, data fields, files, part requirements, and the rest. The difference is that they can change while the work is happening.
Part requirements show this best. On a project, a part requirement can be edited and fulfilled in the same place. An engineer adds a requirement for a bracket the moment they realize the build needs one, and the technician on the bench scans the bracket in against it. The installation is recorded the same way it would be on a controlled work order, so the unit's history shows what went into it and when.
Projects also carry the execution tools a real build needs:
- Task ownership, queues, and scheduling
- Timeline planning and a Kanban view
- Comments on every task, gathered into one conversation on the project page so the whole build can be read top to bottom
That conversation matters more than it sounds. On a prototype, the comments are often where the process is actually being designed. Keeping them attached to the tasks they describe means the reasoning survives alongside the record.
Guardrails, not gates
Projects let work proceed without an approved procedure, so access to them is controlled by dedicated permissions. An organization can limit who may create or execute projects, or turn projects off entirely. A team building flight hardware under a quality system will set this differently from a team on its first three prototypes, and both are reasonable.
When the process settles
At some point the build stops changing. The fifth unit gets built like the fourth, and the team wants that to be the rule, not a habit. That is the moment for a procedure.
A procedure brings the controls a project deliberately skips. Its revisions are reviewed and released. New work orders use the newest released revision. Revision diffs show exactly what changed between releases, step by step. When a released process still needs to change on one unit already in progress, a redline changes that work order through its own review, without touching the procedure.
Writing that procedure is easier when the project already shows the steps that worked, the parts that were actually used, and the comments explaining why. The team isn't reconstructing the process from memory. It's reading it back.
The point isn't that rigor is bad. It's that rigor applied too early pushes the work out of the system, and the record goes with it. Start light, keep the history, and add control as the design earns it.
Read more in the docs on projects and procedures.