Anda di halaman 1dari 42

CHAPTER 4

PROJECT MANAGEMENT

Diajukan untuk Memenuhi Salah Satu Syarat Kelulusan Mata Kuliah


Analisis Perancangan Sistem Informasi

Disusun Oleh :
Nama/NPM

: Fachri Shidqi H / 10070213099


: M. Subhan R / 10070213100
: Ersa Madhenti K / 10070213101

Kelas

: Arif Ridwan / 10070213103


:B

PROGRAM STUDI TEKNIK INDUSTRI


FAKULTAS TEKNIK
UNIVERSITAS ISLAM BANDUNG

2016 M / 1437 H
Chapter 4 Project Management
Apa projek manajemen itu?
Manajemen proyek adalah proses pengelolaan proyek yang meliputi
perencanaan, pengorganisasian dan pengaturan tugas- tugas serta sumber daya yang
dimiliki untuk mewujudkan tujuan yang ingin dicapai, dengan mempertimbangkan
factor-faktornya, terutama waktu dan biaya.
Proyek adalah suatu rangkaian pekerjaan yang diada-kan dalam selang waktu
tertentu & mempunyai tujuan khusus. yang membedakan proyek dengan pekerjaan
lain adalah sifatnya yang khusus dan tidak bersifat rutin pengadaannya, sehingga
pengelolaannya pun memerlukan ekstra lebih banyak. Semua proyek selalu
mengandung resiko relatif besar berkaitan dengan manajemen yang diterapkan untuk
proyek itu.
Manajemen proses adalah kegiatan yang sedang berlangsung yang
mendokumentasikan,

mengelola

penggunaan,

dan

meningkatkan

metodologi

organisasi yang dipilih ( "proses") untuk pengembangan sistem. Proses manajemen


berkaitan dengan kegiatan, kiriman, dan standar kualitas yang harus diterapkan untuk
semua proyek. Ruang lingkup manajemen proses adalah semua proyek, dimana ruang
lingkup manajemen proyek adalah proyek tunggal. Adaptor ini akan fokus pada
manajemen proyek.
manajemen

proyek

proses

melingkupi,

perencanaan,

kepegawaian,

pengorganisasian, pengarahan, dan pengendalian pengembangan sistem yang dapat


diterima dengan biaya minimal dan dalam jangka waktu tertentu. manajemen proses
aktivitas

mendokumentasikan,

mengelola,

dan

terus

meningkatkan

pengembangan sistem.
Penyebab Proyek Gagal
Dari perspektif manajemen proyek, proyek dianggap sukses jika:

Sistem informasi yang dihasilkan dapat diterima kepada pelanggan.

proses

Sistem ini disampaikan "tepat waktu."


Sistem ini disampaikan "dalam anggaran."
Proses pengembangan sistem memiliki dampak minimal pada operasi bisnis
yang sedang berlangsung.
Tidak semua proyek memenuhi kriteria tersebut. dan sebagai hasil. tidak

semua proyek yang sukses. Kegagalan dan keberhasilan yang terbatas jauh melebihi
sistem informasi sukses. Proyek urus dapat merusak aplikasi terbaik dari analisis
sistem dan desain metode yang diajarkan dalam buku ini. Kita bisa mengembangkan
apresiasi akan pentingnya manajemen proyek dengan mempelajari kesalahan dari
beberapa manajer proyek. Mari kita meneliti beberapa masalah salah urus proyek dan
konsekuensi:

Kegagalan untuk membentuk komitmen manajemen atas untuk proyek -

Kadang-kadang komitmen berubah selama proyek.


Kurangnya komitmen organisasi dengan metodologi pengembangan
sistem
- Banyak metodologi pengembangan sistem melakukan sedikit lebih dari

mengumpulkan debu
Mengambil jalan pintas

meskipun

atau

sekitar

metodologi

pengembangan sistem
- tim proyek sering mengambil jalan pintas untuk satu atau lebih dari
-

alasan berikut:
Proyek ini mendapat belakang jadwal, dan tim ingin mengejar

ketinggalan.
Proyek ini melebihi anggaran, dan tim ingin membuat biaya dengan

melewati Langkah
Tim ini tidak terlatih atau terampil dalam beberapa kegiatan metodologi
dan persyaratan, sehingga melompat mereka.

manajemen harapan Miskin

Semua pengguna dan manajer memiliki harapan proyek. Seiring waktu,


harapan ini dapat berubah. Hal ini dapat menyebabkan dua situasi yang
tidak diinginkan:
- Cakupan creep pertumbuhan yang tak terduga dari harapan pengguna
dan kebutuhan bisnis untuk sistem informasi sebagai proyek
berlangsung. Jadwal dan anggaran dapat terpengaruh oleh perubahan
-

tersebut.
Fitur creep penambahan terkendali fitur teknis untuk sistem yang

sedang dikembangkan tanpa memperhatikan jadwal atau anggaran.


komitmen prematur untuk anggaran tetap dan jadwal.
- Anda jarang dapat membuat perkiraan yang akurat dari biaya proyek
dan jadwal sebelum menyelesaikan analisis masalah atau analisis
kebutuhan

rinci.

Perkiraan

prematur

tidak

konsisten

dengan

pendekatan komitmen merayap diperkenalkan pada Bab 3.


Miskin memperkirakan teknik
- Banyak sistem analis memperkirakan dengan membuat perkiraan
terbaik dihitung dan kemudian menggandakan jumlah itu. Ini bukan

pendekatan ilmiah.
Lebih dari optimism
- analis sistem dan manajer proyek cenderung optimis. Seperti jadwal
proyek tergelincir. mereka menjawab, "Tidak ada masalah besar. Kita
bisa melakukannya nanti. "Mereka gagal untuk mengakui bahwa
tugas-tugas tertentu bergantung pada tugas-tugas lainnya. Karena
dependensi ini. jadwal tergelincir dalam satu fase atau kegiatan akan
menyebabkan sesuai slip dalam banyak tahapan dan kegiatan lainnya.

sehingga memberikan kontribusi untuk overruns biaya.


The mitos man bulan
- Sebagai proyek mendapat belakang jadwal, pimpinan proyek sering
mencoba untuk memecahkan masalah dengan menetapkan lebih
banyak orang untuk tim. tidak bekerja! Tidak ada hubungan linear
antara waktu dan jumlah personil. Penambahan personil biasanya
menciptakan masalah komunikasi yang lebih, menyebabkan proyek

untuk mendapatkan lebih jauh di belakang jadwal.


orang yang tidak memadai keterampilan manajemen

Manajer cenderung didorong masuk ke posisi manajemen dan tidak


siap untuk tanggung jawab manajemen. Masalah ini mudah untuk
mengidentifikasi. Tidak ada yang tampaknya bertanggung jawab;
pelanggan tidak mengetahui status proyek; tim tidak bertemu secara
teratur untuk membahas dan memonitor kemajuan; anggota tim tidak
berkomunikasi dengan satu sama lain; proyek ini selalu dikatakan "95

persen selesai."
Kegagalan untuk beradaptasi dengan perubahan bisnis
- Jika pentingnya proyek perubahan selama proyek, atau jika
manajemen atau bisnis mereorganisasi, proyek harus dinilai ulang
untuk kompatibilitas dengan perubahan-perubahan dan pentingnya

mereka untuk bisnis.


Kurangnya sumber daya
- ini bisa disebabkan estimasi miskin atau prioritas lain. atau bisa juga
bahwa sumber daya staf ditugaskan untuk proyek tidak memiliki

keterampilan yang diperlukan atau pengalaman.


Kegagalan untuk "mengelola rencana" faktor
- Berbagai dapat menyebabkan manajer proyek untuk menjadi
teralihkan dari rencana proyek asli.
Pada akhirnya, utama penyebab kegagalan proyek adalah bahwa sebagian

besar manajer proyek tidak berpendidikan atau dilatih untuk menjadi manajer proyek.
seperti programmer yang baik tidak selalu pergi untuk menjadi baik analis sistem.
baik analis sistem tidak otomatis tampil baik sebagai manajer proyek. Untuk menjadi
manajer proyek yang baik, Anda harus dididik dan terampil dalam "seni manajemen
proyek.
The Project Management Body of Knowledge
Proiect Manajer kompetensi manajer proyek yang baik memiliki satu set inti
kompetensi. kompetensi manajemen proyek: Pertama. individu tidak dapat mengelola
proses mereka tidak pernah menggunakan. Kedua, manajer harus memiliki

pemahaman tentang bisnis dan budaya yang menyediakan konteks untuk proyek
tersebut.
Fungsi Dasar Manajemen Proyek
Fungsi dasar dari manajer proyek telah dipelajari dan disempurnakan oleh
theoriss manajemen selama bertahun-tahun. Fungsi ini termasuk scoping, planning
(perencanaan), estimating, organizing (pengorganisasian), scheduling (penjadwalan),
directing (mengarahkan), controling (pengendalian), dan closing (penutupan) :

