1.

INTRODUCTION
1.1 Purpose of Project Management Plan
Dokumen Project Management Plan ini bertujuan sebagai pedoman pelaksanaan,
pengawasan dan penutupan proyek, mendokumentasikan asumsi yang dijadikan dasar
dalam perencanaan Sistem Informasi Peroustakaan Kota Yogyakarta termasuk
rencana kegiatan, dan anggaran yang terlibat didalamnya.

2. EXECUTIVE SUMMARY OF PROJECT CHARTER

Project Name : Sistem Informasi Perpustakaan Kota Yogyakarta
Prepared by : Faisal Natsir, Adita Setya, Asti Nugraheni, Mardiana, Shafira

Date : 1 November 2017

INITIATION 1 November 2017: Membuat Sistem Informasi

Perpustakaan Kota Yogyakarta untuk membantu dalam
pencatatan dan pelaporan transaksi peminjaman dan
pengembalian buku di Perpustakaan Kota Yogyakarta
dengan cepat, efisien dan akurat.

Project Manager: Faisal Natsir

SYNOPSIS Sistem perpustakaan dapat bekerja dan digunakan pada
Perpustakaan Kota Yogyakarta. Sistem dapat digunakan
oleh pihak perpustakaan untuk mendata seluruh buku dan
arsip yang dimiliki, mengelola kegiatan peminjaman dan
pengembalian buku serta denda, mengelola data
pemustaka, dan memudahkan pihak perpustakaan dan
pemustaka dalam pencarian buku yang diingikan.
PURPOSE/KEGIATAN Sistem dapat digunakan oleh pihak perpustakaan sebagai
BISNIS berikut :
1. Untuk mendata seluruh buku dan arsip yang
dimiliki.
2. Mengelola kegiatan peminjaman dan pengembalian
buku serta denda.

1
 3. Mengelola data pemustaka.
4. Memudahkan pihak perpustakaan dan pemustaka
dalam pencarian buku yang diingikan.
SCOPE AND Lingkup kegiatan pekerjaan di Perpustakaan Kota
AGREEMENT Yogyakarta adalah sebagai berikut :
1. Kegiatan A : Pengumpulan data.
2. Kegiatan B : Inputing data tersebut ke database
3. Kegiatan C : Proses peminjaman buku.
4. Kegiatan D : Proses pengembalian buku dan denda.
5. Kegiatan E : Mengelola data pemustaka.
APPROACH Tahapan proses yang akan dilakukan dalam
pengembangan proyek Sistem Informasi Perpustakaan
Kota Yogyakarta :
1. Melakukan komunikasi dengan client yaitu
perpustakaan kota Yogyakarta.
2. Menganalisa kebutuhan proyek.
3. Mempelajari kebutuhan proyek.
4. Implementasi proyek.
5. Uji coba sistem.
PRODUCT Sistem informasi perpustakaan dapat bekerja dan
DESCRIPTION AND digunakan pada Perpustakaan Kota Yogyakarta. Sistem
DELIVERABLES dapat digunakan oleh pihak perpustakaan untuk mendata
seluruh buku dan arsip yang dimiliki, mengelola kegiatan
peminjaman dan pengembalian buku serta denda,
mengelola data pemustaka, dan memudahkan pihak
perpustakaan dan pemustaka dalam pencarian buku yang
diingikan.

PROJECT Project Management Plan nya mencakup :

MANAGEMENT 1. Project Charter.
2. Deskripsi dari Project Management (PM) approach.
3. Ruang lingkup / Cakupan pembahasan.
4. Work Breakdown Structure.
5. Estimasi Biaya, waktu pembuatan dan
penyelesaiannya, aturan dan responsibilities.
6. Rincian pengerjaan dari segi cakupan, waktu dan

2
 biaya.
7. Acuan Target dan tanggal masing-masing tahapan.
8. Sumber daya, Usaha dan Biaya yang dikeluarkan.
9. Perencanaan Manajemen Resiko.
10. Perencanaan Manajemen kualitas.
11. Perencanaan Manajemen komunikasi.

Project Management Plan ini diperbaharui dan dibuat

