Melakukan Pekerjaan alias Fase Perencanaan

Jika Anda telah menyelesaikan Daftar Periksa #1, dan pertemuan kick-off terjadi
minggu lalu, saatnya untuk mulai bekerja keras merencanakan proyek. Bagi banyak manajer
proyek, Tahap Perencanaan adalah yang paling sulit. Di sinilah sebagian besar mekanisme
akan dilakukan dan juga di mana Anda menghadapi tantangan soft skill pertama dan paling
serius. Kabar baiknya, seperti yang saya sebutkan di Bab 1, adalah begitu Anda menguasai
mekanismenya, Anda akan memiliki lebih banyak energi dan waktu untuk fokus pada
tantangan yang lebih sulit itu, jadi mari kita mulai, oke?

APAKAH SEMUA DRAMA ITU?

Menariknya, ini adalah salah satu bidang manajemen proyek di mana ada banyak
drama intelektual tentang siklus hidup mana yang terbaik. Perhatikan bahwa ini
mengasumsikan bahwa memang ada satu model "terbaik" yang akan bekerja untuk semua
proyek, yang bahkan seorang manajer proyek pemula dapat memberitahu Anda tidak
realistis. Tiga teratas semuanya memiliki pendukungnya, dan orang-orang ini sangat
bersemangat dengan favorit mereka. Secara pribadi, saya tidak mengerti; itu alat, bukan
obat untuk semua. Soalnya, banyak orang mengasosiasikan kekurangan organisasi dan
budaya dengan metodologi pelaksanaan proyek. Pemikirannya kira-kira seperti ini: Kami
tidak dapat sepenuhnya menentukan persyaratan selama perencanaan sehingga Air Terjun
gagal dan itu juga mengapa Agile adalah cara terbaik untuk melakukannya. Argumen ini
gagal menahan air, menurut pendapat saya, karena dalam banyak kasus tim proyek dapat
menentukan persyaratan jika mereka mengumpulkannya secara sistematis. Pikirkan seperti
ini. Siklus hidup proyek ini hanyalah alat yang digunakan tim proyek untuk memandu
pekerjaan mereka. Jika Anda perlu menghapus pohon mati dari halaman depan Anda, Anda
memiliki sejumlah alat untuk dipilih. Anda bisa menggigit pohon ek raksasa itu dengan
gergaji dahan tetapi itu akan memakan waktu sangat lama. Anda juga bisa menyalakan
gergaji yang mengumpulkan debu di garasi Anda dan melakukannya seperti orang liar. Tapi
katakanlah Anda masih memiliki akal sehat dan itu adalah pohon yang sangat besar, jadi
Anda mengeluarkan dompet dan membayar seorang profesional untuk memindahkan pohon
itu. Perhatikan bahwa tujuan di sini adalah untuk menghilangkan pohon, bukan
menggunakan gergaji: terlalu sering, kami mendikte metodologi proyek dengan berpikir
bahwa itu akan meningkatkan pelaksanaan proyek ketika itu hanya alat yang salah untuk
pekerjaan itu. Padahal, menurut saya masalah sebenarnya adalah budaya. Ingat, pemilihan
alat tidak memperbaiki budaya yang rusak dan Anda tidak dapat menyalahkan kerangka
kerja untuk eksekusi yang buruk.
Siklus Hidup Proyek Air Terjun
 Siklus hidup Waterfall mungkin merupakan model siklus hidup proyek yang paling
umum dan banyak digunakan. Project Management Institute (PMI) memiliki sejarah yang
kaya dengan kerangka kerja ini, dan PM Body of Knowledge (PMBOK) mereka terutama
didasarkan padanya. Jika Anda telah mendapatkan sertifikasi Project Management
Professional (PMP), maka Anda sudah mengetahui seluk beluk Waterfall. Ini adalah
pendekatan bertahap untuk pelaksanaan proyek dengan tinjauan gerbang di akhir setiap
fase. Perangkat lunak penjadwalan proyek yang paling umum digunakan, Microsoft Project,
dioptimalkan pertama dan terutama untuk siklus hidup Air Terjun. Perlu dicatat bahwa
ketelitian perencanaan merupakan faktor penentu keberhasilan proyek mengikuti siklus
hidup ini. Dengan yang satu ini, gagal merencanakan adalah benar-benar merencanakan
kegagalan, dan itulah yang membuat siklus hidup ini sangat menantang bagi manajer
proyek junior yang mungkin belum merasakan apa yang diperlukan untuk merencanakan
proyek secara memadai.
Metodologi air terjun bekerja dengan baik ketika persyaratan dapat didefinisikan
secara memadai. Perhatikan bahwa ini memerlukan pendekatan sistematis untuk
pengumpulan persyaratan yang banyak diabaikan oleh tim proyek. Metodologi ini juga
bekerja dengan baik ketika tim harus memasukkan banyak kiriman yang saling bergantung
ke dalam proyek. Paket perangkat lunak penjadwalan yang mendukung Air Terjun sering
dioptimalkan dengan sangat baik untuk menangani paket pekerjaan yang saling bergantung
ini, tetapi mereka membutuhkan pengguna yang terampil untuk menyusun jenis jadwal ini.
Air terjun berfungsi paling baik untuk proyek menengah yang berlangsung beberapa kuartal
hingga satu tahun dengan kurang dari dua puluh sumber daya terpisah untuk dilacak.
Terakhir, alasan terpenting untuk memanfaatkan siklus hidup Waterfall adalah
kemampuannya yang unggul untuk memprediksi tonggak proyek dan akhirnya tanggal
penyelesaian.
Air terjun tidak berfungsi dengan baik ketika persyaratannya ambigu atau sering
berubah, karena semua pekerjaan perencanaan dilakukan di depan. Model ini juga gagal
ketika pelanggan tidak tahu apa yang mereka inginkan dan kesuksesan proyek bergantung
pada pengalaman pelanggan yang inovatif, karena tidak ada umpan balik pelanggan yang
dibangun ke dalam siklus hidup. Mencoba merencanakan proyek jangka panjang dengan
banyak sumber daya dan saling ketergantungan yang rumit, menggunakan Waterfall,
menjadi latihan yang membuat frustrasi dalam kerumitan. Masalah terbesar dengan Air
Terjun adalah ketika siklus hidup gagal, ia cenderung gagal total. Ketika hal-hal berjalan ke
selatan, sering terlihat terlambat dalam pelaksanaan proyek dan ada sejumlah besar biaya
hangus yang dikeluarkan. Lebih buruk lagi, sangat mungkin untuk mengeksekusi dengan
sempurna dan tetap memberikan sesuatu yang tidak disukai atau tidak akan digunakan
pelanggan dengan metodologi ini. Singkatnya, metodologi Air Terjun memiliki sedikit
toleransi untuk perencanaan proyek yang tidak memadai.
Metodologi Agile
Metodologi Agile adalah sesuatu yang sama sekali berbeda dari Air Terjun. Ini
adalah kerangka eksekusi berulang; setiap iterasi terdiri dari perencanaan, pelaksanaan,
dan rilis. Pikirkan yang ini sebagai mode eksekusi proyek "busa-bilas-ulangi". Meskipun ada
banyak paket perangkat lunak yang dapat dipilih, dua yang paling populer adalah JIRA dan
Rally. Di sini anggota tim mengatur diri sendiri untuk memenuhi kebutuhan dan tenggat
waktu proyek tertentu. Terutama digunakan untuk pengembangan perangkat lunak,
metodologi ini sangat berguna ketika pengalaman pengguna sangat penting untuk
keberhasilan proyek. Tidak seperti Air Terjun di mana semua persyaratan harus
didokumentasikan di muka dan dengan detail yang baik, metode Agile berfokus pada
dokumentasi yang memadai di setiap iterasi, sehingga memberi tim kemampuan untuk
memanfaatkan, dan bereaksi terhadap, persyaratan yang berubah. Perlu dicatat bahwa
sangat sulit untuk melakukannya dengan benar kecuali jika organisasi tersebut sudah
mengetahui dan menyukai Agile.
Agile seringkali merupakan alat terbaik untuk pengembangan perangkat lunak dan
dalam kasus di mana pelanggan tidak tahu apa yang mereka inginkan atau tidak dapat
mengartikulasikan secara spesifik hasil akhir. Tim menganggap Agile berguna dalam
skenario pembuatan prototipe cepat atau untuk proyek yang melibatkan strategi desain
berulang. Ini unggul dalam memberikan pengalaman pengguna yang tepat sasaran. Agile
juga bekerja dengan baik dengan tim yang benar-benar multidisiplin di mana setiap anggota
tim dapat mengisi banyak peran yang dibutuhkan untuk melaksanakan proyek. Karena
metodologi ini sangat berbeda dari siklus hidup Waterfall yang lebih tradisional, metodologi
ini paling berhasil jika organisasi memahami dan menerapkan pola pikir Agile.
Metodologi Agile tidak berhasil dengan baik dalam budaya Air Terjun yang
didominasi, di mana pola pikir manajemen difokuskan pada pencapaian dan hasil tertentu.
Karena sifat berulang dari kerangka kerja ini, tim proyek tidak dapat berkomitmen untuk
memberikan fitur lengkap yang diperlukan pada tanggal tertentu. Mereka dapat, dan
memang, berkomitmen untuk menghadirkan fitur paling penting pada tanggal tertentu, tetapi
sekali lagi, karena sifat siklus perencanaan Agile, komitmen dengan keyakinan tinggi tidak
mungkin dilakukan selama tahap awal proyek. Apakah itu dapat diterima atau tidak oleh
rantai manajemen adalah titik lemah dari metodologi ini. Metodologi ini juga terbagi untuk tim
di mana setiap anggota hanya dapat mengisi satu peran khusus, seperti analis database
atau desainer web. Fleksibilitas tim proyek untuk bereaksi terhadap lingkungan
pengembangan yang berubah adalah keuntungan sebenarnya dari siklus hidup Agile;
namun, jika tim itu sendiri tidak memiliki fleksibilitas teknis yang diperlukan untuk bereaksi
dengan cepat, keunggulan ini akan hilang. Terakhir, jika tidak ada infrastruktur Agile, saya
sangat menyarankan Anda membiarkan yang ini saja. Rintangan yang terlalu besar bagi
manajer proyek junior untuk menerapkan kerangka kerja siklus hidup yang sangat berbeda
untuk proyek pertama Anda. Anda harus memilih pertempuran Anda, dan masalah budaya
seharusnya tidak menjadi fokus Anda untuk beberapa proyek pertama Anda.
Model Siklus Hidup TOC
Metodologi TOC mirip dengan Waterfall tetapi dengan penggunaan buffering yang
sistematis/strategis. Setiap tonggak utama, atau paket pekerjaan, memiliki buffer jadwal
yang dihitung dengan hati-hati yang terkait dengannya. Tugas direncanakan dengan durasi
kepercayaan 60–80%; kemudian, penyangga ditambahkan ke tonggak titik akhir. Manajer
proyek mengelola konsumsi buffer, bukan paket pekerjaan spesifik, dan komit
dikomunikasikan sebagai rentang kepercayaan (rendah, sedang, tinggi). Idenya adalah
untuk mengoptimalkan alur kerja melalui rantai kritis, dan apakah paket pekerjaan tertentu
diselesaikan tepat waktu atau tidak tidaklah begitu penting. Metodologi ini lebih baik
daripada Air Terjun dalam menangani paket/kiriman kerja saling bergantung yang rumit.
ProChain adalah paket perangkat lunak yang umum digunakan terkait dengan TOC, dan
dengan pengecualian bagaimana buffer dikelola, tampilan dan rasanya sangat mirip dengan
Microsoft Project.
TOC bekerja dengan baik ketika lingkungan proyek sangat ambigu dan
prediktabilitas tanggal penyelesaian penting. Karena ini adalah tweak dari metodologi Air
Terjun, ini bekerja dengan baik di lingkungan di mana Air Terjun berkembang, seperti di
mana persyaratan dapat ditentukan secara memadai dan di mana ada banyak saling
ketergantungan yang rumit. TOC bekerja dengan baik dalam organisasi dengan praktik
manajemen proyek yang matang. Selanjutnya, tidak seperti Agile, jauh lebih mudah untuk
beralih ke TOC jika Anda sudah bekerja dalam budaya yang berorientasi pada Air Terjun.
TOC kesulitan dalam organisasi di mana buffer jadwal dianggap sebagai "padding"
dan toleransi manajemen untuk jendela komit rendah. Itu juga menderita kelemahan yang
sama yang dibahas di atas untuk siklus hidup Air Terjun. Terakhir, TOC sulit untuk
dipraktikkan dalam organisasi di mana manajemen fokus pada hasil kerja tertentu
mengalahkan pencapaian tonggak proyek. Ini adalah poin yang halus tapi penting. Ingat
bahwa dengan jadwal TOC, setiap kiriman dijadwalkan dengan durasi kepercayaan 60–
80%, sehingga sangat tidak mungkin semua kiriman akan selesai tepat waktu. Dalam
organisasi di mana anggota tim secara kaku ditahan untuk mencapai tanggal jatuh tempo
pengiriman, ini menciptakan situasi yang tidak menguntungkan bagi tim proyek dan
mengarah pada perkiraan kerja yang meningkat, dengan penyangga yang dipanggang.
Hasil akhirnya adalah tim yang dipandang berkinerja buruk dengan jadwal proyek yang
mengandung terlalu banyak buffer.
 Ini dia: pro dan kontra dari tiga siklus hidup proyek teratas. Seperti yang saya
