Oct 10 2011

Membangun Rencana Proyek #2: Membuat Rencana Manajemen Lingkup Proyek

Ruang lingkup rencana proyek manajemen mendefinisikan bagaimana ruang lingkup proyek akan ditentukan oleh manajemen tim proyek dalam hal persyaratan proyek, bagaimana ruang lingkup akan dipantau dan dikendalikan sepanjang proyek, dan bagaimana ruang lingkup akan diverifikasi oleh pelanggan proyek. Ruang lingkup proyek adalah semua pekerjaan yang diperlukan untuk proyek yang akan dianggap selesai, dan itu didasarkan pada persyaratan stakeholder proyek. Hal-hal yang berada dalam ruang lingkup, persyaratan dan manfaat dari proyek, adalah pada apa rencana proyek ini berfokus. Hal ini juga mendefinisikan, dalam lingkup proyek pernyataan, hal-hal yang dianggap keluar dari ruang lingkup.

Rencana ini mengarahkan kreasi kita dari pernyataan ruang lingkup proyek, WBS, dan kamus WBS. Ingat bahwa ketiga unsur membentuk dasar ruang lingkup proyek. Setelah kita membuat pernyataan ruang lingkup proyek dan stakeholder telah menyetujui ruang lingkup, kita akan memecah lingkup ini ke dalam paket pekerjaan. Setiap paket pekerjaan, karena kita yakin kita mengingatnya,  dapat diperkirakan waktu dan biayanya. Seiring dengan WBS, kita akan membuat dokumen pendamping yaitu kamus WBS. Dokumen ini mendefinisikan apa paket kerja, sumber daya apa yang dibutuhkan untuk paket pekerjaan, dan waktu dan perkiraan biaya untuk setiap paket pekerjaan.

Ruang lingkup rencana manajemen proyek juga mendefinisikan bagaimana ruang lingkup harus mungkin diperbolehkan diubah. Jika kita pernah berhasil dalam proyek sebelumnya, kita tahu bahwa para stakeholder sering sekali mengubah pikirannya. Mengubah sistem yang mengontrol ruang lingkup yang didefinisikan dalam lingkup pengelolaan rencana proyek. Secara teori, jika kita sudah secara kurat mengumpulkan persyaratan proyek, seharusnya tidak ada permintaan perubahan. Dalam prakteknya, bagaimanapun, stakeholder tidak selengkap kita dalam mengumpulkan dan menawarkan persyaratan. Secara umum, permintaan perubahan yang diperlukan untuk lingkup proyek untuk empat alasan:

By ideva • Manajemen Proyek TI • 0

Oct 9 2011

Membangun Rencana Proyek #1: Dokumen Rencana Proyek

Ingat kisah Nabi Nuh dan bahtera? Kapan dia membangun kapal itu? Tentu saja dia membangun sebelum hujan turun. Itu ide yang sama dengan semua perencanaan yang akan kita lakukan pada setiap proyek yang akan kita tangani. Dengan membuat perencanaan yang efektif, menganalisis, dan memeriksa rencana dari perspektif yang berbeda, berarti kita meningkatkan kesempatan untuk menyelesaikan proyek tepat pada waktunya dan sesuai dengan anggaran yang telah ditentukan.

Pada titik ini, kita sudah melakukan banyak pekerjaan. Melihat kembali pada semua yang telah dicapai: Kita telah membuat sebuah visi, meneliti teknologi, bermitra dengan manajemen, membuat anggaran, membuat WBS, dan membangun suatu tim. Ini sama dengan ribuan kemajuan, walaupun pelaksanaan aktual dari proyek belum dimulai. Jangan berkecil hati, kegiatan yang telah kita lakukan adalah  suatu blok dasar bangunan yang kuat untuk menuju keberhasilan proyek kita. Tanpa semua aktivitas itu, proyek akan hancur.

Artikel ini berfokus pada rencana yang akan kita lakukan bersama. Jika kita sudah melakukan semua pekerjaan di awal seperti yang telah dijelaskan pada materi sebelumnya, berarti rencana kita sudah siap untuk sesuatu yang besar. Namun, masih ada beberapa hal yang memerlukan perhatian kita sebelum kita melalui bergerak. Khususnya, kita perlu memberikan beberapa pemikiran pada jadwal proyek, risiko, dan kegiatan pengadaan yang didefinisikan dalam rencana dan menentukan apakah hal itu mungkin dilakukan.. Hal ini penting pada setiap proyek. Apa yang tampak baik di atas kertas tidak selalu berjalan dengan baik dalam pelaksanaan.

Membuat Rencana Proyek