oleh Project Manager sesuai keperluan. Perencanaan
tersebut kemudian dijalankan dan dievaluasi secara
teratur untuk memperoleh kualitas perangkat lunak yang
bermutu. Team proyek akan dikembangkan untuk
memaksimalkan kinerja proyek. Semua anggota team
akan diberi target waktu berdasarkan jadwal dengan
memanfaatkan manajemen komunikasi.
ASSUMPTIONS, Sistem informasi perpustakaan dapat bekerja dan
CONSTRAINTS, RISK digunakan pada Perpustakaan Kota Yogyakarta. Sistem
dapat digunakan oleh pihak perpustakaan untuk mendata
seluruh buku dan arsip yang dimiliki, mengelola kegiatan
peminjaman dan pengembalian buku serta denda,
mengelola data pemustaka, dan memudahkan pihak
perpustakaan dan pemustaka dalam pencarian buku yang
diingikan.

RESOURCES Project Resources:

1. Human Resources:
a. 1 Project Manager (Project duration):
merencanakan, memanage, mengontrol project.
b. 1 System Analyst: merancang, mendesain system,
membagi tugas, mengeksekusi, komunikasi, dan
mengumpulkan data.
c. 2 Web Developer: membangun dan membuat code,
menguji sistem, mendesain UI, mendukung

3
 installasi, training.

d. Client: menguji sistem.

1) Material and Services Resources : Hosting
2) Financial Resources : Rp 500.000,-
COMMUNICATION Sistem informasi perpustakaan dapat bekerja dan
AND REPORTING digunakan pada Perpustakaan Kota Yogyakarta. Sistem
dapat digunakan oleh pihak perpustakaan untuk mendata
seluruh buku dan arsip yang dimiliki, mengelola kegiatan
peminjaman dan pengembalian buku serta denda,
mengelola data pemustaka, dan memudahkan pihak
perpustakaan dan pemustaka dalam pencarian buku yang
diingikan.
CHANGING Semua perubahan akan didokumentasikan, disampaikan
MANAGEMENT dan dinilai oleh Project Manager (PM). Jika perubahan
disetujui, maka jadwal proyek, ruang lingkup, dan
anggaran akan diperbarui dan disesuaikan serta
dikomunikasikan oleh penanggung jawab sesuai dengan
Comunication plan. PM / Team proyek akan
mengkomunikasi- kan perubahan yang telah disetujui dan
jadwal yang telah diperbarui kepada staf yang
bertanggung jawab untuk melaksanakan perubahan.
PROJECT TEAM PROJECT TEAM ROLES AND RESPONSIBLITIES

M. Faisal Natsir: Project Manager (PM) - menyiapkan

monitoring dan controlling project, menyetujui perubahan
project.

Mardiana Dwi M: System Analys - merancang,

mendesain system, membagi tugas, mengeksekusi,
komunikasi, dan mengumpulkan data.

Asti Nugraheni dan Adita Setya: Web Developer -

membangun dan membuat code, menguji sistem,

4
 mendesain UI, mendukung installasi, training.

Shafira Fitrianissas: Client - perencanaan dan

melaksanakan User Aceptance Testing, membuat resume
laporan hasil Testing, merencanakan regression Testing.

Customer dan manajemen Project Team sangat penting

untuk ikut berpartisipasi dalam melakukan klarifikasi
untuk semua hal yang mempengaruhi kelancaran proyek
sehingga proyek dapat diselesaikan dengan sukses.
AGREEMENT Project Manager: M. Faisal Natsir

Date: 1 November 2017

Sponsor:

Date:

2.1 ASSUMPTION/ CONSTRAINTS

Proyek ini akan direncanakan dengan beberapa asumsi sebagai berikut:
a. Proyek ini akan memberikan hosting dan berbasis web.
b. Server yang diberikan berjalan berbasis windows.
c. Penjadwalan survey lapangan dilaksanakan dengan asumsi cuaca yang
mendukung. Jadwal survey dapat berubah sewaktu waktu jika cuaca tidak
mendukung.
d. Dalam kaitannya dengan jadwal pengerjaan, 1 minggu kerja adalah 6 hari (Senin -
Sabtu).
e. Klien akan menyetujui rancangan desain sistem tidak lebih dari 12 hari.
f. Pengguna akan dapat menggunakan sistem setelah dilaksanakan pelatihan selama
satu minggu.

3. SCOPE MANAGEMENT
Untuk proyek ini, scope management merupakan tanggung jawab Manajer
Proyek. Ruanglingkup untuk proyek ini didefinisikan oleh Lingkup Pernyataan, Work
Breakdown Schedule (WBS) dan Kamus WBS. Manajer Proyek, Sponsor dan
Stakeholder akan menetapkan dan menyetujui dokumentasi untuk mengukur scope

