When Does a Business Need a Fractional Project Manager?

The business has decided to act. Perhaps it is moving to Microsoft 365, implementing a new CRM, running a Cyber Essentials programme, relocating the office, replacing ageing servers, introducing a new finance system, or changing IT provider. The project is real, the deadline exists, and the stakes are significant.

At the start, responsibility is spread across the managing director, internal IT, the finance team, operations, an external IT provider, software suppliers, and consultants. Everyone is involved. Meetings happen. Emails circulate.

Nobody is actually managing the whole project.

Suppliers begin working to different assumptions. Deadlines shift. Nobody owns the dependencies between workstreams. Decisions remain unresolved for weeks. Costs appear that were not in the original budget. Users hear about changes the day before they happen. Testing gets compressed because the go-live date is fixed. Risks stay undocumented. Technical teams blame each other. Senior management assumes somebody else has it under control.

This situation is common in small and medium-sized businesses, not because the businesses are badly run, but because they rarely carry a permanent project-management capability. Projects arrive occasionally and then stop. Managers have operational responsibilities that cannot pause. And the expertise needed to coordinate suppliers, manage scope and maintain decision discipline is genuinely specialist.

A project does not need a full-time project manager to need proper project management.

Understanding the terms

The terminology around external project management overlaps and suppliers use these labels differently. What matters is not the title but the scope, authority, time commitment and responsibility written into the engagement.

The label matters less than the scope, authority, time commitment and responsibility written into the engagement.

Why small and medium-sized businesses use fractional project management

Most SMEs do not run projects continuously. A business might have one or two significant technology changes each year — a migration, a new system, a compliance programme, an office move — and then a quiet period. Carrying a permanent full-time project manager for occasional use is difficult to justify.

At the same time, those occasional projects can be operationally significant. A failed Microsoft 365 migration disrupts every member of staff. A poorly executed CRM rollout produces a system nobody uses. A Cyber Essentials programme that loses momentum misses its certification deadline. The consequences of poor project delivery are real.

Five practical reasons SMEs use fractional project management:

• No permanent requirement — the business runs a few major projects each year, not a continuous pipeline
• Internal capacity — operational managers already have day jobs that cannot pause for a six-month project
• Specialist experience — some projects require someone familiar with cloud migrations, software implementations, cyber-security programmes or supplier transitions specifically
• Project recovery — an experienced project manager can re-establish scope, ownership, priorities and timeline when delivery has already become unclear
• Independence — an external project manager can challenge supplier assumptions, unrealistic deadlines, poorly defined scope and internal politics without the conflicts of interest that internal advocates sometimes carry

Fractional support works best when the need is significant but not permanent.

The real problem with technology project delivery

Many failed SME technology projects do not fail because of technical problems. They fail because of coordination failures.

The problems that accumulate tend to follow a pattern: nobody clearly owns the project, success criteria were never defined, scope was agreed informally and then changed informally, several suppliers are involved but nobody is independently watching the dependencies between them, decisions required from the business sit unresolved for weeks, deadlines were set optimistically without examining what the work actually requires, users are told too late, testing is squeezed, and nobody agrees what project completion looks like.

A CRM supplier might deliver a fully configured system. An IT provider might complete a migration of every mailbox. A connectivity supplier might install the new office circuits. But if the dependencies between these workstreams were not coordinated, the data was not prepared, users were not trained, testing was not planned and nobody owns what happens when something breaks, the project has not delivered its business outcome.

What a fractional project manager should actually do

Project management is not organising meetings. It is making ownership, dependencies, risks and decisions visible.

The work across a typical technology project covers several distinct areas:

• Discovery — understand the business objective, current environment, stakeholders, suppliers, dependencies, risks, deadlines and constraints before planning begins
• Scope — define what is included and excluded, document assumptions, agree acceptance criteria and establish how scope changes will be controlled
• Planning — create milestones, map dependencies, identify resource requirements, define decision points, plan testing stages, prepare a cutover plan and consider rollback
• Ownership — define the executive sponsor, project manager, technical owner, business owner, supplier responsibilities, user responsibilities and decision authority so everyone knows who does what and who decides what
• Risk management — maintain a risk register, issue log, decision log, dependency register and action tracker; make risks visible rather than assuming they will resolve themselves
• Supplier coordination — coordinate internal IT, the managed services provider, telecoms supplier, software supplier, cyber-security provider, Microsoft partner, consultants, facilities and finance as a single programme rather than separate conversations
• Communication — provide regular status, document actions and decisions, surface risks, communicate upcoming changes and prepare users before they are affected
• Delivery — manage milestones, oversee testing, control change requests, support user readiness and manage the cutover
• Closure — confirm acceptance criteria, resolve outstanding issues, transfer documentation, confirm support ownership, remove temporary access and conduct a benefits review

Fractional versus full-time project manager

Neither model is universally better. The right choice follows the workload.

The choice should follow the workload — not the fashionable job title.

When a fractional project manager will not fix the problem

It is worth being direct about the situations where bringing in external project management will not resolve the underlying difficulty.

A fractional project manager is unlikely to rescue a project where:

• The business case is weak or the project was approved without examining whether it is achievable
• The budget is unrealistic for the scope described
• Senior management will not make the decisions the project requires
• There is no executive sponsor who owns the business outcome
• Suppliers are contractually misaligned and disputes are unresolved
• The internal resources needed for testing, training or adoption do not exist
• Key staff refuse to participate or are actively resistant
• Requirements change every week and the business cannot agree what it actually wants
• Nobody agrees what success means
• The delivery timeline is politically fixed but technically impossible
• The project manager cannot challenge assumptions or escalate concerns
• The project manager has responsibility without genuine authority

Authority and governance

A project manager's effectiveness depends significantly on the governance structure around them. Four roles are relevant to most significant technology projects:

A project manager should have authority to call meetings and obtain attendance, challenge missed actions, escalate risks and request decisions, control the agreed change process, obtain status from suppliers and coordinate across workstreams.

A project manager should not silently make executive business decisions, legal decisions, financial approvals, security-risk acceptance decisions or contractual commitments unless explicitly authorised to do so.

Can a fractional project manager rescue a failing project?

Sometimes. But the first stage of a project rescue should normally be an honest reassessment rather than simply pushing harder on the existing plan.

A recovery review should examine the original objective against actual current status; current budget position against original budget; scope against what has actually been delivered; missing deliverables and their dependencies; supplier commitments and whether they remain valid; unresolved decisions and what they are blocking; undocumented risks and technical blockers; realistic remaining timeline; user readiness; and contractual position with each supplier.

The review typically produces one of five outcomes:

• Continue — the original plan remains viable with clearer ownership and tighter management
• Replan — the business objective remains valid but the route, scope, timeline or supplier mix needs to change
• Reduce scope — protect the most important outcome and defer or remove the rest
• Pause — specific dependencies or decisions must be resolved before delivery can continue productively
• Stop — the project no longer makes business sense and the organisation should cut its losses rather than continue spending

Technology project examples

Technology projects become business projects as soon as users, suppliers, money and deadlines are involved. Project management adds value across the full range of common SME technology changes.

A Microsoft 365 migration coordinates tenant configuration, identity management, mail flow cutover, file migration, device management, third-party suppliers and user communications — typically with dependencies between each workstream that a supplier focused on their own deliverable will not manage on your behalf.

A CRM implementation coordinates requirements gathering, data preparation and migration, supplier delivery, integrations with other business systems, user training and adoption support. The system going live is the beginning of the adoption challenge, not the end of the project.

A Cyber Essentials or security programme coordinates technical assessment, remediation across devices and accounts, supplier involvement, policy decisions, user behaviour changes and certification deadlines. The technical remediation is one part; the governance and evidence gathering is another.

