Pengelolaan Proyek Sistem
Informasi
Fase Definisi
Outline
Framework PPSI
 Metodologi
 Software Product RD
 Go/No Go Decision
 Perencanaan Proyek

Framework PPSI

“Project always begin with Problem”
(John J. Rakos)
Framework PPSI

Proyek yang baik adalah proyek yang
mencapai titik kesetimbangan antara
waktu, biaya dan kualitas
Framework PPSI

Project Scope Management: Proses yang
dibutuhkan untuk menentukan lingkup
proyek termasuk segala proses dan semua
pekerjaan yang dibutuhkan untuk
menyelesaikan proyek, meliputi:
◦
◦
◦
◦
◦
initiation
scope planning
scope definition
scope verification
scope change control
Framework PPSI

Project Time Management: Proses
yang dibutuhkan untuk memastikan
penggunaan waktu dalam penyelesaian
proyek, meliputi:
◦
◦
◦
◦
◦
activity definition
activity sequencing
activity duration estimating
schedule development
schedule control
Framework PPSI

Project Cost Management: Proses
yang dibutuhkan untuk melakukan
pengaturan pelaksanaan dengan budget
yang sudah disetujui, meliputi:
◦
◦
◦
◦
resource planning
cost estimating
cost budgeting
cost control
Framework PPSI

Project Quality Management: Proses
yang dibutuhkan untuk memastikan bahwa
proyek akan diselesaikan sesuai yang
ditetapkan dalam pelaksanaanya, meliputi:
◦ quality planning
◦ quality assurance
◦ quality control
Framework PPSI

Project Human Resource
Management: Proses yang dibutuhkan
untuk membuat pemanfaatan SDM yang
paling efektif yang terlibat dengan proyek
tersebut, meliputi:
◦ organizational planning
◦ staff acquisition
◦ team development
Framework PPSI

Project Communications
Management: Proses yang dibutuhkan
untuk memastikan proyek tepat waktu,
menyediakan bagian-bagian informasi, koleksi,
penyebaran, penyimpanan dan disposisi
terakhir informasi proyek, meliputi:
◦
◦
◦
◦
◦
communications
planning
information distribution
performance reporting
administrative closure
Framework PPSI

Project Risk Management: Proses
yang berkonsentrasi dengan identifikasi,
analisa dan merespon resiko proyek,
misalnya:
◦
◦
◦
◦
risk identification
risk quantification
risk response development
risk response control
Framework PPSI

Project Procurement Management:
Proses yang dibutuhkan untuk
mendefinisikan kebutuhan dan layanan dari
luar organisasi yang dapat mempengaruhi
kelangsungan proyek, misalnya:
◦
◦
◦
◦
◦
◦
procurement planning
solicitation planning
solicitation
source selection
contract administration
contract close-out
Framework PPSI

Project Integration Management:
Proses yang dibutuhkan untuk
memastikan berbagai variasi elemen
proyek terkoordinasi dengan baik,
meliputi:
◦ project plan development
◦ project plan execution
◦ overall change control
Metodologi

Sounds familiar?
◦ Schedule slips – the day for delivery comes and you
have to tell the customer that the software won’t be
ready for another six months
◦ Project cancelled – after numerous slips, the project is
cancelled without ever going into production
◦ System goes sour – the software is successfully put
into production, but after a couple of years the cost
of making the changes or the defect rate rises so
much that the system must be replaced
◦ Defect rate – the software is put into production, but
the defect rate is so high that it isn’t used
Kent Beck
Metodologi

Sounds familiar? (con’td)
◦ Business misunderstood – the software is put into
production, but it doesn’t solve the business problem that
was originally posed
◦ Business changes – the software is put into production,
but the business problem it was designed to solve was
replaced six months ago by another, more pressing,
business problem
◦ False feature rich – the software has a host of potentially
interesting features, all of which were fun to program, but
none of which makes the customer much money
◦ Staff turnover – after two years, all the good programmers
on the project begin to hate the program and leave
Kent Beck
Metodologi