5
proyek checklist kualitas dan performance. Perminataa perubahan scope dimulai oleh
Project Manager, Stakeholders atau anggota tim proyek lainnya. Semua permintaan
perubahan akan diserahkan kepada Manajer Proyek yang kemudian akan mengevaluasi
perubahan scope yang diminta. Setelah penerimaan permintaan perubahan scope, Project
Manager akan mengirimkan permintaan scope perubahan kepada Change Control Board
dan Sponsor Proyek untuk penerimaan. Setelah persetujuan perubahan scope oleh
Change Control Board dan Sponsor Proyek, Manajer Proyek akan memperbarui semua
dokumen proyek dan mengkomunikasikan perubahan scope kepada semua stakeholders.
Berdasarkan feedback dan masukan dari Manajer Proyek dan stakeholder, Project
Sponsor bertanggung jawab atas penerimaan deliverable proyek akhir dan scope proyek.

3.1 WORK BREAKDOWN SCHEDULE

1.0 Management
1.1 Project Plan
1.1.1 Membuat Project Plan
1.1.2 Mengupdate Project Plan
1.2 Requirement
1.2.1 Melakukan Pengumpulan Data
1.2.2 Membuat Requirement
1.3 Analisa Business Requirement
1.3.1 Mempersiapkan Dokumen Pengumpulan Data
1.3.2 Melakukan Analisa Business Requirement
1.3.3 Melakukan Review dan Membuat Resume Business Requirement
1.4 Hasil Analisa Business Requirement
1.4.1 Mempersiapkan Dokumen Hasil Analisis
1.4.2 Komunikasi dan Konfirmasi dengan Klien
2.0 Design
2.1 Desain Arsitektur
2.1.1 Arsitektur Desain Front View
2.1.2 Arsitektur Desain Back View
2.2 Desain Basis Data
2.2.1 Desain Basis Data Sumber Daya
2.3 Desain Antarmuka
2.3.1 Desain Antarmuka Front View
2.3.2 Desain Antarmuka Back View
2.4 Membuat Rincian Desain
2.4.1 Membuat Flow Diagram

6
 2.4.2 Membuat Software Design Spesification
3.0 Development
3.1 Membuat Basis Data
3.2 Membuat Antarmuka Pengguna
3.3 Melakukan Pengkodean Program
3.4 Melakukan Testing
3.4.1 Melakukan Unit Testing
3.4.2 Melakukan Integration Testing
3.4.3 Melakukan Regression Testing
3.5 Memasukkan Data
3.6 Membuat User Guide
4.0 User Acceptance Testing
4.1 Perencanaan User Aceptance Testing
4.2 Melaksanakan User Aceptance Testing
4.3 Membuat Resume Laporan Hasil Testing
4.4 Merencakakan Regression Testing
5.0 Deployment dan Instalasi
5.1 Membuat Perencanaan Instalasi
5.2 Melakukan Instalasi Komputer Klien
6.0 Training
6.1 Membuat Perencanaan Training
6.2 Mempersiapkan Kebutuhan Training
6.3 Melaksanakan Training
6.4 Melakukan Review Training
7.0 Maintenance dan Support
7.1 Mencetak Log Performa Sistem
7.2 Support Penggunaan
7.3 Perbaikan Bug Sistem

7
3.2 DEPLOYMENT PLAN
Sistem Informasi Perpustakaan Kota Yogyakarta merupakan aplikasi yang
dibuat untuk memenuhi kebutuhan data dan informasi yang akurat, benar, dan tepat
waktu dengan tujuan didapatkannya data - data sesuai yang dilaksanakan setiap
harinya. Sistem yang dibangun nantinya akan dihosting, database yang digunakan
adalah MySQL. Sistem yang dibuat akan berbasis website agar mudah dalam
pendataan setiap harinya. Pengolahan hasil pendataan tersebut menggunakan PC
komputer. Sistem hanya dapat dilihat oleh pegawai perpustakaan saja.
Pihak dari Perpustakaan Kota Yogyakarta nanti akan dijelaskan mengenai
sistem yang akan dibangun dan mencocokkan hasil rancangan tersebut dengan
keinginan user dan menjelaskan mengenai sistem tersebut. Hal ini juga dilakukan
dengan team proyek, dengan memberikan pemahaman mengenai rencana
pembangunan sistem tersebut, apa yang dibutuhkan, bagaimana rancangan
sistemnya, jadwal pembuatan dan kebutuhan sumber daya manusia untuk

8
 menyelesaikan proyek ini. Hal tersebut perlu diinformasikan kepada seluruh pihak
