KELOMPOK PROSES MANAJEMEN PROYEK
Mata Kuliah : Information System Project Management Dosen pengampu : Sem Paulus Silalahi, SE., M. Ak., Ak.
Disusun oleh :
Kelompok 3
Fidela Raniah Sawity 2002112672 Jannatul Azzahra 2002110973
PROGAM STUDI AKUNTANSI FAKULTAS EKONOMI DAN BISNIS UNIVERSITAS RIAU
T. A 2023/2024
KATA PENGANTAR
Puji dan syukur dipanjatkan kehadirat Tuhan Yang Maha Esa yang telah melimpahkan rahmat dan hidayah-Nya. Atas berkat rahmat dan hidayat-Nya serta berbagai upaya, tugas makalah mata kuliah Information System Project Management yang membahas tentang Perkenalan Manajemen Proyek dapat diselesaikan dengan baik dan tepat waktu.
Terselesaikannya makalah mengenai Perkenalan Manajemen Proyek ini tak terlepas dari fasilitas, bantuan, dan dukungan dari berbagai pihak. Oleh karena itu, saya mengucapkan terimakasih dan penghargaan yang setinggi-tingginya kepada seluruh pihak.
Penulis menyadari bahwa makalah ini masih kurang sempurna. Untuk itu diharapkan berbagai masukan yang bersifat membangun demi kesempurnaannya. Akhir kata, semoga makalah ini dapat membawa manfaat untuk pembaca.
Pekanbaru, 28 Februari 2023
Penulis
DAFTAR IS
KATA PENGANTAR DAFTAR ISI
BAB I PENDAHULUAN...1
1.1. Latar Belakang...1
1.2. Rumusan Masalah...1
1.3. Tujuan Penulisan...2
BAB II PEMBAHASAN...3
2.1 KELOMPOK PROSES MANAJEMEN PROYEK...3
2.2 PEMETAAN KELOMPOK PROSES KE WILAYAH PENGETAHUAN...6
2.3 MENGEMBANGKAN METODE MANAJEMEN PROYEK IT...7
2.4 STUDI KASUS : PROYEK SITUS INTRANET MANAJEMEN PROYEK JWD CONSULTING (AGILE APPROACH)...9
2.4.1 peran scrum, artefak, dan upacara...9
2.4.2 Proyek Pra-Inisiasi dan Inisiasi...11
2.4.3 Perencanaan...13
2.4.4 Mengeksekusi...14
2.4.5 Pemantauan dan Pengendalian...14
2.4.6 Penutupan...16
2.5 Templat Oleh Kelompok Proses...16
BAB III PENUTUP...19
3.1 Kesimpulan...19
3.2 Saran...20
BAB I PENDAHULUAN
1.1. Latar Belakang
Manajemen proyek terdiri dari 10 bidang pengetahuan: integrasi, ruang lingkup, jadwal, biaya, kualitas, sumber daya, komunikasi, risiko, pengadaan, dan manajemen pemangku kepentingan. Konsep penting lainnya untuk dipahami adalah bahwa proyek melibatkan lima kelompok proses manajemen proyek: memulai, merencanakan, melaksanakan, memantau dan mengendalikan, dan menutup. Menyesuaikan kelompok proses ini untuk memenuhi kebutuhan masing-masing proyek meningkatkan peluang keberhasilan dalam mengelola proyek.
Bab ini menjelaskan setiap kelompok proses manajemen proyek secara rinci melalui simulasi studi kasus berdasarkan JWD Consulting. Ini juga mencakup contoh dokumen proyek tipikal yang diterapkan pada kasus ini. Kita dapat mengunduh template untuk ini dan dokumen proyek lainnya dari situs web Companion untuk teks ini. Penting untuk terlebih dahulu mempelajari bagaimana mereka sesuai dengan gambaran besar dalam mengelola proyek. Memahami bagaimana area pengetahuan dan kelompok proses manajemen proyek berfungsi Bersama.
1.2. Rumusan Masalah
Apa saja Kelompok Proses Manajemen Proyek?
Apa Hubungan kelompok proses manajemen proyek dengan area pengetahuan manajemen proyek?
Bagaimana organisasi mengembangkan metodologi manajemen proyek teknologi informasi (TI) ?
Apa hasil dari Tinjauan studi kasus dari proyek yang sama yang dikelola dengan fokus tangkas?
Apa saja template untuk membuat dokumen untuk setiap kelompok proses?
1.3. Tujuan Penulisan
1. Menjelaskan 5 kelompok proses manajemen proyek
2. Menjelaskan hubungan antara kelompok proses dengan area pengetahuan manajemen proyek
3. Menjelaskan bagaimana mengembangkan metodologi manajemen proyek TI 4. Menjelaskan hasil dari Tinjauan studi kasus dari proyek dengan focus tangkas 5. Menjelaskan beberapa template untuk membuat dokumen setiap kelompok proses
BAB II PEMBAHASAN
2.1 KELOMPOK PROSES MANAJEMEN PROYEK
Manajemen proyek adalah upaya integratif. Keputusan dan tindakan yang diambil dalam satu area pengetahuan pada waktu tertentu biasanya mempengaruhi area pengetahuan lainnya. Mengelola interaksi ini sering membutuhkan pertukaran antara ruang lingkup proyek, waktu, dan biaya—batasan rangkap tiga dari manajemen proyek. Proses adalah serangkaian tindakan yang diarahkan pada hasil tertentu.
Kelompok proses manajemen proyek kemajuan dari kegiatan inisiasi ke kegiatan perencanaan, pelaksanaan kegiatan, pemantauan dan pengendalian kegiatan, dan kegiatan penutupan.
Sebuah proyek dapat memiliki kombinasi fase yang berbeda. Satu proyek mungkin memiliki fase konsep, pengembangan, implementasi, dan penutupan, dan yang lain mungkin memiliki fase awal, menengah, dan akhir. Tetapi semua proyek d • Memulai proses termasuk mendefinisikan dan mengesahkan proyek atau fase proyek. Memulai proses berlangsung selamasetiapfase sebuah proyek. Misalnya, dalam fase close- out, proses inisiasi digunakan untuk memastikan bahwa tim proyek menyelesaikan semua pekerjaan, bahwa seseorang mendokumentasikan pelajaran yang didapat, dan bahwa pelanggan menerima pekerjaan tersebut.
• Proses perencanaan termasuk merancang dan memelihara skema yang bisa diterapkan untuk memastikan bahwa proyek memenuhi kebutuhan organisasi.
Proyek mencakup beberapa rencana, seperti rencana manajemen ruang lingkup, rencana manajemen jadwal, rencana manajemen biaya, dan rencana manajemen pengadaan. Rencana ini mendefinisikan setiap bidang pengetahuan yang berkaitan dengan proyek pada titik waktu tertentu.
• Menjalankan proses termasuk mengoordinasikan orang dan sumber daya lain untuk melaksanakan berbagai rencana dan menciptakan produk, layanan, atau hasil proyek atau fase. Contoh proses eksekusi termasuk mengarahkan dan
mengelola pekerjaan proyek, mengelola pengetahuan proyek, memperoleh sumber daya, dan melakukan pengadaan.
• Proses pemantauan dan pengendalian termasuk mengukur dan memantau kemajuan secara teratur untuk memastikan bahwa tim proyek memenuhi tujuan proyek. Manajer proyek dan staf memantau dan mengukur kemajuan terhadap rencana dan mengambil tindakan korektif bila diperlukan. Proses pemantauan dan pengendalian yang umum adalah pelaporan kinerja, di mana pemangku kepentingan proyek dapat mengidentifikasi setiap perubahan yang diperlukan yang mungkin diperlukan untuk menjaga agar proyek tetap pada jalurnya.
• Proses penutupan termasuk memformalkan penerimaan proyek atau fase proyek dan mengakhirinya secara efisien. Kegiatan administratif sering terlibat dalam kelompok proses ini, seperti pengarsipan file proyek, mendokumentasikan pelajaran, dan menerima penerimaan resmi dari pekerjaan yang disampaikan sebagai bagian dari fase atau proyek.an semua fase proyek harus menyertakan kelima kelompok proses.
Kelompok proses tidak saling eksklusif. Misalnya, manajer proyek harus melakukan proses pemantauan dan pengendalian selama masa hidup proyek. Artinya, proses pemantauan dan pengendalian terjadi secara bersamaan di seluruh proyek dengan proses inisiasi, perencanaan, pelaksanaan, dan penutupan. Memulai dan merencanakan proses dapat terjadi bersamaan dengan proses eksekusi, dan seterusnya untuk setiap kelompok proses.
Tingkat aktivitas dan panjang setiap kelompok proses bervariasi untuk setiap proyek. Biasanya, melaksanakan tugas membutuhkan sumber daya dan waktu paling banyak, diikuti oleh tugas perencanaan. Memulai dan menutup tugas biasanya paling singkat (masing- masing di awal dan akhir proyek atau fase), dan membutuhkan sumber daya dan waktu paling sedikit. Namun, setiap proyek itu unik, jadi ada pengecualian.
Masing-masing dari lima kelompok proses manajemen proyek ditandai dengan penyelesaian tugas- tugas tertentu. Saat memulai proses untuk proyek baru, organisasi mengakui bahwa ada proyek baru dan menyelesaikan piagam proyek sebagai bagian dari pengakuan ini. Sampel dari beberapa keluaran disediakan untuk setiap kelompok proses dalam studi kasus proyek situs intranet manajemen proyek JWD Consulting. Manajer proyek dan timnya harus memutuskan keluaran mana yang diperlukan untuk proyek khusus mereka.
Keluaran dari kelompok proses perencanaan meliputi penyelesaian pernyataan ruang lingkup proyek, struktur perincian kerja (WBS), jadwal proyek, dan banyak item lainnya. Proses perencanaan sangat penting untuk proyek TI.
Kelompok proses pelaksana mengambil tindakan yang diperlukan untuk menyelesaikan pekerjaan yang dijelaskan dalam kegiatan perencanaan. Hasil utama dari kelompok proses ini adalah memberikan pekerjaan proyek yang sebenarnya. Misalnya, jika proyek TI melibatkan penyediaan perangkat keras, perangkat lunak, dan pelatihan baru, proses pelaksanaannya akan mencakup memimpin tim proyek dan pemangku kepentingan lainnya untuk membeli perangkat keras, mengembangkan dan menguji perangkat lunak, serta mengirimkan dan berpartisipasi dalam pelatihan. Grup proses pelaksana harus tumpang tindih dengan grup proses lainnya, dan umumnya membutuhkan sumber daya paling banyak.
Proses pemantauan dan pengendalian mengukur kemajuan terhadap tujuan proyek, memantau penyimpangan dari rencana, dan mengambil tindakan korektif untuk menyesuaikan kemajuan dengan rencana. Laporan kinerja adalah keluaran umum dari pemantauan dan pengendalian. Manajer proyek harus memantau kemajuan dengan cermat untuk memastikan bahwa kiriman diselesaikan dan tujuan tercapai. Manajer proyek harus bekerja sama dengan tim proyek dan pemangku kepentingan lainnya dan mengambil tindakan yang tepat agar proyek berjalan lancar. Hasil ideal dari kelompok proses pemantauan dan pengendalian adalah untuk menyelesaikan proyek dengan sukses dengan memberikan ruang lingkup proyek yang telah disepakati dalam batas waktu, biaya, dan kualitas. Jika perubahan tujuan atau rencana proyek diperlukan, proses pemantauan dan pengendalian memastikan bahwa perubahan ini dilakukan secara efisien dan efektif untuk memenuhi kebutuhan dan harapan pemangku kepentingan. Proses pemantauan dan pengendalian tumpang tindih dengan semua kelompok proses manajemen proyek lainnya karena perubahan dapat terjadi kapan saja.
Selama proses penutupan, tim proyek bekerja untuk mendapatkan penerimaan atas produk akhir, layanan, atau hasil dan mengakhiri fase atau proyek secara teratur. Hasil utama dari kelompok proses ini adalah penerimaan formal atas pekerjaan dan pembuatan dokumen penutup, seperti laporan proyek akhir dan laporan pembelajaran.
2.2 PEMETAAN KELOMPOK PROSES KE WILAYAH PENGETAHUAN
Kita dapat memetakan aktivitas utama dari setiap grup proses manajemen proyek ke dalam 10 bidang pengetahuan manajemen proyek. Tabel 3-1 memberikan gambaran besar tentang hubungan antara 49 kegiatan manajemen proyek.
Tabel 3-1 Kelompok proses manajemen proyek dan pemetaan area pengetahuan
Kelompok Proses Manajemen Proyek
Pengetahuan
memul ai Proses
Perencanaan
Proses
mengeksekusi
Proses
Pemantaua n
Dan
mengendalik an
Proses
penutupan
Proses
daerah kelompok kelompok kelompok kelompok kelompok
4. Proyek Integrasi Pengelolaan
4.1
Mengembangk an
Proyek Piagam
4.2 Mengembangkan Proyek
Rencana Manajemen
4.3Langsung dan Kelola Proyek- dll Bekerja 4.4Kelola Proyek
4.5 Mema ntau dan Kontrol Proyek
Bekerja 4.6Melakuk
an
4.7 Tutup Proyek atau Fase
Pengetahuan Terintegra si Mengubah
Kontrol 5. Lingkup
Proyek Pengelolaan
5.1Lingkup Rencana
Pengelolaan
5.2Kumpulkan
Persyaratan
5.5Validasi
Cakupan
5.6Kontrol
Cakupan
5.3 Menentukan Ruang Lingkup
5.4 Membuat WBS 6. Proyek
Jadwal Pengelolaa n
6.1Jadwal Rencana Pengelolaan
6.2Menentukan Aktivitas
6.3Urutan Kegiatan 6.4Estimasi Durasi Aktivitas
6.6 Kontrol Jadwal
6.5 Berkembang
Jadwal 7. Biaya
Proyek Pengelolaan
7.1Biaya Rencana
Pengelolaan 7.2Perkiraan
Biaya
7.4 Kontrol Biaya
7.3Tentukan
Anggaran
Kelompok Proses Manajemen Proyek
Pengetahuan
memul ai Proses
Perencanaan
Proses
mengeksekusi
Proses
Pemantauan
Dan
mengendalikan penutupan
Proses Proses
daerah kelompok kelompok kelompok kelompok kelompok
8. Proyek Kualitas Pengelolaa n
8.1 Kualitas Rencana
Pengelolaan
8.2 Kelola Kualitas
8.3 Kontrol Kualitas
9. Proyek Sumber Pengelolaa n
9.1Rencana Sumber Daya
Pengelolaan 9.2Estimasi
Aktifitas Sumber daya
9.3Memperoleh Sumber daya 9.4Berkembang
Tim 9.5Kelola Tim
9.6 Kontrol
Sumber daya
10. Proyek Kom- nikasi Pengelola an
10.1 Rencana
Komunik asi Pengelol aan
10.2 Kelola Komunika si- tions
10.3 Moni- untuk Komuni-
nikasi
11. Risiko Proyek Pengelolaan
11.1Risiko Rencana
Pengelolaan
11.2Identifikasi Risiko 11.3Lakuka n Risiko Kualitatif Analisis 11.4Lakukan Risiko Kuantitatif Analisis
11.5Risiko Rencana
Tanggapan
11.6 Menerapkan-
Risiko Tanggapan
11.7 Moni-
untuk Risiko
12. Proyek Pengadaan Pengelolaa n
12.1 Rencana Pengadaan-
manajemen
12.2 Perilaku Pengada an
12.3 Kon-
kontrol Pro- penyembuhan
13. Proyek
Pemangku kepentingan
Pengelolaa n
13.1
Mengen ali
Mempertaruhk an-
pemegan g
13.2 Rencana Taruhan- Keterlibatan pemegang
13.3 Kelola
Pemangku kepentingan
Pertunanga n
13.4 Memantau
Pemangku kepentingan
Pertunangan
2.3 MENGEMBANGKAN METODE MANAJEMEN PROYEK IT
PMBOK®Memandu adalah standar yang menjelaskan praktik terbaik untukApa harus dilakukan untuk mengelola proyek. Metodologi menjelaskan Bagaimana sesuatu harus dilakukan, dan organisasi yang berbeda seringkali memiliki cara yang berbeda dalam melakukan sesuatu.
Selain menggunakan PMBOK®Memandu sebagai dasar metodologi manajemen proyek, banyak organisasi menggunakan panduan atau metode lain, seperti berikut ini:
• PROYEK DI Lingkungan Terkendali (PRINCE2): Awalnya dikembangkan untuk proyek TI, PRINCE2 dirilis pada tahun 1996 sebagai metodologi manajemen proyek umum oleh Kantor Perdagangan Pemerintah Inggris (OGC). Ini adalah standar de facto di Inggris Raya dan digunakan di lebih dari 50 negara.
(Melihatwww.prince2.comuntuk informasi lebih lanjut.) PRINCE2 mendefinisikan 45 subproses terpisah dan mengaturnya menjadi delapan grup proses sebagai berikut:
1. Memulai sebuah proyek 2. Perencanaan
3. Memulai sebuah proyek 4. Mengarahkan sebuah proyek 5. Mengontrol panggung
6. Mengelola pengiriman produk 7. Mengelola batasan panggung 8. Menutup proyek
• Metode tangkas : Seperti yang dijelaskan di Bab 2, agile adalah siklus hidup produk adaptif yang digunakan saat kiriman memiliki tingkat perubahan yang tinggi dan frekuensi pengiriman yang tinggi. Istilah tangkas sering digunakan untuk menggambarkan berbagai metode.
• Kerangka Rational Unified Process (RUP) : RUP adalah proses pengembangan perangkat lunak iteratif yang dibuat oleh IBM yang berfokus pada produktivitas tim dan memungkinkan semua anggota tim memberikan praktik terbaik perangkat lunak ke organisasi. Menurut ahli RUP Bill Cottrell, "RUP mewujudkan manajemen standar industri dan metode serta teknik teknis untuk menyediakan proses rekayasa perangkat lunak yang sangat sesuai untuk membuat dan memelihara solusi sistem perangkat
lunak berbasis komponen."8Cottrell menjelaskan bahwa Anda dapat menyesuaikan RUP untuk menyertakan PMBOK®kelompok proses karena beberapa pelanggan meminta kemampuan itu.
• Metodologi Six Sigma: Banyak organisasi memiliki proyek yang menggunakan metodologi Six Sigma. Karya banyak pakar kualitas proyek berkontribusi pada pengembangan prinsip Six Sigma saat ini. Dua metodologi utama digunakan pada proyek Six Sigma: Definisikan, Ukur, Analisis, Tingkatkan, dan Kontrol (DMAIC) digunakan untuk meningkatkan proses bisnis yang ada, dan Definisikan, Ukur, Analisis, Desain, dan Verifikasi (DMADV) digunakan untuk membuat desain produk atau proses baru untuk mencapai kinerja yang dapat diprediksi dan bebas cacat.
2.4 STUDI KASUS : PROYEK SITUS INTRANET MANAJEMEN PROYEK JWD CONSULTING (AGILE APPROACH)
Bagian ini menunjukkan pendekatan gesit untuk mengelola proyek situs intranet manajemen proyek JWD Consulting. Pendekatan tangkas sering digunakan untuk proyek di mana tim bisnis tidak dapat dengan jelas mengungkapkan ruang lingkup di awal siklus hidup produk, tetapi tim ingin menyediakan produk yang berpotensi dapat dikirim lebih awal daripada nanti.
Tim proyek yang gesit biasanya menggunakan beberapa iterasi atau pengiriman perangkat lunak alih-alih menunggu hingga akhir proyek untuk menyediakan satu produk.
Saat menggunakan teknik gesit dan metodenya yang paling populer, Scrum, sebuah tim menggunakan peran, artefak, dan upacara tertentu.
2.4.1 peran scrum, artefak, dan upacara
Dari Bab 2 bahwa Scrum mencakup tiga peran utama bagi peserta proyek:
• Pemilik produk: Orang yang bertanggung jawab atas nilai bisnis proyek dan untuk memutuskan pekerjaan apa yang harus dilakukan dan dalam urutan apa, seperti yang didokumentasikan dalam jaminan simpanan produk. Dalam hal ini, Joe Fleming adalah pemilik produk. Dia adalah CEO JWD Consulting dan orang yang menyarankan proyek tersebut.
• Scrum Master: Orang yang memastikan bahwa tim itu produktif, memfasilitasi Scrum harian, memungkinkan kerja sama yang erat di semua peran dan fungsi, dan menghilangkan hambatan yang mencegah tim menjadi efektif. Scrum Masters memiliki wewenang atas proses tetapi bukan orang-orang dalam tim. Beberapa ahli
berpendapat bahwa manajer proyek tradisional tidak bisa menjadi Scrum-Master yang hebat. Dalam hal ini, Erica Bell akan mengambil tantangan dan berperan sebagai ScrumMaster.
• Tim scrum atau tim pengembangan : Tim lintas fungsi yang terdiri dari lima hingga sembilan orang yang mengatur diri mereka sendiri dan bekerja untuk menghasilkan hasil yang diinginkan untuk setiap sprint. Asprintbiasanya berlangsung dua hingga empat minggu, di mana pekerjaan tertentu harus diselesaikan dan siap untuk ditinjau.
Proyek besar mungkin membutuhkan tim dari tim. Dalam hal ini, Michael Chen, Jessie Faue, Kevin Dodge, Cindy Dawson, Kim Phuong, dan Page Miller adalah anggota tim pengembangan.
Dalam Scrum, sebuahartefakadalah objek berguna yang dibuat oleh orang-orang.
Artefak dapat disebut penyampaian dalam pendekatan manajemen proyek lainnya. Tiga artefak berikut dibuat dengan Scrum:
• Simpanan produk : Daftar fitur yang diprioritaskan menurut nilai bisnis. Item dengan prioritas tertinggi harus dirinci dengan cukup detail agar tim dapat memperkirakan upaya yang terlibat dalam mengembangkannya. Beberapa ahli menyarankan penjadwalan sekitar 10 hari kerja untuk setiap item. Ukuran dan kompleksitas pekerjaan menentukan perkiraan.
• Sprint backlog : Item dengan prioritas tertinggi dari product backlog untuk diselesaikan dalam sprint. Tim Scrum memecah item dengan prioritas tertinggi menjadi tugas-tugas kecil yang membutuhkan waktu sekitar 12 hingga 16 jam untuk menyelesaikannya. Contoh sprint backlog dan product backlog disediakan nanti di bagian Perencanaan.
• Bagan terbakar : Menampilkan pekerjaan kumulatif yang tersisa dalam sprint setiap hari. Contoh bagan burndown disediakan nanti di bagian ini di bawah Pemantauan dan Pengendalian.
ScrumMaster memfasilitasi empat upacara atau pertemuan saat menggunakan metode Scrum:
• Sesi perencanaan sprint: Pertemuan dengan tim untuk memilih serangkaian pekerjaan dari product backlog untuk disampaikan selama sprint. Pertemuan ini memakan waktu sekitar empat jam hingga satu hari penuh.
Eksekusi:
Selesaikan tugas setiap hari selama sprint.
Menghasilkan produk yang dapat dikirim di akhir setiap sprint.
Perencanaan:
Buat backlog produk.
Buat backlog sprint.
Buat backlog rilis.
Rencanakan pekerjaan setiap hari di Scrum harian.
Dokumentasikan batu sandungan dalam sebuah daftar.
Memulai:
Tentukan peran.
Putuskan berapa banyak sprint yang akan disusun setiap rilis dan cakupan perangkat lunak yang akan dikirimkan.
Penutupan:
Merefleksikan bagaimana meningkatkan produk dan proses selama pertemuan retrospektif sprint.
Pemantauan dan Pengendalian:
Mengatasi masalah dan pemblokir.
Buat dan perbarui bagan burndown.
Mendemonstrasikan produk yang sudah selesai selama rapat tinjauan sprint.
• Scrum Harian : Pertemuan singkat untuk tim pengembangan untuk berbagi kemajuan dan tantangan serta merencanakan pekerjaan untuk hari itu. Idealnya anggota tim berada di tempat yang sama, rapat biasanya berlangsung tidak lebih dari 15 menit, dan diadakan di tempat dan waktu yang sama setiap harinya. Jika tidak memungkinkan, tim dapat menggunakan konferensi video untuk mengadakan rapat virtual singkat.
ScrumMaster menanyakan pekerjaan apa yang telah dilakukan sejak kemarin, pekerjaan apa yang direncanakan untuk hari ini, dan hambatan atau batu sandungan apa yang dapat menghambat upaya tim. ScrumMaster mendokumentasikan hambatan ini dan bekerja dengan pemangku kepentingan utama untuk menyelesaikannya setelah Scrum harian. Banyak tim menggunakan istilah tersebutmasalahuntuk item yang tidak harus diselesaikan dalam 24 jam ke depan dan pemblokir untuk hal-hal yang perlu segera ditangani.
• Ulasan sprint: Pertemuan di mana tim mendemonstrasikan kepada pemilik produk apa yang telah diselesaikannya selama sprint.
• Retrospektif sprint: Pertemuan di mana tim mencari cara untuk meningkatkan produk dan proses berdasarkan tinjauan kinerja tim pengembangan yang sebenarnya.
2.4.2 Proyek Pra-Inisiasi dan Inisiasi
Perbedaan utama antara pra-inisiasi dalam kasus ini dan kasus adalah menentukan peran dan memutuskan fungsionalitas apa yang akan dikirimkan sebagai bagian dari setiap rilis, berapa banyak sprint yang diperlukan untuk menyelesaikan sebuah rilis, dan berapa banyak rilis perangkat lunak yang akan dikirimkan. . Ini mirip dengan membagi proyek menjadi beberapa proyek yang lebih kecil. Piagam proyek, daftar pemangku kepentingan, strategi manajemen pemangku kepentingan, dan pertemuan awal masih akan dibuat sebagai bagian dari inisiasi, sama seperti versi prediksi dari kasus ini. Akan tetapi, dengan menggunakan peran Scrum, Joe Fleming akan menjadi pemilik produk, Erica Bell sebagai ScrumMaster, dan orang lain yang tercantum dalam piagam proyek akan menjadi anggota tim.
Joe bertemu dengan Erica untuk membahas fungsionalitas apa yang akan disampaikan dalam setiap rilis, berapa banyak sprint yang diperlukan untuk setiap rilis, berapa banyak rilis perangkat lunak yang diperlukan, dan pendekatan yang diperlukan untuk menyelesaikan proyek. Mereka menyadari bahwa sebelum mereka dapat menentukan fungsionalitas, rilis, dan sprint, mereka perlu mensurvei pengguna potensial untuk mengumpulkan persyaratan untuk perangkat lunak baru dan menentukan cara untuk mengukur nilai situs intranet setelah diimplementasikan. Mereka memperkirakan bahwa mengumpulkan dan menganalisis informasi dari pengguna potensial akan memakan waktu sekitar dua bulan.
Bekerja sama, Joe dan Erica akan membuat survei yang secara khusus menanyakan calon pengguna fitur mana yang akan memberikan nilai paling tinggi. Misalnya, alih-alih membuat daftar ide umum, mereka akan membuat daftar fitur khusus dan meminta responden mengurutkannya berdasarkan kepentingan. Mereka juga akan meminta responden survei untuk mengirimkan contoh template, alat, dan informasi berguna lainnya kepada Cindy Dawson, anggota tim proyek di Departemen IT. Mengumpulkan informasi ini di muka akan merampingkan proses pengembangan perangkat lunak.
Joe dan Erica memutuskan bahwa tiga rilis perangkat lunak akan realistis, mengingat kendala waktu dan biaya. Setiap sprint akan ditargetkan untuk berlangsung selama empat minggu, dan review serta pembuatan produk dan sprint backlog akan menjadi aktivitas berkelanjutan dalam setiap sprint.
Joe dan Erica bertemu dengan Cindy dan anggota tim lainnya beberapa kali. Cindy memiliki pengalaman paling banyak mengerjakan proyek agile. Dia membahas pentingnya mengirimkan beberapa desain antarmuka pengguna grafis kepada calon pengguna untuk mendapatkan umpan balik mereka.
Pendekatan ini sangat berguna di masa lalu, berdasarkan pengalaman Cindy, dan akan menghemat banyak pengerjaan ulang selama pengembangan. Misalnya, anggota tim akan membuat satu hingga empat desain antarmuka tertentu untuk ditinjau oleh calon pengguna dalam sesi yang di hosting oleh tim pemasaran. Cindy menjelaskan bahwa umpan balik akan membantu menghasilkan antarmuka pengguna yang lebih baik dan lebih intuitif.
Cindy menjelaskan bahwa desainer antar muka pengguna biasanya bukan anggota tim pengembangan, tetapi organisasi mungkin menggunakannya untuk memberikan spesifikasi desain terperinci yang menyediakan antarmuka pengguna yang konsisten. Erica dan Joe belajar banyak dari Cindy dan akan memasukkan rekomendasinya ke dalam rencana masa depan.
2.4.3 Perencanaan
Alih-alih membuat piagam tim, WBS, bagan Gantt, dan daftar risiko yang diprioritaskan untuk keseluruhan proyek, tim mengikuti metode Scrum. Pernyataan ruang lingkup awal untuk keseluruhan proyek masih bisa menjadi alat yang berguna untuk perencanaan, meskipun tim tahu bahwa rincian lebih lanjut akan ditambahkan dan perubahan akan dilakukan. Karena Scrum menyiratkan bahwa anggota tim bekerja sebagai kelompok yang diarahkan sendiri, dilatih oleh ScrumMaster, piagam tim seharusnya tidak diperlukan.
Sebagai pengganti WBS, deskripsi tingkat tinggi dari pekerjaan yang harus diselesaikan akan diidentifikasi dalam backlog produk dan sprint. Tim akan mengembangkan daftar cerita teknis dan tugas terkait yang lebih rinci untuk diselesaikan selama setiap sprint.
Tim juga harus menetapkan perkiraan kecepatan (atau kapasitas) untuk setiap sprint berdasarkan ketersediaan anggota tim setiap hari selama sprint. Estimasi dapat diberikan sebagai jam kerja, dengan asumsi bahwa semua pengembang adalah kontraktor yang dapat membuat kode delapan jam per hari. Estimasi juga dapat diberikan sebagai poin, dengan asumsi pengembang adalah karyawan yang membuat kode kurang dari delapan jam per hari.
Misalnya, enam jam per hari sama dengan satu poin, jadi 36 jam usaha sama dengan 6 poin.
Tim Scrum memecah item dalam sprint backlog menjadi item pekerjaan yang lebih spesifik, seringkali dalam bentuk cerita pengguna, cerita teknis, dan tugas terkait.Cerita
penggunaadalah deskripsi singkat yang ditulis oleh pelanggan tentang apa yang mereka butuhkan untuk dilakukan sistem bagi mereka.
Beberapa organisasi menggunakan peta jalan rilis untuk menyusun semua pekerjaan untuk seluruh rilis, yang dapat mencakup lebih dari satu sprint. Peta jalan ini biasanya direpresentasikan sebagai bagan yang terdiri dari beberapa kolom. Peta jalan rilis memberikan gambaran yang jelas tentang cerita (cakupan) apa yang akan dimuat dalam setiap sprint. Alat ini memungkinkan tim Scrum meninjau dan memperbarui perkiraan kecepatan versus aktual dengan mudah. Peta jalan rilis harus berasal dari data dalam Sistem Informasi Manajemen Proyek (PMIS) atau sistem manajemen tangkas terkait, seperti Microsoft's Team Foundation Server, Rally, VersionOne, atau JIRA.
2.4.4 Mengeksekusi
Waktu dan uang paling banyak harus dihabiskan untuk mengeksekusi, ketika rencana diimplementasikan untuk menciptakan produk yang diinginkan. Tim akan menyelesaikan tugas setiap hari, seperti dalam versi prediksi kasus ini. Namun dengan menggunakan pendekatan tangkas, tim akan menghasilkan beberapa iterasi dari produk yang berpotensi dapat dikirim. Misalnya, di akhir sprint pertama, JWD Consulting akan memiliki beberapa fungsi yang tersedia di situs intranet manajemen proyek barunya. Pengguna akan dapat mengakses template, sampel, dan orang penting untuk cerita pengguna, WBS, dan jadwal proyek, seperti yang tercantum dalam sprint backlog pertama. Pengguna juga dapat memberikan saran untuk fungsionalitas yang ingin mereka lihat di situs intranet saat sedang dikembangkan. Karena Erica dan beberapa tim proyek tidak berpengalaman dalam menggunakan Scrum, mereka harus menyelesaikan beberapa tantangan.
2.4.5 Pemantauan dan Pengendalian
Dua alat utama untuk pemantauan dan pengendalian dalam kerangka kerja Scrum adalah Scrum harian dan tinjauan sprint. Scrum harian diadakan setiap pagi untuk merencanakan dan mengomunikasikan pekerjaan untuk hari itu dan mendiskusikan segala risiko, masalah, atau hambatan. Scrum harian mencakup diskusi singkat tentang masalah apa pun dan penghalang yang dihadapi tim. ScrumMaster akan bekerja dengan pemangku kepentingan yang sesuai untuk mengatasi masalah ini sebagai bagian dari pemantauan dan pengendalian. Menghilangkan hambatan agar tim dapat bekerja dengan baik adalah salah satu tugas utama ScrumMaster. ScrumMaster mendokumentasikan masalah dan pemblokir, serupa dengan daftar risiko yang diprioritaskan.
Kemajuan pekerjaan dalam sprint dapat direpresentasikan di papan sprint yang dikelola oleh ScrumMaster. Papan sprint berisi kartu untuk mewakili setiap tugas yang harus dikerjakan selama sprint. Setiap kartu tugas berisi nomor kontrol, nama tugas, perkiraan waktu penyelesaian, peringkat atau nomor prioritas, dan anggota tim yang ditugaskan. Saat tugas dibuka, dikerjakan, dan ditutup, kartu mereka dipindahkan secara fisik ke bagian yang sesuai di papan tulis. Bagian ini termasuk Belum Dimulai, Sedang Berlangsung, Siap Diuji, Diuji, dan Ditutup. Pengembang memperbarui status tugas di bagian Belum Dimulai, Sedang Berlangsung, dan Siap Diuji. Penguji memperbarui status tugas di bagian Diuji. Pemilik produk bertanggung jawab untuk meninjau fungsionalitas, mengonfirmasi bahwa itu berfungsi seperti yang diharapkan, dan mengubah status tugas menjadi Ditutup.
Bagan burndown adalah artefak penting yang digunakan untuk menampilkan kemajuan secara grafis pada setiap sprint. Bagan burndown pada Gambar 3-7 menunjukkan kemajuan selama sprint pertama untuk proyek intranet JWD Consulting, yang dijadwalkan berlangsung selama empat minggu dan menghasilkan lima item atau cerita pengguna yang tercantum dalam sprint backlog. Ingat bahwa selama perencanaan, setiap cerita pengguna dipecah menjadi tugas-tugas tertentu, dan tim memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikan setiap tugas untuk setiap cerita pengguna. Selama rapat Scrum harian, pekerjaan yang diklaim anggota tim harus sesuai dalam satu hari. Setiap hari, tim harus memperkirakan kembali jumlah jam atau poin yang tersisa untuk setiap tugas.
Beberapa tugas mungkin ditambahkan dan beberapa mungkin dibatalkan saat cakupannya menjadi lebih jelas.
200
Bagan Burndown Sprint 1
150 100 50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Hari
TersisaKecepatan Ideal
Di akhir setiap sprint, ScrumMaster—Erica dalam contoh ini—memimpin pertemuan tinjauan demonstrasi sprint. Tim mendemonstrasikan kepada pemilik produk apa yang telah diselesaikannya selama sprint. Dalam hal ini, Joe akan mengulas lima fitur yang dibuat selama sprint pertama. Setelah tinjauan demonstrasi sprint, dia akan memperbarui backlog produk berdasarkan informasi terbaru dan kebutuhan bisnis, dan siklus sprint berikutnya akan dimulai.
2.4.6 Penutupan
Setelah sprint review, ScrumMaster memimpin sprint retrospective. Selama pertemuan singkat ini (sekitar setengah jam), tim merefleksikan apa yang terjadi selama sprint. ScrumMaster biasanya mengumpulkan umpan balik anggota tim melalui email terlebih dahulu dan menyusun hasil ini sebelum rapat. Ini menghemat waktu dan memfokuskan diskusi pada hal-hal yang paling penting. Retrospektif mirip dengan laporan pembelajaran, tetapi berfokus pada periode waktu yang lebih singkat. Retrospektif sprint dimaksudkan untuk menjawab dua pertanyaan mendasar:
• Apa yang berjalan dengan baik selama sprint terakhir yang harus terus kita lakukan?
• Apa yang dapat kita lakukan secara berbeda untuk meningkatkan produk atau proses?
Rapat retrospektif sprint biasanya dipimpin oleh ScrumMaster, yang mendokumentasikan daftar item tindakan untuk implementasi. Item tersebut dapat ditambahkan ke backlog produk jika pemilik produk setuju dengannya. Misalnya, setelah sprint pertama untuk proyek situs intranet manajemen proyek JWD, tim mungkin menyarankan agar situs diaktifkan untuk seluler. Persyaratan baru ini dapat ditambahkan ke product backlog dan dipilih sebagai item untuk sprint berikutnya. Ingatlah bahwa pendekatan gesit menyambut persyaratan baru selama mereka fokus pada nilai bisnis.
2.5 Templat Oleh Kelompok Proses
Tim proyek menyiapkan banyak dokumen sepanjang masa proyek. Banyak orang menggunakan template untuk menerapkan format standar dalam menyiapkan dokumen tersebut. Tabel 3-20 mencantumkan beberapa template yang digunakan untuk menyiapkan dokumen yang ditunjukkan dalam bab ini dan bab selanjutnya. Tabel mencantumkan nama template, nomor bab, grup proses di mana Anda biasanya menggunakan template, perangkat lunak aplikasi yang digunakan untuk membuatnya, dan nama file untuk template.
Tabel 3-20Templat menurut grup proses
nama templat Grup proses
bab
Di mana
digunakan
aplikasi
perangkat lunak
Nama file
Kasus bisnis Pra-inisiasi 3 Kata kasus bisnis.doc
Kasus bisnis Keuangan
Pra-inisiasi 3, 4 Unggul kasus bisnis financials.xls
Pemangku kepentingan
Daftar
Memulai 3, 13 Kata daftar pemangku kepentingan.doc
nama templat Grup proses
bab
Di mana
digunakan
aplikasi
perangkat lunak
Nama file
Pemangku kepentingan
Pengelolaan Strategi
Memulai 3, 13 Kata
manajemen pemangku kepentingan
ment strategy.doc
Pertemuan Awal
Jadwal acara
Memulai 3 Kata pertemuan awal
agenda.doc
Periode pengembalian Bagan
Memulai 4 Unggul periode pengembalian
bagan.xls Tertimbang
Model Penilaian
Memulai 4, 12 Unggul skor tertimbang
model.xls
Piagam Proyek Memulai 3, 4, 5 Kata charter.doc
Log Asumsi Memulai 3, 4 Unggul asumsi log.xlsx
Piagam Tim Perencanaan 3, 9 Kata piagam tim.doc
Persyaratan
Ketertelusuran Matriks
Perencanaan 5 Kata Persyaratan
ketertelusuran
matrix.doc
Cakupan
Penyataan
Perencanaan 3, 4, 5 Kata pernyataan ruang lingkup.doc
Negara Kontrak- pekerjaan
Perencanaan 12 Kata pernyataan kontrak
dari work.doc
Meminta Usul
Perencanaan 12 Kata proposal permintaan.
Dokter
Manajemen Proyek-
Rencana
Perencanaan 4 Kata manajemen proyek
plan.doc Istirahat Kerja-
Struktur bawah (WBS)
Perencanaan 3, 5, 6 Kata wbs.doc
Kamus WBS
Pintu masuk
Perencanaan 5 kamus
WBS deskripsi.
doc
Estimasi biaya Perencanaan 7 Unggul estimasi biaya.xls
Nilai yang Diperoleh
Bagan
Pemantauan dan
Mengontrol
7 Unggul grafik nilai yang diperoleh.xls
nama templat Grup proses
bab
Di mana
digunakan
aplikasi
perangkat lunak
Nama file
Terbakar Bagan
Pemantauan dan
Mengontrol
3, 7 Unggul burndownchart.xls
Metrik Kualitas Eksekusi 8 Kata metrik kualitas.doc Bagan Pareto Pemantauan
dan Mengontrol
8 Unggul bagan pareto.xls
Organisasi Proyek
Bagan zat
Perencanaan,
Eksekusi
9 Kekuatan-
Titik
organisasi proyek bagan.ppt
Tanggung jawab-
Penugasan Matriks
Perencanaan,
Eksekusi
9 Unggul Bagan RACI.xls
Sumber Histogram
Perencanaan,
Eksekusi
9 Unggul resource histogram.xls
Komunikasi-
manajemen tions-
Rencana
Perencanaan 10 Kata Komunikasi
rencana manajemen.doc
Pelajaran-pelajaran
Daftar
Eksekusi 4 Unggul Pelajaran
register.xlsx Laporan Pencapaian Eksekusi 3, 6 Kata laporan tonggak sejarah.doc
Ubah Permintaan
Membentuk
Perencanaan, Pemantauan dan Mengontrol
4 Kata ubah permintaan.doc
Pertunjukan
Laporan
Pemantauan dan
Mengontrol
3, 4 Kata laporan kinerja.doc
Kemungkinan/ Perencanaan, 11 Kekuatan- dampak probabilitas
Matriks Dampak Eksekusi, Titik matriks.ppt
Pemantauan dan
Mengontrol
BAB III PENUTUP 3.1 Kesimpulan
Manajemen proyek melibatkan sejumlah proses yang saling terkait. Lima kelompok proses manajemen proyek adalah inisiasi, perencanaan, pelaksanaan, pemantauan dan pengendalian, dan penutupan. Proses- proses ini terjadi pada berbagai tingkat intensitas di setiap fase proyek, dan hasil spesifik dihasilkan sebagai hasil dari setiap proses. Biasanya proses pelaksanaan membutuhkan sumber daya dan waktu paling banyak, diikuti oleh proses perencanaan. Menghabiskan waktu yang cukup dalam perencanaan terbayar dalam pelaksanaan.
Pemetaan kegiatan utama dari setiap kelompok proses manajemen proyek ke dalam 10 bidang pengetahuan manajemen proyek memberikan gambaran besar tentang kegiatan apa saja yang terlibat dalam manajemen proyek.
Penting untuk menyesuaikan metodologi manajemen proyek untuk memenuhi kebutuhan khusus organisasi. Beberapa organisasi mengembangkan metodologi manajemen
proyek TI mereka sendiri, seringkali menggunakan standar
dalamPMBOK®Memandusebagai yayasan. Metode populer seperti PRINCE2, Agile, RUP, dan Six Sigma mencakup proses manajemen proyek.
Studi kasus JWD Consulting menunjukkan bagaimana satu organisasi mengelola proyek TI dari awal hingga akhir. Studi kasus memberikan contoh keluaran yang dihasilkan untuk inisiasi, perencanaan, pelaksanaan, pemantauan dan pengendalian, dan penutupan:
• Kasus bisnis
• Daftar pemangku kepentingan
• Strategi manajemen pemangku kepentingan
• Piagam proyek
• Agenda rapat awal
• Piagam tim
• Struktur rincian kerja
• Bagan Gantt
• Daftar risiko yang diprioritaskan
• Laporan pencapaian
• Laporan perkembangan
• Laporan pembelajaran
• Laporan proyek akhir
Versi kedua dari studi kasus yang sama mengilustrasikan bagaimana menggunakan Scrum, metode gesit terkemuka, untuk mengelola proyek. Alih-alih merilis perangkat lunak intranet baru sekali menjelang akhir proyek, tim dapat merilis tiga iterasi perangkat lunak.
Versi studi kasus ini memperkenalkan beberapa alat baru, termasuk product backlog, sprint backlog, dan burndown chart.
3.2 Saran
Demikianlah makalah yang kami buat ini, semoga bermanfaat dan menambah pengetahuan pembaca. Kami mohon maaf apabila ada kesalahan ejaan dalam penulisan kata dan kalimat yang kurang jelas dimengerti, dan lugas. Dan kami juga mengharapkan saran dan kritik dari pembaca demi kesempurnaan makalah ini. Sekian penutup dari kami semoga dapat diterima dan kami ucapkan terima kasih yang sebesar-besarnya.