scoping (Penjajakan) - Cakupan mendefinisikan batas-batas prolect tersebut.


Seorang manajer proyek harus harapan proyek ruang lingkup dan consraints

untuk merencanakan kegiatan. biaya perkiraan. dan mengelola harapan.


planning (perencanaan) - perencanaan mengidentifikasikan tugas yang
dibutuhkan untuk menyelesaikan proyek. Hal ini didasarkan pada manajer
pemahaman tentang ruang lingkup prolect dan metodologi yang digunakan

untuk mencapai tujuan-.


estimating (Memperkirakan)

Setiap

tugas

yang

diperlukan

untuk

menyelesaikan proyek harus diestimasi. Berapa banyak waktu akan


diperlukan? Berapa banyak orang akan dibutuhkan? Keterampilan apa yang
akan dibutuhkan? Tugas apa yang harus diselesaikan sebelum tugas lain
dimulai? Dapat beberapa tugas tumpang tindih? Berapa biayanya? Ini semua
adalah masalah memperkirakan. Beberapa masalah ini dapat diselesaikan

dengan proyek pemodelan alat yang akan dibahas kemudian dalam bab ini-.
scheduling (Penjadwalan) - Mengingat rencana proyek, manajer proyek
bertanggung jawab untuk penjadwalan semua kegiatan proyek. Jadwal proyek
harus

dikembangkan

dengan

pemahaman

tentang

tugas-tugas

yang

diperlukan. tugas dtration. dan prasyarat tugas


organizing (pengorganisasian) - Manajer proyek harus memastikan bahwa
anggota tim proyek memahami peran mereka sendiri individu dan tanggung

jawab serta hubungan pelaporan mereka untuk manajer proyek-..


Directing (Pengarahan) - Setelah proyek telah dimulai, manajer proyek harus
mengarahkan kegiatan tim. Setiap manajer proyek harus demonsrate orang

keterampilan

manajemen

untuk

mengkoordinasikan,

mendelegasikan,

memotivasi, menyarankan, menilai, dan menghargai anggota tim-.


controling (pengendalian) - Beberapa rencana akan dilaksanakan tanpa
masalah dan penundaan. Manajer proyek harus memantau dan melaporkan
kemajuan terhadap tujuan, jadwal, dan biaya dan membuat penyesuaian

approprhte bila diperlukan-.


closing (penutupan) - Manajer proyek yang baik selalu menilai keberhasilan
dan kegagalan pada akhir proyek. Mereka belajar dari kesalahan mereka dan
berencana untuk lmprovernent terus menerus dari proses pengembangan
sistem.

PERT dan Gantt chart sebagai alat manajemen proyek


alat dan teknik yang mendukung manajemen proyek yaitu PERT dan Gantt
chart. PERT, yang merupakan singkatan dari Project Evaluation and Review
Technique yang berarti Evaluasi Proyek dan Ulasan Teknik, dikembangkan akhir
1950-an untuk merencanakan dan mengendalikan proyek-proyek pengembangan
senjata besar untuk US Navy. Sebuah grafik PERT adalah suatu model jaringan grafis
yang menggambarkan tugas-tugas proyek dan hubungan antara tugas-tugas.
Gantt chart, pertama dikandung oleh Henry L Gantt pada tahun 1917, adalah
penjadwalan proyek dan kemajuan alat evaluasi yang paling umum digunakan. Gantt
chart adalah bagan batang horizontal sederhana yang menggambarkan tugas-tugas
proyek terhadap kalender.
Gantt dan PERT chart tidak saling eksklusif. Gantt chart lebih efektif bila
Anda sedang mencari untuk berkomunikasi jadwal. PERT chart lebih efektif bila
Anda ingin mempelajari hubungan antara tugas-tugas.

Manajemen Proyek perangkat lunak manajemen Software Project secara rutin


digunakan untuk membantu rencana proyek manajer proyek, mengembangkan
jadwal, mengembangkan anggaran, memonitor kemajuan dan biaya, menghasilkan

laporan, dan perubahan efek. Alat rmnagement proyek otomatis perwakilan tercantum
dalam margin.
Berikut merupakan contoh dari PERT chart.

The bar hitam adalah tugas ringkasan yang mewakili fase proyek yang lebih

lanjut dipecah menjadi tugas-tugas lainnya.


Bar merah menunjukkan tugas-tugas yang telah ditentukan untuk menjadi
penting untuk jadwal, yang berarti bahwa setiap perpanjangan durasi tugastugas akan menunda tugas-tugas lain dan proyek secara keseluruhan. Kita

akan berbicara lebih lanjut tentang tugas-tugas penting nanti.


The bar biru menunjukkan tugas-tugas yang tidak penting untuk jadwal, yang
berarti mereka memiliki beberapa waktu slack selama penundaan tidak akan

mempengaruhi tugas-tugas lain dan proyek secara keseluruhan.


The panah merah menunjukkan prasyarat antara dua tugas-tugas penting. (The

panah biru menunjukkan prasyarat antara dua tugas non kritis.)


Berlian teal menunjukkan tonggak-peristiwa yang tidak memiliki durasi.
Mereka menandakan akhir dari beberapa tugas penting dan deliverable.

Berikut merupakan gantt chart

Siklus Hidup Manajemen Proyek

manajemen proyek adalah kegiatan lintas

siklus hidup; yaitu, kegiatan

manajemen proyek tumpang tindih semua fase pengembangan sistem. kegiatan


manajemen proyek tersebut digambarkan sesuai dengan fungsi manajemen klasik:
pelingkupan.

perencanaan,

memperkirakan,

penjadwalan,

pengorganisasian,

pengarahan. mengendalikan, dan menutup. Proses manajemen proyek yang


ditunjukkan pada Gambar menggabungkan perencanaan proyek (OPP) bersama
teknik perencanaan proyek Joint (IPP) adalah strategi dimana semua stakeholder
dalam proyek (yang berarti pemilik sistem, pengguna, analis, desainer, dan
pembangun).
Kegiatan l-Menegosiasikan Lingkup
Mungkin prasyarat paling penting untuk manajemen proyek yang efektif
terjadi di awal. Semua pihak harus setuju untuk lingkup proyek sebelum upaya
dilakukan untuk mengidentifikasi dan tugas jadwal atau untuk menetapkan sumber
daya (orang) untuk tugas-tugas. Lingkup mendefinisikan harapan proyek. dan
harapan akhirnya menentukan kepuasan dan tingkat keberhasilan. Dengan demikian,
negosiasi lingkup proyek adalah kegiatan yang diperlukan dalam siklus manajemen
proyek hidup. Apa itu lingkup? Lingkup mendefinisikan batas-batas dari proyekbagian dari bisnis yang akan dipelajari. dianalisis. dirancang, dibangun,
diimplementasikan. dan akhirnya ditingkatkan. Ruang lingkup juga mendefinisikan
aspek dari sistem yang dianggap luar proyek. Jawaban atas lima pertanyaan dasar
memengaruhi negosiasi lingkup proyek:

produk-Apa yang Anda inginkan


Kualitas-Seberapa baik Anda ingin menjadi
waktu-Kapan Anda ingin itu???
Biaya-Berapa banyak Anda bersedia membayar?
sumber-sumber daya apa yang Anda bersedia atau mampu membawa

ke meja?
Negosiasi dari faktor di atas adalah memberi dan mengambil kegiatan yang
mencakup banyak iterasi. Penyampaian yang disepakati-pernyataan pekerjaan yang
menjelaskan pekerjaan yang akan dilakukan selama proyek. Dalam pertempuran
konsultasi, pernyataan kerja telah menjadi kontrak yang umum digunakan antara
konsultan dan klien. Pendekatan ini bekerja sama dengan baik untuk proyek-proyek
pengembangan sistem internal untuk membuat kontrak antara manajemen bisnis dan
manajer proyek dan tim. Menurut Keane, inc .. terkemuka proyek konsultasi

manajemen firma, Pernyataan pekerjaan menegaskan bahwa manajer proyek