Yang kita inginkan adalah:
◦
◦
◦
◦
◦
◦
◦
On Time
On Budget
Have the required features
Met the quality standards
Productivity
Predictability
Repeatability
Metodologi
Metodologi adalah deskripsi dari proses
untuk membawa suatu produk software
melalui semua atau sebagian dari life cycle
 Biasanya berfokus pada fase life cycle dan
relasi antara fase yang satu dengan lainnya

Metodologi

Software Life Cycle
◦ Requirements specification resulting in the
product requirements document
◦ Design resulting in the Software architecture
◦ Construction (implementation or coding)
resulting in the actual software
◦ Integration
◦ Testing and debugging
◦ Installation
◦ Maintenance
Metodologi

Contoh dari metodologi yang ada:
◦
◦
◦
◦
◦
◦
◦
◦
MSF (Microsoft Solutions Framework)
XP (Extreme Programming)
RUP (Rational Unified Process)
CMMI (Capability Maturity Model Integration)
SCRUM
Feature Driven Development (FDD)
Formal Methods (Formal to the Extreme)
Hajar BlehTM Programming
Metodologi

Mengapa ada banyak metodologi?
◦ We develop many different types of
applications
◦ Many different software development cultures
and competitive environments
◦ Ego (The drive to be unique)
Software Product RD





Tujuan dan lingkup produk, baik dari sudut teknis maupun bisnis
Identifikasi stakeholder
Perkiraan pasar
Gambaran tentang produk
Kebutuhan (requirement), mencakup:
◦ functional requirements (e.g. what a product should do)
◦ usability requirements
◦ technical requirements (e.g. security, network, platform, integration,
client)
◦ environmental requirements
◦ support requirements
◦ interaction requirements (e.g. how the software should work with
other systems)


Batasan
Evaluasi dan performa
Software Product RD

Stakeholder
Bukan hanya pihak yang mempekerjakan analis,
tetapi juga termasuk:
◦ anyone who operates the system (normal and maintenance
operators)
◦ anyone who benefits from the system (functional, political,
financial and social beneficiaries)
◦ anyone involved in purchasing or procuring the system
◦ organizations which regulate aspects of the system (financial,
safety, and other regulators)
Software Product RD
◦ people or organizations opposed to the system
(negative stakeholders)
◦ organizations responsible for systems which interface
with the system under design
◦ those organizations who integrate horizontally with
the organization for whom the analyst is designing the
system
Software Product RD
Software Product RD

Masalah dalam requirement:
◦ Stakeholder
 Users do not understand what they want or users don't have
a clear idea of their requirements
 Users will not commit to a set of written requirements
 Users insist on new requirements after the cost and schedule
have been fixed
 Communication with users is slow
 Users often do not participate in reviews or are incapable of
doing so
 Users are technically unsophisticated
 Users do not understand the development process
 Users do not know about present technology
Steve McConnell
Software Product RD

Masalah dalam requirement:
◦ Engineer/developer
 Engineer/developer starts coding/implementation immediately
before they really understand the whole requirement from
analyst, which usually causes lots of defect fixing or reworking
in test/verification phase
 Technical personnel and end-users may have different
vocabularies. Consequently, they may wrongly believe they are
in perfect agreement until the finished product is supplied
 Engineers and developers may try to make the requirements
fit an existing system or model, rather than develop a system
specific to the needs of the client
 Analysis may often be carried out by engineers or
programmers, rather than personnel with the domain
knowledge to understand a client's needs properly
Go/No Go Decision

Studi kelayakan bisnis adalah suatu
kegiatan yang cukup mendalam dan
komprehensif untuk mengetahui apakah
pengembangan usaha yang akan dilakukan
layak atau tidak
Go/No Go Decision