Tergantung pada ukuran suatu proyek, rencana proyek akan bervariasi. Rencana proyek bukanlah merupakan satu rencana besar, melainkan kumpulan rencana yang rinci tentang bagaimana menangani hal yang berbeda dalam kondisi, skenario, dan tindakan yang akan dikelola. Ini adalah suatu dokumen formal yang di ulas dan, mudah-mudahan, disetujui oleh manajemen. Rencana proyek bukanlah sebuah novel yang menceritakan kisah bagaimana proyek akan bergerak sepanjang waktu, melainkan sebuah panduan yang memungkinkan untuk melakukan perubahan rencana proyek sebagai rincian lebih lanjut dan menjadikannya tersedia.

Sementara rencana proyek dapat berkembang, ada beberapa elemen dalam proyek  yang umumnya tidak berubah – atau dilindungi dari perubahan. Tentu saja, dasar dari suatu proyek ini adalah ruang lingkup proyek itu sendiri. Ingat bahwa ruang lingkup proyek adalah semua yang diperlukan kerja, dan hanya dibutuhkan kerja, untuk menyelesaikan tujuan proyek. Pernyataan ruang lingkup mendefinisikan apa yang proyek akan dan tidak akan capai. Setelah pernyataan lingkup proyek disepakati, maka perubahan sistem kontrol kita melindungi itu.

Elemen lain dari rencana proyek yang harus kebal dari perubahan adalah piagam proyek dan baseline kinerja. Piagam proyek mengotorisasi proyek. Ini adalah dokumen formal yang memungkinkan manajer proyek untuk mengelola pekerjaan proyek, sumber daya, dan jadwal untuk memenuhi ruang lingkup proyek. Baseline kinerja adalah waktu, biaya, tujuan dan ruang lingkup yang manajer proyek harus penuhi dalam pengiriman proyek. Baseline jarang berubah, karena mencerminkan ruang lingkup proyek. Dengan kata lain, kita seharusnya memiliki cukup waktu dan anggaran untuk memenuhi persyaratan lingkup proyek.

Dokumen Rencana Proyek

Ketika kita dan tim proyek menciptakan elemen-elemen dari rencana proyek, kita dapat memulai dari awal atau mengandalkan informasi historis dari proyek sebelumnya. Seringkali seorang manajer proyek akan menemukan bahwa proyek-proyek mereka mirip, atau bahkan identik, untuk proyek-proyek masa lalu yang telah diselesaikan. Daripada membuat kembali roda manajemen proyek, mereka akan mengandalkan rencana proyek masa lalu menyediakan template untuk proyek-proyek mereka saat ini.

Tidak ada yang salah dengan pendekatan ini semua, ini adalah bekerja cerdas, bukan keras. Tentu saja, bila kita menggunakan rencana yang lama sebagai template, kita akan memperbarui rencana lama tersebut untuk mencerminkan proyek kita saat ini. Terlepas dari pendekatan mana yang kita ambil untuk membangun rencana proyek ini, ada beberapa dokumen proyek manajemen umum yang harus kita sertakan dalam rencana komprehensif kita:

• Project charter. Dokumen ini berasal dari seseorang dalam pengawasan posisi yang lebih tinggi dalam bagan organisasi daripada pengelola langsung dari tim pada proyek. Dokumen memberi kewenangan proyek.
• Scope Baseline. Lingkup proyek sebenarnya merupakan kombinasi dari tiga dokumen: pernyataan ruang lingkup proyek struktur rincian pekerjaan (WBS), dan kamus WBS. Lingkup baseline digunakan di seluruh proyek ketika ada pertanyaan tentang persyaratan proyek, masalah eksekusi, risiko manajemen, estimasi biaya, masalah, dan kegiatan manajemen proyek lainnya. Anda akan menggunakan lingkup baseline sebagai pedoman bagi semua keputusan proyek masa depan.
• Waktu dan perkiraan biaya untuk setiap paket pekerjaan Ingatlah bahwa waktu dan biaya mencerminkan perkiraan tenaga kerja dan bahan yang dibutuhkan untuk memberikan proyek. bagian ini pada rencana proyek juga akan merinci bagaimana asalnya perkiraan, tingkat keyakinan dalam perkiraan, dan setiap asumsi yang terkait dengan perkiraan.
• Pengukuran kinerja baseline. Baseline adalah batasan atau target dari manajer proyek dan tim proyek yang diharapkan dapat diselesaikan. Sebagai contoh, baseline biaya awal dapat memprediksi jumlah anggaran yang harus dihabiskan dengan milestone diberikan dengan variance yang diijinkan.  Waktu dan biaya adalah basis yang paling umum yang untuk mengukur proyek  terhadap kinerja.
  
