How To Align A Construction Team: Conditions Of Satisfaction

Conditions of Satisfaction: The Practice That Eliminates Every “I Thought You Meant” Conversation

There is a failure mode that happens on construction projects, in meetings, in training sessions, in team assignments, and in every other context where one person is depending on another person’s work. One person asks for something. The other person delivers something. And what gets delivered is not what was expected not because either person was careless, but because nobody clearly defined what done actually looked like. The expectation existed in one person’s head. It never made it to the other person’s page. And by the time the deviation becomes visible, the cost of correcting it is always higher than the cost of the conversation that would have prevented it.

Conditions of satisfaction are the discipline that closes that gap. They are the clear, shared definition of what a win-win outcome looks like for every party, on every engagement, before the work begins.

Why Win-Lose Always Becomes Lose-Lose

The foundation of conditions of satisfaction is a commitment to genuine win-win outcomes. Not the superficial version where one party makes a concession and calls it compromise. The real version, where the success condition for every person involved in the work is defined clearly enough that everyone can see when it has been reached.

Here is the honest math on win-lose: it does not stay that way. Every arrangement where one party wins at another’s expense eventually becomes a loss for both. The trade partner that gets squeezed into an unprofitable scope cannot deliver the quality and reliability the project needs. The general contractor who structures every contract to maximize their protection at the trades’ expense will eventually operate in a world where no quality trade partner wants to work with them. There are only win-wins and lose-loses. The conditions of satisfaction practice is what makes win-wins intentional rather than accidental.

The Seven Components

The first is defining what done looks like. This is the concept that the Scrum framework calls the definition of done, and it is exactly as simple and as important as it sounds. Not done-ish. Not mostly done. Done. What does this deliverable, this phase, this scope, this assignment look like when it is complete? The description has to be specific enough that two different people reading it would agree on whether the condition has been met. If the description is vague, the condition cannot be verified, and the retrospective at the end of the work has nothing to compare against.

The second is defining by when. Timing matters because inadequate lead time overburdens the person doing the work and overburden is the first type of waste Lean seeks to eliminate. Knowing the deadline at the outset is not just about accountability. It is about respecting the capacity of the person or team being asked to deliver. When Brandon Montero co-facilitates Super PM Boot Camps, one of the first questions he asks about any assignment is “when do you need it done?” Not as a formality because the timeline is one of the most important pieces of information the person receiving the assignment needs to plan their work correctly.

The third is defining the level of quality. Quality expectations vary enormously depending on context, and assuming everyone has the same standard is one of the most reliable sources of rework in construction. A painted wall in a multi-family residential building does not need to be finished to the same standard as a wall in a house of worship where every surface is examined at close range. What does this specific deliverable require? Not perfection in most cases excellence is the right standard. But the level of excellence needs to be stated. People can deliver exactly what is asked for when they know what is being asked for.

The fourth is confirming handoffs. In any multi-party process which is every construction project who is handing off what to whom, by when, and at what quality level must be explicitly confirmed. The handoff is where the most waste accumulates in construction: information that was not ready, work that was assumed complete, quality that was presumed acceptable. When handoffs are confirmed as part of conditions of satisfaction, each party knows what they need to receive and what they need to deliver, and the system can be held accountable to those commitments rather than to individual assumptions.

The fifth is writing it down. Not as a legal document. Not as a formal contract that will be cited in a dispute. As a written record that makes the shared expectations visible and verifiable. If the expectation is not written down, it exists only in someone’s memory, and memory is not a reliable system for managing complex, multi-party commitments. The conversation that should have been documented is the one that, weeks later, results in “I thought you meant…” The written conditions of satisfaction eliminate that conversation before it starts.

The sixth is reviewing constantly. Conditions of satisfaction are not a one-time exercise at the beginning of a project or an assignment. They are a reference point that the team checks against regularly to ensure the work is on track. Mid-process reviews that compare the current state against the defined conditions create the opportunity to correct course while correction is still cheap. By the time deviation becomes obvious without regular review, the cost of getting back to the right track is always higher than it would have been with earlier visibility.

The seventh is the retrospective. At the end of every significant piece of work, compare what was delivered against what was promised. What worked? What did not? What would be done differently? The retrospective only produces useful learning when there is something to compare against which is exactly what the conditions of satisfaction provide. Without defined conditions, the retrospective becomes a general conversation about feelings. With them, it becomes a precise diagnostic of where the system performed and where it needs to improve.

Here are the signals that conditions of satisfaction are missing from a team’s practice:

• Rework occurs because the quality expectation was not stated before the work began
• Deadlines are missed because the timeline was never confirmed with the person doing the work
• Retrospectives produce vague observations rather than specific improvement actions
• Handoff problems recur because each party assumed the other knew the expectation
• The same type of misalignment keeps occurring between the same parties in the same contexts

Conditions of Satisfaction Are Everywhere

The power of this practice is its universality. Conditions of satisfaction belong in every owner-contractor relationship, in every pre-construction meeting with trade partners, in every pull planning session, in every training assignment, in every team meeting with a deliverable, and in every personal task that involves a handoff to someone else. They are not a construction-specific tool. They are a human coordination tool applied specifically in the construction context.

That breadth is not a complication it is the point. When the question “what are the conditions of satisfaction?” becomes a reflex something you ask automatically before beginning any engagement where another person’s needs and your delivery intersect the quality of every working relationship improves. Expectations are clearer. Disappointments are rarer. Retrospectives produce better learning. And the win-win outcomes that the practice is designed to create become the default rather than the exception.

At Elevate Construction, conditions of satisfaction are embedded in how we structure every engagement from the initial alignment conversation with a new consulting client through the pre-construction meetings with trade partners through the foreman huddle agreements that govern the next day’s handoffs. They are how we make the win-win concrete rather than aspirational. If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow.

Life is only beautiful if we are continuously improving. And the conditions of satisfaction are what give continuous improvement something real to improve from.

On we go.

Frequently Asked Questions

What are conditions of satisfaction and why do they matter?

Conditions of satisfaction are explicit, shared definitions of what a successful outcome looks like for every party in an engagement. They matter because most disappointments in construction result from unclear or unspoken expectations, not from bad intentions.

Why is it important to write conditions of satisfaction down?

Because expectations that live only in memory are unreliable. Written conditions create a verifiable reference point that both parties can compare against at any point and they make the retrospective at the end of the work meaningful rather than impressionistic.

How do conditions of satisfaction connect to retrospectives?

The retrospective examines what worked and what to change but it can only do that precisely when there is a defined standard to compare against. Conditions of satisfaction are that standard.

What is the definition of done?

It is a specific, concrete description of what a deliverable looks like when it is genuinely complete specific enough that two people can independently assess whether the condition has been met.

Can conditions of satisfaction apply outside of formal project agreements?

Yes they apply to any context where one person depends on another’s work, from pull planning commitments to training assignments to daily foreman huddle handoffs. The universality of the practice is one of its greatest strengths.