Appointing a finance, sales or operations manager to lead an IT project sounds sensible. That person knows the company, its processes and its future users. The difficulty begins when project leadership is added to the existing job without removing operational duties or granting clear decision-making authority.
As explained in our article on managing an IT project without an internal IT department, the absence of a permanent CIO is not the main risk. The real risk is starting without effective client-side project leadership.
The promise everyone hears: your best operational manager can lead
The argument is initially convincing. A business manager understands operational rules, team habits, customer constraints and the exceptions that specifications rarely document in full. That manager should therefore be able to coordinate an ERP or CRM implementation.
The vendor or integrator also provides a project manager. This person schedules workshops, maintains a plan and reports progress. The internal manager would only need to answer questions, involve users and approve deliverables.
This arrangement appears to offer several benefits:
- no additional project management hire;
- decisions remain close to business operations;
- no extra intermediary between management and the supplier.
The promise is not unreasonable. It simply merges four separate functions: executive sponsor, business owner, client project manager and supplier project manager.
What is true: business ownership must remain internal
An ERP or CRM project cannot be delegated entirely to a supplier. Someone inside the company must explain how orders are approved, who may change a price, which data must be migrated and which exceptions remain acceptable.
The internal business owner provides decisions that an external consultant cannot legitimately make alone:
- the real priority between competing departments;
- the rules that must be retained or challenged;
- the compromises users can accept;
- the definition of a result that the company can operate.
The executive sponsor has a different role. The sponsor keeps the project aligned with its business purpose, secures resources and resolves decisions outside the project manager’s authority. The Association for Project Management definition of sponsorship clearly distinguishes this accountability from daily project management: the sponsor remains responsible for the continuing validity of the business case and the intended benefits.
The internal manager is therefore essential. That person may own the business process, represent users or act as a delegated sponsor. Business legitimacy, however, does not automatically create the availability, methods and authority required to challenge an integrator.
What is false, or only true under specific conditions
Business expertise is not the same as delivery leadership
A client project manager does more than schedule meetings. The role includes controlling scope, checking dependencies, preparing decisions, maintaining risks and preserving evidence of approvals. It also connects the supplier’s commercial commitments to deliverables that can actually be tested.
These activities quickly compete with the manager’s main job. When a key customer calls, a financial close approaches or an operational incident occurs, the project moves behind day-to-day operations. That choice may be rational in the moment, but it delays decisions and allows unresolved issues to accumulate.
The integrator’s project manager is not the client’s project manager
The supplier manages its own production: consultants, configuration, development, consumed budget and contractual schedule. The client must protect future operations, cross-department consistency, data quality and acceptance conditions.
When the same party proposes a solution, estimates the work and decides whether the outcome is acceptable, the project loses a useful level of challenge. This does not imply bad faith. The supplier and the client simply have different responsibilities.
One person can hold several roles, but not by default
The UK guidance Implementing functional standards: a guide for senior leaders in organisations makes a helpful distinction: standards define roles rather than necessarily defining separate jobs. One person can therefore hold several responsibilities when they are explicitly reflected in objectives and role descriptions.
Combining the roles may work when the scope is contained, the manager’s normal duties are genuinely reduced, decision rights are formalised and another person independently reviews estimates and acceptance evidence.
Without those conditions, “internal project manager” becomes a label placed on an already overloaded business manager.
| Role | Question it answers | Expected deliverable |
|---|---|---|
| Executive sponsor | Why are we investing and what must be decided? | Mandate, priorities and escalation decisions |
| Business owner | How should the process operate? | Business rules and acceptance criteria |
| Client project manager | How will delivery be controlled? | Plan, risks, decisions and change control |
| Supplier project manager | How will the promised solution be produced? | Configuration, development, documentation and evidence |
What it costs when the project starts unprepared
The first cost does not always appear on the software invoice. It emerges through delayed decisions, repeated workshops and conflicting requests sent to the supplier.
| Visible symptom | Underlying cause | Consequence |
|---|---|---|
| Workshops continue, but nothing is approved | Nobody has both the authority and availability to decide | The supplier works from assumptions |
| Additional requests keep appearing | Client-side scope is not controlled | The budget becomes a sequence of change orders |
| The business manager answers between emergencies | Existing duties were not reorganised | Decisions arrive after they can be implemented easily |
| Acceptance is left until the end | Nobody prepares business test scenarios | Defects are discovered near go-live |
| Decisions remain buried in email | No shared decision log exists | Contractual disagreements become harder to resolve |
A second dependency appears after deployment. The integrator may remain the only party that understands the compromises, workarounds and limitations built into the system. The company owns the software but does not fully own the decision history behind it.
Technical debt can then grow. Temporary interfaces, manual imports and rapidly implemented rules remain in production because nobody on the client side owns their replacement.
The deployment model can reduce some of these risks when it matches the company’s actual management capacity. Our comparison of big bang, pilot and phased ERP deployment explains how to align the rollout approach with available internal resources.
The reasonable way forward
1. Have management appoint an executive sponsor
The executive signs a one-page project mandate. It states the business objective, exclusions, budget decisions requiring escalation, the project manager’s authority and the matters reserved for the sponsor.
This is not a decorative organisation chart. It is a decision rule that can be applied when departments request incompatible priorities.
2. Separate business ownership, management and delivery
Management creates a RACI matrix — responsible, accountable, consulted and informed — for each major deliverable: target process, data migration, integrations, acceptance, training and go-live.
Every deliverable must have one accountable approver. Approval “by the project group” creates collective responsibility without a clear decision-maker.
3. Remove operational duties from the internal lead
The appointed manager prepares a workload relief plan with their line manager. It names the operational activities that will be delegated, suspended or reassigned.
If no responsibility can leave the manager’s agenda, that person should remain the business owner rather than receive artificial accountability for the entire project.
4. Establish evidence before workshops begin
The client project manager creates:
- a plan linked to verifiable deliverables;
- a register covering risks, assumptions, issues and dependencies;
- a decision log naming each decision-maker;
- a change register recording operational and financial impacts;
- an acceptance strategy linked to business rules.
These documents allow executives to decide from evidence rather than from a supplier’s declared completion percentage.
5. Retain an independent client-side challenge
An external project manager or shared CIO can review estimates, prepare decisions, control dependencies and organise acceptance without replacing the internal business owner.
This role should remain separate from the implementation work invoiced by the integrator. Depending on the project and available skills, the appropriate model may be internal, independent or shared. We compare these arrangements in our article on shared CIOs, freelancers and integrators.
On Monday morning, management can request four concrete deliverables: the sponsor mandate, the role matrix, the business manager’s workload relief plan and the initial decision log. Missing documents reveal more than a detailed schedule filled with dates.
Our position at D1 Consulting
An SME does not necessarily need a permanent CIO for every technology project. It does need identifiable client-side leadership, traceable decisions and deliverables that can be independently verified.
Our IT project management and shared CIO service covers scoping, supplier management, executive decision preparation, acceptance testing and change management. We work alongside the internal business owner: the goal is not to take control away, but to prevent one manager from carrying two incompatible functions on the same agenda.
👉 Book a free 30-minute diagnostic to clarify project roles, expected deliverables and the client-side management structure required before your next supplier commitment.