yang terlibat dalam proyek ini, sehingga memiliki pemahaman yang jelas baik
mengenai software pendukung proyek ini maupun data data yang dibutuhkan untuk
membangun sistem tersebut. Kedepannya diharapkan pegawai Perpustakaan Kota
Yogtakarta dapat melakukan pendataan dengan mudah.

3.3 CHANGE CONTROL MANAGEMENT

Dokumen change control management dan informasi yang berhubungan
dengan perubahan tersebut diperlukan untuk mengelola perubahan proyek secara
efektif dari awal proyek untuk disampaikan. Rencana manajemen perubahan dibuat
selama Tahap Perencanaan proyek. Pihak pihak yang terkait adalah manajer proyek,
tim proyek, sponsor proyek dari pihak Perpustakaan Kota Yogyakarta dan seluruh
pimpinan senior yang peranannya diperlukan untuk melaksanakan rencana tersebut.
Dokumen perubahan perlu dicatatan sejarah perubahan dalam contoh format seperti
dibawah ini:

Document control/change history

Version Author(s) Date Circulation Comments

Document approval and review

Approved by Perpustakaan Kota Yogyakarta

Date approved

Review date

Author(s)

Owning Department (s)

9
 Proses Manajemen Perubahan tersebut memiliki prosedur yang tersusun
dengan jelas dan efektif untuk melakukan tracking pada kesesuaian, koordinasi,
review, evaluasi, kategorisasi, dan persetujuan untuk release pada semua perubahan
baseline proyek.
Apabila terjadi perubahan jadwal yang telah ditetapkan dan disebabkan oleh
client maka akan terjadi pemunduran jadwal dari yang telah ditetapkan sebelumnya.
Hal ini merupakan diluar tanggung jawab developer. Apabila ada hal hal yang
mengalami perubahan dalam proyek yang akan dibangun akan dibicarakan pada pada
tahap pembangunan dan atas persetujuan manager proyek dan sponsor proyek atau
client.

4. SCHEDULE MANAGEMENT

Manajemen jadwal proyek merupakan bagian penting dari pembuatan rencana

pengembangan sistem informasi yang pada kasus ini adalah memanajemen pengerjaan
sistem informasi perpustakaan kota. Jadwal proyek akan berfungsi sebagai roadmap
bagaimana proyek akan dilaksanakan bagaimana jalannya proyek pada jangka waktu
pengerjaan. Jadwal akan memberikan informasi gambaran pada pihak-pihak yang terkait
dengan proyek seperti stakeholder, sponsor, dan tim proyek. Tujuan dari Schedule
manajemen ini adalah untuk menentukan pendekatan yang akan digunakan oleh tim
proyek membuat jadwal proyek. Rencana ini akan mencakup pengontrolan pekerjaan
yang dikerjakan oleh tim dan memanajemen perubahan jadwal. Hal ini termasuk
mengidentifikasi, menganalisis, memprioritaskan, mendokumentasikan, memprioritaskan,
menyetujui atau menolak, dan mempublish semua perubahan jadwal yang berhubungan
dengan perubahan tersebut.
4.1 SCHEDULE MANAGEMENT APPROACH
Pembuatan jadwal proyek dimulai dengan identifikasi permintaan dalam
Work Breakdown Schedule (WBS). Kegiatan yang telah didefinisikan akan
diidentifikasi dalam work package secara spesifik yang harus dilaksanakan untuk
menyelesaikan permintaan. Urutan Kegiatan digunakan untuk menentukan urutan
work package dan menetapkan hubungan antara kegiatan proyek. Estimasi durasi

10
 kegiatan akan digunakan untuk menghitung jumlah periode suatu pekerjaan yang
dibutuhkan untuk menyelesaikan suatu work package. Estimasi sumber daya akan
digunakan untuk menentukan sumber daya yang dibutuhkan oleh suatu work package
untuk menyelesaikan pembangunan system sesuai jadwal. Setelah jadwal awal telah
dibuat dan dikembangkan, maka akan ditinjau oleh tim proyek dan seluruh
sumberdaya yang ditugaskan untuk setiap tugas dalam proyek. Tim proyek dan
sumber daya harus setuju dengan tugas work package yang diberikan, durasi, dan
jadwalnya. Setelah semuanya selesai sponsor proyek akan meninjau dan menyetujui
jadwal tersebut dan kemudian hal tersebut akan menjadi baselined.

4.2 MILESTONES

Milestones Estimated Completion Timeframe

