How to Scope and Qualify Before Committing
Run this when someone asks you to take on work, so the yes you give is one you can keep. Reliability is set before you agree, not at delivery: qualify the request, weigh it against your load, and reshape it when it does not fit.
Developing
Start here. Build the foundation.- 1
When someone asks you to take work on, say back what you heard and name the outcome that counts as finished in one sentence, and if the ask came verbally, post that restatement where the work lives so they can correct it in writing. You are aligned when they confirm your version rather than amending it.
- 2
Before you answer, open your list of current commitments and count what lands in the same window as the new ask; if you need time, say when you will respond and respond by then. Acceptance should reflect real capacity, not the difficulty of declining in the moment.
Proficient
Build consistency and rhythm.- 3
When a request carries unknowns, list the people, inputs, and approvals delivery depends on in the same reply as your yes, and name the risk behind each. A commitment that carries its assumptions in writing turns a failed dependency into a changed plan, not a failed execution.
- 4
When the request exceeds what you can deliver, reply with a smaller scope, a later date, or a staged plan, and record the agreed version, not the original ask. The requester should leave with something workable instead of a yes that will break.
Mastered
Operate at the highest level.- 5
Review a recent yes with someone you work with: have them restate the ask, check their load, and draft the counter-offer they could have made. Stop prompting once they reshape oversized asks on their own, so requests get qualified without you in the room.
Common Pitfalls
Avoid the common failure modes.- Saying yes in the meeting and regretting it by the afternoon. Go back the same day with the counter-offer you should have made; a same-day renegotiation costs far less than a missed date.
- Accepting a request where the scope and the date are both fixed. Name what you will set aside to fit the new work, and let the requester choose the trade.
- Letting a known dependency fail and then taking the blame for execution. Write the dependencies into the commitment; a failed one that was never named is the step you skipped.