sebutkan, jika ini adalah salah satu proyek pertama Anda, pilih siklus hidup yang sudah
dipahami oleh tim dan rantai manajemen Anda. Terlalu besar rintangan untuk mencoba
mengubah budaya organisasi sambil memikirkan nuansa bagaimana memimpin tim proyek.
Simpan pertempuran udara itu untuk lain waktu setelah Anda menguasai mekanisme
manajemen proyek. Masih tidak yakin harus memilih yang mana? Pilih metodologi Air Terjun
hanya karena buku ini mengikutinya dan saya akan memegang tangan Anda secara virtual
saat Anda mempelajari mekanismenya.
Menyiapkan Tim Anda
Oke, sekarang saatnya untuk mulai meningkatkan tim proyek Anda, jadi mari kita
mulai. Anda sudah mengadakan pertemuan awal, jadi ada beberapa hal yang perlu Anda
lakukan segera. Hal pertama yang perlu Anda lakukan adalah menjadwalkan rapat tim yang
rutin dan berulang. Sekarang pada awalnya tersipu, Anda akan berpikir itu mudah, bukan?
Tidak begitu, temanku, tidak begitu. Anda perlu melakukan beberapa perencanaan sebelum
mengirim undangan kalender itu. Pertama, pertimbangkan siapa yang ada di tim dan di
belahan dunia mana mereka berada. Pilih waktu yang paling cocok untuk semua anggota
tim Anda, waktu yang masuk dalam jam kerja normal untuk setiap orang. Manajer proyek
yang memimpin tim yang tersebar secara geografis sudah tahu bahwa ini bisa jadi
menantang. Jika Anda tidak dapat menemukan waktu yang masuk akal untuk semua orang,
atur jadwal pertemuan bergilir sehingga tidak ada geografi yang diremehkan. Ya, ini lebih
banyak pekerjaan untuk Anda, dan ya, Anda harus berusaha lebih keras untuk
"mengingatkan" anggota tim saat pertemuan berikutnya akan diadakan, tetapi pertimbangan
yang satu ini sangat membantu untuk membangun reputasi yang tinggi. -tim pertunjukan.
Setelah Anda mengetahui slot waktu yang tepat, inilah saatnya mengalihkan perhatian Anda
ke agenda rapat tetap. Saya menemukan bahwa agenda yang menyertakan waktu untuk
meninjau permintaan perubahan (lebih lanjut tentang ini nanti), pembaruan anggota tim
individu, pembukaan, dan item tindakan bekerja dengan baik untuk sebagian besar tim
proyek. Tentunya, Anda juga perlu memesan ruang konferensi jika tim Anda akan bertemu
langsung atau mengadakan telekonferensi jika tim Anda tersebar di seluruh dunia. Ini adalah
praktik yang baik untuk menjadwalkan pertemuan ini selama beberapa minggu melewati
tanggal penyelesaian proyek yang diharapkan, karena tim harus menyelesaikan masalah
yang longgar dan melakukan pekerjaan penutupan proyek setelah tanggal rilis.
Sekarang setelah Anda mengatur semua pertemuan itu, ada beberapa tugas rumah
tangga yang harus diurus. Seringkali, Anda perlu menyiapkan akun baru dan memperbarui
alat catatan organisasi Anda untuk melacak pekerjaan proyek Anda, termasuk keuangan,
metrik proyek, dan sistem pelacakan sumber daya. Karena alat ini khusus untuk organisasi
Anda, saya tidak dapat membantu Anda di sini, tetapi saya menduga Anda mendapatkan
lebih banyak bantuan di bidang ini daripada yang Anda butuhkan dari kolega Anda yang
bertanggung jawab atas sistem tersebut. Jika Anda belum melakukannya, Anda juga perlu
menyiapkan repositori proyek. Ini adalah tempat khusus di mana semua dokumen proyek
akan disimpan saat sedang dikembangkan. Banyak organisasi menggunakan Microsoft
SharePoint atau tempat penyimpanan dokumen lainnya untuk tujuan ini. Oke, satu tugas
rumah tangga terakhir yang harus diurus: kumpulkan rencana liburan dan pelatihan rekan
setim Anda selama perkiraan durasi proyek. Dengan kata lain, kirimi tim Anda email yang
meminta mereka untuk memberikan tanggal kapan mereka tidak akan tersedia untuk
mengerjakan proyek untuk periode waktu tertentu yang Anda harapkan untuk menjalankan
proyek. Anda akan memerlukan informasi ini saat membuat jadwal proyek nanti.
Mengembangkan Rencana Komunikasi
Langkah selanjutnya dalam proses perencanaan kami adalah mengembangkan
rencana komunikasi; itu cepat dilakukan dan akan terbukti sangat berguna sepanjang umur
proyek. Rencana komunikasi menguraikan bagaimana Anda akan mengomunikasikan
informasi proyek penting kepada tim Anda dan pemangku kepentingan Anda. Ini sering kali
hanya dokumen satu halaman sederhana yang menguraikan bagaimana status proyek,
keputusan besar, perubahan yang akan datang, dan eskalasi akan dikomunikasikan dan
kepada siapa hal-hal ini akan dikomunikasikan. Untuk menyusun rencana ini, mulailah
dengan rencana pengelolaan pemangku kepentingan yang Anda buat di Bab 2 . Ingat
spreadsheet Excel yang mencantumkan setiap pemangku kepentingan dan apa yang
mereka pedulikan? Jika Anda memperhatikan, maka Anda juga berpikir untuk mengetahui di
mana orang-orang ini bekerja, dan jika Anda benar-benar sedang dalam permainan A, maka
Anda berpikir untuk bertanya kepada pemangku kepentingan utama bagaimana mereka
lebih suka mendapatkan pembaruan. Jika Anda tidak mengetahui metode komunikasi
pilihan mereka, cari tahu sekarang sehingga Anda dapat mengetahui cara terbaik untuk
mengomunikasikan pembaruan status proyek Anda. Untuk membuat rencana komunikasi,
saya akan sering menggunakan lembar kerja kedua dalam rencana manajemen pemangku
kepentingan saya untuk menangkap informasi ini. Pertama, buat daftar semua peluang
komunikasi proyek utama seperti pembaruan status proyek, pelaporan hasil pengujian,
komunikasikan perubahan pada ruang lingkup pekerjaan, dll. Kemudian, identifikasi siapa
yang membutuhkan informasi ini. Selanjutnya, tentukan seberapa sering informasi ini perlu
dikirim. Misalnya, harus ada item baris untuk informasi status proyek, harus disampaikan
kepada semua pemangku kepentingan, dan harus disampaikan secara teratur. Jika ada
format yang diperlukan untuk informasi ini, catat juga dan mungkin sertakan hyperlink ke alat
web yang diperlukan sehingga semua informasi komunikasi Anda berada di satu
spreadsheet. Setelah Anda menyelesaikan rencana untuk semua informasi proyek yang
penting, ambil kesempatan untuk duduk bersama setiap pemangku kepentingan utama
Anda dan tinjau rencana Anda untuk memastikan bahwa rencana tersebut memenuhi
harapan dan kebutuhan mereka. Di dunia yang sempurna, Anda hanya perlu mengirimkan
satu pembaruan status proyek dalam format yang paling mudah untuk Anda perbarui. Di
dunia nyata, sering kali bijaksana untuk mengirimkan pembaruan tingkat tinggi kepada
pemangku kepentingan utama Anda untuk memastikan bahwa mereka mendapatkan
informasi yang mereka butuhkan dan secara aktif mengelola harapan mereka sehubungan
dengan kemajuan tim. Itu saja yang ada pada rencana komunikasi: lihat, saya katakan itu
cepat!.
Mempermudah Pengumpulan Kebutuhan
Sekarang kita bergerak ke dalam perut binatang buas dan mulai melakukan
beberapa pekerjaan PM yang serius; langkah selanjutnya adalah memfasilitasi
pengumpulan persyaratan. Jika Anda merasa sedikit kewalahan pada saat ini, jangan
khawatir: itu sangat normal. Pengumpulan persyaratan adalah yang kedua setelah
kecemasan berurusan dengan tanggal penyelesaian yang diharapkan para pemangku
kepentingan untuk menghasilkan drama dan tekanan PM. Bertahanlah dan saya akan
memandu Anda melalui lubang ular ini.
Proses mengumpulkan persyaratan sebenarnya cukup sederhana. Inilah contoh
sempurna dari mekanika yang sederhana sementara aspek orangnya sulit. Singkatnya, ini
adalah cara kerjanya. Pimpinan teknis, analis bisnis, atau siapa pun yang memimpin proses
pengumpulan persyaratan bertemu dengan pemangku kepentingan yang sesuai dan
mengumpulkan keinginan dan keinginan mereka sehubungan dengan keluaran proyek.
Harap diperhatikan bahwa biasanya bukan manajer proyek yang memimpin pengumpulan
persyaratan. Persyaratan ini kemudian didokumentasikan dalam beberapa bentuk atau cara
tergantung pada organisasi, biasanya dalam spesifikasi atau dokumen persyaratan produk.
Setelah pimpinan teknis puas dengan kelengkapan persyaratan, tim melakukan tinjauan
persyaratan secara mendetail, membuat penyesuaian sesuai kebutuhan di sepanjang jalan.
Setelah persyaratan diperbarui dengan umpan balik tinjauan, persyaratan tersebut dianggap
"dibekukan" dan setiap perubahan lebih lanjut memerlukan permintaan perubahan formal.
Sederhana, bukan? Ya, saya memang mengatakan bahwa orang-oranglah yang membuat
bagian ini begitu menantang, bukan?
Hal pertama yang perlu Anda pahami tentang pengumpulan persyaratan adalah
peran manajer proyek dalam proses ini. Bukan seperti yang Anda pikirkan dan bukan apa
yang telah Anda lakukan di masa lalu sebagai anggota tim. Tugas manajer proyek adalah
memastikan bahwa uji tuntas dilakukan dalam pengumpulan persyaratan dan semua area
fungsional yang terpengaruh terwakili dalam proses. Secara umum, pimpinan teknis proyek
Anda akan melakukan pengumpulan persyaratan; Anda sebagai PM perlu mengatur proses
pengumpulan dan peninjauannya. Selanjutnya, selama proses peninjauan persyaratan,
Anda harus menjaga topi PM Anda dengan kuat. Anda tidak lagi menjadi bagian dari tim
karena kecakapan teknis Anda; sebaliknya, Anda ada di sana untuk memberikan
kepemimpinan dan organisasi. Ini perbedaan besar, dan banyak PM baru berjuang untuk
memisahkan dua perspektif yang sangat berbeda ini saat memimpin beberapa proyek
pertama mereka.
Oke, jadi apa yang harus dilakukan manajer proyek selama pengumpulan
persyaratan? Pertama, Anda perlu memastikan bahwa pekerjaan ini selesai tepat waktu, jadi
tetapkan tanggal penyelesaian yang diharapkan dan buatlah sedikit agresif. Tujuannya di
sini adalah untuk mendorong rasa urgensi tetapi tidak berkontribusi pada suasana yang
sudah diperkuat yang biasa terjadi selama pengumpulan persyaratan. Penting bagi PM
untuk menahan seluruh tim untuk menyelesaikan pengumpulan persyaratan pada tanggal
tertentu karena, jika dibiarkan sendiri, rekan satu tim Anda akan terhenti di sini, diliputi
kelumpuhan analisis. Selama pekerjaan ini, Anda diharapkan untuk turun tangan dan
memfasilitasi diskusi tentang persyaratan khusus, bernegosiasi dengan pemangku
kepentingan utama sebagaimana diperlukan untuk membantu pimpinan teknis. Setelah
persyaratan dikumpulkan, tim kemudian akan beralih ke proses peer review. Saat meninjau
persyaratan, ingatlah bahwa Anda bukan peninjau teknis; sebagai gantinya, Anda perlu
mempertimbangkan hal-hal seperti kelengkapan, kemampuan pengujian, dan apakah
kebutuhan setiap area fungsional yang terpengaruh terpenuhi atau tidak. Setiap kali saya
perlu meninjau persyaratan dari perspektif teknis dan manajemen proyek, saya merasa lebih
mudah untuk melakukan dua tinjauan terpisah sehingga saya selalu melihat persyaratan
dari pola pikir yang sesuai. Setelah peninjauan selesai, PM perlu memastikan bahwa semua
pihak setuju bahwa persyaratan tersebut akurat dan cukup rinci untuk menginformasikan
pekerjaan proyek. Perjanjian ini perlu didokumentasikan secara formal dan disimpan
sebagai bagian dari arsip dokumentasi proyek. Setelah kesepakatan itu tercapai,
komunikasikan bahwa persyaratan dibekukan dan setiap perubahan harus disetujui oleh
Dewan Kontrol Perubahan proyek.
Jelas, saya membaca poin-poin penting dari pengumpulan persyaratan di sini. Hal
penting yang perlu diingat adalah peran manajer proyek. Tugas Anda adalah memastikan
bahwa proses ini terjadi secara tepat waktu dan menyeluruh dan bahwa semua pihak yang
terkena dampak menyetujui persyaratan tersebut. Saya menyebutkan bahwa Anda ingin
mendorong rasa urgensi tetapi pada kenyataannya, tim Anda perlu meluangkan waktu
sebanyak yang diperlukan untuk memenuhi persyaratan dengan benar. Persyaratan adalah
inti dari pekerjaan proyek dan waktu yang Anda hemat dengan menerima persyaratan
setengah matang dikerdilkan oleh jumlah waktu yang akan Anda habiskan untuk mengulang
definisi dan penerapan persyaratan tersebut nanti. Waktu yang dibutuhkan tim dalam
pengumpulan persyaratan adalah sedikit tindakan penyeimbangan, dan meskipun mungkin
tampak suram bagi Anda sekarang, saat Anda mendapatkan pengalaman sebagai manajer
proyek, Anda akan mengembangkan pemahaman tentang berapa lama proses ini harus
berlangsung. Untuk saat ini, tetapkan tanggal target yang masuk akal untuk menyelesaikan
proses, lalu dorong keluar jika tim benar-benar membutuhkan lebih banyak waktu untuk
melakukannya dengan benar. Anda selalu dapat membuat jadwal dengan persyaratan yang
solid, tetapi kemungkinan besar Anda akan melakukannya lebih lambat jika persyaratannya
tidak jelas, hilang, atau bertentangan. Anggap ini sebagai skenario "bayar saya sekarang,
atau bayar saya nanti" dan luangkan cukup waktu untuk mengembangkan persyaratan yang
solid. Terakhir, jika Anda juga ditandai untuk memimpin upaya pengumpulan persyaratan,
maka saya sangat menyarankan Anda untuk melakukan riset dalam proses ini. Ada banyak
materi pelatihan bagus di luar sana tentang cara merencanakan, menulis, dan
mengumpulkan persyaratan yang baik. Saya pribadi merasa terganggu dan sulit untuk
melakukan pengumpulan persyaratan dan mengelola keseluruhan proyek, jadi jika Anda
menemukan diri Anda dalam kesulitan itu, saya sangat menyarankan Anda untuk
menemukan mentor dan kolega yang dapat membantu Anda di sini.
Menetapkan Dewan Kontrol Perubahan Proyek
Jika Anda ingat, kami mengatakan bahwa setelah semua orang menyetujui
persyaratan, semua perubahan harus disetujui oleh proyek Change Control Board .
Sekarang saatnya untuk menyiapkannya! Hal pertama yang perlu Anda lakukan adalah
menentukan bagaimana perubahan akan dilacak, ditinjau, dan disetujui: proses apa yang
akan Anda gunakan? Ingatlah bahwa di sini Anda hanya memperhatikan perubahan internal
tim proyek Anda, jadi Anda tidak memerlukan proses yang sangat rumit atau dewan
persetujuan yang besar. Inilah rekomendasi saya: dedikasikan 10–15 menit di awal setiap
rapat tim untuk proyek CCB. Selama waktu tersebut, tinjau setiap perubahan baru dan
diskusikan sebagai tim, lalu dokumentasikan hasil diskusi tersebut dalam risalah rapat.
Selama diskusi tersebut, tim Anda akan menentukan apa yang akan Anda lakukan terkait
permintaan tersebut, jadi Anda perlu menentukan siapa yang akan menjadi anggota voting
CCB, yaitu siapa yang dapat menyetujui atau menolak permintaan tersebut. Untuk tim
proyek saya, anggota pemungutan suara—sebenarnya, semua anggota CCB—adalah tim
proyek, dan kami mengikuti proses pengambilan keputusan yang telah disepakati bersama
dalam pertemuan awal. Terlepas dari risalah rapat, Anda perlu mencatat permintaan
perubahan ke dalam Log Kontrol Perubahan sehingga Anda memiliki riwayat perubahan dan
alasan perubahan tersebut dilakukan. Log ini sangat berguna saat menutup proyek untuk
meringkas semua yang terjadi, jadi perlu meluangkan waktu untuk menyiapkan log itu
sekarang.
Itulah keseluruhan proses untuk melacak perubahan secara internal, tetapi ada
beberapa detail yang perlu Anda perhatikan sebagai PM. Pertama, Anda perlu menentukan
jenis perubahan yang harus ditinjau oleh CCB. Aturan praktis yang baik adalah bahwa
permintaan perubahan harus diajukan untuk setiap perubahan yang mengubah bentuk,
kecocokan, atau fungsi dari hasil proyek. Anda juga perlu membuat formulir permintaan
perubahan dan mendistribusikannya ke tim untuk digunakan. Formulir ini harus
mengumpulkan semua informasi yang dibutuhkan tim untuk mengevaluasi potensi
perubahan, termasuk apa yang berubah, mengapa perubahan itu diperlukan, apa yang
dipengaruhi oleh perubahan tersebut, dan berapa lama waktu yang diperlukan untuk
menerapkan perubahan ini menurut area fungsional. Seiring dengan rincian perubahan,
formulir Anda juga harus menyertakan ruang untuk mendokumentasikan pengirim
perubahan, bagaimana permintaan didisposisi (disetujui, disetujui secara bersyarat, ditolak,
dll.), tanggal perubahan disposisi, total dampak jadwal dari perubahan, dan setiap detail
yang relevan dengan penerapan perubahan (perubahan revisi, tanggal penerapan, dll.). Ini
bisa menjadi bentuk sederhana yang Anda buat dalam aplikasi perangkat lunak apa pun
yang Anda suka. Terakhir, Anda perlu menentukan siapa yang perlu diberi tahu tentang
keputusan CCB proyek apa pun dan bagaimana Anda akan mengomunikasikan perubahan
tersebut kepada mereka. Ini bisa sesederhana informasi yang diambil dalam risalah rapat
atau mungkin memerlukan komunikasi terpisah dengan pemangku kepentingan utama.
Intinya di sini adalah bahwa CCB tim proyek harus sesederhana dan semudah mungkin
sehingga rekan tim Anda akan benar-benar menggunakannya.
Ah, saya tahu apa yang Anda pikirkan sekarang: Ubah Papan Kontrol itu
menakutkan dan seluruh prosesnya adalah Bizantium, bukan? Mereka bisa di tingkat
organisasi, tapi di tingkat proyek mereka bisa dan harus sederhana, pendek, dan manis.
Untuk tim proyek CCB, saya melihat proses ini lebih sebagai alat komunikasi daripada
tantangan untuk dijalankan. Tujuannya di sini adalah untuk membuatnya semudah mungkin
bagi tim Anda untuk membicarakan perubahan dengan cara yang mencakup semua orang
yang terpengaruh. Ini adalah proses yang kritis, jadi Anda benar-benar perlu menyiapkannya
sedemikian rupa agar berfungsi untuk tim Anda. CCB organisasi itu adalah masalah lain,
dan kami akan membicarakannya lebih lanjut di Bab 4 selama Fase Eksekusi.
Mengidentifikasi Persyaratan Manajemen Proyek Organisasi
Sekarang setelah kerangka proses eksekusi proyek Anda ditentukan, saatnya untuk
mulai membuat baut di beberapa bagian. Dalam hal ini saya berbicara tentang persyaratan
organisasi tertentu untuk artefak proyek Anda. Sama seperti dalam pelingkupan, beberapa
organisasi lebih matang dalam praktik manajemen proyek mereka daripada yang lain. Jika
Anda bekerja di organisasi yang tidak dapat mengeja "manajemen proyek" tanpa kamus,
kemungkinan ekspektasi tentang artefak manajemen proyek yang Anda hasilkan cukup
rendah. Hal ini justru mempersulit pekerjaan manajer proyek junior, karena bisa
membingungkan menentukan apa yang benar-benar Anda butuhkan. Jika Anda berada di
sana, ikuti saja buku ini dan hasilkan artefak yang kami lalui. Anda tidak perlu melakukan hal
lain. Namun, jika Anda bekerja di organisasi dengan Project Management Office (PMO),
kemungkinan besar Anda diharapkan menghasilkan dokumen tertentu dalam format
tertentu. Aturan praktis saya adalah bahwa apa pun format yang harus saya gunakan, saya
berfokus terutama pada format yang benar-benar membantu saya mengelola proyek.
Semua detritus birokrasi lainnya yang saya lakukan sesedikit mungkin yang bisa saya
lakukan. Izinkan saya memberi Anda contoh tentang apa yang saya bicarakan di sini. Saya
pernah bekerja di organisasi yang mengharuskan saya menggunakan formulir permintaan
perubahan tertentu. Masalahnya, seperti yang mungkin bisa Anda tebak, adalah bahwa
formulir tersebut memiliki banyak bidang untuk diisi oleh pengirim permintaan perubahan
yang tidak relevan untuk mengevaluasi dampak dari perubahan yang diusulkan. Apa yang
terjadi jika Anda mencoba membuat rekan satu tim menggunakan formulir yang
membingungkan dan terlalu rumit? Tidak ada yang menggunakannya, itu saja! Rekan tim
saya hanya menerapkan perubahan dan mengumumkannya setelah fakta. Itu bukan kontrol
perubahan, itu gratis untuk semua. Setelah saya membuat hanya bidang yang paling
berguna yang "diperlukan", tim mulai menggunakan formulir tersebut dan saya dapat
mengendalikan eksekusi. Bagian lucu tentang keseluruhan cerita itu adalah bahwa saya
tidak pernah terlibat dalam audit kepatuhan karena mengisi formulir permintaan perubahan
yang "tidak benar". Jadi, meskipun Anda mungkin diminta untuk menggunakan bentuk atau
alat tertentu, pastikan itu sesuai dengan kebutuhan Anda sebelum Anda menggunakan
terlalu banyak energi untuk menggunakannya.
Sekarang mari kita bicara tentang ke mana Anda pergi untuk mencari tahu tentang
formulir atau alat khusus apa pun yang diharapkan Anda gunakan. Perhentian pertama
Anda haruslah PMO organisasi Anda. Orang-orang ini umumnya dengan senang hati
membantu Anda memulai dan dapat menyediakan template dan instruksi kerja yang Anda
perlukan. Mereka juga akan mengatur Anda dengan alat rekaman apa pun yang perlu Anda
gunakan. Tunggu! Apa yang saya maksud dengan "alat pencatatan"? Izinkan saya
menjelaskan: di sini saya berbicara tentang alat web yang Anda perlukan untuk
memasukkan data proyek Anda. Alat-alat ini sering digunakan untuk membuat kemajuan
pelaksanaan proyek terlihat oleh rantai manajemen organisasi dan untuk menyediakan
mekanisme untuk melacak kepatuhan terhadap proses manajemen proyek yang harus Anda
ikuti. Anda mungkin diminta untuk mengunggah/melacak data seperti pengeluaran sumber
daya (jam yang ditagih, misalnya), memproyeksikan metrik khusus seperti Earned Value
Metrics (EVM), dan menjadwalkan kinerja untuk merencanakan data, konsumsi anggaran,
dll. Karena PMO Anda sangat peduli sistem ini dan data ini, mereka bersusah payah untuk
mendokumentasikan hal ini, jadi Anda mungkin hanya perlu menghubungi orang yang tepat
untuk memulai. Jika organisasi Anda tidak memiliki PMO, Anda mungkin perlu melakukan
ping ke PM yang lebih berpengalaman dalam grup untuk melihat apa yang mereka anggap
sebagai proses atau formulir yang diperlukan. Kemungkinan dalam skenario itu ada sangat
sedikit item "wajib" yang perlu Anda masukkan, karena tidak ada PMO untuk menegakkan
kepatuhan, tetapi mungkin ada beberapa alat yang perlu Anda gunakan untuk tujuan
penganggaran dan pelacakan sumber daya, jadi lakukan sedikit penggalian dan mengatur
hal-hal itu sekarang.
Terakhir, ada beberapa hal lagi yang perlu Anda cari saat mencari persyaratan
manajemen proyek lainnya yang perlu dipenuhi oleh tim Anda, dan ini adalah hasil
kepatuhan: hal-hal seperti tinjauan dan persetujuan peraturan, keselamatan, dan hukum.
Sayangnya, tidak jarang beberapa item ini hilang dalam persyaratan pengocokan, seolah-
olah seorang pesulap mengantongi kartu bertanda dari geladak. Sebagai PM, Anda harus
waspada terhadap hal-hal seperti tinjauan keselamatan yang memerlukan persetujuan dari
dewan peninjau yang ditunjuk. Papan ini sering kali memiliki daftar periksa atau persyaratan
khusus yang harus dipenuhi oleh keluaran proyek Anda, jadi Anda perlu memastikan bahwa
pekerjaan kepatuhan semacam ini dipahami dalam persyaratan proyek dan jadwal proyek
Anda. Izinkan saya memberi tahu Anda bahwa sangat tidak menyenangkan untuk
melakukan perebutan di menit-menit terakhir agar Legal menandatangani beberapa jaminan
pemasaran karena tidak ada yang ingat bahwa Anda tidak dapat menerbitkannya sampai
Legal menyetujuinya. Satu catatan peringatan di sini: Anda harus menyadari jenis
persyaratan kepatuhan apa yang umum untuk industri khusus Anda. Jangan mengandalkan
ahli materi pelajaran dan tim proyek Anda untuk mengetahui hal ini, karena mereka mungkin
hanya bekerja dari pola pikir "beginilah cara kami selalu melakukannya". Ya, saya memiliki
orang teknis senior yang memberi tahu saya bahwa tinjauan keamanan tidak diperlukan
meskipun faktanya kami mengirimkan produk fisik ke pelanggan eksternal, dan saya
memiliki manajer yang memberi tahu saya bahwa kami tidak memerlukan Pemasaran untuk
setujui branding yang kami rancang menjadi layar sutra untuk kotak kontrol. Ini jelas
merupakan salah satu area di mana pekerjaan rumah Anda bermanfaat dan memastikan
bahwa rencana proyek Anda memahami semua persyaratan kepatuhan di awal. Terakhir,
sumber lain yang bagus untuk mengidentifikasi persyaratan semacam ini adalah PM
berpengalaman di organisasi Anda, jadi bicarakan dengan mereka untuk memastikan bahwa
tim Anda tidak melewatkan persyaratan utama apa pun yang mungkin ada di pinggiran hasil
proyek Anda.
Kembangkan Jadwal—Draf Pertama
Setelah Anda mengidentifikasi persyaratan, maka Anda siap untuk mulai membuat
jadwal proyek. Kami sebenarnya akan menangani jadwal proyek dalam dua langkah; kita
akan membuat umpan pertama sekarang, dan kemudian kita akan mengoptimalkannya di
akhir bab ini. Oleh karena itu, tidak perlu menetapkan 100% persyaratan Anda pada saat ini,
tetapi Anda memerlukan 80% yang solid untuk melanjutkan. Banyak manajer proyek junior
menemukan ini sebagai artefak proyek yang paling sulit untuk dibuat, tetapi jika Anda
mengikuti proses sistematis yang akan saya uraikan di sini, Anda akan melihat bahwa apa
yang tampak pada pandangan pertama sebagai tugas monster sebenarnya adalah satu set
lengkap subtugas yang bisa dilakukan. Di sini kita akan membuat draf jadwal menggunakan
proses tiga langkah. Kabar baiknya adalah bahwa setiap langkah ini sederhana untuk
dikuasai dan setelah dirangkai menghasilkan jadwal yang cukup baik, bahkan sebelum kita
mengoptimalkannya. Langkah pertama adalah membangun apa yang kami para praktisi PM
sebut sebagai Struktur Perincian Kerja, alias WBS. Langkah kedua adalah merangkai tugas-
tugas yang diidentifikasi di WBS ke dalam aliran logis yang kita sebut Diagram Jaringan, dan
setelah itu kita mentransfer aliran tugas ke aplikasi perangkat lunak penjadwalan mana pun
yang kita inginkan untuk menghasilkan jadwal proyek kita.
Kembangkan WBS
Kabar baiknya adalah bahwa WBS adalah artefak proyek termudah yang akan Anda
dan tim Anda hasilkan, dan biasanya Anda dapat menyelesaikannya dalam beberapa jam.
Inilah kesepakatannya; Anda dan tim Anda akan mulai dengan kiriman proyek yang
teridentifikasi dan menyerahkannya ke tugas kerja aktual, membangun WBS dalam
prosesnya. Untuk membangun WBS, Anda mulai dengan kiriman utama proyek Anda.
Kemudian, untuk setiap kiriman utama ini, Anda mengidentifikasi sub-kiriman. Untuk setiap
sub-kiriman, Anda memecahnya lebih lanjut hingga Anda mendapatkan tugas. (Gambar 3-2)
Biarkan saya memberi Anda contoh tentang apa yang saya bicarakan di sini. Anda mulai
dengan hasil proyek besar: sesuatu seperti, katakanlah, Dokumentasi Produk. Dokumentasi
itu memiliki sub-kiriman, salah satunya akan menjadi Panduan Pengguna sebagai contoh.
Anda dapat membagi Panduan Pengguna menjadi beberapa bagian seperti Diagram
Pengkabelan dan Instruksi Perakitan. Pada titik tertentu, sub-kiriman Anda menjadi tugas
seperti "Buat Diagram Pengkabelan" dan "Verifikasi Diagram Pengkabelan". Anda dan tim
Anda mengelompokkan setiap hasil kerja utama hingga mencapai tingkat tugas yang ingin
Anda lacak dalam jadwal. Untuk setiap tugas, tangkap siapa yang akan melakukan tugas
tersebut dan menurut mereka berapa lama waktu yang dibutuhkan untuk menyelesaikannya.
Anda mungkin perlu memecah beberapa tugas menjadi ukuran yang lebih mudah dikelola
tergantung pada pekerjaannya. Misalnya, jika tugasnya adalah sesuatu seperti "Buat kotak
kontrol", Anda mungkin perlu memecahnya lebih lanjut jika itu merupakan pekerjaan yang
sangat panjang atau rumit. Potongan besar pekerjaan seperti ini disebut paket pekerjaan
dalam PM-speak dan biasanya dikaitkan dengan tonggak jadwal, tetapi lebih dari itu nanti.
Setelah Anda memecah hasil utama menjadi tugas kerja spesifiknya, Anda pindah ke tugas
berikutnya dan menyabuni, bilas, ulangi sampai Anda dan tim Anda telah memecah semua
pekerjaan untuk melaksanakan proyek. Setelah Anda merasa sudah selesai, lakukan
pemeriksaan nyali dan tanyakan hal ini kepada tim: " Oke, semuanya, apakah sepertinya
kita telah menangkap semua pekerjaan yang perlu kita lakukan untuk melaksanakan proyek
ini?" Intinya di sini ada dua; satu, Anda ingin memanfaatkan pengalaman kolektif tim untuk
memverifikasi bahwa perinciannya komprehensif, dan kedua, Anda ingin membangun
dukungan dengan rekan satu tim Anda untuk jadwal akhir.
Proses ini tampaknya cukup sederhana dan mudah dijalankan, bukan? Yah, itu
karena memang begitu! Ya, ini adalah contoh sempurna dari apa yang telah saya bicarakan.
Bagian tersulit dalam membuat WBS adalah pertama-tama meyakinkan tim bahwa mereka
perlu melakukannya dan kedua mewasiti diskusi yang tak terelakkan tentang siapa yang
memiliki setiap tugas. Selama bertahun-tahun, saya telah menemukan bahwa menjual
cukup mudah untuk meyakinkan tim untuk melakukan latihan ini, dan wasit biasanya
terbatas pada beberapa tugas. Jika saya bekerja dengan tim yang berlokasi bersama atau
tim yang dapat berkumpul secara fisik untuk melakukan perencanaan proyek, maka saya
menggunakan gaya lama dan melakukan latihan ini di dinding kosong yang besar dengan
tumpukan catatan tempel dan spidol. Tim menjabarkan WBS mirip dengan cara Anda
menyusun bagan organisasi, secara hierarkis. Anda juga bisa mengelompokkan tugas-tugas
dengan pengiriman pada tahap ini karena itu tidak terlalu penting. Yang penting adalah
memecah pekerjaan secara sistematis untuk memastikan bahwa tim menangkap semua
paket dan tugas pekerjaan. Jika saya bekerja dengan tim virtual, maka kami akan
menggunakan perangkat lunak pemetaan pikiran, spreadsheet, atau alat kolaborasi yang
memungkinkan kami menangkap rinciannya. Pada titik ini Anda tidak khawatir tentang
urutan tugas yang akan dilakukan; yang datang berikutnya ketika Anda membangun
Diagram Jaringan.
Mengembangkan Diagram Jaringan
Sekarang setelah Anda mendapatkan semua pekerjaan yang perlu Anda lakukan
untuk melaksanakan proyek yang teridentifikasi, saatnya untuk mulai menyusunnya secara
logis pada garis waktu. Untuk membuat Diagram Jaringan, Anda pada dasarnya menyusun
tugas dan paket kerja sesuai urutan pelaksanaannya, yaitu alur kerja. Mulailah dengan
menggambar garis waktu, dimulai dengan tonggak "Project Start" dan diakhiri dengan
"Project Complete." Tambahkan tanggal atau tonggak utama apa pun yang diperlukan tim
untuk mengaitkan alur kerja, seperti komitmen pelanggan, hasil sementara, tonggak proyek
utama seperti tinjauan gerbang, dll. Jika Anda tidak memiliki tanggal pasti untuk tonggak ini,
tidak apa-apa , letakkan saja di tempat yang menurut Anda paling masuk akal untuk saat ini.
Ini hanyalah pancang di tanah untuk menambatkan diagram, dan tanggal sebenarnya untuk
itu akan disesuaikan nanti. Anda hanya memerlukan dua, Mulai dan Selesai, untuk memulai,
tetapi sering kali berguna untuk menambahkan beberapa taruhan menengah ke dalam garis
waktu Anda untuk membantu tim mengatur alur kerja. Selanjutnya, pindahkan tugas dan
paket kerja dari WBS ke garis waktu yang paling masuk akal. Tujuannya di sini adalah untuk
menentukan alur kerja terbaik untuk proyek tersebut, jadi harap untuk memindahkan tugas
sampai Anda mendapatkan alur yang paling masuk akal. Mundur dari diagram dan lihat
apakah ada tempat di mana lebih banyak pekerjaan dapat dilakukan secara paralel dan
pastikan bahwa setiap tugas memiliki hasil apa pun yang diperlukan untuk memulai
pekerjaan dengan tepat. Selanjutnya, optimalkan alurnya. Sebagai tim, ikuti alurnya,
sesuaikan dan sesuaikan sesuai kebutuhan sampai semua orang sepakat. Sekarang
gambar garis penghubung di antara tugas-tugas untuk mengilustrasikan alur kerja, dengan
hati-hati menghubungkan semua tugas satu sama lain. Terakhir, beri nomor setiap tugas
secara berurutan di sepanjang alur kerja. Ledakan! Itu Diagram Jaringan Anda selesai!
Untuk tim yang secara fisik mampu melakukan pekerjaan perencanaan ini bersama-
sama, Anda meminta setiap anggota tim untuk memindahkan catatan tempel yang mereka
miliki ke tempat yang sesuai di garis waktu. "Garis waktu" terdiri dari selembar kertas
panjang, seperti kertas daging, ditempel di dinding. Setelah semua catatan tempel
dipindahkan ke garis waktu, tim menelusuri alur, memindahkan catatan tempel ke sekeliling
hingga alur dioptimalkan. Tautan ditarik dan setiap catatan mendapat nomor indeks. Untuk
tim yang melakukan pekerjaan ini secara virtual, akan sangat membantu jika menggunakan
aplikasi perangkat lunak yang memungkinkan tim untuk menarik dan melepas objek yang
mewakili tugas di sekitarnya untuk membangun "dinding" garis waktu proyek virtual.
Perangkat lunak pemetaan pikiran sangat baik untuk jenis pekerjaan ini. Perlu dicatat bahwa
jenis perencanaan ini sangat sulit dilakukan secara virtual, jadi jika Anda memiliki tim virtual,
maka Anda benar-benar perlu berpikir keras tentang cara terbaik untuk mengeksekusi WBS
dan Diagram Jaringan. Sering kali, tim virtual melakukan banyak pra-pekerjaan secara
mandiri, berkumpul hanya di bagian akhir untuk menjalankan alur kerja dan menyelesaikan
Diagram Jaringan.
Membangun Draf Jadwal Mari kita rekap, oke? Pada titik ini dalam proses
pengembangan jadwal, Anda harus mengetahui:
1. Semua kiriman untuk proyek
2. Semua paket pekerjaan dan tugas yang diperlukan untuk menghasilkan kiriman
dan melaksanakan proyek
3. Pemilik untuk setiap tugas
4. Berapa lama waktu yang dibutuhkan untuk setiap tugas
5. Pendahulu dan penerus untuk setiap tugas, yaitu alur kerja
6. Nomor ID Tugas
Jika Anda kehilangan salah satu dari data ini, berhentilah di sini dan temukan.
Jangan lanjutkan membuat jadwal tanpa basis pengetahuan inti ini. Langkah selanjutnya
dalam proses pengembangan jadwal adalah menggunakan kumpulan data inti ini untuk
membangun jadwal proyek menggunakan beberapa jenis aplikasi penjadwalan. Setiap
tangisan, makian, ludah yang pernah saya alami selama aplikasi penjadwalan adalah
karena fakta bahwa saya tidak memulai dengan kumpulan data inti ini. Ini jelas merupakan
kasus "sampah masuk, buang sampah", jadi ikuti saran saya dan jangan mulai sampai Anda
memiliki kumpulan data lengkap.
Pilihan aplikasi penjadwalan terserah Anda dan tergantung pada metodologi proyek
yang Anda gunakan. Aplikasi ini sedikit berbeda, jadi saya tidak membahas secara spesifik
untuk aplikasi tertentu; sebagai gantinya, saya akan memandu Anda melalui proses tingkat
tinggi. Jika Anda pengguna baru perangkat lunak jenis ini, bantulah diri Anda sendiri dan
ikuti beberapa pelatihan pengguna dasar sebelum Anda mulai. Langkah pertama Anda
adalah menyiapkan parameter proyek seperti jenis kalender yang akan digunakan, tanggal
mulai, seberapa sering penyimpanan file terjadi, satuan ukuran waktu (mis., Minggu, jam,
menit): pada dasarnya, pengaturan konfigurasi umum Anda men-tweak untuk aplikasi lain.
Selanjutnya, muat di hari-hari non-kerja seperti hari libur perusahaan selama perkiraan
durasi proyek Anda; perpanjang tanggal akhir jadwal Anda beberapa minggu jika proyek
berjalan lama.
Sekarang Anda siap untuk mulai memasukkan tugas dan pencapaian tertentu. Anda
akan menggunakan "tonggak sejarah" untuk membedakan paket pekerjaan, untuk menandai
tanggal penting, untuk menyusun laporan status Anda, dan untuk mengukur kemajuan.
Sebagian besar Anda memasukkan bayi-bayi ini ke dalam perangkat lunak penjadwalan
Anda seperti halnya Anda melakukan tugas, dan biasanya ada bidang yang Anda alihkan
untuk menetapkan durasi nol untuk item-item ini. Jadi, mulailah selalu dengan pencapaian
"Project Start" Anda saat item baris pertama Anda masuk ke dalam jadwal. Pada titik ini
Anda memiliki pilihan untuk dibuat: apakah Anda ingin memasukkan setiap tugas proyek
secara berurutan dari Diagram Jaringan menggunakan ID Tugas atau apakah Anda ingin
mengelompokkan tugas berdasarkan kepemilikan, dan maksud saya mengelompokkan
semua tugas untuk setiap fungsional daerah bersama? Tidak ada jawaban benar atau salah
di sini; itu murni masalah preferensi pribadi. Lebih mudah untuk memasukkan tugas secara
berurutan, karena Anda cukup memanfaatkan nomor ID Tugas Diagram Jaringan Anda dan
memasukkan setiap tugas sesuai urutan kemunculannya di alur. Namun, hal ini mempersulit
untuk melihat semua tugas untuk area fungsional tertentu. Saya lebih suka menyusun tugas
secara berurutan berdasarkan area fungsional sehingga saya dapat “melihat” semua
pekerjaan untuk setiap sub-tim sekaligus; ini, bagaimanapun, membuat entri data lebih sulit.
Sebagian besar jenis perangkat lunak penjadwalan memungkinkan Anda menyiapkan
bendera dan filter untuk ditangani, namun Anda ingin melihat datanya, jadi sekali lagi, tidak
ada cara yang salah untuk pergi ke sini. Jika Anda pemula, bantulah diri Anda sendiri dan
susun tugas sesuai urutan yang muncul di Diagram Jaringan. Mengapa meminjam masalah,
kan? Saat Anda melanjutkan Tahap Eksekusi, tugas akan diurutkan dalam jadwal Anda agar
selaras dengan alur kerja dan lebih mudah untuk mengikutinya. Saat Anda memasukkan
tugas, pastikan Anda memasukkan pemilik, perkiraan pekerjaan, pendahulu, dan penerus
untuk setiap tugas saat Anda menjalankannya. Jangan masukkan tanggal mulai dan selesai
tertentu. Tujuannya di sini adalah untuk membuat perangkat lunak melakukan pekerjaan
mencari tahu tanggal tersebut sehingga hanya memasukkan tanggal mulai/selesai untuk
tonggak yang mewakili kiriman masuk. Praktik terbaiknya adalah memasukkan tanggal
mulai/selesai secara manual untuk sesedikit mungkin tugas atau tonggak sejarah karena
tanggal ini membatasi perangkat lunak penjadwalan secara artifisial dan sebenarnya bukan
itu yang Anda inginkan. Sisipkan pencapaian sesuai kebutuhan untuk membantu Anda
melacak kemajuan eksekusi. Saya memisahkan paket pekerjaan utama dengan tonggak
awal/akhir; misalnya, saya akan menggunakan tonggak "Pengembangan Dimulai" dan
tonggak "Pengembangan Selesai" sehingga saya dapat melaporkan status tonggak
"Pengembangan Selesai" selama masa proyek. Gunakan tonggak secara bebas untuk
membantu mengelompokkan paket pekerjaan; pastikan saja bahwa setiap pencapaian
disetel ke durasi nol dan memiliki setidaknya satu pendahulu dan satu penerus.
Setelah Anda memasukkan semua tugas Anda dan selesai mengetik pencapaian
"Proyek Selesai", lompatlah dan lakukan tarian gembira yang cepat! Anda baru saja
menyelesaikan 75% pekerjaan untuk membuat jadwal proyek Anda! Perhatikan bahwa
bagian tersulit dari keseluruhan proses sejauh ini adalah bergulat dengan perangkat lunak
penjadwalan? Jika Anda mengikuti saran saya dan memastikan bahwa Anda memiliki
kumpulan data inti yang lengkap untuk memulai, maka saya yakin Anda akan terkejut
betapa mudahnya menggunakan perangkat lunak penjadwalan itu juga. Jelas, betapa
"mudahnya" proses itu bergantung pada seberapa banyak upaya yang Anda lakukan untuk
mempelajari cara menggunakan perangkat lunak penjadwalan, jadi luangkan waktu untuk
melakukan pelatihan itu.
Oke, duduk kembali dan mari kita lakukan sedikit pembersihan sebelum kita
menyebut draf jadwal itu selesai. Pertama, periksa kembali apakah setiap tugas terkait ke
dalam rantai atau aliran yang berkelanjutan. Dalam jadwal yang sempurna, hanya dua item
baris yang tidak memiliki pendahulu dan penerus adalah pencapaian "Proyek Dimulai" dan
"Proyek Selesai". Lakukan yang terbaik untuk mencapai kesempurnaan. Selanjutnya, cari
tugas apa pun dengan tanggal yang Anda masukkan secara manual: seharusnya hanya ada
beberapa tugas, dan semuanya harus menjadi tonggak yang mewakili pengiriman eksternal
ke dalam alur kerja proyek. Lihatlah jalur atau rantai kritis tergantung pada perangkat lunak
yang Anda gunakan.
Apakah masuk akal? Apakah tugas yang Anda harapkan ada di sana? Jika tidak,
cari tahu di mana logikanya rusak dan perbaiki. Sekarang verifikasi bahwa setiap tugas
memiliki sumber daya yang ditetapkan untuknya. Saya menugaskan diri saya sendiri,
sebagai PM, kepemilikan atas semua pencapaian dalam jadwal. Terakhir, hubungi pakar
materi pelajaran Anda dan lakukan pemeriksaan kewarasan. Tanyakan hal-hal seperti
"apakah masuk akal jika pengembangan kode akan memakan waktu 4 bulan?" dan "apakah
masuk akal bahwa jaminan pemasaran akan memakan waktu 2 minggu untuk
diselesaikan?" Setelah Anda puas bahwa semua area pemecahan masalah ini telah
diselesaikan, maka saatnya untuk menyebut jadwal draf ini selesai!
KATA TENTANG TANGGAL DAN MENGAPA MEREKA TIDAK PENTING PADA
TAHAP GAME INI
Oke, saat ini Anda mungkin panik karena tanggal Penyelesaian Proyek bukanlah
tanggal yang harus Anda capai, bukan? Tenang, inilah yang seharusnya terjadi pada tahap
perencanaan ini. Faktanya, sangat jarang jadwal yang sesuai dengan tanggal target yang
diberikan tim selama pelingkupan. Jadi apa yang terjadi dan mengapa menurut saya tanggal
ini tidak terlalu penting pada tahap permainan ini? Sampai Anda mengoptimalkan jadwal
proyek, tanggal apa pun yang dihasilkan sejauh ini hanya bersifat spekulatif. Ada terlalu
banyak faktor yang berperan saat ini untuk mengunci tanggal tertentu dan percaya bahwa
itu sudah pasti. Misalnya, saat tim sedang membangun Diagram Jaringan, mereka mungkin
menyadari bahwa mereka tidak dapat mencapai tanggal pengiriman proyek yang diinginkan.
Namun, tata letak ini tidak memperhitungkan hari libur, liburan individu, seluk-beluk
mengoordinasikan paket pekerjaan yang sangat saling bergantung, sifat paralel dari
beberapa pekerjaan, dll., jadi tidak mengherankan jika tanggal tersebut tidak akurat. Jadwal
draf Anda hanya itu, draf yang akan kami optimalkan setelah kami melakukan beberapa
perencanaan lagi. Jadi santai, Anda melakukannya dengan benar! Kehati-hatian harus
diberikan untuk mengelola harapan rekan tim dan pemangku kepentingan Anda pada saat
ini. Ingatkan mereka bahwa tanggal-tanggal ini adalah indikator awal dan bahwa semua
faktor yang berkontribusi pada jadwal akhir belum dimasukkan. Faktanya, saya biasanya
mengambil tindakan pencegahan untuk menyembunyikan tanggal seperti yang muncul di
perangkat lunak penjadwalan saat tim memvalidasi logika jadwal untuk menghindari
paranoia massal dan solilokui "langit runtuh".
Buat Daftar Periksa Kesiapan Rilis
Setelah kiriman solid, Anda perlu memikirkan sedikit tentang proses rilis dan
membuat Daftar Periksa Kesiapan Rilis . Langkah ini harus dilakukan sebelum Anda
mengoptimalkan jadwal Anda, tetapi dapat dilakukan kapan saja dalam alur kerja
perencanaan. Saya paling sering mendapati diri saya melakukannya setelah menyelesaikan
draf jadwal. Daftar Periksa Kesiapan Rilis kurang lebih seperti itu: daftar periksa item yang
harus diselesaikan sebelum pengiriman proyek dapat dirilis. Item pada daftar periksa ini
adalah item yang saya anggap sebagai item "uji tuntas", yaitu item yang harus dilakukan
untuk memastikan bahwa produk akhir aman dan terjamin, memenuhi semua persyaratan
kepatuhan yang diperlukan, dan telah dibuat menggunakan praktik terbaik industri. Anda
perlu menemukan, atau membuat, daftar periksa ini sekarang karena bagian dari
pengoptimalan jadwal yang akan kita bahas nanti termasuk memastikan bahwa item pada
daftar periksa ini memiliki paket pekerjaan yang sesuai dalam jadwal proyek. Di organisasi
manajemen proyek yang lebih matang, daftar periksa ini sudah ada dan yang perlu Anda
lakukan hanyalah menggunakannya. Namun, jika tidak ada makhluk seperti itu di dunia
Anda, maka Anda harus membuatnya, jadi mari kita bicara tentang cara Anda membuatnya.
Membuat Daftar Periksa Kesiapan Rilis adalah salah satu dari tugas-tugas PM
langsung yang jika dilakukan secara mandiri mudah dihilangkan. Saya lebih suka
menggunakan spreadsheet, tetapi sebenarnya Anda dapat menggunakan perangkat lunak
apa pun yang Anda suka untuk tugas ini. Secara struktural, Anda ingin memiliki daftar item,
tempat (alias kotak centang) untuk menunjukkan apakah tugas telah selesai atau belum,
tempat untuk catatan untuk setiap item, dan beberapa catatan kontekstual pada proyek
seperti nama proyek, revisi , ruang lingkup pekerjaan dipertimbangkan, dll. Tulis setiap item
sebagai pertanyaan, kira-kira seperti ini: "Apakah semua data yang dapat diidentifikasi
secara pribadi dienkripsi dalam penyimpanan dan dalam perjalanan?" Mengenai apa yang
sebenarnya perlu ada dalam daftar periksa, mulailah dengan praktik terbaik, yaitu hal-hal
seperti tinjauan desain, validasi desain, penutupan dan pengelolaan cacat, kepatuhan
terhadap standar perusahaan seperti branding atau privasi, dll. Selanjutnya, pertimbangkan
keselamatan dan apa yang perlu dilakukan untuk mendapatkan persetujuan kepatuhan
untuk hasil proyek. Pertimbangkan item-item seperti kriteria penerimaan pelanggan dan
metrik terukur lainnya yang mungkin diminta oleh tujuan proyek. Terakhir, pertimbangkan
proses rilis itu sendiri: Apakah ada persetujuan formal yang perlu diperoleh? Ubah
permintaan yang perlu disampaikan? Jika demikian, maka perlu ada item yang sesuai di
daftar periksa. Jangan lupa sertakan item logistik untuk perencanaan rilis seperti
penjadwalan dan ketersediaan sumber daya. Daftar periksa terakhir untuk proyek spesifik
Anda mungkin tidak akan lebih dari 20–30 item tergantung pada ruang lingkup proyek Anda.
Ingat ini adalah item "harus dilakukan" mutlak yang harus diselesaikan oleh tim, dan apa
pun yang mendapatkan "Tidak" di daftar periksa adalah penghenti dan harus mendapat
pengawasan serius sebelum memutuskan apakah akan merilis proyek atau tidak. Setelah
daftar periksa Anda selesai, bagikan ke rekan tim dan pemangku kepentingan utama Anda
untuk memastikan bahwa Anda tidak melewatkan apa pun. Setelah Anda mendapatkan
persetujuan pada item daftar periksa, Anda dapat menyimpannya untuk saat ini. Kami akan
merujuknya saat kami mengoptimalkan jadwal, tetapi kami akan benar-benar
menggunakannya nanti untuk perencanaan rilis di Bab 4.
Menyusun Rencana Manajemen Risiko
 Kami sekarang sampai pada proses manajemen proyek yang paling sering dilewati