Penyelesaian Scope Statement dan WBS /
kamus WBS
Baseline jadwal proyek
Persetujuan final anggaran proyek
Memulai pengerjaan proyek
Pembagian dan persetujuan peran serta
tanggung jawab
Penentuan persetujuan Requirements
Penyelesaian pengumpulan data dan hasil
analisis
Acceptance of final deliverables
2 minggu setelah konsep proyek disetujui
3 hari setelah WBS dari proyek
1 minggu setelah jadwal proyek dan
kebutuhan sumberdaya telah ditetapkan dan
disetujui oleh client
3 hari setelah anggaran, jadwal dan
sumberdaya ditetapkan dan disetujui.
3 hari setelah penentuan sumber daya telah
dilakukan
1 minggu setelah requirement gathering.
2 minggu setelah requirement disetujui oleh
client
1 minggu setelah Integration testing

dan dilakukan UAT oleh client

Implementasi Proyek 3 hari setelah Acceptance of final
deliverables

4.3 PROJECT SCHEDULE

11
 ID Name Durasi November Desember Januari
72 hari 1 2 3 4 1 2 3 4 1 2 3 4
1 Management 15 hari
1.1 Project Plan 6 hari
1.1.1 Membuat Project Plan 3 hari
1.1.2 Mengupdate Project Plan 3 hari
1.2 Requirement 3 hari
1.2.1 Melakukan Pengumpulan Data 3 hari
1.2.2 Membuat Requirement 3 hari
1.3 Analisa Business Requirement 6 hari
1.3.1 Mempersiapkan Dokumen Pengumpulan Data 3 hari
1.3.2 Melakukan Analisa Business Requirement 6 hari
1.3.3 Melakukan Review dan Resume 6 hari
1.4 Hasil Analisa Business Requirement 3 hari
1.4.1 Mempersiapkan Dokumen Hasil Analisis 3 hari
1.4.2 Komunikasi dan Konfirmasi dengan Klien 3 hari
2 Design 12 hari
2.1 Desain Arsitektur 3 hari
2.1.1 Desain Arsitektur Front View 3 hari
2.1.2 Desain Arsitektur Back View 3 hari
2.2 Desain Basis Data 3 hari
2.2.1 Desain Basis Data Sumber Daya 3 hari
2.3 Desain Antarmuka 6 hari
2.3.1 Desain Antarmuka Front View 6 hari
2.3.2 Desain Antarmuka Back View 6 hari
2.4 Membuat Rincian Desain 6 hari
2.4.1 Membuat Flow Diagram 3 hari
2.4.2 Membuat Software Design Spesification 6 hari
3 Development 27 hari
3.1 Membuat Basis Data 3 hari

12
3.2 Membuat Antarmuka Pengguna 6 hari
3.3 Melakukan Pengkodean Program 18 hari
3.4 Melakukan Testing 9 hari
3.4.1 Melakukan Unit Testing 9 hari
3.4.2 Melakukan Integration Testing 9 hari
3.4.3 Melakukan Regression Testing 9 hari
3.5 Memasukkan Data 6 hari
3.6 Membuat User Guide 3 hari
4 User Aceptance Testing 6 hari
4.1 Perencanaan User Aceptance Testing 6 hari
4.2 Melaksanakan User Aceptance Testing 6 hari
4.3 Membuat Resume Laporan Hasil Testing 6 hari
4.4 Merencakakan Regression Testing 6 hari
5 Deployment dan Instalasi 6 hari
5.1 Membuat Perencanaan Instalasi 6 hari
5.2 Melakukan Instalasi Komputer Klien 6 hari
6 Training 3 hari
6.1 Membuat Perencanaan Training 3 hari
6.2 Mempersiapkan Kebutuhan Training 3 hari
6.3 Melaksanakan Training 3 hari
6.4 Melakukan Review Training 3 hari
7 Maintenance dan Support 6 hari
7.1 Mencetak Log Performa Sistem 6 hari
7.2 Support Penggunaan 6 hari
7.3 Perbaikan Bug Sistem 6 hari

13
4.3.1 DEPENDENCIES

Task
Mengupdate Project Plan
Mengupdate kebutuhan sistem
Mengkonfirmasi hasil analisa Mempersiapkan
kebutuhan sistem ke client
Membangun user interface
Membangun database sistem
Melakukan pengkodean program
Testing Sistem
Menginput Data
Uji coba sistem
Melaksanakan Training
Dependensi
Membuat Project Plan
Melakukan pengumpulan data dan
analisa serta interview
dokumen hasil
analisis
Membuat desain interface
Membuat desain database
Membangun database dan user
interface
Melakukan pengkodean program
Membangun database sistem
Perencaan uji coba sistem
Membuat Perencanaan Training dan
Membuat Material Training

