TUGAS MANAJEMEN PROYEK RESOURCE LEVELING
Disusun oleh:
Muthia Zhafira Sahnah 24060122130071
DEPARTEMEN INFORMATIKA FAKULTAS SAINS DAN MATEMATIKA
UNIVERSITAS DIPONEGORO
2025
1 A. Deskripsi Permasalahan
Universitas saat ini sedang mengembangkan sistem manajemen kampus terintegrasi yang akan mencakup informasi mahasiswa, registrasi mata kuliah, manajemen pembelajaran, serta fungsi administratif lainnya dalam satu platform digital yang terpadu. Proyek ini bertujuan untuk meningkatkan efisiensi operasional, mempercepat proses layanan akademik, dan menyediakan akses informasi yang lebih mudah bagi seluruh civitas akademika.
Sebagai Project Manager, tanggung jawab utama adalah memastikan alokasi sumber daya dilakukan secara efisien dan merata selama siklus pengembangan perangkat lunak. Proyek ini melibatkan berbagai peran penting seperti Software Developer, UI/UX Designer, Database Administrator, hingga Quality Assurance Specialist. Setiap sumber daya memiliki kapasitas dan biaya per jam yang berbeda, yang harus dipertimbangkan secara cermat dalam perencanaan dan pelaksanaan proyek.
Permasalahan utama yang dihadapi saat ini adalah potensi terjadinya overallocation atau penumpukan beban kerja pada beberapa sumber daya tertentu, yang dapat menyebabkan keterlambatan jadwal proyek, peningkatan biaya, serta menurunnya kualitas output. Oleh karena itu, diperlukan sebuah rencana resource leveling yang matang untuk menganalisis alokasi sumber daya saat ini, mengidentifikasi bagian yang mengalami overallocation, serta menerapkan teknik leveling yang tepat guna mengoptimalkan jadwal proyek.
Adapun sumber daya yang tersedia dalam proyek ini meliputi:
• 2 Senior Software Developers (SD1, SD2) - $80/hour each
• 3 Junior Developers (JD1, JD2, JD3) - $50/hour each
• 1 Database Administrator (DBA) - $75/hour
• 2 UI/UX Designers (UID1, UID2) - $65/hour each
• 1 Quality Assurance Specialist (QA) - $60/hour
• 1 Project Manager (PM) - $85/hour
• 1 System Administrator (SA) - $70/hour
Melalui perencanaan resource leveling yang efektif, proyek ini diharapkan dapat berjalan sesuai dengan tenggat waktu, efisien dari sisi biaya, dan menghasilkan sistem yang berkualitas tinggi untuk mendukung kebutuhan manajemen kampus secara menyeluruh.
2 Tabel 1. 1 Rencana Jadwal Proyek
ID Activity Original Duration
A Project Planning 5
B Requirements Gathering 10
C Database Design 8
D System Architecture Design 7
E UI/UX Design 12
F Database Development 15
G Core Modules Development 20
H User Interface Development 18
I Integration 10
J System Testing 12
K User Acceptance Testing 8
L Deployment Preparation 5
M Training Materials Creation 7
N System Deployment 3
3 Tabel 1. 2 Tabel Aktivitas Proyek
ID Activity Duration
(days)
Predecessors Resources Required
Effort (person- days)
A Project Planning 5 None PM, SD1 10
B Requirements Gathering
10 A PM, SD1,
UID1
30
C Database Design 8 B DBA, SD2 16
D System Architecture Design
7 B SD1, SD2 14
E UI/UX Design 12 B UID1, UID2 24
F Database Development
15 C DBA, JD1 30
G Core Modules Development
20 D SD1, SD2, JD2 60
H User Interface Development
18 E UID1, JD2,
JD3
54
I Integration 10 F, G, H SD1, JD1, SA 30
J System Testing 12 I QA, JD3, UID2 36
K User Acceptance Testing
8 J QA, PM, UID1 24
L Deployment Preparation
5 J SA, JD1 10
M Training Materials Creation
7 J UID2, JD2 14
N System Deployment 3 K, L, M SA, SD1, DBA 9
4 B. Network Diagram dan Critical Path
Tabel 1. 3 Durasi Aktivitas
Task From (i) To (j) Durasi (Dij)
A 0 1 5
B 1 2 10
C 2 3 8
D 2 4 7
E 2 5 12
F 3 6 15
G 4 7 20
H 5 8 18
I 9 10 10
J 10 11 12
K 11 12 8
L 11 13 5
M 11 14 7
N 12,13,14 15 3
5 Tahap selanjutnya adalah mencari
• ES(i,j) = ET(i)
• EF = ES + Durasi
Tabel 1. 4 Menghitung Forward Pass (ES dan EF)
TASK I J D ES(i,j) EF = ES+D
A 0 1 5 0 5
B 1 2 10 5 15
C 2 3 8 15 23
D 2 4 7 15 22
E 2 5 12 15 27
F 3 6 15 23 38
G 4 7 20 22 42
H 5 8 18 27 45
I 9 10 10 45 55
J 10 11 12 55 67
K 11 12 8 67 75
L 11 13 5 67 72
M 11 14 7 67 74
N 12 15 3 75 78
N 13 15 3 72 75
N 14 15 3 74 77
6 Tabel 1. 5 Menghitung Backward Pass (LF dan LS)
TASK J D LF(j) LS = LF-D
N(12→15) 15 3 77 75
N(13→15) 15 3 77 75
N(14→15) 15 3 77 75
K 12 8 75 67
L 13 5 75 70
M 14 7 75 68
J 11 12 min(67,70,68) = 67 55
I 10 10 55 45
H 8 18 45 27
G 7 20 45 25
F 6 15 45 30
E 5 12 27 15
D 4 7 25 18
C 3 8 30 22
B 2 10 min(22,18,15)=15 5
A 1 5 5 0
7 Selanjutnya kita hitung total float (TF = LS-ES) , Dimana TF=0 kita tandai sebagai critical path
Task ES EF LS LF TF = LS - ES Critical
A 0 5 0 5 0 V
B 5 15 5 15 0 V
C 15 23 22 30 7 X
D 15 22 18 25 3 X
E 15 27 15 27 0 V
F 23 38 30 45 7 X
G 22 42 25 45 3 X
H 27 45 27 45 0 V
I 45 55 45 55 0 V
J 55 67 55 67 0 V
K 67 75 67 75 0 V
N(12→15) 75 77 75 77 0 V
Jadi critical path yang didapat adalah
A → B → E → H → I → J → K → N → (Finish) Durasi total: 77 hari
8 C. Analisis Overallocated Resource Berdasarkan Total Alokasi dan Analisis
Overlap pada Resource
Tabel 1. 6 Tabel Alokasi Resource Awal
ID Activity Duration (days) Resources Required
A Project Planning 5 PM, SD1
B Requirements Gathering 10 PM, SD1, UID1
C Database Design 8 DBA, SD2
D System Architecture Design 7 SD1, SD2
E UI/UX Design 12 UID1, UID2
F Database Development 15 DBA, JD1
G Core Modules Development 20 SD1, SD2, JD2
H User Interface Development 18 UID1, JD2, JD3
I Integration 10 SD1, JD1, SA
J System Testing 12 QA, JD3, UID2
K User Acceptance Testing 8 QA, PM, UID1
L Deployment Preparation 5 SA, JD1
M Training Materials Creation 7 UID2, JD2
N System Deployment 3 SA, SD1, DBA
Tabel 1. 7 Estimasi Biaya Awal
Resource Total Allocation (days) Cost ($) / Hour Cost Estimate ($)
DBA 26 75 15600
JD1 30 50 12000
JD2 45 50 18000
JD3 30 50 12000
PM 23 85 15640
9
QA 20 60 9600
SA 18 70 10080
SD1 45 80 28800
SD2 35 80 22400
UID1 48 65 24960
UID2 31 65 16120
10 Gambar 1. 1 Gantt Chart Sebelum Resource Leveling
11 Gambar 1. 2 Histogram Kebutuhan Developer (Senior maupun Junior) pada Proyek (sebelum)
12 Gambar 1. 3 Histogram Kebutuhan UIUX Design pada Proyek (sebelum)
13 Gambar 1. 4 Histogram Kebutuhan QA pada Proyek (sebelum)
14 Gambar 1. 5 Histogram Kebutuhan PM pada Proyek (sebelum)
15 Gambar 1. 6 Histogram Kebutuhan PM pada Proyek (sebelum)
16 Berdasarkan gantt chart yang ada pada gambar diatas dapat dilihat bahwa ditemukan beberapa konflik alokasi resource. Konflik ini terjadi karena adanya penugasan ganda terhadap individu yang sama dalam waktu yang saling tumpeng tindih.
Selanjutnya kita akan menghitung peak demand yang menunjukkan presentase maksimum alokasi sumber daya pada titik tertentu dalam jadwal proyek. Ini terjadi apabila resource dialokasikan pada lebih dari satu aktivitas secara bersamaan, asumsi apabila persentase alokasi dasar adalah memerlukan 100% untuk resource mengerjakan suatu aktivitas maka cara menghitung persentasenya semisal sebuah resource ada di 2 aktivitas sekaligus maka akan menjadi 200%.
Tabel 1. 8 Tabel Peak Demand Resource
Resource Total Allocation
(days) Peak Demand
Cost Estimate = Total Allocation (days) ×8× Hourly Rate
PM 23 100% Tidak Overlap 15640
SD1 45 200% pada hari 22 (D+G) 28800
SD2 35
300% pada hari 16-22 (C+D) dan
pada hari 22 (C+D+G) 22400
JD1 30 100% Tidak Overlap 12000
JD2 45 200% pada hari 27-42 (G+H) 18000 JD3 30 100% (tidak ada overlap) 12000 DBA 26 200% pada hari 23 (C+F) 15600 UID1 48 200% pada hari 27 (E+H) 24960 UID2 31 200% pada hari 67 (J+M) 16120
QA 20 200% pada hari 67 (J+K) 9600
SA 18 200% pada hari 72 (L+N) 10080
17 D. Resource Leveling
Untuk mengatasi masalah overallocation sumber daya dalam proyek, dilakukan berbagai penyesuaian dengan pendekatan resource leveling yang mencakup strategi time shifting, resource substitution, resource splitting, dan penjadwalan ulang.
Langkah pertama yang dilakukan adalah time shifting terhadap aktivitas G, yaitu Core Modules Development. Aktivitas ini awalnya dijadwalkan mulai pada hari ke-22, namun digeser ke hari ke-24. Pergeseran ini dilakukan untuk menghindari tabrakan alokasi sumber daya dengan aktivitas D (System Architecture Design) yang dikerjakan oleh SD2 pada waktu yang sama. Pada jadwal semula, SD2 harus menangani tiga aktivitas sekaligus (C, D, dan G) antara hari ke-16 hingga 22, yang menyebabkan beban kerjanya mencapai 300%. Dengan memundurkan aktivitas G, SD2 dapat menyelesaikan tanggung jawabnya pada aktivitas C secara optimal tanpa multitasking yang ekstrem.
Selanjutnya diterapkan resource substitution pada aktivitas D. Untuk mengurangi ketergantungan pada SD2, sebagian tanggung jawabnya dalam aktivitas D dialihkan kepada SD1 dan JD1. Dengan demikian, SD1 bertindak sebagai pemimpin pelaksana untuk D dengan dukungan JD1, sementara SD2 diprioritaskan untuk menyelesaikan aktivitas C bersama DBA. Strategi ini memungkinkan distribusi beban kerja yang lebih seimbang dan efisien.
Permasalahan berikutnya muncul pada alokasi JD2, yang terlibat dalam aktivitas G dan H. Untuk menyelesaikan masalah ini, digunakan pendekatan resource splitting dan penjadwalan ulang. Aktivitas G dilaksanakan oleh SD1, SD2, dan JD2 dari hari ke-24 hingga 35. Setelah itu, JD2 dipindahkan ke aktivitas H (User Interface Development), sehingga dari hari ke-36 hingga 42, aktivitas G hanya dilanjutkan oleh SD1 dan SD2.
Penyesuaian ini mengurangi tumpang tindih peran JD2 pada dua aktivitas besar dalam waktu bersamaan.
Aktivitas H sendiri dibagi menjadi dua fase. Fase pertama, pada hari ke-27 hingga 35, dikerjakan oleh UID1 dan JD3. Fase kedua, dimulai dari hari ke-36 hingga 46, mengalami perpanjangan durasi satu hari dari jadwal semula. Pada fase ini, UID1, JD2, dan JD3 terlibat bersama untuk mempercepat penyelesaian dan memastikan kualitas antar muka pengguna (UI) tetap optimal. Kombinasi strategi splitting dan penjadwalan ulang ini memastikan pembagian beban kerja yang realistis dan terukur.
Penyesuaian tambahan dilakukan pada aktivitas non-kritis untuk menghindari konflik alokasi sumber daya dengan aktivitas penting lain. Aktivitas M (Training Materials Creation) dijadwalkan ulang ke hari ke-68 agar tidak bertabrakan dengan aktivitas J (System Testing), yang juga membutuhkan keterlibatan UID2. Sementara itu, aktivitas L (Deployment Preparation) dimajukan ke hari ke-66 hingga 71 untuk meminimalkan overlap dengan aktivitas N (System Deployment), meskipun tetap terjadi sedikit tumpang tindih. Hal ini masih dapat ditoleransi karena tidak memengaruhi jalur kritis proyek.
Secara keseluruhan, langkah-langkah resource leveling ini memberikan sejumlah dampak positif yang signifikan. Beban kerja SD2 yang semula mencapai 300% berhasil dikurangi ke tingkat yang lebih rasional. JD2 dapat berkontribusi secara optimal pada dua aktivitas
18 utama (G dan H) tanpa mengalami overload. UID1 dan UID2 pun terhindar dari multitasking ekstrem yang berpotensi mengganggu konsentrasi dan produktivitas.
Overlap minor yang masih tersisa di beberapa aktivitas telah dikendalikan agar tidak mengganggu timeline proyek secara keseluruhan, khususnya pada jalur kritis.
19 Gambar 1. 7 Gantt Chart Setelah Resource Leveling
20 Gambar 1. 8 Perbandingan kebutuhan developer sebelum dan sesudah
21 Gambar 1. 9 Perbandingan kebutuhan UIUX Designer sebelum dan sesudah
22 Gambar 1. 10 Perbandingan kebutuhan DBA sebelum dan sesudah
23 Gambar 1. 11 Perbandingan kebutuhan QA sebelum dan sesudah
24 Gambar 1. 12 Perbandingan kebutuhan PM sebelum dan sesudah
25 Gambar 1. 13 Perbandingan kebutuhan SA sebelum dan sesudah
26 Gambar 1. 14 Perbandingan kebutuhan resource (All) sebelum dan sesudah
27 E. Kesimpulan
Penerapan resource leveling dalam proyek ini memberikan dampak positif terhadap keberlangsungan proyek secara keseluruhan. Dari segi timeline, meskipun terjadi beberapa penyesuaian seperti pergeseran jadwal aktivitas G dan pembagian fase pada aktivitas H, perubahan ini tidak berdampak signifikan terhadap jalur kritis proyek sehingga durasi total proyek tetap dapat dipertahankan secara optimal. Dari sisi biaya (cost), tidak terdapat penambahan signifikan karena penyesuaian lebih difokuskan pada distribusi ulang sumber daya yang ada, bukan penambahan tenaga kerja baru, sehingga efisiensi tetap terjaga. Sementara dari sisi kualitas (quality), pembagian beban kerja yang lebih seimbang mengurangi potensi kesalahan akibat multitasking ekstrem, meningkatkan fokus individu dalam menyelesaikan tugasnya, serta memastikan bahwa setiap aktivitas dapat diselesaikan dengan standar kualitas yang lebih baik. Dengan demikian, resource leveling ini tidak hanya menyelesaikan permasalahan overallocation, tetapi juga berkontribusi langsung terhadap stabilitas waktu, efisiensi biaya, dan peningkatan kualitas output proyek.
