Resource allocation planning for SAP projects

Resource allocation planning for an SAP project means deciding which roles you need, in which SAP Activate phase, for how many hours a week, and then checking every week whether reality still matches. Staff by role, not generic headcount. Shape the plan to the phase curve: functional people in Explore, technical people in Realize, data, Basis and change in Deploy. Confirm availability in writing with line managers. This guide is for programme directors, PMOs and CIOs building or rescuing an S/4HANA resource plan. Use the FTE tables and day-rate ranges below as starting anchors.

I have watched dozens of implementations struggle with the same resource problems. The plan assumes a stability that disappears once execution starts.

I once saw a team lose an entire week because nobody had realised the security lead had back-to-back leave and training. It was not flagged and it was not tracked, and it delayed a critical system access review by nine days.

Most SAP plans rely on neat estimates, full-time availability and predictable workflows. That version of the world rarely survives the first month of Realize.

I plan around three things: what the work actually requires, what the available people will actually deliver, and what changes when reality differs from the plan. A plan that holds up covers six dimensions:

1. Headcount by role by Activate phase. Not flat allocation. Explore looks nothing like Realize.
2. Hours per week confirmed by the line manager. In writing, not assumed.
3. Concurrent commitments per person. Someone listed at 100% who also covers production support will deliver far less.
4. Backup for every critical-path role. Cross-training is not optional on an 18-month programme.
5. Cross-stream dependencies. Each with a named owner, a due date and an escalation path, visible the day it slips.
6. Update cadence. Weekly in active phases. The plan at kick-off is version one.

Plans go wrong when the planner uses generic IT roles. SAP needs specific functional and technical specialisation. The standard set for an S/4HANA programme:

Programme leadership. Programme manager, PMO lead and solution architect. The architect is accountable for design coherence across modules.

Functional consultants. One lead per module in scope: Financial Accounting (FI), Controlling (CO), Materials Management (MM), Sales and Distribution (SD), Production Planning (PP), Extended Warehouse Management (EWM), plus Human Capital Management (HCM), Plant Maintenance (PM) and Project System (PS) where in scope. If you still run classic Warehouse Management (WM), plan the move: its compatibility-pack use rights on S/4HANA on-premise ended at the end of 2025.

Technical consultants. ABAP developers for reports, interfaces, conversions, enhancements, forms and workflows (RICEFW), and for clean-core extensions on released APIs or SAP BTP. Integration specialists for SAP Integration Suite (Cloud Integration, formerly CPI), SAP Process Orchestration where it still runs, and any third-party middleware.

Platform. Basis consultants for HANA, kernel patches, transports, system copies and performance tuning. Security consultants for role design, segregation of duties analysis and SAP GRC Access Control where in scope.

Data. Migration specialists using the SAP S/4HANA Migration Cockpit's "Migrate Your Data" app (the older LTMC transaction is deprecated), the Migration Object Modeler for custom objects, and SAP Data Services for complex transformations. My guide to why SAP data migration fails explains why this team needs to start earlier than most plans allow.

Change. Change lead, training lead and business readiness owner. Usually understaffed, because the need only becomes visible in Deploy.

Client side. Business analysts (one per major module), process owners (one per process domain) and testers drawn from operations for UAT.

Treating these as interchangeable slots is the most common planning error. A senior FI consultant cannot run an SD design session. A junior ABAP developer cannot architect an integration. For role-by-role responsibilities, see my list of essential SAP implementation team roles.

Resource demand is not flat. The Activate phases create predictable curves that a flat allocation misses.

Prepare (typically weeks 1 to 4). Light. Programme manager, architect and a lead per module for scoping. Business users confirm scope. Basis and security start environment set-up.

Explore (typically months 2 to 5). Heavy on functional consultants and business users, with design workshops driving the schedule. ABAP and integration are light until design decisions land. Basis prepares sandbox and quality systems.

Realize (typically months 5 to 12). Heavy on technical people: configuration, build, unit and integration testing. ABAP load peaks. Business users join test cycles. The data team builds migration objects and runs dry runs.

Deploy (typically months 12 to 14). Heavy on data migration, Basis, security, change and training. UAT consumes business capacity. Cutover rehearsals need co-located teams. Hypercare planning starts.

Run (from month 14; hypercare typically 30 to 90 days). A light core team and heavy support coverage. Basis and application management ramp up while consultants ramp down.

Treat these as equal demand windows and you will overstaff Prepare, understaff Realize and run short on data migration in Deploy. The phase curve is the most important shape in the plan.