4.3.2 SCHEDULE CONTROL

Schedule control diperlukan untuk mengevaluasi kembali jadwal yang

sebelumnya telah dibuat sehingga diharapkan pengerjaan tetap selesai sesuai
dengan jadwal. Dalam pengerjaan sistem informasi perpustakaan ini jadwal
proyek akan di review dan diperbarui oleh manajer proyek apabila diperlukan
dalam jangka waktu 2 minggu sekali sejak proyek ini dikerjakan hingga proyek
ini selesai. Selain itu manajer proyek juga bertanggung jawab untuk
menentukan dampak dari evaluasi jadwal, mengirimkan permintaan perubahan
jadwal, dan melaporkan status jadwal sesuai dengan communication
management plan.
Tim proyek juga memili tanggung jawab untuk ikut berpartisipasi
dalam mengupdate review jadwal setiap 2 minggu dan, melakukan komunikasi

14
 mengenai apapun yang berhubungan dengan perubahan secara aktual mengenai
tanggal start/finish kepada manajer proyek, dan juga berpartisipasi dalam
kegiatan review dan perubahan jadwal yang dibutuhkan.
Sponsor proyek akan mempertahankan status dari jadwal proyek dan
mereview/menyetujui permintaan perubahan jadwal disampaikan oleh manajer
proyek.

4.3.3 SCHEDULE CHANGE AND THRESHOLDS

Suatu proyek terkadang memerlukan perubahan jadwal terhadap jadwal

yang sudah ditentukan, Apabila akan ada perubahan jadwal maka diperlukan
pertemuaan terlebih dahulu antara tim dan manajer proyek untuk mengevaluasi
apakah benar-benar diperlukannya melakukan perubahan jadwal dan
memperhitungkan apabila ada perubahan jadwal akan berpengaruh pada bagian
apa saja pada masa mendatang. Manajer proyek dan tim proyek harus
menentukan tugas yang memberikan pengaruh terhadap proyek, varians
merupakan hal yang berpotensi untuk dilakukan perubahan, dan semua
alternatif dapat digunakan untuk melihat bagaimana varians tersebut
berpengaruh terhadap scope, jadwal, dan sumber daya. Apabila proses evaluasi
telah selesai dan ada perubahan yang melebihi kondisi batas yang telah
ditetapkan maka permalasahan tersebut akan diserahkan kepada seluruh tim
proyek.
Permintaan persetujuan perubahan jadwal juga diperlukan dari
persetujuan pihak sponsor juga apabila kondisi di bawah ini terlampaui:
1. Perubahan jadwal yang diminta akan mempengaruhi durasi kerja dari tiap
individu tim dengan memerlukan tambahan durasi sebesar 20% atau lebih
atau mengurangi durasi kerja individu sebesar 20% atau lebih.
2. Perubahan jadwal yang diminta akan mempengaruhi dari kesulurahan
jadwal yang direncakan dengan sebuah penambahan durasi sebesar 20%
atau lebih atau mengurangi durasi jadwal sebesar 20% atau lebih .

15
 Pdan permintaan perubahan jadwal yang tidak sampai memenuhi
kondisi tersebut maka hanya perlu meminta persetujuan dari manajer proyek
untuk diurus dengan semua tim.
Ketika semua perubahan sudah disetujui maka manajer proyek akan
memantau, mengawal, dan memanajemen dengan jadwal yang baru dan
manajer proyek perlu memberi semua info tentang jadwal yang baru terhadap
sponsor, stakeholder, tim proyek dari alasan dan dampaknya kedepan. Dan
Manajer proyek memastikan semua perubahan yang telah disepakati untuk di
arsipkan.

5. COST/ BUDGET MANAGEMENT

Project Manager akan bertanggung jawab untuk mengelola dan melaporkan biaya proyek
selama proyek Sistem Perpustakaan Kota Yogyakarta. Setiap bulan akan diadakan
pertemuan yang akan membahas kinerja proyek dan juga keuanagn. Project Manager juga
bertanggung jawab untuk menyampaikan masalah keuangan kepada pihak client yang
juga berperan sebagai sponsor yaitu Pemerintah Kota Yogyakarta.