memahami yang benar-benar bertanggung jawab atas upaya, yang mengendalikan
dompet, apa organisasi formal dan informal dalam mana proyek akan dikembangkan,
yang merupakan "raja dan ratu" yang memiliki minat, dan isu-isu lain yang sejenis
tetapi terutama nonteknis. itu menetapkan hubungan bisnis perusahaan antara manajer
proyek dan kedua pelanggan dan tim proyek diperpanjang. Garis untuk khas
pernyataan dari pekerjaan dokumen ditunjukkan pada Gambar 4-5. Ukuran dokumen
akan bervariasi dalam organimisi yang berbeda. mungkin sekecil satu sampai dua
halaman, atau mungkin beberapa.
Kegiatan 2-ldeniify Tugas
mengingat ruang lingkup proyek. aktivitas berikutnya adalah untuk
mengidentifikasi tugas-tugas proyek. tugas mengidentifikasi pekerjaan menjadi
selesai. Secara tipikal, pekerjaan ini didefinisikan secara garis besar dalam Bab 3,
Anda belajar tentang rute pengembangan sistem dan fase mereka. Tapi fase terlalu
besar dan kompleks untuk perencanaan dan penjadwalan proyek Kita perlu istirahat
mereka ke dalam kegiatan dan tugas-tugas sampai tugas masing-masing mewakili
sejumlah pekerjaan yang dapat direncanakan. dijadwalkan, dan ditugaskan. Beberapa
ahli menganjurkan menyelsaikan tugas sampai tugas mewakili jumlah pekerjaan yang
dapat diselesaikan dalam dua minggu.
akhirnya, manajer proyek akan menentukan tingkat detail dalam garis besar.
Namun, sebagian besar metodologi pengembangan sistem terurai untuk Anda dalam
kegiatan dan tugas. Kegiatan dan tugas-tugas yang belum tentu diukir di batu: yaitu,
kebanyakan metodologi memungkinkan untuk beberapa penambahan, penghapusan,
dan perubahan kegiatan dan tugas-tugas berdasarkan sifat unik setiap proyek. Salah
satu alat yang populer digunakan untuk mengidentifikasi dan kegiatan proyek
dokumen dan tugas adalah struktur rincian kerja. Sebuah struktur rincian kerja (WBS)
adalah dekomposisi proyek hirarki yang menjadi fase, kegiatan, dan tugas-tugas.

PERNYATAAN KERJA
I.
II.

Tujuan
Latar Belakang

A. Masalah, peluang, atau direktif pernyataan


B. Sejarah permintaan proyek
C. Tujuan proyek dan tujuan
D. Dscription produk
III. Lingkup
A. Stakeholder
B. Pengetahuan
C. Proses
D. Komunikasi
IV. Pendekatan proyek
A. Route
B. Kiriman
V. Pendekatan manajerial
A. Pertimbangan membangun tim
B. Manajer dan pengalaman
C. Kebutuhan pelatihan
D. Jadwal rapat
E. Metode pelaporan dan frekuensi
F. Kon fl ik
G. Manajemen lingkup
VI. Consvaints
A. Startdate
B. Tenggat waktu
C. Anggaran
D. Teknologi
VII. Ballpak Etimates
A. Jadwal

B. Anggaran
VIII. Kondisi Kepuasan
A. Kriteria keberhasilan
B. Assumptiors
C. Risiko
IX. Lampiran
struktur Kerja breakdown dapat ditarik menggunakan top-down grafik hirarki,
mirip dengan bagan organisasi (Gambar 4-6). . di Microsoft Project, aWBS
digambarkan menggunakan gaya garis sederhana, lekukan kegiatan dan tugas-tugas
di Guntt grafik "view" dari proyek Microsoft Project juga menawarkan skema
penomoran militer untuk mewakili dekomposisi hirarkis proyek sebagai berikut:
1. Tahap 1 proyek
1.1 Kegiatan 1 Tahap l
1.1.1 Tugas l Kegiatan l di Tahap l
1.1.2 Tugas 2 Kegiatan 1 di Tahap 1
1.2 Kegiatan 2 Tahap l ...
2. Tahap 1 dari proyek
Jika Anda melihat kembali Gambar 4-3 (a), Anda akan melihat bahwa
Microsoft Project menyediakan kolom untuk WBS dalam bagan Gantt. Juga
perhatikan penggunaan lekukan dan penomoran untuk membedakan antara tugas dan
subtasks.
Kami mungkin ingin memasukkan dalam WBS tugas khusus yang disebut
tonggak. ini adalah peristiwa yang menandakan prestasi atau penyelesaian point
utama selama proyek. dalam sistem informasi proyek contoh tonggak sejarah
mungkin penyelesaian semua tugas terkait dengan memproduksi deliverable proyek
besar seperti pernyataan persyaratan (lihat Bab 3). hal ini mungkin berguna untuk
membedakan tonggak dari tugas-tugas lain dalam WBS dengan menggunakan format
khusus.

Kegiatan 3-Memperkirakan jangka waktu tugas


Mengingat struktur rincian kerja dengan tingkat yang sesuai detail, manajer
proyek harus memperkirakan durasi untuk setiap tugas . Durasi setiap tugas adalah
variabel subjek acak untuk faktor Sach sebagai ukuran tim, jumlah pengguna.
ketersediaan pengguna, bakat dari pengguna, kompleksitas sistem bisnis, arsitektur
informasi technology, pengalaman personil tim, waktu berkomitmen untuk proyekproyek dan pengalaman dengan proyek-proyek lainnya lainnya.
Kebanyakan metodologi pengembangan sistem tidak hanya mendefinisikan
tugas tetapi juga memberikan perkiraan awal untuk durasi tugas . Manajer proyek
harus disesuaikan menjadi taksiran yang wajar untuk setiap proyek yang unik.
Di Microsoft Project, semua fase. kegiatan, dan tugas dari metodologi yang
hanya disebut tugas Struktur rincian kerja maka terdiri dari kedua ringkasan dan tugas
primitif. Sebuah tugas ringkasan adalah salah satu yang terdiri dari tugas-tugas lain
(seperti tahapan dan kegiatan). Sebuah tugas primitif adalah salah satu yang tidak
terdiri dari tugas-tugas lainnya. Ini adalah tugas primitif yang manajer proyek harus
memperkirakan durasi. (Seperti kebanyakan perangkat lunak manajemen proyek.
Microsoft Project secara otomatis akan menghitung durasi semua tugas ringkasan
berdasarkan estimasi durasi komponen tugas primitif mereka.)
Bagi tugas primitif yang tidak tonggak, kita harus memperkirakan durasi.
Dalam estimasi durasi tugas, penting untuk memahami konsep waktu berlalu. Waktu
berlalu mempertimbangkan dua faktor penting sehubungan dengan orang:

Efisiensi-ada

pekerja

melakukan

pada

efisiensi

100

persen.

Kebanyakan orang mengambil rehat kopi, makan siang istirahat, Restroom,


dan waktu untuk membaca e-mail mereka, memeriksa kalender mereka,
berpartisipasi dalam kerja nonproyek dan bahkan terlibat dalam percakapan
menganggur. Para ahli memperkirakan seberapa produktif rata-rata pekerja,
tapi salah satu tokoh yang umum digunakan adalah 75 persen.
Panggilan pengalaman Interupsi-Orang telepon, pengunjung. dan
gangguan yang tidak direncanakan lain yang meningkatkan waktu yang
diperlukan untuk pekerjaan proyek. Ini adalah variabel untuk pekerja yang

berbeda. interupsi dapat mengkonsumsi sesedikit 10 persen dari hari pekerja


atau sebagai lumpur! 50 persen.
Mengapa ini penting? Mengingat tugas yang bisa diselesaikan dalam 10 jam
dengan efisiensi 100 persen dan tidak ada interupsi, dan dengan asumsi pekerja
efflsiensi 75 persen dan 15 persen interupsi, perkiraan benar untuk tugas akan
10 hours + 0.75 efficiency

= 15.3 hours + (1.00 0.15 interruptions)


= 15.7 hours

Ada banyak teknik untuk memperkirakan durasi tugas. Demi demonstrasi,


kami menawarkan teknik klasik berikut:
1. Perkirakan jumlah minimal waktu yang dibutuhkan untuk melakukan tugas
tersebut. Nah memanggil durasi optimis ini (OD). Durasi optimis
mengasumsikan bahwa bahkan gangguan yang paling mungkin dan
penundaan. seperti penyakit karyawan sesekali, tidak akan terjadi.
2. Perkirakan jumlah maksimum waktu yang dibutuhkan untuk melakukan tugas
tersebut. juga menyebut durasi pesimis ini (PD). Durasi pesimis
mengasumsikan bahwa hampir segala sesuatu yang bisa salah akan salah.
Semua kemungkinan gangguan atau keterlambatan, seperti mogok kerja,
penyakit, keakuratan persyaratan. keterlambatan pengiriman peralatan. dan
meremehkan kompleksitas sistem, diasumsikan tak terelakkan.
3. Perkirakan durasi yang diharapkan (ED) yang akan dibutuhkan untuk
melakukan tugas. Jangan hanya mengambil median durasi optimis dan
pesimis. Mencoba untuk mengidentifikasi gangguan atau keterlambatan yang
paling mungkin terjadi. studi sebagai penyakit karyawan sesekali. personil
berpengalaman, dan sesekali latihan.

Beberapa alat manajemen proyek otomatis , seperti CS / IOOOO dan Biaya


