Project constraints: examples, and the one you can bill for.

Project constraints are the limits you already know about on the day you price the work: a launch date the client has committed to elsewhere, a platform they already pay for, a budget ceiling somebody else set, a brand system you have to work inside. Because all of them were visible before the fee was agreed, a constraint is already paid for, which is why a constraint holding steady can never produce a bill. The case worth planning for is the opposite one, and it's the client moving a limit they set themselves.

Almost everything published about this topic explains the triangle instead. Asana builds its guide around scope, time and cost, then adds resources and quality as two more to watch. ProjectManager counts ten, reaching as far as sustainability, strategic alignment and safety. A PMI paper makes the case for six. Those models disagree with each other, and that's fine, because none of them is trying to answer the question an agency actually has, which is what a constraint does to an invoice. So the rest of this covers the definition and the examples, and then the four lines you write into a signed scope, with a real $26,700 project underneath them.

What are project constraints?

A project constraint is a limit that exists before you quote, so the estimate is built to fit it rather than threatened by it. That word "before" is carrying the whole definition. If you knew about the limit while you were adding up the fee, the fee reflects it, and the client has already bought whatever inconvenience it causes you.

This is where the standard framing quietly misleads an agency. Inside a company running its own program, moving one constraint to relieve another is a management decision, because the same organization owns the budget, the schedule and the scope. When you're selling a fixed fee to somebody else, you don't own those dials. The client owns some of them, you own the rest, and the only question that matters is which side is holding the one that moved.

That makes constraints a commercial section of the paperwork rather than a planning one. A scope of work is a list of what you'll produce with a number attached, and the constraints are the conditions that number was calculated under, which is a different job from the one a risk register does.

What are examples of project constraints?

The useful ones on client work are specific, datable and owned by somebody you can name. Five cover most agency projects and are worth adapting rather than reinventing each time:

• A launch date fixed by a season, a store opening or an event the client has already booked.
• A vendor or platform the client is contractually stuck with and you have to build against.
• An existing brand system that rules out new art direction.
• A budget ceiling set by somebody above your client contact.
• One named approver whose availability sets the pace of every review.

Notice how little of that list is about your team. A constraint you impose on yourself, such as the languages your developers write in, isn't worth a line in a client document, because the client has no way to change it and no reason to care. The lines worth writing are the ones the other side controls, since those are the only ones capable of moving after signature.

Sorting them by who owns them is more useful than sorting them by type, though the type split is how most guides do it. Project-management.com divides the same material into internal constraints and external ones, putting regulatory, vendor, environmental and market limits on the external side. That cut tells you where a constraint came from. It doesn't tell you who pays when it shifts, and on a fixed fee that second question is the expensive one.

A constraint your client can't change is background. A constraint they can change is a price.

How is a constraint different from an assumption, a risk or an exclusion?

A constraint is a limit you knew was real, an assumption is a condition you believed without confirming, a risk is something that might happen, and an exclusion is work you're definitely not doing. Those definitions are uncontroversial and every guide on the subject gets them right.

What none of them does is attach money to the difference, and on paid work the money is the whole distinction. A constraint was priced in, so it costs the client nothing extra while it holds. An assumption was priced around, so it produces a quote the moment it fails, which is why project assumptions belong in the scope rather than a risk log. An exclusion was priced out, so the client buys it separately if they want it, which is the ordinary trade settled on the line between in scope and out of scope. Three conditions, three different commercial outcomes, and one shared requirement, which is that the client has to have seen all three in writing.

Risks fold into the same test rather than needing their own section. A risk with a price and a named trigger has become an assumption in everything but the label, and a risk without one belongs in your internal notes where it can't confuse anybody.

Where do project constraints belong in a scope of work?

In a short numbered section of the document the client signs, next to the assumptions and the exclusions, and never only in a plan they'll never read. Three to six lines is normal on agency work. Each one names the limit and the person or body that set it, so that six weeks later nobody has to reconstruct whose deadline it was.

The line that decides money is the last one in the section, and it's the line most templates skip. It says what happens if a constraint the client owns changes after signature. Without it, a client who pulls their own launch date forward is asking for a favor, and favors are free by definition. With it, the same request has a number beside it that both sides agreed to back when nobody knew which constraint would move. Writing the scope section by section shows where that paragraph sits relative to the fee.

What does a constraint clause look like on a real project?

Brindlecote Optical Co. runs nine eyewear stores and hired an agency to build an online booking flow and a store locator, eight weeks for a fixed fee of $26,700. Three constraints were on the table before anybody quoted: the site had to go live in time for Brindlecote's fall collection drop, the booking had to run on the vendor Brindlecote already pays for, and the design had to sit inside their existing brand system with no new art direction.

Clauses 5.1 through 5.3 look like ordinary background until you read the rates sitting inside two of them. The $3,800 in 5.2 and the $95 in 5.3 are what turn a description of the situation into terms, and they're readable by somebody who never meets your team. The client can work out what a vendor switch costs on the day they start wondering about it, which is months before anyone is annoyed.

Clause 5.4 is the one doing the real work, and it's the sentence a constraints section is usually missing. It converts a client-owned limit into a priced condition, so that moving the limit is a purchase rather than a negotiation. Everything about the tone of the later conversation depends on that paragraph existing in week one.

Who pays when the client moves a constraint?

Whoever the document says pays, and at Brindlecote the document said the client did. In week four the collection drop moved forward, so the launch went from the week of November 9 to the week of October 26, and the brand assets arrived as print-ready artwork rather than the web-ready files clause 5.3 named.

Both halves were arithmetic rather than argument. Brindlecote sent 34 assets, 14 more than the 20 covered by the fee, which came to $1,330 at the stated $95 each. The compression hit the booking integration and the six page templates, $16,300 of work between them, and the 25% uplift in clause 5.4 added $4,075. The change went back the same afternoon at $5,405, taking the engagement to $32,105, and it was approved in writing before the compressed work started.

Run the same week with the constraints written as context and the agency is absorbing two weeks of overtime plus fourteen assets, then explaining in the closing meeting why the margin disappeared. Nobody asked for extra work in either version. The only difference is whether the date had a number beside it, and a surprising share of what scope creep costs an agency over a year is made of exactly this: requests nobody recognized as requests.

Are the triple constraints worth anything on client work?

Yes, as a thinking tool for you, and almost nothing as a clause for the client. The triangle is a decent reminder that pulling a date forward has to come out of scope or cost, and it's genuinely useful in the hour before you send a quote, when you're deciding what the compressed version of the project even looks like.

Where it stops helping is the moment you need somebody else to agree with you. A client told that scope, time and cost are linked hears an abstraction, while a client who reads that compressing delivery below five business days carries a 25% uplift has a fact they can plan around. The model explains why the number exists, and the number is the part that has to be in the document, which is the same reason a fixed fee behaves so differently from time and materials once a schedule starts sliding.

The date you didn't price is the date they can move for free

Of everything in this piece, clause 5.4 is the line worth copying, because it's the only one that changes an outcome rather than describing a situation. Where Brindlecote changes a constraint in this section after signature, the affected work is requoted before it begins, and work compressed into fewer than five business days between approval and delivery carries a 25% uplift. Two sentences, written before anyone knew which constraint would move, and worth $4,075 on a single project.

Everything after that sentence is mechanics. The client moves their date, the request gets priced against a rate they already read, and somebody approves it in writing before the work starts. That's the part Docket handles, turning a constraint change into a dated, priced request the client says yes to on the record. The change request form is what clause 5.4 becomes on the day the launch moves, and letting the client own the scope-change moment is what stops the whole thing feeling like a penalty.

Frequently asked questions