On 7 August 2026, France’s Interministerial Digital Directorate presented a redesign of its method for assessing major government digital projects. Although it does not apply directly to private companies, the new approach places greater emphasis on delivered value, usage and adaptability rather than merely tracking budget and schedule. This is also the decision facing a business leader preparing an ERP, CRM or business application project: should everything be specified upfront, should an independent party frame the requirements, or should the company proceed with an evolving backlog? DINUM’s presentation of the MAREVA Produit method illustrates this shift towards impact-based governance.
An IT requirements document remains useful, but its format must match the project’s level of uncertainty. A vague document prevents meaningful bid comparison; an excessively rigid one turns every discovery into a paid change request.
The choice you actually face
The decision is not whether to write requirements. It is who should produce them, how detailed they should be and how much room for change must remain.
The document should allow management to answer practical questions:
- Which business outcome must the project deliver?
- Which activities and entities are within scope?
- Which user scenarios will actually be delivered?
- Which data must be migrated, retained or deleted?
- Which interfaces must work with existing systems?
- Who will approve the deliverables, using which tests?
- What can the company recover if it changes software or supplier?
France Num explains that a requirements document helps clarify objectives, compare proposals and establish a shared reference with the supplier. Although its guide to building a requirements document focuses on website projects, these principles also apply to broader IT initiatives.
Before downloading a template, appoint a sponsor authorised to arbitrate scope and budget, together with a business owner able to validate operating rules. If neither role has a clear mandate, the immediate problem is governance rather than documentation, as discussed in our article on running an IT project without an IT director.
The available options
Drafting the document internally
The business owner consolidates user requests, describes the required capabilities and prepares the material sent to potential suppliers.
This keeps ownership of the requirements inside the company. It is appropriate when the process is stable, documented and understood by someone who knows its users, exceptions and data.
The deliverable should go beyond a list of ideas. It must include scope, user scenarios, priorities, constraints, acceptance criteria and internal responsibilities.
Using an independent business analyst or project director
An independent project management consultant organises decisions, formalises requirements and prepares a consultation pack that several integrators can use.
Independence matters: the person drafting the requirements should not benefit from imposing a particular product. This option suits cross-functional projects, data migrations, ERP or CRM deployments and organisations without an available IT leader.
The consultant does not replace business teams. Their role is to convert business decisions into auditable deliverables: process flows, requirement sheets, data matrices, integration requirements, a supplier scoring framework and an acceptance strategy.
A discovery phase led by a shortlisted supplier
The company appoints an integrator to conduct a paid discovery phase before committing to the full implementation.
This makes it possible to compare requirements with the actual capabilities of a chosen software family. It is suitable when the technology ecosystem is already known but the gap between standard configuration and company-specific processes remains unclear.
The discovery agreement should state that the deliverables belong to the client, can be reused by another supplier and do not automatically trigger the next contract.
A functional backlog and iterative delivery
Instead of freezing every feature, the company defines a product goal, non-negotiable requirements and an ordered list of needs. Priority items are detailed as the project progresses.
This is appropriate when users need to test a future workflow before they can express their requirements precisely. Each cycle must still deliver something usable and reviewable. Within Scrum, the official Scrum Guide limits a Sprint to one month or less, allowing regular inspection and adaptation.
A backlog therefore does not remove the need for a target budget, security requirements or an initial scope. It replaces premature detail, not accountability.
The criteria that really matter
| Option | Framing cost | Time before supplier consultation | Vendor dependency | Internal skills required | Reversibility |
|---|---|---|---|---|---|
| Internal drafting | Low external spend, high internal effort | Short if requirements are documented | Initially low | Strong business knowledge and writing skills | Good if documents are structured and retained |
| Independent consultant | Medium | Medium | Low | Availability of decision-makers and business owners | High because several suppliers can use the same pack |
| Supplier-led discovery | Medium, sometimes credited against implementation | Short to medium | High if deliverables depend on the supplier’s method | Ability to challenge technical proposals | Depends on contract terms and file formats |
| Iterative backlog | Progressive | Very short before the first cycle | Depends on architecture and delivery team | Available business owner able to prioritise and approve | Good if code, data and documentation are transferable |
Do not decide solely on the visible framing cost. Include internal effort, change requests, test licences, data migration, post-go-live support and the retirement of the former system.
When to choose each option
Choose internal drafting when the project covers a stable process, has an identified owner and involves limited technical dependencies. Ask the business owner to describe each scenario through the actor, action, data, expected outcome and acceptance test. Management should arbitrate priorities before the document reaches suppliers.
Choose an independent consultant when several departments must agree, when data must be migrated or when an ERP and CRM need to exchange information. The interface matrix must identify reference data, the system of record, exchange rules and error handling. Our guide to connecting CRM and ERP systems explains the decisions that should precede supplier consultation.
Choose supplier-led discovery when the software ecosystem has already been selected and the main question is what can be configured as standard versus what requires custom development. Purchase discovery separately, with a capped price, defined deliverables and a formal go-or-stop decision.
Choose an iterative backlog when workflows are likely to evolve after user feedback or when a prototype is needed to settle key choices. Define non-negotiable requirements upfront: access rights, data retention, critical interfaces, minimum performance, export capabilities and reversibility.
For an ERP or CRM deployment, a hybrid approach is often the most robust: an independently framed baseline for consultation and contractual commitments, followed by a backlog for progressively detailing configuration and screens. If the company lacks someone to maintain these decisions, consider whether a part-time IT director is required before launch.
The hidden traps in each option
The internal drafting trap is reproducing the current organisation without separating essential rules from historical habits. Require each request to have an owner, a business justification and an acceptance test. A requirement that cannot be tested will remain open to interpretation.
The independent consultant trap is producing a large document that nobody inside the company owns. Every section should be approved by a named decision-maker, and every requirement should be connected to a process, risk or objective. The consultant structures decisions but should not make them alone.
The supplier-led discovery trap is premature dependency. Check delivery formats, usage rights, assumptions and the company’s ability to consult a competitor. Proposals should distinguish standard capabilities, configuration, custom development, integrations and licences.
The backlog trap is using the word “agile” to postpone decisions about budget, quality or scope. Each cycle should end with a demonstration, completed tests and a decision on what happens next. Work that has started but cannot be tested is not a delivered result.
No option should relegate GDPR and security to a generic appendix. When personal data is involved, requirements should cover purposes, permissions, retention, incidents, subprocessors and data return. CNIL’s guidance on managing processors calls for contracts to define responsibilities, security measures and data return or deletion conditions. ANSSI’s guide to IT outsourcing also addresses transfer, operation and reversibility requirements.
How we work at D1 Consulting
Our IT Project Management service converts management and business decisions into a package that suppliers can price, the company can govern and users can test.
Our method produces:
- An executive decision note defining the expected outcome, sponsor, project boundaries and unresolved choices.
- A functional requirements package based on business scenarios, exceptions, roles and necessary data without prematurely imposing a technology.
- An interface and data matrix identifying source systems, ownership, migration requirements and controls.
- A common supplier response framework separating implementation, licences, maintenance, options and assumptions.
- An acceptance strategy prepared before contracting, with blocking tests, required evidence and approval responsibilities.
- A governance model defining who approves changes, how they are priced and when they enter the project scope.
We then adapt the documentation model: a stable requirements document for a predictable project, a governed backlog for an evolving product, or a combination for an ERP, CRM or custom business application. The objective is not to predict everything, but to make every commitment understandable, comparable and testable.
👉 Book a free 30-minute diagnostic to choose your framing approach and identify the deliverables you need before consulting suppliers.