Xpert , menyediakan teknologi sistem pakar yang membuat esimates ini untuk Anda
berdasarkan jawaban Anda untuk speciic quesions .
Tonggak ( sebagaimana didefinisikan sebelumnya ) tidak memiliki durasi .
Mereka hanya terjadi . Dalam Microsoft Project , tonggak yang ditunjuk dengan
menetapkan duraion ke nol . ( Dalam grafik Gantt , tugas-tugas nol - duraion berubah
dari bar untuk berlian . )
Kegiatan 4 menentukan Intertask Dependensi
Mengingat perkiraan durasi untuk semua tugas, kita sekarang dapat mulai
mengembangkan jadwal proyek. Jadwal proyek tidak hanya tergantung pada jangka
waktu tugas tetapi juga pada dependensi tugas intertask. Dengan kata lain, awal atau
penyelesaian tugas individu mungkin tergantung pada awal atau penyelsaian dari
tugas-tugas lain. Ada empat jenis dari Intertask dependensi:

Flnish-to-start (FS) -akhir dari satu tugas memicu awal tugas lain.

start-to-start (SS) -Awal sebuah tugas memicu awal tugas lain.

Flnish-to-flnish (FF) -Dua tugas selesai pada waktu yang sama.

Start-to-finish (SF) -Awal sebuah tugas menandakan akhir dari

tugas lain.
Intertask dependensi dapat dibentuk dan digambarkan dalam kedua Gantt dan
diagram PERT. Gambar 4-7 menggambarkan bagaimana memasukkan intertask
dependensi di Gantt lihat grafik di Microsoft Project. Kami menyebutnya attenion
Anda untuk peluru dijelaskan sebagai berikut:
1. Intertask dependensi dapat dimasukkan dalam Gantt tampilan grafik di
pendahulu kolom dengan nomor baris tugas tergantung '. Perhatikan bahwa
Tugas dapat memiliki nol, satu, atau banyak pendahulunya.
2. Intertask dependensi juga dapat dimasukkan dengan membuka kotak dialog
Informasi tugas untuk tugas yang diberikan.
3. Jenis ketergantungan dapat dimasukkan dalam dialog Informasi Tugas
kotak untuk setiap tugas yang bergantung diberikan.

4. Intertask dependensi grafis diilustrasikan dalam bagan Gantt sebagai anak


panah antara bar yang mewakili setiap tugas. Panah dapat memulai atau
mengakhiri di sisi kiri atau samping

Tonggak (sebagaimana didefinisikan sebelumnya) hampir selalu memiliki


beberapa pendahulu untuk menandakan tugas-tugas yang harus diselesaikan sebelum
tonggak telah dicapai. Mengingat tanggal mulai untuk sebuah proyek, tugas yang
harus diselesaikan, durasi tugas, dan dependensi intertask, proyek sekarang dapat
dijadwalkan. Ada dua pendekatan untuk penjadwalan:
1. Forward Scheduling menetapkan tanggal mulai proyek dan kemudian
jadwal maju dari tanggal tersebut. Berdasarkan duratsi perencanaan tugas
yang diperlukan, mana pun mereka berada saling ketergantungan. dan
alokasi sumber daya untuk menyelesaikan tugas-tugas, proyek tanggal
compleion diproyeksikan dihitung.
2. Schedulling Reverse menetapkan tenggat waktu proyek dan kemudian
jadwal mundur dari tanggal tersebut. Durasi tugas mereka, saling

ketergantungan, dan sumber daya harus bdipertimbangkan untuk


memastikan bahwa proyek dapat diselesaikan dengan batas waktu.
Setiap tugas dapat diberikan sendiri awal dan akhir tanggal nya. Seperti
kebanyakan proyek alat manajemen. Microsoft Project benar-benar membangun
jadwal untuk memasukkan durasi tugas dan intertask dependensi (pendahulunya).
Pada grafik Gantt, bar tugas diperluas untuk mencerminkan durasi dan bergeser kiri
untuk mencerminkan awal dan akhir tanggal. Microsoft Project juga dapat
menghasilkan tampilan kalender tradisional jadwal akhir, seperti yang ditunjukkan
pada Gambar 4-8.

Kegiatan 5 Menetapkan Sumber Daya


Langkah-langkah sebelumnya mengakibatkan sebuah jadwal yang Kami
belum pertimbangkan alokasi sumber dayanya. untuk proyek Sumber Daya meliputi
kategori berikut :

1. Orang - meliputi semua pemilik sistem , pengguna , analis , desainer ,


pembangun , agen eksternal , dan bantuan administrasi yang akan terlibat
dalam proyek di cara apapun .
2. Layanan - termasuk layanan seperti ulasan kualitas yang mungkin dikenakan
pada basis yang digunakan.
3. Fasilitas dan peralatan - mencakup semua kamar dan teknologi yang akan
dibutuhkan untuk menyelesaikan proyek .
4. Perlengkapan dan bahan - mencakup segala sesuatu dari pensil , kertas , dan
catatan buku-buku untuk toner cartridge , dan sebagainya .
5. Uang - Termasuk terjemahan dari semua di atas ke dalam dolar yang
dianggarkan !
Ketersediaan sumber daya, terutama orang-orang dan fasilitas, secara
signifikan dapat mengubah jadwal proyek. Kebanyakan metodologi pengembangan
sistem mengidentifikasi sumber orang diperlukan untuk setiap tugas dalam bentuk
peran. Peran tidak sama sebagai jabatan. Pikirkan peran sebagai "topi" bahwa
seseorang memakai karena ia memiliki keterampilan tertentu (s). Setiap individu
diberikan mungkin mampu mengenakan banyak topi (dengan demikian memainkan
banyak peran). Selain itu, banyak orang mungkin memiliki keterampilan yang
dibutuhkan untuk bermain tugas yang diberikan manajer proyek role. Tugas manajer
proyek adalah untuk menetapkan orang-orang tertentu untuk mengisi peran atau
untuk mendapatkan komitmen dari manajemen untuk menyediakan orang untuk peran
sakit. peran perwakilan dari metodologi CEPAT tercantum dalam margin.
Dalam Microsoft Project, peran dan tugas yang ditentukan dalam tampilan
Sumber Daya Lembar, seperti yang ditunjukkan pada Gambar 4.9 (a). peran dan
sumber daya yang telah ditetapkan mungkin tersedia dalam metodologi dan rute yang
dipilih template.
1. Manajer proyek berperan di Sumber daya Nama kolom. Sumber mungkin
juga mencakup layanan spesifik, fasilitas, peralatan, perlengkapan, mateials,
dan sebagainya.

2. Perhatikan bahwa Lembar Sumber Daya menyediakan kolom untuk


menetapkan berapa persentase sumber daya akan dialokasikan untuk proyek.
Misalnya, database administrator mungkin dialokasikan waktu seperempat (25
persen) untuk proyek. Alokasi yang lebih besar dari 100 persen menunjukkan
kebutuhan untuk lebih dari satu orang ke orang yang sakit peran yang
diberikan dalam proyek. Dengan menetapkan Max. Unit untuk 250 persen
untuk sumber daya itu, akan ada kebutuhan untuk setara dengan 2'j
programmer penuh waktu.
3. Proyek juga memungkinkan manajer proyek untuk estimasi biaya setiap
sumber daya. Biaya ini dapat esimated berdasarkan sejarah perusahaan,
kontrak konsul, atau standar biaya akutansi internal. Perhatikan bahwa baik
biaya standar dan lembur dapat diperkirakan. Biaya tersebut biasanya
didasarkan pada standar untuk melindungi informasi tentang gaji yang
sebenarnya siapa pun.
4. Setiap sumber daya memiliki kalender yang menganggap pekan kerja standar
dan liburan, serta liburan individu dan komitmen lainnya.
Mengingat sumber daya, mereka sekarang dapat secara khusus ditugaskan
untuk tugas-tugas, seperti yang ditunjukkan pada Gambar 4.9 (b). Sebagai sumber
daya dikerahkan untuk tugas-tugas, manajer proyek akan menentukan unit yang
sumber daya yang akan dibutuhkan untuk menyelesaikan setiap tugas yang diberikan.
(Ini mungkin persentase ime seseorang yang dibutuhkan untuk tugas itu.)
Sebagai sumber daya ini secara resmi ditetapkan, jadwal akan disesuaikan
(yang terjadi secara otomatis dalam alat-alat seperti Project). Jika Anda memasukkan
biaya sumber daya, alat-alat seperti Microsoft Project akan secara otomatis
menghitung dan mempertahankan anggaran berdasarkan pada sumber daya dan
jadwal.

