Launching an IT project without scoping is like starting a construction site without a blueprint. Everyone is motivated on the first day. The problems arise in the third month, when the foundations are missing.
Yet, the majority of SMEs start their IT projects without formal scoping. Not out of negligence, but because "project scoping" is associated with weeks of meetings and incomprehensible documents. This isn't true: solid scoping can be done in three well-run meetings.
Scoping is the transformation of a vague need into a concrete project. It is the moment when you decide what the project will do, and more importantly, what it will not do.
Without this step, two things are guaranteed to happen. First, each stakeholder starts with their own version of the project in mind; these discrepancies only surface once the project has launched, at the worst possible time. Second, scope creep occurs: without formalized limits, every meeting brings its share of new requests. The project expands, deadlines slip, and the budget explodes.
Duration: 1.5 hours — Participants: management + business leads
The first meeting is not a solution meeting; it is a discovery meeting. The goal: establish a shared context (where the need comes from, what is no longer working, what the real stakes are). "We want a new CRM" can hide dozens of realities: unreliable data, poorly used tools, training issues, or genuine functional limitations.
What we need to get out of it: a one-page context sheet, objectives in three points maximum, the people involved, and an initial order-of-magnitude estimate. A written summary sent within 24 hours. This is non-negotiable.
Duration: 2 hours — Participants: operational business leads
This is the most technical meeting, and the one most often forgotten. The project manager will have prepared a list of structured questions about current processes: data flow, problematic manual steps, volumes, exceptions, and edge cases.
The workshop is used to formalize what the future system must do, starting from reality rather than a sales presentation. What comes out of it: a list of prioritized use cases, a map of required integrations, and the first scope exclusions formalized in writing.
Duration: 1 hour — Participants: management + decision-making sponsor
The shortest and most important one. It presents the synthesis of the first two: scope, selected and excluded use cases, macro schedule, validation milestones, and acceptance criteria. Everything is submitted for formal validation before any contract is signed with a provider.
After this meeting, the scope is locked. Any changes require a priced amendment. A project whose scope is not formally validated before launch has no scope: it has an intention.
Following the scoping phase, Logexia delivers a ten-page document covering: objectives and success metrics, scope inclusions and explicit exclusions, stakeholders and roles, a high-level timeline with milestones, technical prerequisites, and the change management process for scope adjustments. This document serves as the foundational agreement between the client, Logexia, and the technical provider.
"Are three meetings really enough?" For a standard SME project (ERP deployment, business tool migration, partial IS overhaul), yes. Three well-prepared meetings, with the right people and rigorous minutes, produce a solid scope in two to three weeks.
The weeks invested in proper scoping are always recouped over the course of the project. Projects that go off track rarely do so because of a lack of technical skills: they go off track because the right questions weren't asked at the right time. And if you're unsure about the right support format to lead it, run the 2-minute simulation.
