Why an Example Tells You More Than Any Definition
Resource planning is one of the most demanding tasks in project planning. Even if you know the theory, the question remains: what does it actually look like in practice? That is exactly what this article shows — step by step, using a realistic project.
The example project: The fictional TechNova GmbH, a mid-sized IT service provider with 120 employees, is rolling out a CRM system for a major client. The project profile:
| Parameter | Value |
|---|---|
| Project goal | Implementation of a CRM system including data migration and training |
| Duration | 6 months (January–June) |
| Budget | 280,000 € |
| Team size | 10 internal + 2 external employees |
| Departments involved | Development, Consulting, QA, Training |
The starting point for resource planning is the defined project scope and the work breakdown structure (WBS), which breaks the project down into work packages.
Step 1 — Identify Resource Requirements
From the WBS to Resource Requirements
TechNova has structured the CRM project into five phases with a total of 18 work packages: requirements analysis, data migration, backend development, frontend/UX, testing, and go-live with training. From these work packages, the project team derives which roles and physical resources are needed:
Roles: Project Manager (PM), 2 Backend Developers (BE), 1 Frontend Developer (FE), 1 UX Designer (UX), 1 Database Administrator (DBA), 2 Consultants (CON), 1 Tester (QA), 1 Trainer (TR)
Physical resources: Test environment, staging server, CRM licenses (development environment)
The Resource Matrix — Requirements at a Glance
The resource matrix shows the estimated effort per work package and role in person-days (PD). It is the central planning document.
| Work Package | PM | BE | FE | UX | DBA | CON | QA | TR | Total |
|---|---|---|---|---|---|---|---|---|---|
| Requirements Analysis | 10 | – | – | 5 | – | 15 | – | – | 30 |
| Data Migration | 5 | 15 | – | – | 20 | 5 | 5 | – | 50 |
| Backend Development | 5 | 60 | – | – | 10 | – | 10 | – | 85 |
| Frontend & UX | 3 | 10 | 40 | 20 | – | 5 | 10 | – | 88 |
| Testing & QA | 3 | 10 | 5 | – | 5 | – | 30 | – | 53 |
| Training & Go-Live | 5 | 5 | – | – | – | 10 | 5 | 15 | 40 |
| Total per Role | 31 | 100 | 45 | 25 | 35 | 35 | 60 | 15 | 346 |
How to read this: Backend development requires a total of 85 person-days — 60 PD for the two backend developers, 10 PD for the DBA, and 10 PD for QA support.
This matrix forms the basis for all subsequent planning steps. It answers the question: How much capacity do we need in total per role?
Step 2 — Check Availability and Assign Resources
Balancing Capacities
Before resources are assigned, the project manager checks actual availability. This reveals typical constraints:
- Backend Developer A is simultaneously tied up in a maintenance project → only 60% available
- UX Designer doesn’t start until February (previous project still running)
- DBA has two weeks of vacation in March
- External Consultant is contractually limited to a maximum of 15 days per month
These constraints feed directly into the assignment planning.
Assigning Resources Concretely
The following table shows who works on the CRM project, when, and how much — as a percentage of available working time:
| Role | Jan | Feb | Mar | Apr | May | Jun |
|---|---|---|---|---|---|---|
| Project Manager | 40 % | 30 % | 20 % | 20 % | 20 % | 30 % |
| Backend Dev. A | – | 30 % | 60 % | 60 % | 40 % | 10 % |
| Backend Dev. B | – | 20 % | 80 % | 80 % | 50 % | 20 % |
| Frontend Dev. | – | – | 20 % | 80 % | 80 % | – |
| UX Designer | – | 50 % | 60 % | 40 % | – | – |
| DBA | 20 % | 60 % | 40 % | 20 % | 10 % | – |
| Consultant 1 | 80 % | 40 % | – | – | – | 30 % |
| Consultant 2 (external) | 60 % | 30 % | 20 % | – | – | 20 % |
| Tester | – | – | 20 % | 40 % | 80 % | 30 % |
| Trainer | – | – | – | – | 20 % | 60 % |
When creating this assignment, a conflict immediately becomes apparent: Backend Developer A is scheduled at 60% for the CRM project in March and April — but the maintenance project also demands 50% of his time. The total load is 110%.
Solution: The project manager shifts some of the backend work from March into April. At the same time, the tester starts two weeks earlier with preparatory test cases. This relieves the bottleneck without jeopardizing the project schedule overall.
Step 3 — Visualize the Resource Plan
A good resource plan needs a representation that makes bottlenecks and idle time visible at a glance. TechNova creates a workload overview for the entire team:
| Month | Planned PD | Available PD | Utilization | Assessment |
|---|---|---|---|---|
| January | 38 | 55 | 69 % | 🟢 Capacity available |
| February | 52 | 58 | 90 % | 🟡 Good utilization |
| March | 62 | 60 | 103 % | 🔴 Overload |
| April | 58 | 62 | 94 % | 🟡 Good utilization |
| May | 55 | 62 | 89 % | 🟡 Good utilization |
| June | 35 | 55 | 64 % | 🟢 Capacity available |
The overview shows: March is the critical month. Data migration and backend development run in parallel — while the DBA is on vacation at the same time. Without countermeasures, an overload with quality degradation and schedule delays looms.
The project manager uses milestones as control points: end of February (requirements approved), end of April (core features complete), and end of May (testing finished). At each milestone, the resource plan is reconciled against actual effort.
Why Excel hits its limits here: In a spreadsheet, every change must be tracked manually. If a work package shifts, all dependent assignments must be adjusted by hand. With 12 team members and 18 work packages, this quickly becomes error-prone. Professional project management software automatically flags conflicts and simulates the impact of replanning.
Step 4 — Respond to Changes
No resource plan survives first contact with reality unchanged. In TechNova’s CRM project, two typical situations arise:
Scenario 1 — Postponed workshop: The client postpones the requirements workshop by three weeks. The requirements analysis is delayed, and with it the start of data migration shifts. The project manager uses the free capacity in January to deploy the consultants for an advance analysis of the existing data structures. This later shortens the data migration by one week.
Scenario 2 — DBA absence: The database administrator is unexpectedly sick for two weeks in March — on top of the already-planned vacation. The project manager responds:
- Backend Developer B takes over the less complex DBA tasks (database schema adjustments)
- The complex data migration shifts two weeks into April
- The built-in buffer of 10% absorbs the delay
After each milestone, the team compares planned and actual effort. At the second milestone, it becomes clear: backend development has consumed 15% more effort than estimated. The team adjusts the resource plan for the remaining months and documents the variance as a lesson learned for future projects.
Brief Example: Trade Fair Construction — Resource Planning in Another Industry
Resource planning works across industries. A second example illustrates the differences: the fictional EventForm GmbH is planning a trade fair booth at the Hannover Messe.
Project profile: 8-week duration, budget €45,000, team: 1 project manager, 2 carpenters, 1 graphic designer, 1 electrician.
| Work Package | PM | Carpenters | Graphic | Electrician |
|---|---|---|---|---|
| Design & Planning | 5 PD | – | 8 PD | – |
| Fabrication | 2 PD | 20 PD | 3 PD | 2 PD |
| On-site Assembly | 3 PD | 6 PD | – | 4 PD |
The key difference from the IT example: physical resources (wood, lighting, transport vehicle) and on-site physical availability dominate the planning. The carpenters can only fabricate once the material has been delivered. The electrician is only needed at specific points, but must be available at exactly those times.
The key insight: The principle — identify requirements, check availability, assign, control — remains identical. What changes is the weighting of resource types: in the IT project, specialist skills and availability take center stage; in trade fair construction, it is the coordination of materials and physical presence.
Common Mistakes — and How the Example Avoids Them
| Mistake | Avoided in the example by |
|---|---|
| Underestimating multitasking | Developer A identified at 110% → tasks spread out over time |
| Forgetting buffer time | 10–15% reserve per phase built in → DBA absence absorbed |
| Ignoring physical resources | Test environment and staging server planned as resources |
| Never updating the plan | Actual-vs-planned comparison at every milestone, adjustment in April |
Frequently Asked Questions
How do I create a resource plan in Excel?
Set up a table with work packages in the rows and roles in the columns — like the resource matrix above. Add a second sheet with the time-based assignment (months as columns, utilization as a percentage). Conditional formatting highlights overloads in color. For projects with more than 10 participants or multiple parallel projects, however, Excel quickly becomes unwieldy — switching to project management software is worthwhile at that point.
What does a resource plan for a concrete project look like?
A complete resource plan contains at minimum: a resource matrix (work packages × roles × effort), a time-based assignment (who works on what and when), a workload overview, and defined control points. The CRM project in this article illustrates all of these elements. Further details on methodology and process can be found in the article Resource Planning in Project Management.
Are there templates for a resource plan?
Simple Excel templates are suitable for getting started and for small projects. They typically include a resource matrix and a workload overview. For work involving multiple parallel projects and shared resources, a professional solution that automatically detects conflicts and can simulate scenarios is recommended.
What belongs in a resource matrix?
A resource matrix maps work packages (rows) against the required roles (columns). The cells contain the estimated effort — usually in person-days or hours. You can also note competency requirements and priorities. The table in the “Step 1” section of this article shows a concrete example with totals columns.
Senior Advisor
Jörg Friedrich is the original author of the project management software Allegra and continues to accompany its development to this day. He has many years of industry experience as a project and department manager. He also serves as a professor in the Faculty of Computer Science and Information Technology at Esslingen University of Applied Sciences.