Menugaskan Orang untuk Tugas Merekrut anggota tim yang tepat dapat
membuat atau menghancurkan sebuah proyek. Berikut ini adalah panduan untuk
seleksi dan merekrut tim:
1. Merekrut yang berbakat, orang sangat termotivasi. Sangat terampil dan tim
termotivasi anggota lebih mungkin untuk mengatasi hambatan proyek tanpa
bantuan dan lebih mungkin untuk memenuhi tenggat waktu proyek dan
menghasilkan kualitas kerja.
2. Pilih tugas terbaik bagi setiap orang. Semua pekerja memiliki kekuatan dan
kelemahan. manajer proyek yang efektif belajar untuk memanfaatkan
kekuatan dari anggota tim dan menghindari memberikan tugas kepada
anggota tim tidak terampil di daerah-daerah.
3. Mempromosikan harmoni tim. manajer proyek harus memilih anggota tim
yang akan bekerja sama dengan baik.
4. Rencana untuk masa depan. personil junior dengan potenial akan dibimbing
oleh para pemimpin proyek harus dipertimbangkan. Meskipun personil junior
mungkin tidak akan produktif sebagai veteran berpengalaman, manajer proyek
akan membutuhkan mereka dan harus bergantung pada mereka pada proyekproyek masa depan.
5. Jauhkan ukuran tim kecil Dengan batas ukuran tim, overhead komunikasi dan
kesulitan akan berkurang. Sebuah tim 2-orang hanya memiliki 1 komunikasi
jalur. tim 4-orang memiliki 6 komunikasi jalur. dan tim 50-orang memiliki
setidaknya 1.200 jalur komunikasi. Jalur komunikasi lebih ada, semakin besar
kemungkinan yang akan ada peningkatan masalah komunikasi. Dengan cara
yang sama tim harus besar cukup untuk menyediakan cadangan dan cakupan
yang memadai dalam keterampilan kunci jika anggota tim hilang.
Sumber daya leveling tugas Sejauh ini, kami telah menolak, durasi tugas, dan
intertask dependensi dan sumber daya yang ditugaskan untuk setiap tugas untuk

menghasilkan jadwal proyek. Hal ini umum untuk kelebihan alokasi sumber ketika
menetapkan sumber daya untuk tugas-tugas. Kelebihan alokasi mengacu pada
tindakan menugaskan sumber daya lebih dari yang tersedia.
Misalnya, durasi jangka waktu tertentu dalam proyek (hari, minggu, dll),
seorang manajer proyek mungkin telah menetapkan seseorang untuk bekerja pada
beberapa tugas yang menambahkan hingga jam lebih dari orang tersebut telah
tersedia untuk bekerja selama periode itu. Hal ini membuat jadwal secara keseluruhan
tidak layak karena sumber daya yang kelebihan alokasi tidak dapat cukup lengkap
semua tugas yang diberikan sesuai dengan jadwal. Untuk memperbaiki masalah ini,
manajer proyek harus menggunakan teknik yang disebut meratakan sumber daya.
Sumber daya leveling adalah strategi yang digunakan untuk memperbaiki kelebihan
alokasi sumber daya oleh beberapa kombinasi. Mari biefly menjelaskan kedua
pendekatan. Menunda tugas adalah berdasarkan pada konsep jalur kritis dan waktu
slack. Kapan itu datang ke jadwal proyek, beberapa tugas yang lebih sensitif untuk
jadwal penundaan dari lain. Untuk alasan ini, manajer proyek harus menyadari cara
kritis untuk proyek. Cara kritis untuk sebuah proyek adalah urutan tugas-tugas
tergantung yang memiliki jumlah terbesar dari yang paling durasi kemungkinan. Cara
kritis menentukan tanggal penyelesaian sedini mungkin proyek. (Kami sebelumnya
dijelaskan bagaimana memperkirakan paling kemungkinan durasi untuk tugas.) Tugas
jalan kritis tidak punya waktu kendur availablethus, keterlambatan dalam penyelsaian
dari salah satu tugas pada jalur kritis akan menyebabkan keterlambatan keseluruhan
dalam penyelesaian proyek. Kebalikan dari tugas kritis adalah salah satu yang
memiliki beberapa waktu jeda. Waktu tersedia untuk setiap tugas non kritis adalah
jumlah tunda yang dapat ditoleransi antara waktu awal dan waktu penyelsaian dari
tugas tanpa menyebabkan keterlambatan dalam tanggal compleion dari seluruh
proyek. Tugas-tugas yang harus waktu jeda bisa mendapatkan di belakang jadwal
dengan jumlah yang kurang dari atau sama dengan kelonggaran waktu tanpa dampak
apapun pada tanggal penyelsaianproyek. Ketersediaan waktu dalam tugas-tugas
tertentu memberikan kesempatan untuk menunda dimulainya tugas untuk sumber

tingkat sementara. Tentu saja, mungkin perlu menunda tugas jalur kritis untuk tingkat
sumber daya, kecuali jika Anda dapat membagi tugas.
Sumber daya leveling dapat menjenuhkan untuk jika dilakukan secara
manual. Untuk setiap sumber daya, manajer proyek perlu mengetahui total waktu
yang tersedia untuk proyek untuk sumber daya, semua tugas tugas dibuat untuk
sumber daya, dan jumlah semua duraions dari mereka tugas tugas di berbagai peiods
waktu. Semua perangkat lunak manajemen proyek, seperti Microsoft Project, secara
otomatis menentukan cara kritis. Hal ini memungkinkan perangkat lunak yang sama
untuk melacak alokasi sumber daya dan secara otomatis melakukan perataan sumber
daya. Hal ini jarang bagi manajer proyek modern untuk tugas sumber daya tingkat
manual. Sumber daya leveling akan menjadi aktivitas berkelanjutan karena jadwal
dan sumber daya tugas mungkin berubah selama proyek.
Jadwal dan Anggaran Mengingat jadwal berdasarkan sumber diratakan dan
diberikan biaya dari setiap sumber daya (misalnya, biaya per jam dari analis sistem
atau database administrator) manajer proyek dapat menghasilkan dokumen yang
mengkomunikasikan rencana proyek untuk semua pihak. alat manajemen proyek
akan memberikan pandangan muliple proyek seperti kalender. Gantt chart. PERT
chart, laporan sumber daya dan meratakan sumber daya, dan anggaran laporan.
Semua yang tersisa adalah untuk mengarahkan sumber daya ke penyelsaian tugas.
Komunikasi Pernyataan kerja, untuk point utama, dan jadwal proyek secara
keseluruhan harus dikomunikasikan kepada semua pihak yang terlibat dalam proyek
tersebut. Komunikasi ini juga harus terencana untuk melaporkan kemajuan, baik
secara lisan maupun tertulis, frekuensi komunikasi tersebut, dan orang yang kontak
dan metode untuk mengirimkan umpan balik dan saran. Sebuah perusahaan internet
dapat menjadi cara yang efektif untuk menjaga semua orang diberitahu tentang
kemajuan proyek dan isu-isu.
Kegiatan 6-Mengarahkan Usaha Tim
Semua manajemen proyek aktivitas sebelumnya menyebabkan rencana induk
untuk proyek tersebut. Sekarang saatnya untuk melaksanakan rencana itu. Ada

beberapa dimensi untuk mengarahkan usaha tim. Tom Demarco menyatakan dalam
buku Batas waktu nya: A Novel tentang Manajemen Proyek bahwa pekerjaan yang
paling sulit dalam manajemen adalah orang.
Beberapa manajer proyek baru terampil mengawasi orang. Kebanyakan
belajar pengawasan melalui pengalaman mereka sendiri mereka suka dan tidak suka
tentang mereka yang diawasi mereka. Topik ini bisa dengan mudah mengambil satu
bab. Dalam margin checklist, kami menyediakan daftar klasik rekomendasi
pengawasan proyek dari people Side of Systems, oleh Keith London.
Seperti dicatat oleh Graham McLeod dan Derek Smith. "Individu membawa
bersama-sama dalam tim pengembangan sistem tidak membentuk unit erat segera.
"McLeod dan Smith menjelaskan bahwa tim melewati tahap-tahap pengembangan
tim, seperti yang ditunjukkan pada One Minute Manager, oleh Kenneth Blanchard
dan Spencer Johnson, bantuan klasik dan sangat diperlukan untuk orang yang
mengelola orang untuk waktu, penulis berbagi rahasia sederhana mengelola orang
dan mencapai sukses melalui aksi bawahan.
Kebanyakan pengalaman muda, dan banyak, manajer memiliki dificuly
dengan seni halus delegasi dan cukup akunt5an. Lebih buruk lagi, mereka
membiarkan bawahan delegasi terbalik untuk tugas kembali ke manajer. Hal ini
menyebabkan manajemen waktu yang buruk dan manajer frustraion. Dalam Tbe One
Minute Manager Memenuhi Monyet, tim Kenneth Blanchard dengan William Oncken
dan Hal Burrows untuk membantu manajer mengatasi masalah ini. Solusi itu
didasarkan pada prinsip klasik Oncken untuk "perawatan dan memberi makan
monyet." Monyet "masalah" yang manajer mendelegasikan kepada bawahan mereka,
yang pada gilirannya mencoba untuk membalikkan-mendelegasikan kembali ke
manajer. Dalam 125-halaman ini buku penulis mengajarkan manajer bagaimana
menjaga monyet di punggung bawahan '. melakukan hal peningkatan waktu kerja
yang tersedia manajer, mempercepat tugas prestasi oleh bawahan, dan mengajarkan
bawahan bagaimana untuk mengambil tanggung jawab dan memecahkan masalah
mereka sendiri.