Menurut Kasmir dan Jakfar ada lima
tujuan mengapa sebelum suatu usaha atau
proyek dijalankan perlu dilakukan studi
kelayakan yaitu:
◦
◦
◦
◦
◦
Menghindari resiko kerugian
Memudahkan perencanaan
Memudahkan pelaksanaan pekerjaan
Memudahkan pengawasan
Memudahkan pengendalian
Go/No Go Decision

Faktor-faktor penyebab kegagalan suatu bisnis:
◦ Data dan informasi tidak lengkap atau adanya
ketidaklengkapan dan kepalsuan data
◦ Tidak teliti atau adanya kecerobohan yang menyebabkan
kesalahan
◦ Salah perhitungan atau adanya kesalahan saat perhitungan
ataupun rumus-rumus yang digunakan
◦ Pelaksanaan pekerjaan salah atau adanya pekerja yang tidak
mengerjakan proyek berdasarkan pedoman yang
ditetapkan
◦ Kondisi lingkungan atau adanya unsur-unsur yang tidak
dapat dikendalikan
◦ Unsur sengaja atau adanya kesalahan yang disengaja oleh
peneliti dengan berbagai sebab. Hal ini sangat fatal
Go/No Go Decision

Faktor yang mempengaruhi seseorang
untuk melakukan pengambilan keputusan:
◦ Kondisi internal dan eksternal organisasi
◦ Ketersediaan informasi
◦ Ketrampilan pengambil keputusan
Go/No Go Decision

Aspek-aspek penilaian dalam studi kelayakan adalah:
◦ Aspek hukum: untuk meneliti kelengkapan, kesempurnaan dan
keaslian izin-izin dan dokumen-dokumen
◦ Aspek pasar dan pemasaran: meneliti besar pasar dan
kemampuan perusahaan menguasainya, serta menilai strateginya
◦ Aspek keuangan: menilai perolehan pendapatan dan biaya yang
dikeluarkan
◦ Aspek teknis/operasional: menentukan lokasi, layout gedung dan
ruangan serta teknologi yang digunakan
◦ Aspek manajemen: meneliti kesiapan SDM yang menjalani usaha
◦ Aspek ekonomi dan sosial: menilai manfaat usaha terhadap
ekonomi dan sosial masyarakat
◦ Aspek dampak lingkungan: menilai dampak lingkungan yang dapat
ditimbulkan
Perencanaan Proyek
Meyakinkan rekan-rekan yang lain bahwa
proyek tersebut sebaiknya dibuat dengan
membuat sebuah proposal
 Sebuah proposal adalah dokumen yang
merinci biaya dan jadwal proyek serta
garis besar langkah langkah yang akan
digunakan oleh suatu perusahaan untuk
memproduksi produk

Perencanaan Proyek
PPP
 WBS
 Project Network Diagram
 Project Cost
 Project Schedule
 PPP Outline

Perencanaan Proyek

Preliminary Project Plan (PPP)
Sebuah rencana untuk proyek software
yang menjabarkan akrifitas yang diinginkan,
berapa lama setiap aktifitas dilakukan,
kapan aktifitas ini harus mengambil tempat
dan berapa banyak sumber daya yang
dihabiskan pada setiap aktifitas untuk
memproduksi hasil yang diinginkan
Perencanaan Proyek

Work Breakdown Structure (WBS)
◦ Dekomposisi suatu proyek menjadi komponen
yang lebih kecil
◦ Memiliki struktur tree
◦ Komponennya dapat berupa produk, data,
layanan, atau campuran
◦ WBS menyediakan kerangka kerja yang
dibutuhkan untuk perkiraan biaya dan kontrol
sehingga memudahkan pengembangan
penjadwalan
Perencanaan Proyek

Work Breakdown Structure (WBS)
◦ 100% rule
 “the sum of the work at the “child” level must equal 100% of the work
represented by the “parent” and the WBS should not include any work that
falls outside the actual scope of the project, that is, it cannot include more than
100% of the work”
◦ Rule of thumb
 80 hours rule: no single activity or group of activities at the
