How do you frame your project? 6 steps, an example of a scoping note and tools to help you

By Ainhoa Carpio-Talleux

Published: 1 August 2025

Project framing is the key phase that sets the course and benchmarks to be followed before the project is planned and launched.

Good framing enables you to set coherent objectives and define deadlines and budgets to avoid any setbacks.

So it's a stage in effective project management that shouldn't be skipped.

See all software Project Management

Why should a project be scoped?

The scoping phase is used to define the scope of the project and comes just after the preliminary project phase, which generally includes :

needs analysis
opportunity study
feasibility study (using the Proof of Concept method, for example).

At the time of the project scoping, carried out in the form of one or more interviews, the initial information gathered helps to :

structure the project
recall the context, challenges and objectives,
identify the human and technical resources required
define a budget and deadlines.

This key phase enables the customer and the project owner, or project manager, to discuss and communicate instructions to the project team, so that all the stakeholders have a clear understanding and visibility of the expectations and resources to be mobilised.

At the end of these meetings, a scoping memo is drawn up, which serves as a kind of reference for the project, enabling key information to be shared internally. It is also known as a :

mission statement
briefing note
launch note
project charter.

How do you write a scoping memo? The 6 key steps

Before rushing headlong into a project, take a deep breath... and write a scoping memo. This structuring document lays a solid foundation. Here are the steps you need to follow to ensure your project scope is just right 🧅.

Stage 1: present the project (in two clear words)

Explain where the need comes from :

is it a customer request?
Is it an internal idea?
Is it a regulatory emergency?

Then briefly describe the context: the department concerned, the current problem, the expected impact.
You need to make your readers (sponsors, team, management) want to get involved.

Step 2: Define the project objectives

Don't use vague formulas like "improve productivity". Be surgical.
A web application delivered? An HR process automated?

Also specify the success indicators: +20% of leads? -15% reduction in processing time?

The project objective is the compass that will guide everything that follows.

📌 Spoiler: without clear objectives, stakeholders will quickly pull in all directions.

Step 3: detail the scope... and what's outside the scope

The scope is often vague at first. This is a bad idea. Here, we define :

the functions covered
the modules delivered
the users concerned.

But you also specify what won't be done. 👉 Example: customer support will not be included in this first version.
This is THE section that avoids additional requests ("just one more little feature?") along the way.

Step 4: List the stakeholders and roles

Identify all the people involved in the project scope and the following phases :

who is in charge (often the project manager)?
who validates the deliverables?
who provides the information?
who can block progress (and how do you convince them)?

By naming the stakeholders, you can anticipate friction and establish clear communication from the outset.

Step 5: Plan the main stages

Set out the main phases of the project:

scoping
design
testing
deployment,
feedback.

Set visible and achievable milestones, with dates. It's not set in stone, but it sets the pace. This reassures sponsors and avoids the tunnel effect.

Step 6: Anticipate the risks and the resources required

List the areas of uncertainty (technical dependency, availability of resources, project team workload, etc.).
Propose a realistic plan B for each sensitive point.
Also include the necessary resources: budget, project management tools , external skills.

It's better to set limits now than to discover them when it's time to pay the bill.

Download a sample scoping memo

For inspiration, Appvizer has provided a sample scoping memo that you can download in .doc or .pdf format.

Methods and tools for framing a project

QQOQCP method

The QQOQCP method can be used here, to answer the main project scoping questions:

⃞ Who:
- the client,
- the project manager
- the project team
- all stakeholders, such as any subcontractors,
- end users;

⃞ What:
- the purpose of the project,
- its perimeter, or scope, i.e. its content, the processes to be followed, its division into different sub-projects if applicable,
- functional specifications (web project);

⃞ Where:
- the location of the project, if it's on the web, which page, front or back?
- the location of the next control meetings according to the various milestones identified;

⃞ When:
- The start and end of the project,
- deadlines,
- the various major stages;

⃞ How:
- the methods to be used,
- the human, technical and budgetary resources to be mobilised,
- the opportunities to be seized,
- the constraints and potential risks to be avoided ;

⃞ Why:
- the context,
- the objectives,
- the needs expressed,
- expected benefits.

☝️ In project management, it is preferable to state the what and the why at the very beginning of the scope note.

In addition to the QQOQCP method for writing the scope document, other complementary techniques can be used to define its content, in particular the major stages, project resources and project deadlines.

The Product Breakdown Structure (PBS)

The Product Breakdown Structure, or PBS for short, is a compass for structuring your deliverables. The idea? Break the project down into concrete, visible, deliverable sub-products. We're not talking about tasks here, but tangible elements:

a specifications document
a validated mock-up
a user manual, etc.

The PBS resembles a family tree of expected results. Each branch represents a more precise version of the final product. And at the end of each branch: clear deliverables that can be shown, tested and delivered. In short, something concrete.

This is a formidable tool for clarifying the scope of the project. It avoids misunderstandings between the customer, the stakeholders and the project team. And because it focuses on the "what", it is the perfect complement to the WBS, which we'll look at next.

The Work Breakdown Structure (WBS)