Kegiatan 7-Monitor dan Kontrol Kemajuan


Sementara pelaksanan proyek, manajer proyek harus mengontrol proyek,
yaitu. memantau kemajuan terhadap ruang lingkup, jadwal, dan anggaran. Manajer
harus melaporkan kemajuan dan, bila perlu, menyesuaikan ruang lingkup, jadwal, dan
sumber daya.
Pelaporan kemajuan harus cukup sering untuk membangun akuntabilitas dan
kontrol, tetapi tidak begitu sering untuk menjadi beban dan halangan untuk kemajuan
proyek nyata. Sebagai contoh. Keane. Inc .. sebuah perusahaan konsultan,
merekomendasikan bahwa laporan kemajuan atau pertemuan terjadi setiap dua
minggu konsisten dengan strategi proyek-perencanaan perusahaan yang terurai

proyek dalam tugas-tugas yang menghasilkan kiriman yang membutuhkan tidak lebih
dari 80 jam kerja. laporan kemajuan proyek bisa lisan atau tertulis. Gambar 4-11
mengilustrasikan template untuk laporan kemajuan tertulis. laporan kemajuan proyek
(atau presentasi) harus jujur dan akurat, bahkan jika berita itu kurang baik. laporan
kemajuan proyek harus melaporkan keberhasilan tetapi harus jelas mengidentifikasi
masalah dan kekhawatiran sehingga mereka dapat ditangani sebelum meluas kepada
isu-isu besar atau bencana.
Sebagai tugas selesai, kemajuan dapat disimpan di Microsoft Project (lihat
Gambar 4-12). Kami meminta perhatian Anda sebagai berikut Gantt kemajuan item:
1. Semua tugas dalam tahap pemeriksaan pendahuluan yang lengkap seperti
yang ditunjukkan dengan garis kuning yang menjalankan panjang penuh dari
setiap task bar. Perhatikan bahwa karena semua tugas ini selesai, mereka tidak
lagi kritis. Bar telah berubah dari merah ke biru.
2. Pada tahap analisis masalah, hanya tugas pertama, "Menganalisis saat ini
sistem. "adalah 1 (K) persen selesai.
3. Perhatikan bahwa "Membangun tujuan perbaikan sistem" task bar memiliki
garis kuning parsial berjalan 60 persen panjangnya. Hal ini menunjukkan
tugas adalah sekitar 60 persen selesai. Task bar masih merah karena
keterlambatan dalam menyelesaikan tugas akan mengancam tanggal
penyelesaian proyek.
4. Semua tugas yang tersisa terlihat pada grafik yang ditampilkan belum dimulai.
Sebenarnya kemajuan ketika tugas dimulai, dalam proses, atau selesai.

Q progess untuk setiap tugas yang diberikan dicatat dalam informasi tugas
kotak dialog untuk tugas itu. Dalam contoh ini, manajer proyek merekam 10 persen
penyelesaian tugas bernama. Microsoft Project juga menyediakan sejumlah
peconfigued dan disesuaikan laporan yang dapat menyajikan informasi status proyek
yang berguna. Manajemen Perubahan Hal ini tidak biasa untuk lingkup untuk tumbuh
di luar kendali bahkan ketika sebuah pernyataan benar menyelesaikan pekerjaan
disepakati pada awal perencanaan proses. Kami mengacu pada pertumbuhan lingkup
sebagai "perubahan." Seperti dicatat oleh Keane. Inc .. "Perubahan sering merupakan
titik pertikaian antara pelanggan dan organisasi sistem informasi, karena mereka tidak
setuju pada apakah fungsi tertentu adalah perubahan atau bagian dari kesepakatan
awal "The inevitabiliy perubahan lingkup memerlukan bahwa kita memiliki strategi
formal dan proses untuk menghadapi perubahan dan dampaknya terhadap jadwal dan
biaya.
Perubahan manajemen dimaksudkan untuk melindungi manajer proyek dan
tim dari yang bertanggung jawab atas jadwal dan anggaran overruns yang wee

didorong oleh perubahan lingkup. Perubahan dapat menjadi hasil dari berbagai acara
dan faktor, termasuk: Suatu kelalaian dalam mendefinisikan lingkup awal (seperti
yang didokumentasikan dalam laporan kerja). Sebuah kesalahpahaman dari lingkup
awal (produk yang diinginkan lebih rumit daripada yang dikomunikasikan atau
dirasakan).
Peristiwa eksternal seperti peraturan pemerintah yang menciptakan kebutuhan
baru. perubahan organisasi, seperti merger, akuisisi, dan kemitraan, yang
menciptakan masalah bisnis baru dan peluang (untuk tidak menyebutkan "pemain").
Ketersediaan teknologi yang lebih baik. Pergeseran dalam teknologi direncanakan
yang memaksa perubahan yang tak terduga dan signifikan terhadap organisasi bisnis,
kultur, dan atau proses. Desain manajemen untuk memiliki sistem melakukan moe
dari yang awalnya diminta atau disetujui. Mengurangi pendanaan untuk proyek atau
pengenaan batas waktu sebelumnya.
Sebuah sistem manajemen perubahan menghasilkan koleksi prosedur untuk
mendokumentasikan permintaan perubahan dan mendefinisikan langkah-langkah
yang diperlukan untuk mempertimbangkan perubahan berdasarkan dampak yang
diharapkan dari perubahan. Kebanyakan sistem manajemen perubahan mengharuskan
perubahan formulir permintaan diprakarsai oleh stakeholder proyek satu atau lebih
(Mis .. pemilik sistem, pengguna, analis, desainer, atau pembangun). Idealnya,
mengubah permintaan yang didasarkan oleh dewan perubahan kontrol (CCB), yang
bertanggung jawab untuk menyetujui atau menolak semua permintaan perubahan.
komposisi CCB biasanya meliputi anggota tim proyek serta luar yang mungkin
memiliki kepentingan atau saham dalam proyek tersebut. Keputusan CCB harus
didasarkan pada analisis dampak analisis dampak kelayakan harus menilai pentingnya
perubahan untuk bisnis, dampak dari perubahan pada jadwal proyek, dan dampak dari
perubahan pada anggaran proyek dan biaya operasi jangka panjang. Pada akhirnya,
manajemen perubahan bermuara mengelola harapan para pemangku kepentingan.
Pada bagian berikutnya, kami memperkenalkan kerangka sederhana tetapi secara
konseptual suara untuk mengelola harapan dan dampaknya terhadap jadwal proyek
dan anggaran.

Harapan Manajemen Berpengalaman manajer proyek sering mengeluh bahwa


mengelola pemilik sistem dan pengguna harapan dari proyek lebih sulit daripada
mengelola biaya, jadwal, orang, atau kualitas. Pada bagian ini kami memperkenalkan
alat sederhana yang juga memanggil matriks manajemen harapan yang dapat
membantu manajer proyek kesepakatan dengan masalah ini. Kami pertama kali
belajar tentang alat ini dari Dr. Phil Friedlander. konsultan dan trainer kemudian
dengan McDonnell Douglas. Dia atribut matriks untuk "folkloe" tapi juga kredit Jerry
Gordon, dari Majer. dan Ron Leflour, proyek manajemen pendidik / pelatih. makalah
Dr Friedlander (tercantum dalam Bacaan yang disarankan untuk bab ini) disesuaikan
dalam teks ini untuk pesentation ini.
Setiap proyek memiliki tujuan dan kendala ketika datang ke biaya jadwal,
lingkup, dan kualitas. Dalam kata ideal, masing-masing parameter tersebut dapat
dioptimalkan. Manajemen sering memiliki harapan itu. Realiy menunjukkan,
bagaimanapun, bahwa Anda tidak dapat mengoptimalkan mereka semua. Anda harus
menjaga keseimbangan yang baik layak dan dapat diterima untuk manajemen. Itu
adalah tujuan dari matriks manajemen harapan. Manajemen harapan matriks adalah
alat aturan-didorong untuk membantu manajemen memahami dinamika dan dampak
parameter proyek berubah seperti biaya, jadwal, lingkup, dan kualitas.
Matriks dasar, yang ditunjukkan pada Gambar 4-13. terdiri dari tiga baris dan
tiga kolom (Ditambah judul). Baris sesuai dengan langkah-langkah keberhasilan
dalam setiap proyek: biaya, jadwal, dan ruang lingkup dan / atau kualitas. Kolom
sesuai dengan prioritas: pertama, kedua, dan ketiga. Untuk membangun harapan, kita
menetapkan nama untuk prioritas sebagai berikut:
1. Memaksimalkan atau meminimalkan-ukuran keberhasilan yang ditentukan
untuk menjadi yang paling penting untuk proyek tertentu.
2. Membatasi-kedua yang paling penting dari tiga ukuran keberhasilan di sebuah
proyek.
3. Terima-paling penting dari tiga langkah dalam sebuah proyek.

