When a new project begins, the first instinct is often to turn to the schedule. We start defining tasks, assigning deadlines, and organizing the various stages.
However, before determining when the work will be completed, we must first understand why the project exists, what it is intended to produce, and what resources will be available to carry it out.
Misunderstood objectives, an unclear scope, conflicting expectations, or unavailable resources: many of the difficulties encountered during a project stem from an inadequately prepared kickoff phase.
To explore this topic further, we brought together four project managers with diverse backgrounds for a webinar focused on project kickoff :
Despite the diversity of their environments, they all share the same conviction: the time spent on scoping is one of the best investments throughout the entire project lifecycle.
Would you like to revisit the entire discussion? The full recording of the webinar is also available on YouTube right here: Comment bien démarrer un projet ?
Above all, a strong start brings clarity and peace of mind.
Within an organization, information is often spread across multiple stakeholders. Business units drive the need, experts handle the technical constraints, senior leadership sets the objectives, and managers know the teams’ actual availability.
The kickoff phase must therefore clearly answer three questions:
These discussions also help verify that the conditions for success are in place. Starting without answering these questions is like moving forward with uncertainties that could weigh on the entire project going forward.
The kickoff meeting is not the true starting point for the project. A significant portion of the work must be completed beforehand.
At INSP, proposal sponsors complete a needs assessment form. This form helps clarify the context, objectives, and initial information needed to study the topic.
Proposals are then reviewed to determine whether they are sufficiently clear, admissible, and consistent with the organization’s priorities. Depending on their level of urgency, they are submitted to various decision-making bodies.
Only after approval does a request officially become a project, with a kickoff meeting and appropriate monitoring procedures.
This distinction between an idea, a request, and an officially authorized project prevents teams from being mobilized on topics that have never been the subject of a formal decision.
One of the main risks at the outset is assuming that all stakeholders naturally share the same vision.
Jérémy Ganis specifically mentioned a project in which management was seeking productivity gains, while the IT department wanted to implement a secure and maintainable solution. Users wanted to keep their habits, and the sponsor was focused on staying within budget.
All of these expectations are legitimate, but they are not automatically aligned.
The project manager’s role is therefore to bring these different expectations to light and build a shared understanding of the objectives, deliverables, and success criteria.
Insufficient scope definition can lead to very real consequences.
At Axians, Vincent Longuépée sometimes observes that an expert begins work thinking they understand the assignment, even though they haven’t been sufficiently briefed by the project manager, the sales representative, or the client.
Even if the person is competent, they may head in the wrong direction. This leads to rework, wasted time, delays, and sometimes a workload that exceeds the original estimate.
A poorly defined scope can also lead to projects that never end. New requests are gradually added, objectives evolve, and it becomes difficult to know whether the initial commitments were actually met.
Olivier Crélerot also shared several real-world examples in which missing technical information or a late strategic change had led to a significant amount of rework.
These situations show that not all missing information is equally important. Some can be treated as assumptions. Others are so fundamental that it may be better to delay the launch.
Before officially launching a project, it is necessary to obtain a clear decision.
This “GO” should not be merely an agreement in principle. It must be based on a sufficiently well-defined framework: objectives, deliverables, scope, key milestones, resources, costs, and major constraints.
This does not mean you have to wait until you know everything perfectly. A project always involves some degree of uncertainty.
The challenge is to distinguish between essential information and details that can be clarified later. Elements that are still uncertain can be recorded as assumptions or risks, provided they are clearly identified.
The project charter is a particularly useful tool for formalizing the project’s foundations.
Depending on the organization, it may also be called a project brief or scope statement. Its purpose remains the same: to enable anyone who consults it to quickly understand the project.
In particular, it may specify:
Vincent Longuépée uses the project charter available in Gouti to structure his kickoff meetings. Once completed and approved, it becomes a common reference for the team and the client.
A schedule remains essential, but it is not necessary to detail every task from day one.
At the outset, a high-level schedule may suffice to outline the major phases, key milestones, mandatory deadlines, and review periods.
It can then be refined gradually as more precise information becomes available.
A schedule cannot be realistic if the people responsible for carrying out the work are not available.
In multi-project organizations, the same experts are often called upon by multiple teams. When workloads are consolidated, certain individuals may find themselves stretched well beyond their actual capacity.
According to Olivier Crélerot, the project manager must therefore obtain a clear commitment from department heads regarding employee availability.
As he illustrated during the webinar, a Formula 1 car, no matter how high-performing it may be, will not leave the pit if it lacks fuel.
After the scoping phase, the kickoff meeting marks the official start of the project.
According to Jérémy Ganis, it serves three main purposes.
The first is to formalize the commitment. The objectives, scope, timeline, and responsibilities are presented to all stakeholders.
The second is to clear up any remaining misunderstandings and ensure that everyone shares the same understanding of the project.
Finally, the meeting should create a space for discussion. It should not be limited to simply going through a presentation. Participants should be able to ask questions, point out constraints, and identify risks.
Olivier Crélerot compares this meeting to a play, where much of the work is done behind the scenes.
Major disagreements must therefore have been identified and addressed beforehand. The kickoff meeting then serves to formalize the decisions made and avoid a mere “weak consensus,” in which everyone appears to agree without truly committing.
The kickoff meeting should remain focused on the overall scope of the project.
It may include some technical discussions to clarify ambiguities, but it should not turn into a design workshop.
Its purpose is to ensure that participants are aligned on the objectives, scope, key deliverables, roles, resources, high-level schedule, risks, and next steps.
Detailed technical issues can be addressed during dedicated meetings.
There is no universal timeframe for preparing a project.
In some cases, a few hours may be enough. In others, particularly when the scope of the project has yet to be define, the preliminary planning phase can last several weeks or months.
The key is to accept that this preparation represents a real workload.
As Jérémy Ganis put it, this time is never wasted. On the contrary, it is one of the best investments throughout the entire life of the project.
The speakers also emphasized three other points: avoiding superficial agreements, securing resources, and relying on a methodology that is well-established and supported by management.
Getting a project off to a good start doesn’t mean eliminating all uncertainties. It’s about creating a framework that’s clear enough so that everyone knows why the project is being launched, what it’s supposed to produce, and what role they’re supposed to play.
The effort put into the initial phase will always cost less than the delays, rework, and disagreements caused by a project launched too quickly.
Would you like to see the examples and read all the tips shared by the speakers? Watch the webinar replay right here: Comment bien démarrer un projet ?
Gouti's Blog