A study published on July 23, 2026, offers a useful perspective for SMEs running digital projects without an established IT department. Based on six small service firms, the researchers found that technology resources and company culture do not create digital readiness on their own: an organisation also needs the ability to manage projects. This study on digital readiness in small firms is not a survey of French SMEs, but it highlights a crucial distinction: operating without a CIO does not remove the need to perform the project leadership function.
The promise everyone hears: the tool and vendor will run the project
The argument sounds reasonable. A SaaS ERP or CRM should be easier to deploy than a legacy on-premises system. A project management platform will centralise tasks, deadlines and documents. The implementation partner will provide the method, while a finance, operations or sales manager coordinates internal requests alongside their normal duties.
Under this model, the SME supposedly needs neither a CIO nor a dedicated project manager. Management only has to select a reputable solution, ask department heads to attend workshops and monitor progress in a shared dashboard.
This promise confuses three separate functions:
- the tool, which stores and displays information;
- the vendor, which designs, configures or deploys the purchased solution;
- client-side leadership, which sets priorities, assesses business value and accepts or rejects deliverables.
The first two functions can be outsourced. The third remains the company’s responsibility, even when its day-to-day execution is entrusted to an external project director.
What is true: an SME does not always need a permanent CIO
An IT project does not automatically justify recruiting a full-time Chief Information Officer. An SME can deploy a CRM, replace an ERP, move an application to the cloud or automate a process without immediately creating a new internal department.
Collaborative tools also provide genuine value. They make pending tasks, decisions, defects and responsibilities visible. An iterative method allows users to review working elements before the end of the project rather than discovering the completed solution just before launch.
The implementation partner brings expertise that the SME does not need to rebuild for every technology. It understands the product, configuration constraints and available interfaces. It can recommend a realistic architecture and flag requests that require custom development.
The correct conclusion is not that every SME needs a permanent CIO. It is that the project requires a leadership function proportionate to its scope. Depending on the number of digital initiatives involved, this function can be temporary or form part of a shared CIO arrangement for an SME.
What is false, or only true under specific conditions
A dashboard cannot make decisions
A platform can show that a task is blocked. It cannot decide whether the sales department should abandon a feature, whether funding should be redirected to data migration or whether deployment should be postponed because acceptance testing is incomplete.
Every project therefore needs a sponsor: a senior manager with the authority to decide on budget, scope and priorities. A project lead organises delivery, while a business owner verifies that the solution supports real operations. The Project Management Institute assigns the sponsor responsibilities including clarifying objectives, defining success criteria, approving deliverables and making go or no-go decisions in its guidance on project sponsorship.
The vendor cannot arbitrate on behalf of the client
An implementation partner is responsible for the quality of its work, but it is not neutral in every decision. Its contract, available skills and commercial model naturally influence its recommendations.
The vendor can explain that a requested feature falls outside the standard product. It cannot determine whether that feature is essential to the company’s business model. It can propose an interface between two applications, but the SME must decide which data should move, which system is authoritative and who handles errors. These questions become particularly important when connecting a CRM to an ERP.
Agile delivery does not remove scope or acceptance testing
Working iteratively does not mean starting without a target, adding requests continuously or signing off simply because the budget has been consumed. The official Scrum Guide defines cycles of no more than one month, but it also requires a product goal, accountability for value and an explicit definition of completed work.
Agile delivery therefore works only when a business decision-maker is available, priorities are ordered and every review produces a decision. Otherwise, it becomes a sequence of meetings that documents delays without resolving them.
SaaS does not eliminate technical choices
Even when the vendor operates the infrastructure, the SME must still address access rights, data quality, integrations, test environments, exit arrangements and documentation. It must know who controls the administrator accounts and how its data can be retrieved in a usable format.
Cloud services simplify some technical operations. They do not remove the client’s accountability or the dependency created by poorly documented configuration.
What proceeding without preparation really costs
Consider an illustrative scenario: an SME asks an implementation partner to deploy its CRM. Sales wants fast data entry, finance requires additional controls and customer service wants to retain its existing categories. No business owner has been authorised to settle the disagreements.
The vendor configures requests as they emerge during workshops. During acceptance testing, management discovers that sales indicators are not calculated as expected. Some corrections are treated as new requirements because the original rules were never documented. The planned launch is approaching, but no one knows who can formally accept the remaining gaps.
The cost is not limited to an additional invoice:
| Leadership gap | Practical consequence |
|---|---|
| No identified decision owner | Vendor waiting time, workarounds and conflicting instructions |
| Implicit business scope | Reconfiguration and disputes over what the contract included |
| Testing prepared at the end | Defects discovered when design choices are costly to change |
| Documentation controlled by the vendor | Dependency for every future change or data export |
| Integrations managed separately | Duplicate records, synchronisation errors and unclear ownership |
| Launch driven by the calendar | Users forced to operate with uncontrolled exceptions |
These issues also create technical debt: temporary solutions become permanent, exceptions accumulate and future changes require teams to reconstruct decisions that were never recorded.
The reasonable way to proceed
1. Give the sponsor and project lead an explicit mandate
Senior management appoints a sponsor with authority over funding and priorities, followed by a project lead responsible for daily organisation. Their mandate runs from initial framing through post-launch stabilisation. The required deliverable is a concise decision charter stating who approves scope, expenditure, change requests and production launch.
2. Protect a genuine framing phase
The project lead brings together department managers, representative users and the vendor to document the problem, affected processes, data, interfaces, regulatory constraints and acceptance criteria. As a methodological benchmark, beta.gouv.fr allocates six to nine weeks to validating a need in its white paper on designing digital services. An SME can adapt this duration to the scope but should not remove the validation work. The deliverable is a framing pack containing the selected scope, exclusions, responsibilities, risks and acceptance plan.
3. Use cycles that end with a decision
The project lead divides delivery into cycles of no more than one month, following the benchmark established by the Scrum Guide. At the end of each cycle, the business owner reviews a demonstration or testable deliverable and decides whether to accept it, request a correction or change its priority. The resulting deliverables are an updated work list, a decision log and a clear view of what is genuinely complete.
4. Start acceptance testing during framing
Representative users write scenarios based on real operations: creating a customer, changing an order, importing data, checking permissions or handling an integration error. The project lead maintains the test pack throughout delivery, while the Data Protection Officer is involved from the design stage whenever personal data is processed.
The CNIL states that data protection and testing should be considered throughout the project lifecycle in its guide on developing in compliance with the GDPR. This approach also complements our guide to GDPR compliance in automated processes.
5. Plan the exit before signing the entry contract
Before contract signature and at every major milestone, the project lead verifies data export methods, administrator access, ownership of custom developments, interface documentation and transfer conditions for a future vendor. The deliverable is an updated exit pack containing exportable files, the data dictionary, operating procedures and the list of custom components.
On Monday morning, do not ask only whether the project is on schedule. Ask who can make decisions, which document defines the scope, which scenarios will be used for acceptance and how the company will retain control of the solution.
Our position at D1 Consulting
An SME can run an IT project without an internal CIO. It cannot run one sustainably without business ownership, decision-making authority and a control method independent of the vendor.
Our IT Project Management service is not designed to add another layer of meetings. We frame the requirement, establish responsibilities, challenge technical proposals, monitor decisions, prepare acceptance testing and secure production launch. Management retains strategic authority; we provide the information and deliverables required to exercise it before unresolved choices become expensive.
👉 Book a free thirty-minute diagnostic to identify the missing responsibilities, decisions and deliverables currently putting your IT project at risk.