While the PBS answers the question "what do we deliver?", the Work Breakdown Structure (WBS) tackles the question " how do we get there? Here, the project is broken down into tasks, activities and sub-stages. In short, concrete actions to be taken to achieve the objectives.

Each node represents :

a phase
a task
a logical sub-assembly.

We start with the main deliverable, then go into more detail until we reach an operational level: the level at which a person can take on the task and carry it out without any artistic fuzziness.

This breakdown makes it possible to :

better allocate resources
estimate the workload
identify dependencies between tasks.

A word of advice: linking the WBS to a schedule (such as a Gantt chart) and to the people responsible for it helps to align the whole project team.

The Organisation Breakdown Structure (OBS)

The Organisation Breakdown Structure, or OBS, is the organisational mirror image of the WBS. Here, the focus is no longer on tasks or deliverables, but on roles and responsibilities:

who does what in the project?
Who validates?
Who executes?
Who steers?

The OBS sets out the hierarchical structure of the project team. It enables the work in the WBS to be assigned to the right profiles, according to their skills or their place in the organisation. It is an invaluable ally in clarifying the decision-making chains... and avoiding the "ah, I thought it was you" in the middle of the scoping phase.

Cross-reference WBS and OBS to obtain the RACI matrix. An unbeatable tool for finding out :

who is responsible
who is involved,
who is consulted
who is informed at each stage of the project.

And no, OBS doesn't stand for "On Bricole en Silence" 😉

Macro-planning

The macro-planning is the helicopter view of the project. We don't go into detail yet, but we do mark out the major phases, key stages and milestones. The aim: to see at a glance where you're going... and when you should get there.

This simplified schedule is a formidable communication tool. It makes it easy for stakeholders to find their way around without getting bogged down in dates. It also helps the project manager anticipate bottlenecks and allocate resources over time.

📊 The format? It's up to you. Timeline, slimmed-down Gantt schedule, shared calendar... as long as the visibility is there, the medium doesn't matter.

The provisional project budget

It's often said that money can't buy happiness... but without budget, there can be no project. The provisional budget is an essential part of the project framework. It is used to estimate the financial resources required to successfully complete each phase.

Salaries, tools, external services, travel, equipment... Every item of expenditure needs to be anticipated. It's better to aim high than to run out of money halfway through.

A good budget is also a decision-making tool for the stakeholders. It enables them to validate (or not) the launch of the project. And to monitor any discrepancies between forecasts and reality, once the action has been launched.

🧠 A word of advice: accompany your budget with clear assumptions and a margin for unforeseen events. There is no such thing as zero risk.

Tools for scoping a project

Project management software supports you from scoping to drafting specifications, from planning to monitoring the project. They allow you to structure the scoping note, collaborate with the project team and keep a clear record of each stage. Here are 5 tools that deserve a place in your digital toolbox:

Notion is the champion of flexibility. You can create a collaborative scoping note, add checklists, deadlines and even reference documents. Its modular interface is ideal for documenting each phase of the scoping process, while maintaining a pleasant visual appearance.

ClickUp combines tasks, docs, schedules and time tracking. You can integrate your Product Breakdown Structure, generate a WBS, and assign roles from your Organisation Breakdown Structure. It's the tool that lets you go from scoping to execution without changing platforms.

Need a clear macro-plan to share with stakeholders? TeamGantt is just what you need. Its intuitive interface lets you build visual Gantt charts and associate tasks, milestones and responsibilities.

If your project involves a lot of technical documentation or procedures, Confluence is a great ally. Connected to Jira, it allows you to archive each version of the scope note, document decisions and keep track of the contributions of each stakeholder.

Asana is particularly useful for breaking down a project into tasks, setting deadlines and tracking the progress of each phase. It's the perfect tool for managing the transition from scoping to action, while maintaining fluid communication between all team members.

If your IT project requires more technical management, you can also explore Trello, monday.com or Microsoft Project. There's a tool for everyone, as long as it fits the story.

Good practice in project scoping

👉 Involve the right stakeholders from the outset

No effective scoping note without the right brains around the table. Identify the key stakeholders and consult them early. Their expectations, constraints and weak signals are invaluable in setting a realistic scope.

👉 Ask more questions than answers

You're not there to impress, you're there to understand. List the requirements, rephrase, dig deeper. Framing is first and foremost an investigation. And yes, you're entitled to ask the same question five times as long as it clarifies the project objective.

👉 Write it down in black and white... then reread it aloud

The scoping document is not just an internal document. It will be re-read, validated and shared. So be clear, structured and precise. Avoid unnecessary jargon. A good practice is to have it reread by someone who is not involved in the project. If that person understands, you've won.

👉 Anticipate holes in the plan

Not everything will be set in stone. There will be unforeseen circumstances. Prepare some room for manoeuvre (in budget, timeframe, resources). And formalise the risks at the outset, even if not everyone likes them. That's not being pessimistic, that's being professional.

👉 Don't work alone in your corner

Get people to proofread, challenge assumptions, organise a workshop if necessary. Framing is collective: the more it is shared, the more it will be respected once the project is launched.

And above all: resist the temptation to complete the framework "quickly". It's precisely when you think "everything is clear" that you miss the real weak signals.