---

Di Blue, kami menghabiskan banyak waktu untuk memikirkan manajemen proyek. Hal ini sangat penting bagi apa yang kami lakukan dan kesuksesan dari apa yang kami berikan kepada klien-klien kami. Tanpa pemahaman yang solid tentang manajemen proyek, bagaimana mungkin kami bisa membangun perangkat lunak manajemen proyek?

Setiap kali kami memulai proyek baru, baik itu fitur baru, peningkatan teknik backend, kampanye pemasaran, atau rekrutmen karyawan, kami memulai dengan menganalisis proyek itu sendiri dan bagaimana proyek tersebut dijalankan. Jadi, dengan pengalaman dan wawasan yang luas, kami telah memutuskan untuk mulai merumuskan beberapa prinsip dasar manajemen proyek.

Meskipun umum (dan dapat diterima) untuk menavigasi proyek menggunakan pendekatan yang lebih informal dan berdasarkan insting pribadi, pendekatan ini sulit untuk diskalakan — dan bukan tanpa kekurangannya.

Sebuah Proyek

Mari kita mulai dengan mendefinisikan proyek.

Proyek adalah upaya sementara dengan awal dan akhir yang jelas untuk menghasilkan produk, layanan, atau hasil yang unik. Beginilah cara sebagian besar orang memikirkan proyek. Namun ada juga beberapa properti proyek yang lebih formal dan penting untuk dipertimbangkan:

• Proyek memiliki sumber daya yang terbatas (waktu, uang, orang);
• Proyek dilakukan untuk mencapai tujuan tertentu;
• Proyek memiliki ruang lingkup yang jelas (sehingga ada hal-hal yang jelas tidak akan dilakukan);
• Proyek tunduk pada ketidakpastian dan risiko.

Sekarang setelah kita memiliki pemahaman yang lebih baik tentang apa itu proyek, kita dapat beralih ke prinsip-prinsip dasar — blok bangunan inti yang diperlukan proyek untuk sukses. Ini termasuk:

• Seorang manajer proyek;
• Sebuah tujuan;
• Daftar hal-hal yang harus diselesaikan — ini sering disebut rencana;
• Seseorang yang ditugaskan untuk melakukan setiap hal;
• Jadwal waktu untuk setiap hal;
• Strategi komunikasi dengan ritme reguler pembaruan dan rapat, serta rencana untuk tempat penyimpanan informasi.

Kami menemukan bahwa hal-hal ini biasanya berlaku untuk semua proyek dan, jika dilakukan dengan baik, menghilangkan 99% dari semua masalah dalam proyek.

Seorang Manajer Proyek

Hal pertama yang dibutuhkan proyek adalah seseorang yang bertanggung jawab untuk menyelesaikannya dengan sukses. Ini mungkin tampak seperti pernyataan yang jelas, tetapi perlu ditekankan.

Orang ini adalah manajer proyek. Mereka bertanggung jawab untuk memastikan bahwa tujuan proyek tercapai dan bahwa proyek diselesaikan tepat waktu, sesuai anggaran, dan sesuai standar kualitas yang diperlukan. Seringkali, banyak dari kita menjadi manajer proyek de-facto tanpa menjadi manajer proyek yang terlatih. Jika itu adalah Anda, maka Anda beruntung, kami menulis panduan untuk itu!

Perlu dipertimbangkan apa yang seharusnya dan tidak seharusnya dilakukan oleh manajer proyek. Lagi pula, mereka memiliki banyak tanggung jawab, dan mereka harus menganggap tanggung jawab ini dengan serius.

Seringkali manajemen proyek dapat mengambil bagian yang signifikan dari anggaran proyek — biasanya antara 2% dan 10% darinya, tergantung pada seberapa berisiko proyek tersebut. Semakin berisiko, semakin banyak manajemen proyek yang diperlukan untuk memastikan bahwa hal-hal tetap berada di jalur yang benar dan proyek tidak gagal.