An office move coordinates connectivity procurement, network infrastructure, Wi-Fi, telecoms, device preparation, access control, supplier handoffs and the cutover from old premises to new — with a hard deadline that cannot be extended because the lease ends.

An IT provider change coordinates the transfer of credentials, documentation, domain management, Microsoft tenant configuration, backup ownership, licences, security tools and support processes. Gaps in handover documentation create operational risk that can take months to discover.

A business acquisition coordinates IT due diligence, identity integration, network connectivity, Microsoft tenant decisions, supplier consolidation, licensing, security assessment and user transition — often against a tight post-completion timetable.

Choosing a fractional project manager

Relevant questions to ask before engaging external project management:

• Have they managed this type of project before, with similar complexity and supplier mix?
• Can they explain clearly how they structure the discovery and scoping phase?
• How much time will they actually provide and how is that time distributed across the week?
• Who performs the work — them personally, or a team behind them?
• Are they independent from the main technical supplier?
• How do they surface and report risks?
• How do they escalate decisions that the business needs to make?
• How is scope change controlled?
• What tools and documentation will they use?
• Will project information and documentation remain available to the business after the engagement ends?
• How is documentation handed over at project closure?
• What professional indemnity insurance do they carry?
• What system and data access will they need and how will it be controlled?
• How is confidential business information handled?
• Do they understand the technical subject well enough to challenge suppliers on dependencies and deliverables?
• Can they communicate clearly with non-technical directors?
• How do they define and confirm project completion?

Credentials such as PRINCE2, APM, PMP, Agile or Scrum qualifications may be relevant, but certification is not the same as capability. Experience, judgement and relevant delivery history also matter. A certification does not prove that someone can manage a complex multi-supplier technology project in a business under commercial pressure.

Security and temporary access

An external project manager may receive access to significant business information in the course of their work: project plans, supplier contracts, budgets, Microsoft tenant configuration, security reports, network diagrams, employee information, credentials passed informally, incident records and business strategy.

Apply the same controls as for any external access: least privilege, a confidentiality agreement, named individual accounts (no shared credentials), multifactor authentication, secure document storage, access logs, clear data ownership, documented retention rules, a defined offboarding process and prompt access removal at engagement end.

Measuring project success

Project success should not be reduced to whether the launch date was met.

A more complete assessment examines whether the agreed scope was delivered; whether the business outcomes were accepted; the final budget position against original; whether major risks were resolved; actual user adoption; operational stability after go-live; completeness of documentation; support readiness; security position; unresolved issues; supplier handover quality; whether the business now owns what it was supposed to receive; and whether the anticipated benefits have been realised or are being tracked.

Does your project need fractional project management?

Use this checklist to assess your current situation:

Project

• Is the outcome important to the business?
• Is the project temporary rather than continuous?
• Are several teams or suppliers involved?
• Is there a defined deadline?
• Are dependencies between workstreams significant?

Ownership

• Is there a named executive sponsor?
• Is somebody currently managing delivery across all workstreams?
• Are decisions being made on time?
• Is authority to make decisions clear?

Capacity

• Do internal managers have sufficient time alongside operational responsibilities?
• Does somebody on the project understand project-management discipline?
• Are important actions slipping or rolling forward repeatedly?

Complexity

• Are technical and business workstreams connected and dependent on each other?
• Is significant user communication required?
• Is a cutover or go-live event involved?
• Is the cost of failure significant?

Suppliers

• Are several suppliers involved?
• Is someone independently coordinating them?
• Are supplier responsibilities documented?

Risk and governance

• Is there a risk register?
• Is there an issue log?
• Are decisions recorded?
• Is there a rollback or recovery plan?

Delivery

• Is progress measurable against agreed milestones?
• Are acceptance criteria defined?
• Is testing planned?
• Is project closure defined?

Warning signs

A project may need intervention where any of the following are present:

• Nobody owns the complete plan across all workstreams
• Meetings generate no decisions and the same issues appear again next week
• Actions repeatedly roll forward without completion
• Suppliers blame each other for problems
• Deadlines move without documented explanation or replan
• Budget changes are discovered late rather than anticipated
• Users hear about significant changes at the last minute
• Testing is continually reduced or delayed because the deadline is fixed
• Technical teams cannot explain the business impact of their decisions
• Scope changes informally without a change-control process
• Risks are discussed in meetings but never recorded
• Project status is always described as 'nearly there'
• Senior management receives only optimistic reporting
• Nobody can describe what project completion looks like

Common mistakes

• Hiring a project manager only after the project is already visibly failing
• Starting with an unclear or informally agreed scope
• No named executive sponsor
• No defined decision authority
• Too little fractional time — two hours a week cannot control a project that requires daily decisions
• Expecting the project manager to perform technical work outside their agreed scope
• Confusing project administration with project management
• Selecting purely on day rate without assessing relevant experience
• Selecting purely on certification without assessing delivery history
• No knowledge transfer and no documentation at project end
• No exit plan defined at the start of the engagement
• No security controls over temporary access
• Allowing suppliers to mark their own homework without independent verification
• Failing to involve users until go-live
• Treating go-live as project completion
• No benefits review after the project closes

Practical implications for your business

• Fractional does not mean junior — the model describes time commitment, not skill level
• You may not need a permanent project manager — occasional major projects can justify temporary leadership without creating a permanent role
• Project ownership still stays with the business — an external manager does not replace executive sponsorship
• Independence can help — someone outside the main supplier may challenge supplier assumptions more effectively than internal advocates
• Technical knowledge matters — a technology project manager should understand enough to identify missing dependencies and challenge suppliers on deliverables
• Time commitment must match the project — the agreed time must be sufficient for the actual complexity
• Documentation matters — knowledge should remain with the business after the engagement ends
• Security matters — temporary external roles may receive significant business information and need appropriate controls
• Project closure matters — the engagement should have a defined exit, not simply stop when everyone is tired

The IT Club view

Fractional project management is useful because many small businesses have an awkward gap: their technology projects are too important to manage casually, too complex to leave entirely to suppliers, and too occasional to justify a permanent project manager.

The project manager should work for the project outcome — not for whichever supplier shouts loudest.

IT Club recommends:

• Define the business outcome before any supplier conversations begin
• Appoint a named executive sponsor who will make decisions when required
• Clarify what authority the project manager has and document it
• Agree the time commitment explicitly and ensure it matches the project
• Select for relevant experience with this type of change, not just certification
• Keep project information and documentation owned by the business from the start
• Use named supplier responsibilities and document them
• Record risks and decisions as they arise — not retrospectively
• Apply proper access controls from day one and define the offboarding process
• Define project closure before the engagement begins, not when everyone wants to stop
• Review major projects through an Operational Heartbeat

Fractional project management works when it fills a genuine leadership gap. It fails when it is used as a substitute for decisions the business itself still needs to make.

Operational Heartbeat

Technology projects drift. Scope changes informally. Suppliers change. Deadlines move without replan. Assumptions become invalid. Resources are reassigned to operational priorities. Risks increase without being escalated. Budgets change. Users resist change that was never properly communicated. Technical dependencies emerge late. Executive priorities shift.

Important technology projects need an Operational Heartbeat: ownership, scope, risks, decisions, suppliers, milestones and unresolved blockers should be reviewed rather than assumed to remain under control.

A recurring project review should examine the current position against the business outcome; whether the executive sponsor remains engaged; whether the project manager has the authority and access they need; scope position and any informal changes; milestone status; critical dependencies; budget position; current risks and their owners; open issues; decisions outstanding and their age; supplier performance; testing status; user readiness; security position; change requests; unresolved blockers; agreed corrective actions; and the date of the next review.