• Milestone (tonggak) dan tanggal target untuk milestone. Dalam proyek, kita harus mudah mengidentifikasi milestone, yang merupakan sinyal bahwa kita bergerak menuju penyelesaian proyek. Dengan mengasosiasikan milestone utama dengan tanggal target yang kita dan manajemen telah setujui. Hal ini memungkinkan kita dan manajemen untuk merencanakan pemanfaatan sumber daya, mempertimbangkan proses tambahan dalam bisnis kita, dan menjaga semua stakeholder dikomunikasikan di mana proyek harus poskan dan kapan.
  
• Persyaratan sumber daya. Sumber daya manusia, bahan, peralatan, perlengkapan, fasilitas, dan layanan yang kita akan perlukan untuk menyelesaikan proyek kita. Mungkin ada bagai dari rencana proyek kita yang membutuhkan sumber daya sementara atau sumber daya khusus untuk menyelesaikan sebagian dari pekerjaan proyek. Diperlukan personil, bahan, dan jasa yang harus diidentifikasi, ketersediaan mereka ditentukan, dan biaya yang terkait didokumentasikan.
  
• Catatan Issue. Issue adalah keputusan yang belum ditentukan tetapi perlu ditentukan pada tanggal tertentu atau mereka akan menjadi risiko untuk keberhasilan proyek. Iseue didokumentasikan dalam catatan issue, pemilik risiko ditugaskan untuk menyelidiki risiko, dan tenggat waktu untuk mengambil keputusan yang melekat pada setiap issue. Akan ada banyak issue terbuka dan keputusan tertunda pada saat rencana pertama kali diciptakan. Bagian dari rencana ini mengidentifikasi dan mendokumentasikan issue yang akan ditentukan dan memungkinkan proyek untuk dilanjutkan. Tentu saja, keputusan dan issue-issue pada bagian proyek ini harus ditangani secara benar, yang menyebabkan area lain dari rencana proyek akan diperbarui.
  
• Catatan Asumsi. Asumsi adalah sesuatu yang kita yakini benar namun belum terbukti kebenarannya. Pada TI, kita seringkali harus membuat asumsi dalam melakukan perencanaan: perangkat lunak dan hardware akan bekerja sama, driver hardware baru bisa bekerja dengan sistem operasi yang ada, kurva pembelajaran perangkat lunak tidak terlalu drastis, dan banyak lagi. Ketika kita melengkapi manajemen risiko perencanaan, kita akan menguji asumsi ini untuk membuktikan teori-teori tersebut benar atau salah. Asumsi yang terbukti salah dapat menjadi risiko dalam proyek.
  
• Persyaratan kualitas Kualitas merupakan hal yang esoteris – apa yang yang cepat, baik, dan super untuk Anda mungkin tidak cepat, baik, atau super bagi saya. Untuk memiliki kualitas dalam TI proyek, Anda harus menentukan metrik kualitas, menyediakan pengukuran kuantitatif yang akan menyamakan kualitas, dan menjelaskan kepada para stakeholder proyek apa artinya pengukuran dan bagaimana mereka akan memetakannya dengan persyaratan untuk kualitas penerimaan dalam proyek. Organisasi sebaiknya juga dapat berlangganan kualitas program-program, seperti Six Sigma atau program ISO. Kita harus menyertakan persyaratan proyek untuk kualitas dalam manajemen berbasis program.
  
• Kalender Rencana manajemen proyek memerlukan dua kalender: sumber daya kalender dan kalender proyek. Kalender sumber daya mendefinisikan kapan sumber daya proyek diperlukan, kapan sumber daya tersedia, dan kapan sumber daya akan digunakan dalam proyek kita. Ingat, sumber daya lebih dari sekedar orang – bahan, fasilitas, dan layanan sumber daya manusia juga. Proyek kalender mendefinisikan kapan pekerjaan proyek akan berlangsung. Anda akan menentukan jam kerja proyek, liburan perusahaan, dan musim sibuk ketika pekerjaan proyek dapat, atau tidak mungkin berlangsung.
  
• Manajemen strategi stakeholder. Proyek kita mungkina akan memiliki stakeholder  yang negatif, netral, dan positif. Strategi manajemen pemangku kepentingan mendefinisikan bagaimana kita akan meningkatkan dukungan untuk proyek kita, menangkis stakeholder negatif, mengurangi ketakutan dan kekhawatiran, dan mempromosikan dukungan untuk proyek tersebut. Kita akan menggunakan strategi manajemen pemangku kepentingan bersama dengan manajemen komunikasi proyek rencana.
  
• Rincian pendukung. Rincian pendukung adalah setiap dokumentasi yang relevan yang mempengaruhi keputusan proyek kita, dokumentasi teknis, dan setiap standar yang relevan dengan proyek ini akan beroperasi di bawah proyek kita.
  

By ideva • Manajemen Proyek TI • 0