Framing is not administrative overhead you get through before the real work starts. It is the only window where changing your mind costs a conversation rather than rework, renegotiation and a slipped date. What follows is what a scoping stage has to produce — six answers, not a document.
1. An objective someone can disagree with
"Improve the customer experience" is not an objective. Nobody can disagree with it, which means nobody has agreed to anything.
A usable objective states what will be true at the end that is not true now, in terms someone could contest. If two stakeholders read it and picture different outcomes, it is not finished.
2. A deliverable list — and its exclusions
This is the core output. A work breakdown structure decomposes the objective into deliverables and work packages, and the 100% rule forces you to check coverage rather than assume it.
The part most teams skip is the exclusions. For each significant deliverable, write what it does not include. Almost every scope dispute later in the project is an argument about something one person assumed was in and another assumed was out. Writing exclusions costs an hour and settles the argument before it happens.
3. The dependencies, including the ones you inherit
Ask each contributor the inbound question — what do you need, from whom, by when, before you can start? — rather than only the outbound one. That single reversal surfaces most cross-team and external constraints in a single session.
Model the answers in a dependency network rather than a list. A list cannot hold a constraint, which is why dependencies stay invisible until they block something.
4. Risks stated as decisions, not as a register
Risks do not appear mid-project by surprise. They were nearly always present at the start and simply unformulated.
Framing is the moment where uncertainty can still be discussed freely: technical, organisational, human, external. The point is not to eliminate risk — it is to know what you are committing to. A risk with no named owner and no decision attached is a note, not a control.
5. The stakeholders who can actually block you
A project is rarely delivered by one team. Clients, operational teams, subject-matter experts, suppliers, decision-makers: framing identifies who must be involved, when, and at what level of authority.
The useful test is not "who is interested?" but "who can stop this?". Anyone in the second group who is not in your plan is a dependency you have not modelled.
6. A date derived from the structure, not announced before it
This is the output that everything else exists to make possible.
Once the deliverables and dependencies are known, the schedule is a computation, not a negotiation: the longest chain through the network sets the minimum duration. Announce a date before that, and you have committed to a number that the structure may not support — which you will discover at the worst possible moment.
How long framing should take
There is no universal answer, and any percentage rule you read is invented. The practical test is simpler: framing is finished when the contributors agree on what will be delivered and in what order. If they still disagree, more scheduling will not help.
The common failure is not spending too little time on framing. It is spending time on the wrong artefact — producing a long document nobody will reopen instead of six answers everyone can act on.