di luar sana, mengembangkan rencana manajemen risiko. Da-duh. . . Da-duh. . . Da-duh. . .
udah denger musik Jaws belum? Oke, sebenarnya tidak seburuk itu, dan menurut saya
sebagian besar PM, termasuk yang senior, bergumul dengan pengembangan rencana
manajemen risiko karena meskipun mekanisme sebenarnya dari manajemen risiko mudah
dipelajari, PM harus memotivasi, bernegosiasi, wasit, dan memimpin tim mereka untuk
menyelesaikan perencanaan risiko, dan itu adalah ketel ikan lainnya. Sekali lagi, kita melihat
bahwa mekanismenya sederhana, tetapi soft skill yang dibutuhkan untuk sukses membuat
ini bekerja lebih keras dari yang seharusnya. Jadi, seperti rekor rusak yang saya alami,
izinkan saya mengatakannya lagi: kuasai mekanisme sehingga Anda memiliki lebih banyak
waktu dan energi untuk menghadapi tantangan antarpribadi dalam manajemen proyek.
Rintangan terbesar untuk menerapkan manajemen risiko adalah persepsi bahwa
semuanya adalah kekacauan birokrasi yang rumit yang sebagian besar membuang-buang
waktu tim. Untuk mengatasi persepsi ini, saya akan membantu Anda merampingkan proses
dan menyusunnya menjadi sesuatu yang benar-benar dapat Anda dan tim proyek Anda
gunakan. Jika Anda tergoda untuk melewatkan proses ini, izinkan saya mengatakan bahwa
saya yakin proses manajemen risiko saja adalah satu-satunya alat terbaik yang dimiliki PM
untuk mengurangi kebutuhan akan pemadaman kebakaran yang panik selama Fase
Eksekusi. Anda lihat, kami akan merencanakan potensi kebakaran tersebut dan menyiapkan
tanggapan sehingga ketika bara api potensi kebakaran hutan menyala, tim siap dengan
rencana yang secara efektif memadamkan percikan tersebut dengan eksekusi yang solid
dan baik.
Perencanaan risiko, seperti kebanyakan perencanaan proyek, merupakan proses
tiga langkah: pertama kami mengumpulkan risiko, lalu kami memeringkatnya, dan terakhir
kami mengembangkan rencana untuk menghadapi risiko teratas. Untuk mengumpulkan
potensi risiko proyek, fasilitasi sesi curah pendapat dengan tim proyek Anda. Idenya di sini
adalah untuk mengidentifikasi sebanyak mungkin risiko, jadi jangan terpaku pada seberapa
masuk akal setiap saran. Untuk mendapatkan serangkaian risiko yang kaya, ajukan
pertanyaan pemikiran masa depan seperti “Kami baru saja merilis hasil proyek ini dan tidak
ada yang membelinya. Apa yang telah terjadi?" dan “Produk ini sangat sukses sehingga
sekarang manufaktur tidak dapat memenuhi permintaan. Apa yang kita lewatkan?” Seperti
semua sesi curah pendapat, tim pada akhirnya berhenti, jadi lanjutkan ke langkah
berikutnya, yaitu memeringkat risiko yang teridentifikasi. Untuk memeringkat risiko, Anda
memerlukan dua skala: satu untuk dampak risiko jika akan terjadi dan satu lagi untuk
kemungkinan risiko akan terjadi. Timbangan ini benar-benar arbitrer, jadi buat saja yang
seimbang; pastikan untuk menggunakan opsi penskalaan dalam jumlah genap, seperti skala
1–4. Jika Anda memilih skala 1–9, misalnya, apa yang akan Anda temukan adalah bahwa
beberapa tim Anda tidak ingin memihak dan akan mengambil jalan tengah dari 5. Jika cukup
banyak orang yang memilih 5, maka Anda berakhir dengan setiap risiko dinilai sebagai
kemungkinan yang sama/berdampak, yang tidak membantu, jadi buatlah skala Anda dengan
jumlah opsi yang genap. Sangat umum bagi beberapa rekan tim Anda untuk menawarkan
risiko yang sangat tidak mungkin dan mengadvokasi mereka dengan penuh semangat. Ini
bukan masalah besar dan Anda dapat meredakan diskusi yang berpotensi berantakan
hanya dengan menyetujui untuk menambahkan risiko hewan peliharaan mereka ke dalam
daftar. Selama proses pemeringkatan, banyak dari risiko ini akan hilang karena
kemungkinan terjadinya sangat rendah. Oleh karena itu, selamatkan diri Anda dari sakit
kepala dan jangan mempermasalahkan pembicaraan gila mereka. Untuk sebagian besar
proyek kecil hingga menengah, tim dapat mengidentifikasi dan menilai potensi risiko dalam
satu atau dua jam. Dalam kasus proyek besar, kemungkinan sudah ada alat catatan yang
diperlukan untuk merekam dan melacak risiko proyek. Dalam kasus ini, identifikasi dan
penilaian risiko dapat memakan waktu cukup lama untuk diselesaikan. (Gambar 3-3).
Setelah semua risiko yang teridentifikasi telah dinilai untuk kemungkinan terjadinya
dan dampaknya, saatnya untuk memeringkatnya. Peringkat risiko adalah rumus sederhana;
peringkatnya sama dengan peringkat kejadian dikalikan dengan peringkat dampak . Jika
Anda mengurutkan risiko berdasarkan peringkat, maka Anda akan melihat risiko yang paling
mendesak untuk ditangani di bagian atas daftar. Ngomong-ngomong, daftar ini dengan
setiap risiko yang terdaftar termasuk peringkat dan peringkat disebut sebagai daftar risiko.
Keren, ya? Anda sekarang membuang terminologi yang diberkati PMI! Langkah selanjutnya
adalah menerapkan sedikit akal sehat. Sebagai sebuah tim, tinjau daftar risiko peringkat dan
tentukan pesaing teratas mana yang benar-benar dapat dipengaruhi oleh tim. Perdebatan
tentang risiko yang tidak dapat ditangani oleh tim tidak ada gunanya dan membuat frustrasi.
Misalnya, saya sering mendengar risiko “sumber daya dapat ditarik dari proyek”; baik, tentu,
itu bisa terjadi, tetapi pada titik perencanaan risiko dalam proyek, tidak ada rencana untuk
melakukan itu, jadi mengapa membuang waktu untuk memperdebatkannya? Jika ada
kemungkinan sumber daya tertentu akan ditarik, maka itu adalah sesuatu yang dapat kami
rencanakan, tetapi risiko samar yang tidak dapat diprediksi atau terpengaruh bukanlah
sesuatu yang dapat direncanakan oleh tim. Kami menyebutnya tidak diketahui tidak
diketahui dalam PM-berbicara. Sebagai sebuah tim, identifikasi tiga hingga lima risiko
teratas yang ingin Anda tangani. Mengapa hanya tiga sampai lima risiko? Nah, menurut
pengalaman saya, itulah jumlah risiko yang paling masuk akal yang dapat ditangani tim
pada satu waktu tanpa mengurangi produktivitas mereka. Jika tim Anda memiliki bandwidth
dan Anda telah mengatasi risiko teratas, Anda selalu dapat menambahkan lebih banyak ke
dalam rencana manajemen risiko jika waktu memungkinkan, namun untuk saat ini fokus saja
pada tiga hingga lima risiko teratas tersebut.
 Sejauh ini, sangat bagus bukan? Anda sekarang memiliki daftar tiga sampai lima