Karena mereka adalah manajer, manajer proyek harus fokus pada bagaimana mencapai tujuan melalui orang lain. Mereka perlu memastikan bahwa tim proyek efektif dan bahwa mereka bekerja bersama secara harmonis menuju tujuan bersama. Manajer proyek adalah orang yang perlu memastikan bahwa semua orang melakukan pekerjaan mereka dan bahwa mereka melakukannya dengan baik.

Manajer proyek juga bertanggung jawab untuk berkomunikasi dengan pemangku kepentingan proyek dan menjaga mereka tetap terinformasi tentang kemajuannya.

Sama seperti yang kita diskusikan dalam Prioritisasi untuk Pemimpin, manajer proyek harus terus-menerus fokus pada titik kendala. Jika mendapatkan persetujuan pemangku kepentingan membutuhkan terlalu banyak waktu, maka mereka perlu sangat fokus untuk mendapatkan komitmen tersebut. Mereka perlu terus-menerus bertanya pada diri sendiri, "Apa yang menahan kami dari menyelesaikan tujuan proyek, dan bagaimana cara saya membuka blokir masalah secepat mungkin?"

Dalam beberapa hal, manajemen proyek identik dengan komunikasi. Menulis ide-ide terperinci adalah keterampilan yang berharga bagi manajer proyek, karena hal ini secara drastis mengurangi jumlah rapat yang diperlukan — anggota tim dapat melayani diri sendiri dengan informasi yang diperlukan.

Sebuah Tujuan

Blok bangunan inti lain dari proyek adalah bahwa proyek perlu memiliki tujuan yang jelas dan terukur. Setelah proyek selesai, seharusnya mudah untuk melihat hasilnya dan mengetahui apakah proyek mencapai tujuannya atau gagal.

Tujuan harus dipublikasikan sehingga setiap anggota tim memiliki akses terhadapnya. Ini penting karena berarti pengambilan keputusan dapat didistribusikan dan didesentralisasi, karena setiap anggota tim dapat melihat bagian kecil pekerjaan mereka dan menghubungkannya dengan tujuan menyeluruh proyek. Kemudian, mereka dapat mengangkat masalah jika ada ketidakselarasan atau mengubah pendekatan mereka di area kecil proyek mereka untuk melayani tujuan yang lebih besar dengan lebih baik.

Tujuan proyek harus SMART:

• Spesifik. Proyek sering memiliki tujuan tingkat tinggi yang terdengar lebih seperti pernyataan misi atau visi. Contoh tujuan yang buruk adalah "meningkatkan dukungan pelanggan". Ini tidak cukup spesifik. Sesuatu seperti "Kami bertujuan untuk membalas email 90% pelanggan dalam 30 menit pada akhir Q4" jauh lebih spesifik.
• Terukur. Ketika Anda menetapkan tujuan yang spesifik, Anda kemudian umumnya menyelesaikan masalah pengukuran secara bersamaan karena kemudian mudah untuk menilai apakah tujuan telah tercapai.
• Dapat dicapai. Tujuan hanya masuk akal jika dapat dicapai. Tetapi ini bukan alasan untuk membuat tujuan yang mudah. Tujuan yang baik harus memiliki elemen peregangan — cukup menantang untuk dapat dicapai, tetapi tidak mustahil atau sangat tidak mungkin.
• Relevan. Ini mungkin terdengar sangat jelas, tetapi Anda akan terkejut betapa sering ini terjadi. Tujuan proyek harus dapat dicapai dengan melakukan proyek. Anda tidak dapat menetapkan tujuan yang tidak dapat dikontrol oleh tim proyek yang melakukan pekerjaan spesifik proyek. Misalnya, tim yang bekerja di divisi manufaktur perusahaan mungkin tidak mempengaruhi pengalaman berbelanja dalam toko pelanggan.
• Terikat waktu. Tujuan yang baik perlu memiliki beberapa jenis timing yang terkait dengannya. Ini bisa sulit, terutama dengan proyek perangkat lunak modern di mana pekerjaan yang harus dilakukan tidak selalu jelas, sehingga jadwal waktu bisa sangat sulit diperkirakan. Kadang-kadang Anda bisa meleset berkali-kali lipat, dan itu bukan kesalahan spesifik siapa pun. Yang mengatakan, memiliki jadwal waktu memastikan bahwa ruang lingkup keseluruhan proyek tetap dalam batas tertentu. Jika Anda memiliki satu bulan untuk menyelesaikan masalah versus satu tahun, Anda akan datang dengan solusi yang sangat berbeda.