lowest level of detail of the WBS to produce a single
deliverable should be more than 80 hours of effort
 no activity or group of activities at the lowest level of detail of
the WBS should be longer than a single reporting period
 “if it makes sense” rule: one can apply "common sense" when
creating the duration of a single activity or group of activities
necessary to produce a deliverable defined by the WBS
Perencanaan Proyek

Work Breakdown Structure (WBS)
◦ Sampai kapan dilakukan?
 dapat diperkirakan secara realistis
 komponen sudah tidak mungkin untuk dibagi lagi
 dapat dilaksanakan mengikuti aturan-aturan yang
disebutkan sebelumnya
 menghasilkan suatu hasil yang dapat diperkirakan
Perencanaan Proyek

Work Breakdown Structure (WBS)
Perencanaan Proyek

Work Breakdown Structure (WBS)
Perencanaan Proyek

Work Breakdown Structure (WBS)
Perencanaan Proyek

Work Breakdown Structure (WBS)
Perencanaan Proyek
AKTIFITAS
USAHA
PRECEDENT
Definition
20
-
Analysis
35
Definition
Design
25
Analysis
Program A (control)
20
Design
Program B (registration)
30
Design
Program C (warehouse)
25
Design
System test
10
Program A, B, C
Documentation
20
Design
Acceptance
5
System Test,
Documentation
Training
10
Documentation
Operation
10
Acceptance
TOTAL
210 person - days
Perencanaan Proyek

Project Network Diagram
◦ Menggambarkan urutan komponen proyek
dan ketergantungannya (dependency)
◦ “The work breakdown structure show the "part-whole"
relations. In contrast, the project network shows the
"before-after" relations”
Perencanaan Proyek

Project Network Diagram
Perencanaan Proyek

Project Cost
◦ Jika kontrak dari proyek sudah disetujui, manajer
proyek dapat menghitung harga kotor, untuk
tenaga kerja dengan mengalikan jumlah biaya
buruh per hari dengan biaya rata-rata per hari
◦ Jika anda menghitung biaya secara manual dan
anda yakin bahwa total perkiraan dari 210
orang/hari, harga proyek dengan mengalikan 210
denga rata-rata biaya per hari, dan menambah
biaya tetap peralatan
Perencanaan Proyek

Project Schedule
◦ Salah satu kesulitan tugas ini adalah
mengalokasikan sumber daya manusia yang
akan melakukan pekerjaan yang akan
dilaksanakan, terutama ketika tugas berjalan
secara serentak. Kesulitan lain adalah
memutuskan bagaimana mempersingkat
pekerjaan yang akan dilakukan dengan
menggunakan sumber daya yang ada
Perencanaan Proyek

Project Schedule
Gantt Chart menggunakan Microsoft Project
Perencanaan Proyek

PPP Outline
Merupakan garis besar yang diusulkan
untuk PPP
Perencanaan Proyek

PPP Outline
◦ Project team, organisasi dari tim proyek, siapa
yang membuat laporan untuk siapa, siapa
berkomunikasi dengan siapa dan lain-lain
◦ Biaya proyek, perkiraan dan perhitungan yang
dipergunakan untuk menentukan harga/biaya
◦ Jadwal proyek, Merupakan inti dari proyek
◦ Pemeriksaan ulang, tujuan dari setiap pemeriksaan
dan siapa yang akan menghadirinya, catat tanggung
jawab semua orang yang terlibat didalamnya
Perencanaan Proyek

PPP Outline
◦ Laporan, bentuk dan isi dari laporan status, laporan
milestone dan dokumen proyek lain dirinci disini,
serta daftar orang yang menerima tiap laporan dan
apa tanggapannya setelah menerima laporan tersebut
◦ Dokumentasi, dokumen mana yang akan diproduksi
dan tanggapan yang bersangkutan dari 2 jenis
dokumen didalam proyek: pengguna dan manajemen
proyek
◦ Kesimpulan, fakta-fakta yang diberikan kepada anda
(kadang-kadang lisan) oleh pengguna