1. PrepareAbout 11 FTEsWeeks 1 to 4. Leads scope, Basis sets up
2. ExploreAbout 36 FTEsMonths 2 to 5. Functional people and business users
3. RealizeAbout 56 FTEs, the peakMonths 5 to 12. Build, and ABAP load peaks
4. DeployAbout 42 FTEsMonths 12 to 14. Data, Basis, security, change
5. RunAbout 12 FTEsFrom month 14. Hypercare typically 30 to 90 days

Constant emergencies. When the team is always firefighting, the plan has stopped predicting reality. One absence should not be able to derail a workstream.

Business users disappear when you need them. Design sessions and UAT stall because business users are unavailable. It is one of the most common sources of slip. The cause is almost always the same: the time was assumed, not formally committed. Operational pressure wins every time the commitment was not formalised.

Technical people spread too thin. Gerald Weinberg's work on software management estimated that someone split across three projects delivers about 60% of their total capacity, with the rest lost to switching. The American Psychological Association's summary of task-switching research reports the same order of loss: brief mental blocks from shifting between tasks can cost as much as 40% of productive time. The plan looks efficient. The output does not.

The critical path changes every week. Constant reshuffling, late-starting workstreams and weekly priority changes usually trace back to unclear scope or badly sequenced dependencies. Fix the scope before you fix the resource plan.

1. Fake availability. Someone listed at 100% also runs month-end close and production support. Ask how many hours a week, what else they are working on and whether their line manager has confirmed it in writing.
2. Shared roles with no boundaries. One person doing solution design, testing and change management at once. Split responsibilities by task, not title, and never make one person critical in two places at the same time.
3. Missing business user time. Workshops slip and UAT sign-offs take weeks longer. Get time committed in writing and signed by the department head, track attendance and escalate patterns early.
4. No buffer. One absence stalls a workstream. Build buffer at task level, not just phase level, and cross-train at least one person on each core role.
5. A plan never updated. Built at kick-off and never revised. Review it weekly in active delivery, tie it to phase gates and update it when reality shifts.

Start with confirmed availability. Go to line managers before the project starts. Confirm hours per week and other commitments, and document them. When availability changes mid-project, that baseline is your basis for escalation.

Shape it by phase. An ABAP developer's load in Explore differs from Realize. Business users peak in Explore for design and in Deploy for UAT. Flat allocation looks balanced on paper and fails on the ground.

Map dependencies explicitly. Data migration feeds integration testing, which feeds UAT, which drives cutover. Give every dependency an owner, a date and a flag, so a slip is visible the same day.

Protect business user time at steering level. Their day jobs continue. Without explicit sign-off from their management on hours per week, they will drop the project when operational pressure arrives. The sponsor, not the project manager, should ask department heads for that time.

Update the plan weekly. A plan untouched for two weeks is probably wrong. Track actual against planned utilisation. Someone at 120% for two straight weeks is a signal that either they are overloaded or the plan is wrong.

These are indicative headcount and rate ranges to use as starting anchors. Industry, scope, geography and partner all move them. Use the tables as sanity checks, not quotes.

Mid-market brownfield ($5M to $15M, about 12 months)

Typical scope: a single legal entity or small group, three or four modules (usually FI, CO, MM, SD), standard processes and limited custom development.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programme manager	1	1	1	1	0.5
Solution architect	1	1	1	0.5	0
Functional consultants (FI/CO, MM, SD plus one)	1	4	4	2	1
ABAP and technical	0	1	3	1	0.5
Integration	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
Security and authorisations	0	0.5	1	1.5	0.5
Data migration	0	1	2	3	0
Testing lead	0	0.5	1	1	0
Change and training	0.5	1	1	2	0.5
Client business analysts	1	4	3	2	1
Peak total FTE	5	14	20	17	5

Enterprise brownfield ($30M to $80M, 15 to 18 months)

Typical scope: multiple entities, six to nine modules, complex integration, meaningful custom development and several country rollouts.

Workstream	Prepare	Explore	Realize	Deploy	Run
Programme manager and PMO	2	2	3	3	1
Solution architects (lead plus module)	2	3	3	1.5	0.5
Functional consultants (all modules in scope)	2	10	12	5	2
ABAP and technical	0	3	8	3	1
Integration and middleware	0.5	2	5	2	1
Fiori and UI5	0	1	3	1	0.5
Basis	1	1	2	4	2
Security and GRC	0.5	1.5	2	3	1
Data migration	0	2	5	6	0.5
Testing	0.5	1	3	4	0
Change and training	1	2	3	5	1
Client business analysts	2	8	7	5	2
Peak total FTE	11	36	56	42	12

Day rates by role and region (2024 to 2025)