Tujuan harus diulang kepada semua anggota tim hingga mereka muak: mereka harus (secara kiasan) merasa muak dengan manajer proyek yang terus-menerus membahas tujuan. Beberapa dashboard real-time (atau sedekat mungkin dengan real-time) yang melacak kemajuan juga dapat sangat berharga untuk memastikan semua orang selaras dengan tujuan dan mengetahui bagaimana proyek berjalan.

Daftar Hal-Hal yang Harus Diselesaikan

Kami sangat menyarankan untuk menyebut rencana sebagai "daftar hal-hal yang harus diselesaikan" sebagai gantinya, karena hal ini mendemistifikasi proses perencanaan.

Rencana sering kali adalah dugaan, tetapi tetap bermanfaat. Ini karena proses perencanaan itu sendiri membantu menyoroti apa yang kita ketahui dan apa yang belum kita ketahui.

Gagal merencanakan, berencana untuk gagal.

Inti dari rencana adalah mendapatkan daftar terperinci dari semua langkah untuk pergi dari awal proyek hingga penyelesaiannya yang sukses. Beberapa tindakan akan memerlukan langkah sebelumnya untuk diselesaikan, dan sehingga Anda mungkin berakhir dengan serangkaian tugas yang saling terkait, sering disebut dependensi. Tindakan lain dapat dilakukan secara paralel dan tidak memblokir satu sama lain.

Manajer proyek harus selalu fokus pada tindakan paling penting yang memblokir tindakan lain, karena ini mendefinisikan apa yang dikenal sebagai jalur kritis proyek. Yaitu, jumlah waktu minimum di mana proyek dapat diselesaikan jika semua dependensi diatur berurutan.

Bekerja pada rencana dari kedua ujung proyek dapat membantu tremendously dalam membangun rencana yang efektif. Ini berarti bahwa Anda mulai dari awal dan pergi ke akhir, tetapi kemudian Anda juga mulai di akhir dan bekerja mundur untuk memahami apa yang diperlukan untuk menyelesaikan proyek dan mencapai tujuan.

Bagian terakhir dari membalikkan proses perencanaan ini umumnya akan menggali tugas-tugas yang terlewat.

Tetapi, proses perencanaan tidak lengkap sampai kita memahami siapa yang bertanggung jawab untuk setiap tugas dan berapa lama setiap tugas akan memakan waktu untuk diselesaikan.

Poin-poin ini harus dicakup secara bersamaan karena mereka sangat terkait erat. Anda tidak dapat membuat perkiraan untuk pekerjaan tanpa melibatkan para ahli yang mengetahui spesifik tugas tersebut, dan bahkan kemudian, Anda masih perlu mengawasi sumber daya Anda. Seorang individu jarang dapat bekerja secara efektif pada beberapa hal pada saat yang sama, jadi Anda perlu memahami apakah rencana proyek kemungkinan akan memiliki kemacetan. Ini adalah di mana satu orang tidak dapat menyelesaikan semua tugas yang ditugaskan karena mereka hanya tidak memiliki waktu yang cukup tersedia.

Seseorang yang Ditugaskan untuk Melakukan Setiap Hal

Setiap tugas dalam proyek perlu memiliki individu spesifik yang diberi tanggung jawab untuk menyelesaikan tugas tersebut. Jika Anda menemukan bahwa Anda memerlukan beberapa individu yang ditugaskan untuk tugas yang sama, Anda sering belum pergi ke tingkat yang cukup terperinci untuk membedakan tugas.