Kebanyakan manajer, idealnya, ingin memberikan prioritas sama dengan


semua. Pengalaman menunjukkan bahwa tiga measues cenderung menyeimbangkan
diri secara alami. Misalnya, jika Anda meningkatkan lingkup atau peralatan kualitas,
proyek ini akan mengambil lebih banyak waktu dan / atau uang. Jika Anda mencoba
untuk mendapatkan pekerjaan apapun yang dilakukan lebih cepat, biasanya Anda
harus membayar uang lebih untuk mengkompensasi. Harapan manajemen matriks
membantu manajemen untuk memahami hal ini melalui tiga aturan sederhana:
1. Untuk setiap proyek, Anda harus mencatat tiga Xs dalam sembilan sel yang
tersedia.

2. Tidak ada baris mungkin berisi lebih dari satu X. Dengan kata lain, ukuran
tunggal Keberhasilan harus memiliki satu dan hanya satu prioritas
3. Tidak ada kolom mungkin berisi lebih dari satu X. Dengan kata lain, harus
ada pertama, kedua, dan prioritas ketiga.
Mari kita menggambarkan alat menggunakan contoh Dr. Friedlander sendiri.
Pada tahun 1961 Presiden John E Kennedy mendirikan proyek-tanah besar manusia
di bulan dan reuirn dengan selamat sebelum akhir dekade ini. Figue 4-14
menunjukkan harapan yang realistis dari proyek. Mari kita berjalan melalui contoh: 1.
pemilik sistem (masyarakat) memiliki baik lingkup dan harapan kualitas. Itu lingkup
(atau persyaratan) adalah untuk berhasil mendaratkan manusia di bulan. Ukuran
kualitas adalah untuk mengembalikan manusia (atau pria) dengan aman. Karena
masyarakat akan mengharapkan tidak kurang dari program luar angkasa baru, ini
harus menjadi prioritas pertama. Dengan kata lain, kita harus memaksimalkan
keamanan dan meminimalkan risiko sebagai prioritas pertama. Oleh karena itu, kami
mencatat X di kolom 1, baris 3- 2. Pada saat awal proyek, Uni Soviet berada di depan
dalam perlombaan ruang. Ini adalah masalah kebanggaan nasional; oleh karena itu,
prioriy kedua adalah untuk mendapatkan pekerjaan yang dilakukan pada akhir dekade
ini. Kami menyebutnya proyek kendala-tidak perlu terburu-buru tenggat waktu, tapi
kami tidak mau ketinggalan batas waktu. Dengan demikian, kami mencatat X kedua
pada kolom 2, baris 2. 3. Secara default, prioritas ketiga harus biaya (diperkirakan
sebesar $ 20 miliar 1961). Dengan membuat biaya prioritas ketiga, kita tidak
menyatakan biaya yang tidak akan dikontrol. Kami hanya menyatakan bahwa kita
mungkin harus menerima kelebihan biaya untuk mencapai cakupan dan kebutuhan
kualitas dengan batas waktu dibatasi. Kita merekam X ketiga pada kolom 3. baris 1.
Sejarah mencatat bahwa kita mencapai cakupan dan kualitas peralatan, dan
melakukannya pada tahun 1969. Proyek ini sebenarnya jauh melebihi biaya dari $ 30
miliar, lebih dari biaya 50 persen. Apakah yang membuat proyek gagal ? Sebaliknya ,
kebanyakan orang dianggap proyek sebagai sukses besar . Pemerintah berhasil
harapan publik proyek di menyadari bahwa keamanan maksimum dan risiko
minimal , ditambah memenuhi tenggat waktu ( mengalahkan Soviet ) , yang diterima.

Sistem pengembangan manajer proyek dapat belajar pelajaran berharga dari tindakan
penyeimbangan ini .
Pada awal setiap proyek, manajer proyek harus mempertimbangkan
perkenalan sistem pemilik untuk konsep harapan matriks dan harus bekerja dengan
sistem pemilik untuk menyelesaikan matriks. Untuk sebagian besar proyek, akan sulit
untuk diterima semua lingkup dan kebutuhan kualitas dalam matriks. Sebaliknya,
mereka akan tercantum dalam laporan kerja. estimasi biaya dan tenggat waktu bisa
diterima langsung dalam matriks.
Manajer proyek tidak menetapkan prioritas; ia hanya memberlakukan aturan
matriks. Ini terdengar mudah, tapi jarang. Banyak manajer tidak bersedia untuk
disematkan di atas prioritas "Bukankah kita bisa memaksimalkan segala sesuatu?"
manajer ini perlu dididik tentang alasan untuk piorities. Mereka perlu memahami
prioritas jika mereka tidak dapat memaksimalkan semua tiga langkah. Hal ini
menyebabkan kompromi cerdas bukan hanya dugaan.
Bagaimana jika pemilik sistem menolak untuk memprioritaskan? Alat ini
menjadi kurang berguna, kecuali sebagai mekanisme untuk mendokumentasikan
masalah sebelum mereka menjadi bencana. Seorang pemilik sistem yang menolak
untuk menetapkan prioritas mungkin pengaturan proyek manager untuk review
kinerja tidak-menang. Dan seperti yang ditunjukkan Dr. Friedlander, * Mereka yang
tidak melakukan 'percaya' prinsip-prinsip (dari matriks] akhirnya akan 'tahu'
kebenaran. Anda tidak harus percaya pada graviy tetapi Anda akan menyentuh tanah
hanya sekeras orang yang melakukan. "
Mari kita asumsikan matriks harapan manajemen yang sesuai dengan aturan
afoementioned. Bagaimana hal ini membantu manajer proyek mengelola ekspektasi?
Selama. Tentu saja dari proyek pengembangan sistem rata, prioritas tidak stabil.
faktor vaious seperti ekonomi, pemerintah, dan politik perusahaan dapat mengubah
Anggaran menjadi lebih atau kurang dibatasi. Tenggat waktu mungkin menjadi lebih
atau kurang penting. Qualiy dapat menjadi lebih penting. Dan. paling kerap kali,
kebutuhan

meningkat.

Seperti

telah

dicatat,

ini

faktor-faktor

perubahan

mempengaruhi semua tindakan dalam beberapa cara. Itu adalah trik mengelola
harapan meskipun parameter proyek yang selalu berubah.
Teknik ini relatif mudah. Setiap kali "max / min " atau "membatasi ukuran"
mulai tergelincir, hal itu dapat mengakibatkan masalah harapan manajemen potensial.
Misalnya, pertimbangkan seorang manajer proyek yang dihadapkan dengan prioities
berikut (lihat Gambar 4-15):
1. kebutuhan eksplisit dan harapan kualitas didirikan pada awal proyek dan
diberi prioritas tertinggi .
2. Sebuah anggaran maksimum mutlak didirikan untuk proyek tersebut .
3. Manajer proyek setuju untuk menembak untuk batas waktu yang diinginkan,
tetapi sistem pemilik ( s ) menerima ealiy bahwa jika sesuatu harus tergelincir,
itu harus jadwal.

Sekarang anggaplah bahwa selama analisis sistem , masalah bisnis yang


signifikan dan tak terduga diidentifikasi . Analisis masalah ini telah menempatkan
proyek di belakang jadwal . Memecahkan masalah bisnis baru secara substansial
memperluas pengguna peralatan untuk sistem baru. Bagaimana manajer proyek
bereaksi? Disini seharusnya tidak ada reaksi berlebihan untuk jadwal jadwal selip.
Selip adalah "menerima" prioritas di matix. Peningkatan lingkup (dalam bentuk
beberapa requiements baru) adalah masalah yang signifikan moe karena equirements
menambahkan akan incease biaya proyek. Biaya adalah ukuran terkendala