5.1 COST MANAGEMENT APPROACH

Menggunakan pendekatan penilaian dengan indeks tertentu. Varians biaya +/-

0,1 merupakan indeks untuk biaya dan jadwal kinerja yang akan mengubah status
biaya sebagai peringatan. Varians biaya +/- 0,2 merupakan indeks untuk biaya dan
jadwal kinerja yang akan mengubah status biaya sebagai tahap peringatan yang
membutuhkan perhatian lebih, misalnya, nilai-nilai tersebut akan berubah menjadi
merah dalam proyek. Hal Ini akan memerlukan tindakan korektif dari Manajer
Proyek untuk mengembalikan indeks biaya dan jadwal kinerja menjadi tingkat siaga.

Performance Measure Yellow Red

Schedule Performance Antara 0.9 dan 0.8 atau Lebih kecil dari 0.8 atau
Index (SPI) Antara 1.1 dan 1.2 lebih besar dari 1.2
Cost Performance Index Antara 0.9 dan 0.8 atau Lebih kecil dari 0.8 atau
(CPI) Antara 1.1 dan 1.2 lebih besar dari 1.2

16
5.2 MEASURING PROJECT COSTS
Kinerja proyek akan diukur dengan menggunakan Earned Value
Management,diantaranya:
1. Schedule Varians (SV)
2. Cost Varians (CV)
3. Schedule Performance Indeks (SPI)
4. Cost Performance Index (CPI)

Jika Schedule Performance Indeks atau Cost Performance Index memiliki

perbedaan antara 0,1 dan 0,2 Project Manager harus melaporkan alasan untuk
pengecualian tersebut. Jika SPI atau CPI memiliki perbedaan lebih besar dari 0,2
Project Manager harus melaporkan alasan untuk pengecualian dan menyediakan
rincian korektif management plan untuk mengembalikan kinerja proyek ke level
yang sesuai. Perubahan biaya proyek harus diatas persetujuan sponsor proyek.

5.2.1 REPORTING FORMAT

Laporan akan dibuat dalam format bulanan termasuk didalamnya
manajemen biaya. Perbedaan seluruh biaya yang berada di luar batas yang
telah ditentukan dalam Rencana Pengelolaan Biaya akan dilaporkan, termasuk
tindakan korektif yang telah direncanakan. Pengubahan Permintaan akan
dimasukkan dalam laporan ini.

5.2.2 COST VARIANCE RESPONSE PROCESS

CPI atau SPI yang kurang dari 0.8 atau lebih dari 1.2 merupakan batas
kontrol biaya dalam proyek ini. Ketika proyek mencapai salah satu dari batas
tersebut maka diperlukan adanya Cost Variance Corrective Action Plan. Cost
Variance Corrective Action Plan merupakan rincian tindakan yang diperlukan
untuk mengembalikan proyek kedalam anggaran semula yang mana hal ini
merupakan tindakan yang efektif dalam perencanaannya.

Jadi nantinya Manajer Proyek akan menyampaikan pada Sponsor Proyek

mengenai pilihan untuk melakukan korektif dalam waktu empat hari kerja
ketika varians biaya pertama kali dilaporkan. Jika Sponsor Proyek memilih

17
 tindakan untuk melakukan korektif maka dalam waktu dua hari kerja pada saat
dia memutuskan melakukan korektif, Manajer Proyek akan menyampaikan
Cost Variance Corrective Action Plan secara resmi pada Sponsor Proyek.
Setelah hal tersebut diterima dan disetujui maka Cost Variance Corrective
Action Plan akan menjadi bagian dari rencana proyek dan proyek tersebut akan
diperbarui untuk memperlihatkan tindakan koreksi yang telah dilakukan.

5.2.3 COST CHANGE CONTROL PROCESS

Control proses perubahan biaya akan mengikuti proses perubahan
permintaan yang telah disepakati, dimana perubahan anggaran / biaya proyek
harus disetujui oleh sponsor proyek selaku sumber dana dalam proyek.

5.3 MEASURING PROJECT COSTS

5.3.1 PERHITUNGAN BIAYA PEKERJAAN PERSONIL

Personil Jumla Biaya/Hari

h
Project Manager 1 300.000
Web Developer 2 200.000
Analis 1 250.000

