Planning an IT project is the key to avoiding slippage (particularly in terms of budget, deadlines and quality). Follow these key steps to get off to a good start.

Solid planning doesn't mean “making a schedule”: it means align stakeholders, define what is delivered, organise work and master risks.

1. Define the project objectives

Objective

Clarify why we make the project, for whomand how we measure success.

Best practice

• Formulating objectives SMART : Specific, Measurable, Achievable, Realistic, Time-bound.
• Add KPIs and acceptance criteria from the outset (otherwise “finished” becomes subjective).
• Distinguish :
  • Business objectives (value) vs technical objectives (means)
  • Must-have vs Nice-to-have

Figures/benchmarks

• Limit yourself to 3 to 5 SMART objectives maximum: beyond that, prioritisation becomes diluted.
• Define 2 to 4 KPIs (too many KPIs = no management).

Example of a SMART objective

“Reduce the time it takes to process after-sales requests by 48 h to 24 h by 30/06, implementing a ticket portal and knowledge base, with a user satisfaction rate ≥ 4/5.”

Expected deliverables

• Background note (1-2 pages): context, SMART objectives, KPIs, scope, milestones.
• Definition of Done / acceptance criteria (even in V-cycle mode).

2. Identify stakeholders

Objective

Avoid bottlenecks: who decides, who validates, who executes, who is affected?

Best practice

• Mapping stakeholders: Sponsor / Owner / Users / IT / Security / Legal / Operations / Support / Suppliers.
• Use a RACI matrix for each key deliverable (specifications, tests, production launch, etc.).
• Anticipating change management : who loses what? who wins what?

Figures/benchmarks

• 1 sponsor clearly identified (and available): otherwise, arbitration is impossible.
• 1 decision = 1 decision-maker (otherwise infinite consensus).
• Visit at least 1 user representative by major profile (e.g. back office + front office).

Example of RACI (extract)

• R (Responsible): IT Project Manager
• A (Accountable) : Business sponsor
• C : CISO, DPO, Operations, Purchasing
• I Support, teams affected

Expected deliverables

• Stakeholder map (influence/impact)
• RACI + list of committees (roles, frequency, arbitration rules)

3. Drawing up specifications

Objective

Define what is included / excluded, requirements, constraints and validation criteria.

Best practice

• Recommended structure :
  1. Background & objectives
  2. Perimeter (IN/OUT)
  3. Functional requirements (user stories or specifications)
  4. Non-functional requirements (perf, security, SLA, accessibility)
  5. Constraints (IS, regulatory, budget, planning)
  6. Data & interfaces (APIs, flows, formats)
  7. Test & acceptance strategy
  8. Deployment and support
• Formalising assumptions and dependencies (often forgotten).
• Defining now how to manage the change request (otherwise scope creep).

Figures/benchmarks

• Aim for 10 to 25 functional requirements well written rather than 80 blurred.
• Add 5 to 10 non-functional requirements minimum (security, availability, backup, RTO/RPO, performance, audit, etc.).
• To reduce ambiguity: each requirement should be testable (recipe criteria).

Example

“The user can create a ticket by ≤ 2 minutes, with attachments up to 10 Mb, and receives a confirmation email in less than 60 seconds.”

Expected deliverables

• Requirements specification (or backlog) validated
• Perimeter management rules (change request process)

4. Plan resources and deadlines

Objective

Transforming need into executable plan Tasks, workloads, dependencies, milestones.

Best practice

• Cut into WBS (Work Breakdown Structure): batches → sub-batches → tasks.
• Estimate using simple methods :
  • 3 points Optimistic / Probable / Pessimistic
  • Poker schedule (Agile) or PERT (if you want to refine)
• Identify the critical path (tasks that move the final date).
• Make time for what is often forgotten: testing, acceptance, correction, documentation, support, deployment, run.

Useful figures

• Typical breakdowns (benchmarks) :
  • Dev/parameterisation : 40-60 %
  • Tests + correction : 20-35 %
  • Business recipe : 10-20 %
  • Deployment and change management : 10-20 %
• Plan a buffer :
  • Known project / low risk : 10 %
  • Multi-team project / dependencies : 15 %
  • Innovative/uncertain project : 20 %

Sample mini-planning

Ticket portal“ project - 8 weeks

• S1: framing + workshops (2-3 workshops of 2 h)
• S2-S4: build (sprints or batches)
• S5: system tests + corrections
• S6: business recipe (scenarios + PV)
• S7: preparation for deployment + training (sessions 1 h)
• S8: production start-up + hypercare (5 days)

Expected deliverables

• Planning (Gantt / roadmap / release plan)
• Workload plan (who does what, when)
• Milestones + passage criteria (Go/No-Go)

5. Assessing risks

Objective

Anticipate obstacles and avoid fire-fighter mode.

Best practice

• Hold a RAID log Risks, Assumptions, Issues, Dependencies.
• Using a simple matrix Probability (1-5) x Impact (1-5) = score (1-25).
• For each risk : prevention + plan B + owner + review date.

Figures/benchmarks

• On a standard project, the aim is to 10 to 20 risks identified with the framing (yes, that's normal).
• Risk review weekly as a team, monthly in committee.

Examples of risks and countermeasures

• Risk dependence on an unstable external PLC
  • Prevention: load tests + contractual SLA
  • Plan B: caching / downgraded mode
• Risk insufficient business availability for the recipe
  • Prevention: reserve your slots from the planning stage
  • Plan B: Recipe by “key users” + priority scenarios

Expected deliverables

• Risk register (score, person responsible, action plan)
• Continuity plan / gradual deployment if necessary

6. Establish regular monitoring

Objective

Keep control and detect early: «the earlier you see it, the less it costs».

Best practice

• Setting up a steering routine :
  • Weekly project update (30-45 min): progress, risks, decisions
  • Daily (15 min) if dedicated dev team (Agile)
  • Steering Committee (every 2-4 weeks): arbitration, budget, planning
• Monitor 4 simple indicators:
  • Progress (deliverables completed vs. planned)
  • Quality (defects, test success rate)
  • Timeframes (gaps and critical path)
  • Risks (total score, new risks, open issues)

Figures/benchmarks

• 1 report (CR) in ≤ 24 h after each committee meeting.
• A dashboard 1 page (not a novel): readable by a sponsor in 2 minutes.

Concrete example of a “1-page dashboard”.”

• Overall status: 🟢/🟠/🔴
• 3 highlights of the week
• 3 major risks + plans
• Decisions expected from the sponsor (with deadline)
• Next milestone + criteria

Expected deliverables

• Reports + action plan (who/what/when)
• Project dashboard
• Receipt report + Go/No-Go