kesuksesan. Seperti berdiri, masalah harapan ada. Manajer proyek perlu meninjau
matix dengan pemilik sistem. Pertama, pemilik sistem perlu dibuat sadar yang ukuran
atau tindakan berada dalam bahaya dan mengapa. Kemudian bersama-sama, manajer
proyek dan pemilik sistem dapat mendiskusikan program tindakan. Beberapa
program aksi mungkin:
1. Sumber daya (biaya dan / atau jadwal) dapat dialokasikan. Mungkin sistem
pemilik dapat menemukan lebih banyak uang dimanapun. Semua prioritas
akan Emain yang sama (mencatat, tentu saja, batas waktu revisi berdasarkan
jadwal slippages sudah encounteed duing analisis sistem).
2. Anggaran mungkin meningkat, tapi itu akan diimbangi dengan tambahan
direncanakan jadwal. Misalnya, dengan memperluas proyek menjadi fiskal
baru tahun, uang tambahan mungkin dialokasikan tanpa mengambil uang dari
proyek atau penggunaan yang ada. Solusi ini ditunjukkan pada Gambar 4-16.
3. The kebutuhan pengguna (atau kualitas) mungkin melalui politisi mereka
menyaratkan dan menunda beberapa orang kebutuhan sampai versi 2 dari
sistem. Alternatif ini akan telah sesuai jika anggaran tidak dapat ditingkatkan.
4. Akhirnya, politisi pengukuran dapat diubah.
Hanya pemilik sistem dapat memulai perubahan pioriy. Misalnya, pemilik
sistem dapat setuju bahwa kebutuhan diperluas banyak biaya tambahan. Itu mungkin
mengalokasikan dana yang cukup untuk menutupi kebutuhan tetapi dapat bermigrasi
prioritas sehingga meminimalkan biaya sekarang menjadi prioriy tertinggi (lihat Rgue
4-17, langkah 1). Tapi sekarang matriks melanggar aturan ada dua Xs dalam kolom 1.
Untuk kompensasi, kita harus bermigrasi lingkup dan / atau kualitas ke kolom lain,
dalam hal ini, kolom (lihat Figue 4-17, langkah 2 ). Harapan telah disesuaikan.
Akibatnya, pemilik sistem pembekuan pertumbuhan persyaratan dan masih menerima
jadwal selip
Ada komentar akhir tentang perubahan prioritas . Pertama , prioritas bisa
berubah lebih dari sekali selama proyek . Harapan dapat dikelola melalui sejumlah
perubahan selama matriks seimbang ( artinya sesuai dengan aturan kami). Kedua,
manajemen harapan dapat dicapai melalui kombinasi dari perubahan prioritas dan

penyesuaian sumber. Akhirnya, pemilik sistem dapat melakukan perubahan prioritas


bahkan jika proyek ini sesuai jadwal. Misalnya, peraturan pemerintah mungkin
memaksa batas waktu tanpa kompromi pada proyek yang sudah ada. Yang tiba-tiba
akan bermigrasi kami "menerima" jadwal selip untuk " kendala maksimal." The Xs
lainnya akan harus bermigrasi untuk menyeimbangkan matix. Sementara harapan
manajemen matriks adalah alat sederhana, mungkin salah satu yang paling efektif.
Jadwal Penyesuaian Analisis Kritis Ketika datang ke jadwal proyek, beberapa
tugas yang lebih sensitif untuk jadwal penundaan dari yang lain. Untuk alasan ini,
manajer proyek harus menjadi awae dari citical jalan dan kendur kali untuk sebuah
proyek. Memahami jalur kritis dan waktu slack dalam sebuah proyek sangat
diperlukan untuk manajer proyek. Pengetahuan tentang faktor proyek tersebut
mempengaruhi keputusan manajemen orang harus dibuat oleh manajer proyek.
Penekanan dapat dan harus ditempatkan pada tugas-tugas jalur kritis, dan jika perlu,
sumber mungkin temporaily dialihkan dari tugas-tugas dengan waktu slack untuk
membantu mendapatkan tugas-tugas penting kembali pada jadwal.
Jalan citical dan waktu untuk proyek dapat digambarkan pada kedua grafik
Gantt dan PERT; namun grafik PERT umumnya lebih disukai karena mereka lebih
jelas menggambarkan intertask dependensi yang menentukan jalan kritis.
Kebanyakan perangkat lunak manajemen proyek, termasuk Microsoft Project,
otomatis menghitung dan menyoroti jalur citical berdasarkan dependensi intertask
dikombinasikan dengan durasi. Hal ini berguna, namun, untuk memahami bagaimana
citical jalan dan kendur kali dihitung.
Perhatikan contoh hipotetis berikut. Sebuah proyek terdiri dari sembilan tugas
primitif ditunjukkan pada Gambar 4-18. Yang paling mungkin durasi (dalam hari)
untuk setiap tugas dicatat. Ada empat urutan yang berbeda dari tugas-tugas dalam
suatu proyek. diantaranya :
Path 1

A-B->C- D- I

Path 2

A -r B - C -> E -r I

Path 3

A-B-C-F- G

Path 4

A- B- C- F-> H

Total dari semua kali durasi kemungkinan untuk setiap jalur dihitung sebagai berikut
Path 1

3 + 2 + 2 + 7+5= 19

Path 2

3 + 2 + 2+6+5= 18

Path 3

3 + 2 + 2 + 3 + 2 + 5= 17

Path 4

3 + 2 + 2 + 3+1 + 5= 16

Dalam contoh ini , jalan 1 adalah criticalpatb di 19 hari . ( Catatan : Anda dapat
memiliki beberapa jalur kritis jika mereka memiliki total durasi yang sama . )
Dalam contoh ini , tugas E. F. dan G tidak pada jalur kritis ; mereka masingmasing memiliki beberapa waktu kendur . Misalnya , tugas E termasuk dalam jalur
yang memiliki durasi satu hari kurang dari jalur kritis : Oleh karena itu , tugas E bisa
mendapatkan di belakang sebanyak satu hari tanpa merugikan tanggal penyelesaian
proyek . Demikian pula , tugas F dan G dapat menggabungkan untuk slack
maksimum dua hari tanpa menunda jadwal.
Pada Gambar 4-18 . jalur kritis ditampilkan dalam warna merah . Tugas-tugas
yang harus capaciy slack ditunjukkan pada Mac k Demikian pula , perangkat lunak
manajemen proyek juga menggunakan warna untuk membedakan tugas jalur kritis di
bagan Gantt atau PERT .
Kegiatan 8-Menilai Hasil dan Pengalaman Proyek
Manajer proyek harus belajar dari kesalahan mereka! Mereka harus
merangkul terus menerus peningkatan proses. Kegiatan akhir ini melibatkan meminta
umpan balik dari proyek anggota tim (termasuk pelanggan) mengenai pengalaman
proyek mereka dan saran yang bertujuan untuk meningkatkan proyek dan proses
manajemen organisasi. Ulasan proyek (s) harus dilakukan untuk menjawab mendasar
berikut pertanyaan:
1. Apakah produk akhir memenuhi atau melebihi harapan pengguna?
2. Apakah proyek datang pada jadwal?
3. Apakah proyek datang di bawah anggaran?

Jawaban atas pertanyaan-pertanyaan ini harus diikuti dengan pertanyaan dasar


"Mengapa atau mengapa tidak?" Selanjutnya, dan berdasarkan tanggapan atas
pertanyaan di atas, perubahan harus dilakukan untuk meningkatkan metode
pengembangan sistem dan manajemen proyek yang akan digunakan pada proyekproyek masa depan. Saran untuk perbaikan dikomunikasikan kepada "Centers for
Excellence", yang dapat memodifikasi standar dan proses, serta berbagi ide berguna
dan pengalaman dengan tim proyek lain yang mungkin meminta bantuan atau
keahlian mereka. penilaian proyek sering menyebabkan perbaikan deliverable
spesifik proyek (tonggak), proses atau tugas yang menciptakan kiriman, dan
manajemen proyek secara keseluruhan. Jika Anda pergi dari sini tergantung pada di
mana Anda berasal dari dan di mana Anda ingin pergi. Jika Anda membaca melalui
bab secara berurutan, Anda mungkin harus pindah ke Bab 5, "Analisis Sistem," untuk
memperluas pemahaman Anda tentang tugas analisis sistem, alat, dan teknik. Atau,
jika Anda terdaftar dalam sistem desain yang berfokus Tentu saja, Anda mungkin
langsung beralih ke baik Bab 11, "Analisis Kelayakan dan Sistem Proposal" (yang
menandai akhir dari analisis sistem), atau Bab 12, "Desain Sistem" ( yang
menyediakan mendalam pada kegiatan perancangan sistem, prototyping, dan
pengembangan aplikasi cepat).
Beberapa instruktur telah ditangguhkan bab ini manajemen proyek untuk
akhir Tentu saja Anda. Jika demikian, Anda mungkin tertarik dalam memperluas
pengetahuan Anda tentang proyek alat manajemen, teknik, dan metode. Beberapa
sekolah menawarkan kursus manajemen proyek. Jika tidak, Anda mungkin
menemukan bahwa analisis sistem Anda dan instruktur desain mungkin mengawasi
Anda untuk menyelesaikan kursus studi independen pada subjek. Jika begitu, kami
mengarahkan Anda ke dua referensi spesifik pada akhir bab ini mungkin teks: (1)
Wysocki et al. Buku ini juga diselenggarakan di sekitar Badan Pengelola Proyek
Pengetahuan yang kita pesented dalam bab, dan (2) McLeod dan Smith buku ini
terutama komprehensif dalam cakupan yang dimensi manajemen proyek yang kita
tidak bisa bahas sepenuhnya dalam bab.