Misalnya, di banyak industri, akan ada fase desain dan pembangunan; ini bisa dalam manufaktur, konstruksi, atau bahkan perangkat lunak. Anda harus memecah ini sehingga Anda dapat menugaskan tugas spesifik desainer dan tugas spesifik pembangun. Anda akan sering menemukan bolak-balik antara kedua disiplin, yang dapat Anda faktorkan. Contohnya mungkin terlihat seperti ini:

1. Fase Desain 1 oleh Desainer
2. Pemeriksaan Kelayakan 1 oleh Pembangun
3. Fase Desain 2 oleh Desainer
4. Pemeriksaan Kelayakan 2 oleh Pembangun
5. Tinjauan oleh Pemangku Kepentingan Senior
6. Finalisasi Desain oleh Desainer
7. Pemeriksaan Akhir oleh Pembangun
8. Persetujuan oleh Pemangku Kepentingan

Ini menunjukkan naik-turun yang realistis antara pihak-pihak berbeda yang terlibat, daripada memiliki "Fase Desain" saja yang ditugaskan kepada tim desain hingga penyelesaian fase desain.

Jadwal Waktu untuk Setiap Hal

Ini mungkin bagian paling menantang dari pembuatan rencana — bagaimana kita mengukur berapa lama setiap hal akan memakan waktu? Seperti yang dibahas sebelumnya, jadwal waktu tidak boleh dilakukan dari atas ke bawah tetapi dari bawah ke atas. Ini berarti bahwa setiap item diperkirakan oleh orang yang akan melakukan pekerjaan (atau setidaknya rekan yang berpengetahuan) dan bahwa semua perkiraan ini ditambahkan dan dihitung menjadi jadwal waktu keseluruhan.

Yang mengatakan, membantu untuk memiliki jadwal waktu tingkat tinggi keseluruhan sebelum perkiraan terperinci dibuat karena memperkirakan berapa lama sesuatu akan memakan waktu dan memutuskan pendekatan spesifik untuk menyelesaikan tugas pada dasarnya adalah hal yang sama.

Jadi jika proyek memiliki jadwal waktu tingkat tinggi yang murah hati, maka ahli individu dapat memperhitungkan itu dalam perkiraan mereka dan mencoba mengoptimalkan solusi untuk jangka panjang daripada memotong sudut untuk memastikan jadwal waktu tercapai. Jika proyek memiliki jadwal waktu yang terburu-buru, maka setiap ahli tahu mereka mungkin perlu membuat trade-off.

Satu hal yang sering dilupakan selama pembuatan rencana proyek adalah bahwa pemangku kepentingan akan perlu meninjau kemajuan dan mengkonfirmasi keputusan yang perlu diperhitungkan. Cara terbaik untuk melakukan ini adalah dengan melihat proyek sebelumnya yang mencakup set pemangku kepentingan yang sama dan memahami berapa waktu putaran yang khas bagi mereka untuk memberikan umpan balik.

Bahaya lain di sini adalah bahwa jika ada rapat komite pengarah bulanan dengan pemangku kepentingan kunci, apa yang terjadi jika hasil proyek tidak dapat diserahkan tepat waktu untuk salah satu rapat tersebut? Apakah proyek ditunda hingga bulan depan ketika pemangku kepentingan bertemu lagi, atau akan ini ditangani dan disetujui (atau dikirim kembali dengan umpan balik) di antara komite pengarah bulanan?

Strategi Komunikasi

Ketika masalah seperti ini muncul, mereka mengkonfirmasi bahwa pendekatan komunikasi dalam proyek adalah sangat penting.

Biasanya, masalahnya bukan bahwa ada strategi yang buruk tetapi bahwa tidak ada strategi yang ada sama sekali. Jadi saluran komunikasi terbuka dengan cara yang informal dan ad-hoc, dan "cukup baik" menjadi standar.

Masalah dengan ini adalah bahwa hal-hal tidak selalu berjalan sesuai rencana. Orang berubah, pengetahuan hilang, dan ketika proyek menjadi lebih luas dan lebih banyak orang bergabung, overhead komunikasi dapat dengan cepat meledak.

