ENDE

BOUND: push back on unrealistic expectations

Baseline · Objectivity · Understand · Negotiate · Document

BOUND turns blanket pushback into an evidence-based choice: clarify the need, offer options, and record the agreement.

  • Reset unrealistic expectations
  • Use facts, not assumptions
  • Record the agreement

Start a reflection about:

Also helps with:Performance review seasonAnnual planningA new manager

BOUND in 5 steps

BOUND moves from the current expectation to an evidence-based, workable agreement. It makes needs and trade-offs visible.

  1. Baseline

    Clarify the expectation, commitments, capacity, and hard constraints.

  2. Objectivity

    Use verifiable evidence. Separate facts from assumptions.

  3. Understand

    Ask which need, urgency, or risk is driving the expectation.

  4. Negotiate

    Offer realistic options. Show trade-offs across scope, time, resources, and quality.

  5. Document

    Record the decision, responsibilities, open points, and process for later changes.

When this method helps

Use BOUND to reset an unrealistic deadline or scope request while preserving the working relationship.

Key benefits

  • Creates a shared evidence base
  • Reveals the need behind the request
  • Turns trade-offs into realistic choices
  • Prevents scope drift with written agreements

Limits and when to pause

BOUND cannot create authority, remove contractual constraints, or replace formal escalation for safety, ethics, or legal duties.

BOUND examples

The five steps stay the same whether the expectation is a date, a scope that keeps growing, or a standing demand nobody ever agreed to. Each example shows the steps separately and then how you could open the conversation.

A deadline that doesn't fit

Keep the date that matters by cutting scope, not quality.

Illustrative scenario

Baseline
Marketing expects the full reporting dashboard, with twelve metrics, for a customer conference on 16 September. The team is committed to a billing release until 22 August. Starting on 25 August, the full dashboard is ready on 20 October at the earliest.
Objectivity
The last two comparable integrations took five and six weeks. The security review for customer data adds ten working days. Six weeks from 25 August plus the review ends on 20 October.
Understand
She asks why the date matters. The keynote needs a credible live demo of the three key metrics. The other nine are for customers after the conference.
Negotiate
Option 1: a pilot with the three metrics on sample data by 12 September, which needs no security review, and the full version on 20 October. Option 2: the billing release waits until November, work starts on 4 August, and the full version is ready on 29 September. That still misses the conference.
Document
She sends the marketing lead and the product lead a short email: pilot by 12 September, full version on 20 October, acceptance by the product lead, a status check every Thursday. Changes to the scope go through the product lead.
How you could open
I know the dashboard has to work on stage on 16 September. The full version with all twelve metrics can't be ready before 20 October: comparable integrations took five to six weeks, and the security review adds two more. What I can offer is a live demo of the three key metrics on sample data by 12 September. Would that work for the keynote?

Scope that keeps growing

Decide what comes out when something new goes in.

Illustrative scenario

Baseline
The app release has a fixed code freeze on 14 February. The team has 30 developer days left, and the eight agreed features need 26 of them. Sales asks for three more features, estimated at 9, 7 and 5 days.
Objectivity
The estimates come from the team's planning. Over the last six sprints, the team finished within 10 percent of its estimates. The three requests add 21 days to a plan with 4 days of slack.
Understand
He asks the head of sales what drives the requests. Bulk export was promised to a key customer whose contract renews in March. The other two came from a wish list.
Negotiate
Option 1: bulk export goes in, and dark mode (8 days) moves to the April release. That makes 27 of 30 days. Option 2: the scope stays, and bulk export ships in April, after the renewal.
Document
He adds a change note to the release ticket: bulk export in, dark mode moved to April, the other two requests go into April planning. From now on, new requests go through the product owner's weekly review.
How you could open
Which of the three new requests is tied to the renewal? We have 30 developer days left before the code freeze, and the agreed features already take 26. If bulk export is the one that matters, I can swap it in for dark mode, which moves to April. Adding all three would mean missing the code freeze.

A demand nobody agreed to

Turn an unspoken expectation into a written agreement.

Illustrative scenario

Baseline
Sales expects the data team to deliver ad-hoc reports within one day. The team has three analysts and about 190 hours a month for ad-hoc work. There is no written agreement on turnaround times.
Objectivity
Last quarter's tickets show 45 requests a month at about six hours each, so demand is around 270 hours. The median turnaround was four working days. Sixty percent of the requests came from sales.
Understand
She asks the head of sales where the one-day expectation comes from. Sales managers need current pipeline figures before the forecast call every Monday. Most other requests could wait a few days.
Negotiate
Option 1: a pipeline dashboard sales can use directly, built in two weeks, and five working days for everything else. Option 2: one-day turnaround for up to ten urgent requests a month, flagged by the head of sales, and five working days for the rest.
Document
She writes a one-page agreement on the team wiki: turnaround times, what counts as urgent, who flags it, and a monthly review with the head of sales for the first quarter.
How you could open
Your team needs the pipeline figures before every Monday forecast call, and right now they often arrive late. With three analysts, we have about 190 hours a month for ad-hoc requests, and demand is around 270. I'd suggest a pipeline dashboard your team can use directly, plus agreed turnaround times for everything else. Can we go through the two options on Thursday?

The dates and numbers are illustrative. Each opening names the need first, then the numbers, then a choice. None of them ends with a flat no. Keep the full evidence ready for when the questions come.

Blanket answer or real choice?

