Project constraint
A limit on how a change is delivered: time, budget, team, tools.
What it is
A project constraint limits the delivery rather than the product: live within three months, a budget ceiling, a team of two, only approved tools, no production access for contractors. It belongs to the initiative that carries out the change.
Why it matters
Time and money shape every technical choice. A design that is right for a two-year programme is wrong for a three-month launch. Making the limits explicit lets everyone choose solutions that fit them.
What goes wrong without it
- The team designs for an ideal world and runs out of time.
- Scope is cut at the last moment instead of planned.
- Tools or services are adopted that the organisation cannot pay for or support.
What it gives an AI agent
Agents do not know your deadline or budget. A project constraint lets the agent prefer the simpler option, flag work that will not fit, and avoid paid services the initiative cannot pay for.
Example: Clinic Booking
| Weak | Strong |
|---|---|
| We need this soon. | The system is live in three months, before the spring rush. |
How it relates to the rest
- Constrains the whole solution or specific requirements.
- Differs from a project requirement: a constraint limits how the change is delivered, a project requirement is something it must deliver.
- Work packages and their dates are planned within it.
In CorPole
- Type Project Constraint (PJC), in the Constraints group. It belongs to an initiative.
- Acceptance criteria are optional.
- Agents receive solution-wide constraints with every piece of work.