Anda pernah di tengah-tengah sebuah proyek atau tugas dan berpikir untuk diri sendiri, "Ada harus menjadi cara yang lebih baik?" Jika demikian, Anda tidak sendirian. Memimpin proyek adalah bisnis yang rumit. Semakin lama Anda berada di itu semakin Anda bisa belajar dan semakin baik Anda bisa mendapatkan.
Daftar ini dimaksudkan untuk mulai manajer proyek menengah.
Ini ditulis dari perspektif Teknologi Informasi, dan harus berlaku untuk jenis lain dari proyek.
Bahkan pro harus menemukan sesuatu yang berharga.
Berikut adalah 72 tips yang manajemen proyek yang dirancang untuk membantu Anda memimpin proyek Anda dengan keterampilan, wewenang dan rahmat.
Mulai Proyek (Inisiasi)
Inisiasi adalah tahap pertama dari Proyek Manajemen Siklus Hidup. Dalam memulai tahap Anda menentukan tujuan proyek, tujuan, ruang lingkup dan kiriman, dan membuat orang dan sumber daya lain untuk proyek Anda.
1. Bagaimana Anda akan tahu jika proyek Anda sukses? Bisa kamu sebutkan kriteria keberhasilan dalam beberapa kata atau kalimat? Dengan kata lain, bagaimana Anda tahu ketika Anda selesai?
2. Apakah Anda melakukan proyek? Proyek adalah usaha temporer dengan hasil atau tujuan tertentu. Jika proyek Anda tidak memiliki akhir yang terlihat dan / atau tidak ada ruang lingkup yang jelas, maka apa yang pernah yang Anda lakukan mungkin penting, tapi itu bukan proyek. Anda akan memiliki waktu yang sulit menunjukkan tim Anda bahwa mereka menjadi sukses.
3. Jika Anda tidak memiliki akhir proyek dalam 3 sampai 6 bulan ke depan, Anda dapat membaginya menjadi beberapa proyek?
4. Apakah Anda berpikir tentang kendala tiga ? waktu, ruang lingkup, dan biaya. Baru mencakup kepuasan pelanggan, risiko, dan kualitas.
5. Apakah Anda memiliki sebuah piagam proyek / definisi proyek? Jika tidak, tuliskan satu untuk keuntungan Anda sendiri. Memiliki piagam dapat menghilangkan banyak kesempatan untuk kebingungan selama proyek.
6. Siapa stakeholder utama Anda? Siapa stakeholder Anda yang lain?
7. Jika Anda memiliki lebih dari satu pemangku kepentingan, bagaimana perbedaan antara pemangku kepentingan dalam hal ruang lingkup proyek, jadwal, anggaran atau kiriman diselesaikan? Jika Anda tidak yakin, maka ini adalah diskusi yang baik untuk memiliki dengan mereka.
8. Apakah Anda memiliki peran dan tanggung jawab grafik? Siapa yang ada di tim? Siapa yang tidak di tim?
9. Apakah semua anggota tim inti memahami peran mereka dan setuju untuk mereka?
Pengorganisasian Diri
10. Apakah Anda memiliki portofolio template? Jika tidak, memulai satu.
11. Apakah Anda menyimpan koleksi dokumen proyek benar-benar baik yang ditulis oleh Anda dan orang lain? Jika tidak, memulai satu.
12. Bagaimana proyek kiriman, dokumen dan catatan yang dikelola pada proyek Anda? Apakah ada satu tempat utama di mana hal-hal yang disimpan? Apakah setiap orang di tim proyek tahu ini?
13. Apakah backup yang dilakukan (dokumen, kiriman, kode, dll)? Kapan terakhir kali Anda diuji cadangan? Cobalah hari ini dan melihat apa yang terjadi.
Biaya dan Anggaran
14. Apa anggaran Anda disetujui? Jika Anda tidak tahu, bagaimana Anda bisa mencari tahu?
15. Siapa yang bertanggung jawab untuk melacak anggaran? Jika tidak Anda, dapat Anda bernegosiasi akses ke faktur seperti yang disampaikan dan pembayaran seperti yang dibuat?
16. Apa metode Anda untuk melaporkan pengeluaran terhadap anggaran?
17. Berapa banyak yang Anda habiskan? Jika Anda berpikir Anda akan lebih dari 10% dari anggaran pada akhir proyek, apa yang Anda lakukan tentang hal itu? Bisakah Anda mendapatkan lebih banyak uang? Dapatkah Anda memangkas lingkup? Apakah Anda mengatakan kepada stakeholder Anda?
18. Apakah anggaran Anda up to date?
Perencanaan
Perencanaan adalah tahap kedua dari Proyek Manajemen Siklus Hidup. Anda akan mengatur rencana yang dibutuhkan untuk mengelola waktu, risiko dan masalah, perubahan, kualitas dan segala sesuatu yang akan dilakukan selama pelaksanaan proyek.
Lingkup Proyek
19. Apakah Anda memiliki lingkup proyek ditandatangani?
20. Apakah Anda termasuk lingkup apa yang tidak dalam proyek Anda?
21. Apakah ruang lingkup ditulis dalam bahasa yang ada kecerdasan akal bisa mengerti? Apakah semua akronim dijelaskan?
Risiko (dan masalah)
22. Apakah Anda memiliki log risiko atau mendaftar? Ini adalah salah satu tempat di mana Anda melacak potensi peristiwa yang akan memiliki dampak positif atau negatif pada proyek jika mereka terjadi. Jika tidak, mengapa tidak? (Email saya jika Anda ingin template sampel dari excel log berbasis risiko sederhana.)
23. Apakah Anda menghabiskan beberapa menit dengan tim Anda setiap minggu atau dua mengidentifikasi risiko baru dan bekerja untuk mengurangi atau menangani yang sudah ada?
24. Apakah Anda berkomunikasi risiko signifikan (kemungkinan tinggi, dampak tinggi) kepada para pemangku kepentingan Anda baik di muka sehingga mereka tidak pernah terkejut?
25. Apakah Anda menyimpan catatan segala sesuatu yang Anda dan tim Anda berencana untuk melakukan, melakukan, atau telah dilakukan sehubungan dengan risiko dan masalah pada proyek Anda? Ini adalah informasi yang sangat berharga untuk digunakan pada proyek-proyek masa depan.
Jadwal dan Kerja Struktur Breakdown (WBS)
26. Apakah Anda mengidentifikasi semua kiriman Anda untuk proyek tersebut?
27. Apakah Anda termasuk tim Anda dalam mengidentifikasi langkah-langkah yang diperlukan untuk setiap deliverable?
28. Apakah Anda menggunakan PERT (Program Evaluasi dan Teknik Review) atau metode lain untuk datang dengan perkiraan waktu Anda? Apakah Anda datang dengan perkiraan waktu? Apakah Anda memvalidasi mereka dengan orang-orang yang benar-benar akan melakukan pekerjaan?
Rencana Manajemen Proyek
PRINCE2 (Proyek dalam lingkungan terkendali) mendefinisikan rencana manajemen proyek, "sebuah pernyataan tentang bagaimana ... tujuan proyek adalah untuk dicapai."
29. Bagaimana informasi proyek penting dikumpulkan? Disebarluaskan? Email? Pertemuan? Wiki? Twitter? Percakapan santai? Ini kadang-kadang dikenal sebagai rencana komunikasi.
30. Bagaimana risiko diidentifikasi, diukur, dipantau dan dikelola pada proyek Anda? Apakah Anda memiliki log risiko? Ketika Anda akan memberitahu orang lain? Bagaimana mereka akan diberitahu? Ini kadang-kadang dikenal sebagai rencana manajemen risiko.
31. Bagaimana perubahan persyaratan proyek atau ruang lingkup ditangani? Jika ada proses perubahan manajemen secara keseluruhan, bagaimana perubahan terhadap proyek berhubungan dengan proses itu? Ini kadang-kadang dikenal sebagai rencana manajemen perubahan.
32. Bagaimana keputusan pembelian akan dilakukan pada proyek Anda? Bagaimana Anda akan mengidentifikasi penjual potensial? Apakah Anda akan menggunakan Request for Proposal proses (RFP)? Apakah organisasi Anda memiliki standar yang ditetapkan? Ini kadang-kadang dikenal sebagai pengadaan atau rencana manajemen vendor.
33. Bagaimana anggota tim, klien dan stakeholder dibawa ke tingkat kompetensi pada produk proyek? Apakah setiap anggota tim membutuhkan dukungan untuk menyelesaikan tanggung jawab proyek mereka? Bagaimana pelatihan akan disampaikan? Online? Melalui panduan dicetak atau manual? Train-the-trainer? Pelatihan kelas? Ini kadang-kadang dikenal sebagai rencana pelatihan.
34. Bagaimana solusinya dipindahkan ke produksi atau disampaikan? Apakah akan ada go / no go pos pemeriksaan? Apa langkah-langkah? Siapa melakukan apa? Apa kelompok atau organisasi lain perlu terlibat? Apakah ada jendela waktu yang harus dihormati? Ini kadang-kadang dikenal sebagai rencana implementasi.
35. Bagaimana dukungan yang berkelanjutan ditangani setelah proyek selesai? Siapa yang akan bertanggung jawab untuk menjaga produk proyek? Siapa yang akan membantu dengan isu-isu atau masalah pengguna? Bagaimana akan peningkatan maupun perbaikan dilaporkan dan dimasukkan? Apa pemeliharaan preventif akan dibutuhkan? Ini kadang-kadang dikenal sebagai rencana transisi pemeliharaan.
36. Isu apa yang mungkin muncul setelah produk digunakan? Apakah ada langkah-langkah yang dapat diambil untuk meminimalkan kemungkinan dan / atau keparahan potensi isu ini? Ini kadang-kadang dikenal sebagai rencana pemulihan bencana.
Persyaratan
53. Apakah pelaporan status mengkomunikasikan sesuatu yang berharga?
54. Apakah laporan status Anda baca? Bagaimana Anda tahu?
55. Jika Anda memiliki satu laporan status, apakah itu ditujukan pada tingkat untuk memenuhi tim Anda proyek, stakeholder aktif Anda, atau eksekutif? Akan masuk akal untuk membuat laporan yang berbeda untuk kelompok yang berbeda?
56. Jika Anda mengharapkan laporan dari anggota tim Anda, vendor atau orang lain, Anda mendapatkan mereka?
57. Jika Anda mendapatkan mereka, apakah mereka memberitahu Anda sesuatu yang berharga? Jika tidak, bagaimana Anda dapat mengubah mereka sehingga mereka bernilai bagi Anda?
58. Apakah Anda memiliki status pertemuan mingguan? Dapatkah Anda menyusun mereka sehingga orang dapat dilepaskan tanpa menginap untuk seluruh pertemuan?
Pengujian
59. Apakah uji kasus Anda selesai sebelum pembangunan awal? Hal ini dapat sangat mempersingkat siklus tes. Jika tidak, apakah Anda bersedia untuk mencoba ini pada proyek masa depan?
60. Apakah stakeholder Anda tahu bagaimana melakukan pengujian penerimaan pengguna? Apa yang Anda lakukan untuk memfasilitasi UAT cepat?
61. Dapatkah Anda menguraikan strategi pengujian dan bekerja dengan mereka untuk menentukan apa yang akan diuji?
62. Dapatkah Anda setuju dengan para pemangku kepentingan Anda sebagai spesifik yang diperlukan untuk UAT sukses sebelum pengujian dimulai UAT?
63. Apakah proyek Anda rentan terhadap teror yang berasal dari dua kesalahan yang fatal pengujian filosofis: (a) Dalam mencari bug rilis gratis dan (b) pengujian yang baik berarti menemukan jumlah tertinggi bug?
64. Apakah pengembang Anda berkomunikasi dengan penguji Anda? (Ini berlaku bahkan jika Anda memiliki tim uji outsourcing.) Dalam perangkat lunak toko jaminan paling efektif kualitas (QA) dan pembangunan tidak pernah berkomunikasi sebelum pengujian dimulai. Jangan biarkan ini terjadi pada Anda.
Menutup Proyek
Tutup adalah fase terakhir dalam Manajemen Proyek Siklus Hidup. Di sini Anda resmi menutup proyek Anda dan melaporkan keseluruhan tingkat keberhasilan untuk stakeholder Anda.
Pelajaran
65. Apakah Anda melihat pelajaran sebagai sarana untuk meningkatkan upaya proyek masa depan? Atau lebih tepatnya adalah sebuah cara untuk mendapatkan keadilan dengan memukuli di pihak bersalah?
66. Dapatkah Anda membuat, tempat yang aman terbuka bagi orang untuk memberikan umpan balik yang jujur dan tulus dalam proyek tersebut? Jika tidak, apakah ada orang lain di perusahaan Anda atau di luar yang bisa melakukan pelajaran untuk Anda?
67. Kapan terakhir kali Anda melakukan pelajaran?
68. Mengapa tidak memulai proyek ini?
Survey Kepuasan Pelanggan
69. Apakah Anda meminta umpan balik
dari pelanggan Anda, klien atau pemangku kepentingan? Sebuah pertanyaan contoh
mungkin, "Apa yang bisa dilakukan lebih baik pada proyek ini?"
70. Jika Anda meminta umpan balik,
pertanyaan-pertanyaan baik dasar dan loyalitas termasuk? Sebuah contoh dari
sebuah pertanyaan mendasar adalah, "Seberapa puaskah anda dengan apa yang
tim proyek disampaikan?" Contoh pertanyaan loyalitas, "Bagaimana mau
akan Anda bekerja dengan tim ini proyek lagi?"
71. Apakah Anda bersedia untuk
mengirimkan sebuah survei anonim untuk tim proyek Anda? Beberapa pertanyaan
untuk bertanya: Apa yang berjalan dengan baik dalam proyek tersebut? Apa yang
bisa pergi lebih baik? Apa yang akan meningkatkan pengalaman Anda pada
proyek-proyek masa depan? Bagaimana mungkin pemimpin proyek menjadi lebih
efektif?
Obral Proyek
72. Sebuah dokumen obral proyek formal, ditandatangani email atau satu halaman
dokumen yang secara resmi menutup proyek dan melepaskan tim. Apakah Anda pernah
melihat satu? Apa yang akan Anda lakukan untuk memastikan bahwa Anda
menggunakan salah satu pada proyek Anda?