Jadi, jelas, alat-alat itu sendiri tidak begitu penting; itu hanya fakta bahwa ketika Anda melewati jumlah orang yang non-trivial (katakanlah, 10), kerja tim menjadi semakin lebih sulit.

Itu karena komunikasi tim tidak skala secara linear dibandingkan dengan jumlah orang dalam tim.

Misalnya, jika Anda memiliki tim 2 orang, ada satu utas komunikasi (antara dua individu). Lempar orang lain ke dalam campuran; sekarang Anda memiliki tiga utas komunikasi. Jadi, sementara ukuran tim telah meningkat 50%, utas komunikasi telah meningkat 300%.

Mari kita lihat bagaimana ini tumbuh:

• 2 anggota tim = 1 utas komunikasi
• 3 anggota tim = 3 utas komunikasi
• 5 anggota tim = 10 utas komunikasi
• 8 anggota tim = 28 utas komunikasi
• 10 anggota tim = 45 utas komunikasi
• 15 anggota tim = 105 utas komunikasi
• 20 anggota tim = 190 utas komunikasi
• 30 anggota tim = 435 utas komunikasi
• 50 anggota tim = 1,225 utas komunikasi
• 100 anggota tim = 4,950 utas komunikasi

Ini dapat dinyatakan dengan persamaan berikut:

n(n-1)/2

Di mana n adalah jumlah orang yang perlu terlibat dalam proyek.

Seperti yang dapat Anda lihat, angka ini tumbuh secara eksponensial ketika ukuran tim meningkat. Jika Anda memiliki tim 10 orang, 45 utas komunikasi potensial perlu dikelola. Tetapi jika Anda memiliki tim 50 orang, ada 1,225 utas komunikasi potensial — itu 27 kali lebih banyak! Dan jika Anda memiliki tim 100 orang, ada 4,950 utas komunikasi yang mungkin — itu 110 kali lebih banyak!

Penting untuk dicatat bahwa ini bukan hanya masalah dengan tim yang lebih besar tetapi dengan tim mana pun di mana individu tidak berada di lokasi yang sama. Ini karena jumlah utas komunikasi yang mungkin tidak dibatasi oleh kedekatan fisik anggota tim.

Misalnya, Anda memiliki tim 10 orang, tetapi mereka semua berlokasi di bagian dunia yang berbeda. Dalam hal ini, masih ada 45 utas komunikasi potensial yang perlu dikelola — meskipun anggota tim tidak secara fisik berdekatan satu sama lain.

Dan bisa menjadi lebih buruk. Perhitungan di atas mengasumsikan hanya satu metode komunikasi. Jika kita ingin memperhitungkan metode komunikasi yang berbeda, kita harus menulis ulang persamaan dengan cara berikut:

n(n-1)/2

Di mana n adalah jumlah saluran komunikasi.

Mari kita ambil kembali jumlah utas komunikasi di atas, tetapi kali ini mari kita asumsikan bahwa n terdiri dari:

• Email
• Obrolan Grup
• Obrolan Personal
• Komentar dalam sistem manajemen proyek
• Panggilan
• Catatan/Komentar dalam dokumen

Memasukkan angka-angka, inilah yang kita dapatkan:

• 2 anggota tim = 6 utas komunikasi
• 3 anggota tim = 18 utas komunikasi
• 5 anggota tim = 60 utas komunikasi
• 8 anggota tim = 168 utas komunikasi
• 10 anggota tim = 270 utas komunikasi
• 15 anggota tim = 630 utas komunikasi
• 20 anggota tim = 1,140 utas komunikasi
• 30 anggota tim = 2,610 utas komunikasi
• 50 anggota tim = 7,350 utas komunikasi
• 100 anggota tim = 29,700 utas komunikasi

Menakutkan betapa cepat jumlah utas komunikasi tumbuh — dan jika kerja jarak jauh lebih mudah memungkinkan rapat yang lebih besar yang tidak akan praktis dalam kehidupan nyata, maka itu adalah pedang bermata dua.