Penanggung
ID Durasi Cost Total
Name Jawab
72 hari 46500000
1 Management 15 hari
1.1 Project Plan 6 hari 900000
1.1.1 Membuat Project Plan 3 hari Project Manager 900000
1.1.2 Mengupdate Project Plan 3 hari Project Manager 900000
1.2 Requirement 3 hari 1650000
1.2.1 Melakukan Pengumpulan Data 3 hari Analis 750000
1.2.2 Membuat Requirement 3 hari Project Manager 900000
1.3 Analisa Business Requirement 6 hari 2550000
Mempersiapkan Dokumen
1.3.1 3 hari Analis 750000
Pengumpulan Data
Melakukan Analisa Business
1.3.2 6 hari Project Manager 1800000
Requirement
1.3.3 Melakukan Review dan Resume 6 hari Project Manager 1800000
1.4 Hasil Analisa Business Requirement 3 hari 1650000
1.4.1 Mempersiapkan Dokumen Hasil 3 hari Analis 750000

18
 Analisis
Komunikasi dan Konfirmasi
1.4.2 3 hari Project Manager 900000
dengan Klien
2 Design 12 hari
2.1 Desain Arsitektur 3 hari 750000
2.1.1 Desain Arsitektur Front View 3 hari Analis 750000
2.1.2 Desain Arsitektur Back View 3 hari Analis 750000
2.2 Desain Basis Data 3 hari 750000
2.2.1 Desain Basis Data Sumber Daya 3 hari Analis 750000
2.3 Desain Antarmuka 6 hari 4800000
2.3.1 Desain Antarmuka Front View 6 hari Web Dev 2400000
2.3.2 Desain Antarmuka Back View 6 hari Web Dev 2400000
2.4 Membuat Rincian Desain 6 hari 1500000
2.4.1 Membuat Flow Diagram 3 hari Analis 750000
Membuat Software Design
2.4.2 6 hari Analis 1500000
Spesification
3 Development 27 hari 21600000
3.1 Membuat Basis Data 3 hari Web Dev 1200000
3.2 Membuat Antarmuka Pengguna 6 hari Web Dev 2400000
3.3 Melakukan Pengkodean Program 18 hari Web Dev 7200000
3.4 Melakukan Testing 9 hari 4350000
3.4.1 Melakukan Unit Testing 9 hari Web Dev 3600000
3.4.2 Melakukan Integration Testing 9 hari Web Dev 3600000
3.4.3 Melakukan Regression Testing 9 hari Web Dev 3600000
3.5 Memasukkan Data 6 hari Web Dev 2400000
3.6 Membuat User Guide 3 hari Analis 750000
4 User Aceptance Testing 6 hari
4.1 Perencanaan User Aceptance Testing 6 hari Client
Melaksanakan User Aceptance
4.2 6 hari Client
Testing
Membuat Resume Laporan Hasil
4.3 6 hari Client
Testing
4.4 Merencakakan Regression Testing 6 hari Client
5 Deployment dan Instalasi 6 hari 2400000
5.1 Membuat Perencanaan Instalasi 6 hari Web Dev 2400000
5.2 Melakukan Instalasi Komputer Klien 6 hari Web Dev 2400000
6 Training 3 hari 1200000
6.1 Membuat Perencanaan Training 3 hari Web Dev 1200000
6.2 Mempersiapkan Kebutuhan Training 3 hari Web Dev 1200000
6.3 Melaksanakan Training 3 hari Web Dev 1200000
6.4 Melakukan Review Training 3 hari Web Dev 1200000
7 Maintenance dan Support 6 hari 2400000
7.1 Mencetak Log Performa Sistem 6 hari Web Dev 2400000
7.2 Support Penggunaan 6 hari Web Dev 2400000
7.3 Perbaikan Bug Sistem 6 hari Web Dev 2400000

19
5.3.2 PERHITUNGAN BIAYA HARDWARE DAN SOFTWARE

No Items Unit Biaya/ Unit Subtotal Total

1. Hardware
Komputer 3 3000.000 9.000.000 9.000.000
2. Software
Domain + Hosting 1 3000.000 3.000.000 8.000.000
Lisensi 1 5.000.000 5.000.000
Total 17.000.000

Dari table diatas jumlah total biaya pengembangan dari segi software dan
hardware yang dibutuhkan adalah: 17.000.000

5.3.3 PERHITUNGAN BIAYA TOTAL PROYEK

Anggaran untuk proyek ini secara rinci dapat dilihat sebagai berikut:
Biaya Pekerjaan Personil: 46.500.000
Biaya Hardware dan Software: Rp 17.000.000,-
Biaya Cadangan: Rp 7.500.000
TOTAL BIAYA: Rp 71.000.000

20