risiko yang Anda perlukan untuk mengembangkan rencana, jadi mari kita bicara tentang
perencanaan risiko sekarang. Trik untuk perencanaan manajemen risiko adalah menyadari
bahwa hanya ada lima cara untuk menghadapi potensi risiko, yaitu sebagai berikut:
• Mitigasi—mengambil tindakan khusus untuk mencegah atau mengurangi dampak
risiko yang terjadi
• Kontinjensi—mengambil tindakan khusus untuk mengurangi dampak risiko setelah
terjadi
• Pemindahan—mengambil tindakan khusus untuk mengalihkan risiko ke entitas lain
• Penerimaan—tidak melakukan apa-apa dan menerima dampaknya jika risiko terjadi
• Penghindaran—mengambil tindakan khusus untuk menghindari kemungkinan dan
dampak risiko yang terjadi
Itu dia! Setelah Anda memahami fakta bahwa Anda hanya memiliki lima opsi ini,
rencana manajemen risiko menjadi jauh lebih mudah untuk dikembangkan. Telusuri kelima
opsi ini untuk setiap risiko dan tentukan tindakan mana yang akan diambil (atau tidak
diambil) oleh tim untuk mengantisipasi risiko yang terjadi dan setelah risiko itu benar-benar
terjadi. Tindakan yang diputuskan oleh tim di sini perlu dimasukkan kembali ke dalam jadwal
Anda sebagai tugas khusus. Dengan melakukan ini, Anda menghilangkan banyak birokrasi
yang umumnya terkait dengan proses manajemen risiko. Tugas-tugas ini sekarang dilacak
sebagai bagian dari pekerjaan proyek reguler dan dipantau serta dikendalikan seperti itu.
Kami akan membicarakan lebih lanjut tentang ini nanti, tetapi untuk saat ini, pahami saja
bahwa penting bagi Anda untuk menerjemahkan rencana manajemen risiko Anda ke dalam
tugas tertentu yang disematkan ke dalam jadwal proyek. Anda mungkin akan memilih lebih
dari satu opsi untuk menangani risiko yang sangat penting dan Anda akan memilih untuk
menerima semua risiko yang tidak Anda tangani. Ini tidak apa-apa, dan sangat sah untuk
menyatakan penerimaan itu di muka. Satu catatan terakhir di sini tentang cara merekam
rencana manajemen risiko Anda. Karena saya mengintegrasikan tugas-tugas yang terkait
dengan pengelolaan setiap risiko yang diambil tim ke dalam jadwal proyek, risalah rapat tim
mingguan adalah tempat pembaruan rencana risiko didokumentasikan. Namun, banyak
organisasi meminta PM untuk mencatat risiko dan melacak risiko ke dalam daftar risiko
formal. Ini sering kali merupakan alat atau dokumen web terpisah yang diharapkan
dipertahankan oleh PM. Mempertahankan daftar risiko terpisah adalah duplikasi upaya jika
Anda telah memasukkan rencana risiko ke dalam jadwal Anda, jadi ini adalah salah satu
area di mana saya berusaha sesedikit mungkin untuk mematuhinya.
Optimalkan Jadwal
Oke,kita hampir selesai dengan merencanakan proyek pertama Anda; faktanya,
kami sangat dekat sehingga Anda bisa mencium garis dasarnya! Satu-satunya hal yang
harus dilakukan adalah mengoptimalkan jadwal, jadi mari kita lakukan. Hal pertama yang
perlu Anda lakukan adalah memverifikasi bahwa semua pekerjaan proyek terwakili dalam
jadwal. Jika Anda ingat, Anda mungkin telah membangun WBS dengan hanya 80% dari
persyaratan proyek yang terdokumentasi, jadi inilah saatnya untuk memeriksa kembali dan
memastikan bahwa semua persyaratan yang terdokumentasi memiliki tugas terkait dalam
jadwal. Pastikan bahwa semua item pada Daftar Periksa Kesiapan Rilis memiliki tugas
perwakilan dalam jadwal. Lakukan hal yang sama untuk rencana manajemen risiko Anda.
Tidak jarang beberapa paket pekerjaan atau rencana risiko memiliki beberapa ambiguitas
tentangnya. Misalnya, pimpinan teknis sedang menunggu umpan balik akhir dari arsitek
keamanan, yang dapat menghasilkan persyaratan baru. Untuk tugas yang ambigu ini, Anda
perlu memasukkan tugas placeholder ke dalam jadwal dan memberikan perkiraan pekerjaan
yang konservatif. Tugas placeholder ini benar-benar buffer jadwal, dan kita akan
membicarakannya nanti. Kuncinya di sini adalah mengurangi ambiguitas dengan
menambahkan buffer ini. Dalam hal manajemen risiko, Anda mungkin tidak mengetahui
apakah risiko tersebut telah terjadi, sehingga Anda perlu menambahkan tugas untuk
menguji apakah risiko tersebut aktif atau tidak. Ini adalah tugas-tugas sederhana seperti
"Periksa ramalan cuaca sebelum melakukan penuangan fondasi." Dalam contoh tersebut,
jika cuaca buruk diperkirakan dan penuangan pondasi akan tertunda, tugas selanjutnya
dalam alur kerja adalah tugas penyangga cuaca yang diaktifkan. Jika tidak ada penundaan
yang diharapkan, tugas tersebut dapat dinonaktifkan atau ditandai sebagai selesai dengan
durasi nol. Setelah Anda yakin telah menangkap semua pekerjaan yang diketahui, saatnya
untuk beralih ke langkah berikutnya.
Setelah memverifikasi bahwa semua pekerjaan terwakili, Anda perlu memastikan
bahwa semua hari libur dan hari-hari tidak bekerja direkam dalam alat penjadwalan.
Pastikan untuk memasukkan liburan, pelatihan, dll yang direncanakan anggota tim. Mungkin
merepotkan untuk membuat rekan tim Anda memberikan rencana liburan mereka, terutama
jika Anda bertanya pada bulan Februari dan mereka bahkan belum mulai memikirkan
tentang liburan musim panas mereka. Dalam kasus tersebut, masukkan placeholder untuk
liburan atau waktu pelatihan apa pun yang mungkin mereka miliki yang akan bertahan lebih
lama dari beberapa hari. (Untuk diketahui, hari-hari non-kerja ini dilacak dalam fungsi
kalender aplikasi penjadwalan Anda dan bukan merupakan tugas khusus dalam jadwal.)
Sebaiknya rencanakan saat-saat ketika anggota tim Anda tidak akan mengerjakan proyek
Anda di awal untuk menghindari membuat orang-orang yang sama bekerja lembur untuk
mengejar pekerjaan proyek begitu mereka kembali. Jika proyek akan mencakup liburan
akhir tahun seperti Thanksgiving, Natal, dan Tahun Baru, saya memblokir satu minggu
penuh untuk setiap hari libur sebagai hari tidak bekerja. Saya melakukan hal yang sama
untuk Tahun Baru Imlek sesuai kebutuhan. Ini memberikan sedikit penyangga tambahan
untuk jadwal dan memperhitungkan fakta bahwa sebagian besar tim akan mengambil cuti.
Berbicara tentang buffer, sekarang saatnya untuk menambahkan lebih banyak lagi.
Untuk setiap paket pekerjaan utama, tambahkan tugas penyangga ke jadwal untuk
mengantisipasi hal-hal yang tidak diketahui yang tidak diketahui yang telah kita bicarakan
sebelumnya. Tempatkan tugas penyangga ini tepat sebelum tonggak penyelesaian dan
jadikan pendahulu untuk tugas berikutnya dalam alur kerja. Jangan khawatir tentang berapa
banyak pekerjaan yang harus ditetapkan ke setiap buffer; cukup tambahkan mereka ke
dalam jadwal antara paket pekerjaan utama atau pencapaian. Saya biasanya buffer
pekerjaan pengembangan, pekerjaan validasi, dan buffer catchall tepat sebelum tonggak
rilis proyek. Untuk mengetahui berapa banyak buffer yang Anda butuhkan, lihat perkiraan
total pekerjaan dan hitung persentase dari total untuk didistribusikan ke seluruh timeline
proyek. Untuk proyek di mana saya merasa kami memiliki kepercayaan tinggi terhadap
persyaratan dan risiko rendah hingga sedang, saya biasanya akan menggunakan buffer
15%; untuk proyek yang masih banyak yang tidak diketahui dan risikonya lebih tinggi saya
akan menggunakan 25%. Jelas, berapa banyak buffer yang Anda gunakan adalah masalah
pengalaman, jadi jika Anda tidak yakin, mulailah dengan 20%. Jadwal yang di-buffer ini
adalah skenario "kasus terburuk" Anda, yang berarti bahwa meskipun keadaan sedikit
melenceng dan tim menghadapi beberapa kendala yang tidak Anda rencanakan, Anda
masih dapat mencapai komitmen rilis yang di-buffer. Selama tidak terjadi hal yang tidak
terduga dan berdampak besar, tim Anda dapat memenuhi jadwal ini; itu adalah komitmen
"kepercayaan tinggi" Anda. Sisi sebaliknya juga benar; bahkan jika semuanya berjalan
lancar, kemungkinan tim mengirimkan proyek jauh lebih awal dari tanggal buffer ini rendah.
Anda dan rantai manajemen Anda mungkin tidak menyukai tanggal ini, tetapi kemungkinan
besar itu adalah tanggal yang dapat dipenuhi oleh tim kecuali tindakan khusus diambil untuk
menarik jadwal.
LEBIH LANJUT TENTANG BUFFERING JADWAL
Ya, jadwal yang di-buffer menghasilkan komitmen kepercayaan diri yang
tinggi untuk disampaikan, tetapi apakah itu realistis? Banyak organisasi melihat buffer jadwal
sebagai padding jahat dan dengan cermat memeriksa jadwal proyek apa pun dalam upaya
untuk menghilangkan buffer. Ini sangat picik menurut pendapat saya, karena Anda
kemudian merencanakan tidak ada yang salah, agar matahari selalu bersinar, dan
desainnya selalu berfungsi. Itu tidak realistis, bukan? Sebaliknya, saya melihat buffer
sebagai bagian dari perencanaan proyek yang bertanggung jawab. Jadwal yang disangga
dengan baik secara dramatis meningkatkan prediktabilitas pengiriman proyek tepat waktu,
dan bukankah itu tujuan perencanaan? Prediktabilitas tinggi dari pelaksanaan proyek
memungkinkan organisasi untuk memanfaatkan sumber daya dengan lebih baik dan
mengoordinasikan pekerjaan lintas program. Selanjutnya, jadwal buffer memastikan bahwa
tim tidak kehabisan tenaga pada akhirnya karena penundaan dan risiko tak terduga telah
direncanakan.
Tarik Tanggal Rilis (jika Diperlukan)
Pada titik ini, Anda mungkin terjebak di antara batu karang (harapan pemangku
kepentingan) dan tempat yang sulit (jadwal dengan tingkat kepercayaan tinggi), dan Anda
perlu mencari tahu apa yang harus dilakukan selanjutnya. Penting untuk menyadari poin
kunci di sini. Harapan pemangku kepentingan terutama didasarkan pada kebutuhan bisnis
dan mungkin komitmen kepada pelanggan. Mereka tidak didasarkan pada pekerjaan aktual
yang diperlukan untuk menghasilkan kiriman proyek. Jadwal kepercayaan tinggi didasarkan
pada konten pekerjaan yang sebenarnya dan mungkin tidak memenuhi kebutuhan bisnis itu.
Sekarang saatnya mengoptimalkan jadwal untuk melihat apakah mungkin menjembatani
kesenjangan antara harapan dan kenyataan pemangku kepentingan.
Langkah pertama Anda saat menarik jadwal adalah mencari cara untuk
mengoptimalkan alur kerja. Ini adalah buah yang menggantung rendah. Identifikasi
pekerjaan yang dapat dilakukan secara paralel dan susun ulang alur kerja untuk
mempersingkat durasi proyek secara keseluruhan. Carilah tugas-tugas khusus yang dapat
dimulai lebih awal dengan pengiriman sebagian pendahulu. Pekerjaan apa pun yang dapat
Anda keluarkan dari jalur kritis akan mempersingkat durasi proyek secara keseluruhan, jadi
cermati tugas tersebut dengan cermat dan lihat apakah ada peluang untuk menyusun ulang
pekerjaan tersebut. Setelah Anda melakukan semua pengoptimalan alur kerja yang Anda
bisa, garis dasar jadwal Anda dan buat salinannya. Anda akan menggunakan salinan ini
untuk melakukan pemodelan skenario "bagaimana-jika" selanjutnya.
Di Bab 2 kita membahas Triple Constraint dan fakta bahwa Anda harus
menyeimbangkan jadwal, ruang lingkup, dan sumber daya proyek. Jika Anda ingat,
sebenarnya hanya ada dua cara untuk menarik jadwal proyek Anda—mengurangi cakupan
pekerjaan atau menambahkan lebih banyak sumber daya—jadi mari kita gali lebih dalam
seperti apa bentuknya.
Mengurangi ruang lingkup pekerjaan seringkali merupakan cara paling realistis untuk
menarik jadwal karena sumber daya tidak tumbuh di pohon. Sebagai sebuah tim, cermati
dengan cermat persyaratan dan identifikasi apa saja yang dianggap “bagus untuk dimiliki”
atau yang bisaditunda. Pertimbangkan untuk menggunakan pendekatan bertahap untuk
mengimplementasikan persyaratan yang akan memungkinkan tim memberikan
fungsionalitas yang paling penting tepat waktu. Strategi lain yang benar-benar layak,
meskipun tidak populer, adalah mengurangi kualitas penyampaian proyek melalui
pengurangan jumlah validasi yang harus dilakukan, sehingga sekali lagi, fungsionalitas yang
paling penting dapat disampaikan tepat waktu. Gunakan salinan jadwal yang Anda buat
untuk melakukan pemodelan skenario "bagaimana-jika" dengan memotong tugas dari jadwal
untuk memahami dampaknya terhadap garis waktu keseluruhan. Pastikan untuk melacak
pengaruh jadwal yang dihasilkan oleh masing-masing opsi cakupan yang dikurangi ini.
Menambahkan sumber daya ke jadwal disebut "menghancurkan jadwal". Nama yang
lucu, ya? Siapa bilang manajer proyek tidak punya selera humor? Seringkali manajer proyek
junior pergi ke pemangku kepentingan mereka dengan permintaan umum untuk lebih
banyak sumber daya: "Kami membutuhkan lima sumber daya lagi untuk dapat merilis
produk ini pada akhir Oktober." Masalahnya di sini adalah bahwa permintaan ini terlalu
kabur dan tidak dapat ditindaklanjuti oleh para pemangku kepentingan. Trik untuk
mendapatkan lebih banyak sumber daya adalah dengan mengidentifikasi paket pekerjaan
tertentu untuk diterapkan, guna mempercepat jadwal. Untuk melakukan ini, Anda mengambil
jadwal pemodelan skenario "bagaimana-jika" dan menambahkan sumber daya ke tugas di
jalur kritis untuk melihat apa dampaknya pada tanggal akhir. Dengan melakukan pemodelan
ini, Anda dan tim Anda dapat mengidentifikasi beberapa paket kerja strategis di mana
sumber daya tambahan dapat memberikan dampak yang berarti. Sekarang pertanyaannya
terlihat seperti ini: "Jika kita bisa mendapatkan analis database tambahan untuk dua minggu
pertama bulan Juni, maka kita dapat menarik jadwalnya dalam tiga minggu." Sekarang,
pemangku kepentingan yang dapat menyediakan sumber daya itu tahu persis apa yang
Anda butuhkan dan kapan Anda membutuhkannya, dan pemangku kepentingan Anda lebih
cenderung bertindak.
Pada titik ini, Anda harus memiliki jadwal kepercayaan diri yang tinggi dan beberapa
opsi untuk menariknya, jadi sekarang saatnya bernegosiasi dengan pemangku kepentingan
Anda. Negosiasi ini seringkali kontroversial dan sulit karena manajer proyek belum
menyelesaikan pekerjaan rumahnya. Tugas manajer proyek di sini adalah memberikan opsi
yang layak kepada para pembuat keputusan. Kami dibayar baik saat menjalankan Rencana
A atau Rencana B, tetapi merupakan tanggung jawab kami untuk memberikan data kepada
pembuat keputusan sehingga mereka dapat membuat keputusan yang tepat tentang
sumber daya tambahan atau pengurangan ruang lingkup. Perencanaan hati-hati yang telah
Anda dan tim Anda lakukan sejauh ini telah menghasilkan data tersebut melalui pemodelan
skenario "bagaimana-jika", dan sementara pemangku kepentingan Anda mungkin sedikit
terengah-engah, pada akhirnya mereka akan menghadapi kenyataan dan membuat
beberapa keputusan yang memungkinkan Anda mengunci dalam rencana dan jadwal. Pada
titik ini, Anda dapat memperoleh pembelian pemangku kepentingan atas pencapaian proyek
utama, jadi perbarui jadwal dasar Anda dengan perubahan apa pun berdasarkan negosiasi
ini. Garis dasar ulang jadwal dan gunakan tanggal ini sebagai komitmen Anda untuk
menyampaikan. Terakhir, kirim komunikasi formal untuk melakukan proyek ke tanggal baru
ini.
 Itu dia! Anda selesai merencanakan proyek Anda! Fase Perencanaan adalah tempat
sebagian besar mekanisme manajemen proyek terjadi, dan semuanya menurun dari sini
sehubungan dengan artefak yang perlu Anda hasilkan atau proses PM tertentu yang perlu
Anda ikuti