Jadi, singkatnya, strategi sangat penting untuk menghindari ledakan komunikasi yang dapat terjadi dengan jumlah anggota tim yang relatif kecil sekalipun.

Dan sementara ide "strategi komunikasi" dapat terdengar kompleks dan megah, itu tidak harus demikian. Hal kunci adalah untuk menetapkan beberapa prinsip, menyatakan saluran komunikasi kunci, dan mungkin juga memberi tahu orang apa yang tidak boleh dilakukan.

Beberapa prinsip mendasar untuk dipertimbangkan:

• Jaga informasi tetap terbuka. Asumsikan bahwa semua yang perlu mudah ditemukan dan dapat dibagikan bulan/tahun dari sekarang. Pastikan semua orang di tim proyek memiliki akses ke semua informasi yang diperlukan, dan berhati-hatilah untuk menamai file dan dokumen dengan mengingat hal ini.
• Condong ke sisi kejelasan. Bayangkan seseorang yang baru bergabung dengan tim proyek. Dokumentasikan informasi dengan jelas dan ringkas untuk memastikan bahwa mereka dapat dengan mudah memahami keputusan-keputusan kritis.
• Jaga notulen rapat. Pastikan bahwa semua rapat penting dicatat dan mudah ditemukan.

Dalam hal saluran komunikasi, semakin sedikit, semakin baik. Kami akan menyarankan menguranginya menjadi berikut:

• Perangkat lunak manajemen proyek untuk memiliki diskusi khusus tugas.
• Rapat (tatap muka atau jarak jauh) dengan notulen rapat dan tempat untuk menemukan semua notulen rapat proyek di satu tempat.
• Dokumen: ini bisa berupa komentar dan diskusi dalam Google Docs atau alat khusus (mis. Figma untuk desain UX) yang memungkinkan komentar.

Juga dapat diterima untuk menambahkan obrolan grup ke daftar ini — tetapi kemudian harus dikelola dengan hati-hati karena dapat menjadi rapat besar sepanjang hari (dan setiap hari!) tanpa tujuan atau agenda yang jelas.

Manajer proyek perlu menetapkan aturan-aturan ini dengan jelas dan menjadi contoh yang bersinar tentang bagaimana berkolaborasi sambil kadang-kadang menggunakan tongkat (metaforis, bukan literal!) untuk memukul anggota tim proyek kembali ke komunikasi yang benar.

Pemikiran Akhir

Terlepas dari tingkat keahlian seseorang, selalu berharga untuk mundur dan melihat topik atau proses pada tingkat dasar. Jadi, dalam menyelami lebih dalam subjek manajemen proyek, kami telah mengidentifikasi prinsip-prinsip dasar kunci yang diperlukan untuk berhasil menjalankan proyek.

Setiap proyek harus memiliki manajer proyek: mereka memastikan bahwa proyek memiliki tujuan yang jelas, yang dipecah menjadi tugas-tugas yang harus diselesaikan untuk mencapai tujuan akhir. Manajer proyek kemudian perlu menugaskan anggota tim untuk setiap tugas. Bersama-sama, tim dapat mengidentifikasi jadwal waktu untuk setiap to-do individu dan untuk seluruh proyek.

Seringkali hal-hal yang tampaknya faktual yang dapat menyebabkan masalah, daripada subjek-subjek canggih, yang cenderung mendapat lebih banyak perhatian — misalnya, komunikasi. Inilah mengapa harus ada strategi komunikasi yang terdefinisi dengan baik baik dalam tim proyek maupun secara eksternal, dengan para pemangku kepentingan.

Manajemen proyek adalah subjek yang kompleks, jadi ini sama sekali bukan panduan yang lengkap. Masih ada beberapa faktor yang perlu dipertimbangkan yang belum kita bahas dalam gambaran awal ini, seperti anggaran, metode untuk menyelesaikan konflik antara opsi, dan seberapa jauh mengambil delegasi dalam proyek.