A blanket no, or a vague yes, leaves the other person with nothing to decide. A real choice says what is possible, by when, and what it costs.

  • Blanket answer“That's impossible by September.”

    Real choice“The full dashboard needs until 20 October. By 12 September, I can deliver the three key metrics on sample data.”

  • Blanket answer“We're already at full capacity.”

    Real choice“We have 30 developer days left before the code freeze, and the agreed features take 26. For bulk export to fit, dark mode moves to April.”

  • Blanket answer“We'll do our best.”

    Real choice“We answer up to ten urgent requests a month within one day. Everything else takes up to five working days.”

The real choice can be accepted, rejected or changed. A blanket no tends to come back as escalation, and a vague yes comes back as a missed deadline.

Template: open your expectation conversation

Copy the template and replace each bracket with your own case.

I know [the need behind the expectation] matters. With [current commitments and capacity], [the full request] is realistic by [date] at the earliest. [Your strongest evidence]. I can offer [option 1] or [option 2]. Which works better for you? I'll send a short summary of what we agree.

Check before you say it

  • Baseline: Does it name what's already committed and the capacity left, in numbers?
  • Objectivity: Could the other person check your evidence? Mark estimates as estimates.
  • Understand: Did you ask why the date or scope matters, instead of guessing?
  • Negotiate: Does each option say what the other person gets and what it costs?
  • Document: Who gets the written summary, and by when?

Questions Reflacto asks

BOUND is Reflacto's own mnemonic, not a published model. Three questions follow the expectation-management practice it is based on: understand the need behind the expectation, negotiate a compromise, and record the agreement. Reflacto added the other two: a baseline of commitments and capacity, and evidence kept separate from assumptions.

Expectation management

Reset a deadline, scope, or demand that doesn't fit the capacity you have.

  1. 1B - Baseline: What is the realistic situation based on facts, constraints, and what I know right now?Added by Reflacto
  2. 2O - Objectivity: What evidence or reasoning can I use to ground this discussion in reality rather than assumptions?Added by Reflacto
  3. 3U - Understand: What underlying needs, concerns, or pressures might be shaping this stakeholder's expectations?Expectation management practice
  4. 4N - Negotiate: How can I frame balanced options or trade-offs that lead to a constructive decision?Expectation management practice
  5. 5D - Document: How will I capture and share what we've agreed on so it stays clear and aligned over time?Expectation management practice

After the last question, Reflacto shows a plan for resetting the expectation with concrete next steps.

Questions about using BOUND

Before the conversation

How do I push back on a deadline I can't meet?

Raise it early, before the date is announced further. Show the evidence, ask what the date is for, and offer options across scope, timing, or resources.

You could say
“The full version needs until 20 October. What exactly has to work on 16 September?”

The later you raise it, the fewer options are left. Record whatever you agree. Example: a deadline that doesn't fit

What if I don't have hard numbers?

Use what you have, such as past projects, the team's estimates or ticket data, and say which parts are estimates.

You could say
“This is our team's estimate, and it has been within 10 percent over the last six sprints.”

An honest estimate is more useful than a precise-sounding guess. If the gap is big, offer to measure it first, for example by tracking requests for two weeks.

Saying no

How do I say no at work without damaging the relationship?

Don't reject the need. Reject the combination of scope, deadline, and capacity, then offer workable alternatives.

You could say
“The demo matters, so let's make sure it works. The full dashboard can't make it, but the three key metrics can.”

People accept a limit more easily when they hear that you understood why they asked. Blanket answers and real choices side by side

What if the stakeholder rejects every option?

Ask what an acceptable option would need to include, and check whether that is possible at all.

You could say
“Which part of the request can't move: the date, the scope, or the quality?”

If nothing can move and the capacity isn't there, the decision belongs to whoever owns the priorities. Say so, and bring both options to that person.

Authority and limits

What if the expectation comes from senior leadership?

Treat it as prioritization. Ask what the new request displaces and show the consequences to the person who owns that trade-off.

You could say
“If this comes first, the billing release moves to November. Is that the trade-off you want?”

You don't have to decide the priority yourself. Your job is to make the cost of each choice visible.

When is BOUND the wrong tool?

When the issue is safety, ethics, legal duties or a contract, use formal escalation instead of negotiating.

BOUND also can't give you authority you don't have. If you can't offer any option yourself, prepare the options and bring them to someone who can. Limitations

About the method

Why is documenting part of the method?

A short written summary of the decision, open points, owners, and dates prevents misunderstandings and later scope disputes.

You could say
“As agreed: pilot by 12 September, full version on 20 October, scope changes go through Maria.”

Send it the same day, while everyone still remembers the conversation. Copy the template

Is BOUND an established framework?

No. BOUND is Reflacto's own mnemonic, built on common practice in project and expectation management.

The sources support the underlying practices, not the name BOUND. Three of the five questions follow that practice; Reflacto added the other two. Origin and sources

Origin and Reflacto's adaptation

BOUND is Reflacto’s own mnemonic, not an adaptation of one named method. The sources support its underlying practices, not the name BOUND.

What Reflacto changed

From expectation management practice
From expectation management practice: understanding the need behind an expectation, negotiating a compromise both sides can accept, and recording the agreement.
Added by Reflacto
Reflacto adds a baseline of commitments and capacity, and evidence kept separate from assumptions, before any option is offered.

See every question Reflacto asks

Primary sources and further reading

Editorially reviewed by Daniel Schmeiß

Last substantive review: September 29, 2026

Related reflection methods

Compare another method that approaches a similar situation from a different angle.

Compare all methods