These are partner billed rates per specialist, not salaries. The programme-blended rate usually comes out 30 to 50% below the onshore senior rate, because most programmes mix onshore architects with offshore delivery.

Role	Onshore US/UK/DE	GCC (UAE/KSA)	Nearshore (LatAm/EE)	Offshore (India)
Solution architect (senior)	$2,000 to $3,500	$1,500 to $2,500	$900 to $1,500	$500 to $1,000
Functional consultant (senior)	$1,500 to $2,800	$1,200 to $2,000	$700 to $1,400	$300 to $700
Functional consultant (mid)	$1,000 to $1,800	$800 to $1,400	$500 to $900	$200 to $500
ABAP and technical (senior)	$1,400 to $2,500	$1,000 to $1,800	$600 to $1,200	$300 to $700
Integration specialist	$1,500 to $2,800	$1,100 to $1,900	$700 to $1,300	$350 to $800
Basis	$1,400 to $2,200	$1,000 to $1,800	$600 to $1,100	$300 to $700
Security and GRC	$1,500 to $2,500	$1,100 to $1,900	$700 to $1,300	$350 to $800
Data migration	$1,300 to $2,200	$1,000 to $1,700	$600 to $1,100	$300 to $700
Change and training lead	$1,200 to $2,000	$900 to $1,500	$500 to $1,000	$250 to $600
Junior consultant (any role)	$800 to $1,400	$500 to $900	$400 to $700	$150 to $350

The onshore, nearshore and offshore split

Most SAP programmes blend regions. It is a cost-versus-velocity decision, not a binary one.

US private sector programmes typically run 30 to 60% onshore by FTE. Onshore is concentrated in architecture, change, business analysis and senior functional roles, where proximity to the business matters. Offshore is concentrated in ABAP, integration build and data migration execution, where the work is easier to specify. US federal programmes are often fully onshore with US-person restrictions, depending on the workload.

GCC programmes typically run 60 to 70% onshore, because local hiring rules and Arabic-language requirements push the share up. Offshore work tilts towards South Asian centres for the time-zone overlap. European programmes vary: manufacturing often runs around 50% onshore, while public sector and regulated industries go higher for data residency reasons.

A common mistake is optimising the split for cost alone. A team that is 80% offshore with 20% onshore architects looks cheap on the spreadsheet. The hidden costs are the daily handoff cycle and slower design workshops without business context. The cheapest team rarely delivers the cheapest programme. When you compare partners, my guide to SAP implementation partners by tier covers how rates and team shape differ between them.

A plan built once and never re-examined is not a plan. Treat every assumption in it as a hypothesis to test in the first week of execution, and every week after.

This guide is part of my SAP implementation hub, which links every topic from the business case to go-live.

What is resource allocation planning in SAP projects, and why does it matter?

It is deciding which people the project needs, when and for how much of their time, and then tracking whether that matches reality.

SAP projects depend on specific individuals: the FI/CO lead who understands your chart of accounts, the migration specialist who knows your legacy data, the change lead with relationships in the business. When they are unavailable at the right moment, work stops or is done wrong. Many delays that look technical are really resource problems.

How does poor resource allocation cause SAP project delays?

Through dependencies. A configuration lead is pulled onto another project in Realize. Their work stalls, which delays integration testing, then UAT, then cutover readiness. A two-week absence in week eight can become a six-week slip by go-live.

Small gaps early become large delays late. By the time the impact is visible, recovery costs several times what an early fix would have.

How do I get business users committed to an SAP project when they have day jobs?

Get written commitment from their line manager before the project starts: hours per week, which phases need them most and what approval is required if availability changes.

Track their attendance like any other resource. When it drops, escalate at steering level. Department heads can enforce the commitment; the project team cannot.

How should I handle a key person leaving mid-project?

Avoid single points of failure in the first place: at least one other person should understand each critical workstream well enough to keep it moving.

When someone leaves, capture what they know immediately: undocumented decisions and configuration rationale. That is often harder than finding a replacement. For backfill, a handover document, recorded sessions and a one-week overlap are the minimum.

When should I escalate a resource problem?

Earlier than feels comfortable. Escalate when a named dependency owner has been unavailable for more than a week, a business user keeps missing sessions, a technical resource runs above 120% utilisation for two weeks, or a workstream is blocked by a deferred resourcing decision.

The cost of escalating too early is an awkward conversation. The cost of escalating too late is weeks of slip.

How should shared resources across multiple projects be handled?

Assume shared people will prioritise something else when pressure hits. Agree specific hours per week with their primary manager, build buffer into work that depends on them and keep them off your critical path unless you have a fallback.

For shared business users, the request has to come from the sponsor. A project manager asking a department head for time will lose to operational priorities every time.