Evolusi Manajemen Proyek: Startup vs. Perusahaan

Startup bermain poker, perusahaan besar bermain catur.

Kutipan dari Don Dodge, Advokat Pengembang di Google ini, merangkum perbedaan antara menjadi manajer proyek di perusahaan rintisan versus perusahaan.

Startup memainkan permainan probabilitas. Seperti halnya pemain poker, yang terbaik secara konsisten menang, tetapi terkadang kalah dari amatir. Dalam manajemen proyek startup, Anda memerlukan eksekusi yang hebat, tetapi kenyataannya adalah bahwa bahkan pengusaha terbaik pun bisa gagal. Seperti halnya catur, sistem manajemen proyek perusahaan harus jauh lebih strategis, merencanakan dua langkah ke depan, dan mengambil risiko yang lebih kecil.

Tidak Semua Hitam Putih

Satu peringatan sebelum kita masuk ke topik ini adalah bahwa ada semua jenis perusahaan. Bisakah Anda menyebut perusahaan dengan 100 karyawan sebagai startup lagi? Bagaimana jika tumbuh menjadi 200 atau 300 karyawan? Terkadang Uber masih disebut sebagai startup di media, namun Uber kini memiliki 12.000 karyawan. Perbedaan lainnya adalah bahwa startup yang dimulai oleh mahasiswa sangat berbeda dari startup yang dimulai oleh pengusaha serial dengan pengalaman profesional lebih dari 20 tahun yang mungkin sebelumnya pernah bekerja di perusahaan tersebut dan telah membawa kembali praktik terbaik dari sana ke startup mereka.

Dengan demikian, ada banyak kasus mulai antara startup yang berlokasi bersama dengan 5 orang dan perusahaan multinasional dengan kantor di seluruh dunia. Meskipun artikel ini sebagian besar akan fokus pada dua ekstrem, ambil semuanya dengan sebutir garam dan pikirkan secara kritis apakah takeaways berlaku untuk situasi spesifik Anda.

Startup vs. Perusahaan

Dengan peringatan ini, mari kita coba mendefinisikan dua ekstrem untuk meletakkan dasar bagi diskusi kita. Untuk keperluan artikel ini, karakteristik dari sebuah startup adalah:

• Tim yang ditempatkan bersama (~1-50 karyawan) tempat Anda biasanya mengenal semua kolega Anda dengan namanya.
• Peran didefinisikan secara longgar.
• Co-founder sangat aktif dalam membuat sebagian besar keputusan.
• Perusahaan kehilangan uang dan tidak ada landasan panjang yang tersisa - kelangsungan hidup adalah masalah utama.

Di ujung lain spektrum, sebuah perusahaan akan terlihat seperti ini:

• Beberapa departemen dan lokasi.
• Anda hanya mengenal kolega langsung Anda dengan baik dan berinteraksi dengan segelintir orang dari departemen lain.
• Setiap orang memiliki tanggung jawab dan hierarki yang jelas.
• Perusahaan mungkin bersifat publik.
• Profitabilitas dan kelangsungan hidup jangka pendek sepertinya tidak menjadi perhatian.

Manajemen Proyek Permulaan

Manajer Proyek Manajer Produk

Secara teori, manajer proyek memiliki tanggung jawab yang berbeda secara substansial dengan manajer produk. Namun, dalam pengaturan startup, kedua peran tersebut biasanya saling terkait. Jika Anda seorang manajer proyek di sebuah perusahaan rintisan, Anda cenderung mengambil lebih banyak tugas di luar apa yang biasanya Anda lakukan di perusahaan.

Peluang untuk Manajer Proyek di Startup

Keputusan Cepat dan Dampak Besar

Dalam manajemen proyek startup, cukup mudah untuk membuat keputusan penting karena tidak ada banyak ketergantungan dalam hal proses, tim lain, klien, dll. Sesuatu yang penting seperti mempekerjakan rekan baru, mengubah beranda, menambahkan fitur baru atau memperpanjang tenggat waktu bisa menjadi satu pertemuan atau percakapan Slack. Ini memberdayakan manajer proyek dan menciptakan rasa otonomi.

Startup adalah tempat yang baik untuk mencoba ide-ide Anda dan tumbuh secara profesional. Anda dapat mencoba alat manajemen proyek baru yang dikatakan teman Anda bahwa mereka digunakan di perusahaannya. Bagaimana kalau pindah dari Scrum ke Kanban? Apa pun yang membuat Anda memberikan lebih cepat, jawab CEO. Apa pendapat Anda tentang penerapan chatbot baru yang memungkinkan kueri Google Analytics Anda dalam bahasa alami? Anda tidak memerlukan pengembang untuk itu, jelas CTO Anda saat makan siang. Dalam suatu perusahaan, semua ini akan menjadi inisiatif yang terpisah, besar, dan panjang yang dikelola oleh manajer proyek yang berdedikasi.

Semuanya Cepat Selesai

Siklus hidup pengembangan di perusahaan rintisan jauh lebih pendek daripada di perusahaan. Anda dapat membuat ide hari ini dan memiliki sesuatu dalam produksi minggu depan. Tidak banyak kode lawas, jadi pengembang tidak mengeluh bahwa basis kode perlu difaktorkan ulang dan dengan demikian dapat memberikan hasil dengan cepat. Ini memungkinkan Anda untuk berada dalam lingkaran umpan balik yang konstan dengan klien Anda dan benar-benar gesit.

Mudah Diadaptasi atau Diputar

Kecepatan pengiriman yang sama dan kurangnya ketergantungan memungkinkan tim startup untuk mengubah arah dengan cepat. Contoh yang terkenal adalah PayPal. Dalam 15 bulan pertama sejak diluncurkan sebagai solusi "kriptografi untuk ponsel", Paypal berputar 5 kali. Pasar pembayaran berubah dengan cepat dan PayPal mampu mengungguli eBay, yang mengembangkan solusi pembayarannya sendiri yang disebut Billpoint. Kelincahan PayPal memungkinkannya untuk memiliki daya tarik yang lebih baik dengan pembeli dan penjual eBay, yang akhirnya menyebabkan eBay mengakuisisi Paypal.

Proses Fluida

Biasanya, tidak banyak proses dan prosedur yang ketat tentang bagaimana orang-orang dalam startup beroperasi. Sebagian besar diserahkan kepada akal sehat dan negosiasi internal. Ini adalah salah satu alasan utama mengapa poin-poin yang disebutkan di atas benar-benar berfungsi, yaitu Anda dapat membuat keputusan lebih cepat dan tidak perlu banyak persetujuan. Tentu saja, ini tak terelakkan merupakan trade-off, yang menyebabkan masalah lain di kemudian hari seperti yang akan kita lihat nanti di artikel ini. Namun, untuk sebuah startup, yang mencari kecocokan pasar produk dan mencoba untuk mengalahkan pesaing yang didanai lebih baik dan lebih besar, ini adalah trade-off yang masuk akal untuk dimiliki.

Tantangan bagi Manajer Proyek di Startup

Tanggung Jawab Tidak Ditetapkan Sepenuhnya

Proses yang lancar memungkinkan keputusan yang cepat dan intuitif. Ini adalah pelayaran yang mulus ketika segala sesuatunya berjalan dengan baik, namun, sisi sebaliknya menghasilkan kesalahan dan lingkungan yang kacau. Dipecah, suatu proses pada dasarnya adalah daftar periksa - langkah-langkah apa yang perlu diambil untuk hasil yang akan dicapai. Proses biasanya muncul sebagai akibat dari beberapa kegagalan, ketika rekan kerja mulai saling menyalahkan karena tidak mengurus sesuatu dan perusahaan memulai penciptaan proses untuk merampingkan pengambilan keputusan ke dalam langkah-langkah yang jelas untuk mengurangi risiko masalah tersebut terjadi di masa depan.

Misalnya, rilis baru membuat situs web klien mogok. Semua orang di perusahaan tahu tentang rilis yang akan datang, namun tidak ada yang memberi tahu klien. Haruskah manajer proyek atau manajer akun utama menghubungi tim pengembangan klien? Haruskah CTO lebih proaktif? Setelah diskusi panas, orang-orang yang terlibat setuju bahwa lain kali karyawan tertentu akan bertanggung jawab atas tindakan tertentu sebelum dibebaskan, untuk memastikan hal ini tidak terjadi lagi.

Contoh ini adalah mikrokosmos tentang bagaimana sebuah startup berkembang menjadi sebuah korporasi. Ketika kompleksitas dalam startup tumbuh dari hari ke hari, keputusan seperti itu dibuat dan ambiguitas dihilangkan dari operasi sehari-hari. Namun, sampai keadaan itu tercapai, banyak kesalahan menyakitkan yang biasanya dilakukan.

Daya Tawar Lemah

Sebagai manajer proyek di startup, Anda cenderung terlibat dalam negosiasi eksternal. Co-founder mungkin membawa Anda ke pertemuan klien tahap selanjutnya untuk mewakili sisi teknis atau produk dari lapangan. Banyak pertanyaan dan persyaratan baru mungkin muncul selama pertemuan itu dan manajer proyek harus memastikan untuk tidak menyetujui kiriman terlalu cepat. Co-founder mungkin ingin memenangkan klien potensial dan menyetujui persyaratan mereka bahkan selama pertemuan, tidak menyadari sepenuhnya biaya item jaminan baru. Klien mungkin menggunakan fakta, bahwa startup Anda tidak memiliki rekam jejak yang panjang, untuk membuat Anda berkomitmen pada lebih dari yang dapat Anda berikan secara wajar.

Seorang manajer proyek harus mampu mendorong kembali dan meminta lebih banyak waktu untuk mengevaluasi persyaratan baru dengan tim pengembangan. Setelah Anda memiliki setidaknya perkiraan kasar dari tim, tunjukkan kepada rekan pendiri dan diskusikan jika masih masuk akal untuk menyetujui kondisi baru dari kesepakatan.

Pintasan Membuat Masalah Warisan

Dalam startup, sangat mudah untuk berada dalam mode MVP konstan. Sebagai manajer proyek, sangat menggoda untuk mendorong tim pengembangan agar menyetujui tenggat waktu yang lebih ketat dan mengambil jalan pintas untuk item peta jalan. Dengan co-founder yang terus-menerus mendukung Anda, tampaknya hampir perlu. Namun, seperti kata pepatah populer – dengan kekuatan besar datang tanggung jawab besar. Jika Anda menyalahgunakan kekuatan ini, pada akhirnya tim Anda akan mulai mengalami masalah warisan. Dan ini tidak berarti suatu saat di masa depan-Anda cenderung mengalami ini saat masih dalam mode startup.

Misalnya, katakanlah perusahaan Anda memutuskan untuk membuat halaman listingan produk. Itu harus memiliki beberapa filter untuk mempersempit hasil. Itu juga harus memiliki opsi penyortiran berdasarkan berbagai atribut. Perkiraan awal terlalu besar dan Anda mencoba mempersempit filter dan opsi penyortiran yang diperlukan. Akhirnya, ternyata sebagian besar perkiraan adalah keseluruhan sistem - mencari dan mengembalikan hasilnya. Anda bertanya apakah ada cara untuk memberikan versi yang lebih sederhana dengan lebih cepat. Salah satu pengembang menyarankan untuk menggunakan solusi pihak ketiga dengan langganan bulanan. Pengembang lain berbicara tentang masalah ketergantungan dan masalah warisan. Bagi Anda, kedengarannya sempurna, karena Anda mendapatkan MVP lebih cepat dan nantinya langganan dapat dibatalkan jika Anda memutuskan untuk membatalkan proyek. Master scrum setuju untuk menggunakan solusi pihak ketiga hanya jika mereka mendapat kesempatan untuk menulis ulang kode jika proyek tidak dihapus.

Kenyataannya adalah bahwa perjanjian ini hampir tidak pernah terpenuhi kecuali jika master scrum benar-benar melakukan tugas hutang teknis di sprint selanjutnya dan mempertahankannya ketika saatnya tiba. Jika umpan balik awal untuk halaman daftar adalah positif, reaksi alami bagi manajer proyek adalah mengembangkan fitur tambahan karena MVP hanyalah sebuah tes. 6 bulan kemudian, Anda mencapai titik di mana menambahkan fitur baru menjadi sangat mahal, tetapi refactoring bahkan lebih mahal, dan kemudian ada prioritas lain yang menjadi lebih penting dan menutupi niat awal.

Positif Palsu

Positif palsu dalam kasus manajemen proyek TI adalah ketika tim Anda mengembangkan MVP dan Anda mengambil umpan balik positif awal sebagai bukti kecocokan pasar produk. Itu bisa terjadi bahkan lebih awal dalam proses ketika pemangku kepentingan Anda memberi tahu Anda: “Saya telah mengajukan solusi kami kepada klien terbesar di industri kami dan mereka mengatakan bahwa mereka pasti akan membelinya dari kami.” Anda mengembangkannya, dan kemudian mereka tidak benar-benar membelinya dari Anda.

Positif palsu adalah tantangan besar, tetapi ada cara untuk menguranginya. Steve Cohn, Pendiri Validately, menyarankan agar Anda memvalidasi permintaan untuk solusi Anda. Ada tiga sinyal yang dapat membantu Anda:

1. Apakah klien Anda bersedia membelanjakan atau memberikan uang bahkan sebelum Anda memberikan solusi lengkap? Mendapatkan kontrak sebelum memberikan solusi mungkin merupakan validasi terbaik yang bisa Anda dapatkan.
2. Apakah klien Anda bersedia meluangkan waktu bersama Anda untuk mengembangkan solusi? Waktu adalah uang dan setiap orang memiliki tumpukan tugas yang tak ada habisnya. Semakin klien secara aktif terlibat dengan Anda dalam mencari tahu persyaratan, melibatkan rekan-rekannya yang lain ke dalam diskusi, menguji MVP secara menyeluruh dan memberikan banyak umpan balik, semakin besar kemungkinan Anda berada di jalur yang benar.
3. Apakah klien Anda bersedia menggunakan reputasi mereka untuk mempromosikan Anda? Baik itu di media sosial, di acara profesional atau dalam bentuk lainnya, ketika klien mempromosikan Anda, mereka meminjamkan reputasi mereka yang memvalidasi minat asli mereka.

Manajemen pemangku kepentingan

Pemangku kepentingan yang paling penting dari seorang manajer proyek dalam sebuah startup biasanya adalah co-founder. Seperti yang kita lihat di bagian peluang, co-founder dapat memungkinkan pengambilan keputusan cepat berdasarkan akal sehat. Namun, masalahnya adalah banyak co-founder cukup sering mengandalkan naluri mereka untuk mengambil keputusan. Hal ini terutama berlaku untuk co-founder yang telah bekerja di industri tertentu sebagai profesional di bidangnya dan sekarang telah memutuskan untuk membuat solusi TI untuk memecahkan masalah yang mereka hadapi sendiri dalam pekerjaan mereka.

Pengetahuan pasar yang mendalam sangat berguna untuk startup mana pun, namun, itu tidak bisa hanya diandalkan saat membuat peta jalan. Aspirasi sebagian besar startup adalah menciptakan solusi, yang akan berskala internasional. Bahkan jika ada banyak perusahaan di pasar yang sama, mereka tidak serta merta menyelesaikan masalah mereka dengan cara yang sama. Co-founder mungkin memiliki pengetahuan mendalam tentang bagaimana perusahaan sebelumnya melakukan sesuatu, tetapi itu tidak berarti pengetahuan tentang bagaimana perusahaan lain, terutama di negara lain, memecahkan tantangan yang sama.

Co-founder lebih sering berpegang pada keyakinan mereka dan membutuhkan manajer proyek independen untuk mengimbangi pandangan mereka. Merupakan tugas manajer proyek untuk mendidik para pendiri bersama tentang pentingnya pengambilan keputusan berbasis data dan pengembangan tangkas pada tahap awal penemuan produk.

Manajemen Proyek di Perusahaan

Manajer Proyek Manajer Produk

Saat startup menjadi dewasa dan menjadi perusahaan besar, peran berbagai posisi menjadi semakin jelas seiring dengan semakin spesifiknya pekerjaan. Bahkan di perusahaan, ada kasus di mana manajer proyek dan manajer produk tumpang tindih. Namun, manajer proyek cenderung lebih fokus pada aspek operasional proyek, sedangkan manajer produk bertanggung jawab atas pelaksanaannya.

Kantor Manajemen Proyek (PMO)

Seiring pertumbuhan perusahaan, portofolio proyek mereka tumbuh bersamanya. Manajer proyek baru bergabung dan bersama mereka membawa alat dan metodologi manajemen proyek baru. Awalnya, keadaan menjadi sedikit kacau dan kebutuhan akan kantor manajemen proyek (PMO) muncul. PMO memperhatikan siklus hidup manajemen proyek dan dapat menyebarkan atau menerapkan praktik terbaik di seluruh perusahaan.

Sebagai manajer proyek di suatu perusahaan, Anda harus berinteraksi dengan PMO. Setiap PMO berbeda, tetapi hal-hal yang mungkin Anda hadapi adalah:

• Mengisi berbagai formulir untuk inisiasi dan penutupan proyek.
• Mengajukan anggaran untuk ditinjau.
• Memberikan pembaruan kemajuan secara teratur.
• Mendapatkan sign-off pada tonggak atau berbagai langkah proses.

Untuk manajer proyek yang sudah melakukan banyak perencanaan dan pelacakan, banyak persyaratan PMO mungkin tampak seperti birokrasi yang tidak perlu, terutama jika mulai memperlambat proyek. Meskipun birokrasi ini dapat menjadi sumber frustrasi, manajer proyek yang proaktif dapat meminimalkan biaya overhead dan bahkan mengekstraksi nilai proyek dari PMO:

• Libatkan PMO sejak dini untuk mengetahui persyaratan pelaporan. Ini kemudian dapat dicocokkan dengan bahan yang dihasilkan selama pelaksanaan proyek untuk menghemat waktu.
• Jadilah juara proses. Berikan umpan balik kepada PMO tentang bagaimana proses dapat diubah untuk membuat kehidupan manajer proyek lebih mudah. Salah satu tujuan utama PMO adalah membantu manajer produk menjadi efektif.
• Manfaatkan PMO untuk bantuan saat proyek Anda mengalami masalah. PMO memiliki pandangan seluruh perusahaan dari semua proyek dan memiliki pengalaman dalam menangani berbagai masalah atau risiko yang muncul selama pelaksanaan proyek. Manfaatkan pengetahuan mereka untuk keuntungan Anda.

Peluang untuk Manajer Proyek di Perusahaan

Kredibilitas

Stabilitas dan perencanaan jangka panjang perusahaan menunjukkan kredibilitas kepada klien dan mitra. Orang-orang yang ingin terlibat dengan perusahaan Anda mencari rekam jejak yang baik - bahwa Anda dapat memenuhi janji Anda dan memiliki banyak pengalaman di bidang keahlian Anda. Ini adalah salah satu keuntungan terbesar yang dimiliki perusahaan dibandingkan startup. Itu membuatnya lebih mudah untuk menemukan klien dan mitra baru.

Kepercayaan ini memungkinkan Anda untuk memiliki lebih banyak integrasi dengan klien. Sebagai vendor teknologi Anda memungkinkan pelanggan Anda dan pada gilirannya, mereka mungkin menyesuaikan peta jalan mereka sendiri dengan Anda untuk dapat memberikan fitur baru sesegera mungkin. Hubungan seperti itu akan sangat sulit dicapai oleh startup karena startup sangat fluktuatif dan sulit dipercaya.

Lebih Mudah Mengumpulkan Persyaratan

Perusahaan memiliki kehadiran yang jauh lebih besar di pasar dibandingkan dengan startup. Seiring pertumbuhan perusahaan, dan pekerjaan menjadi semakin spesifik, semakin banyak profesional khusus yang dipekerjakan. Pada saat yang sama, untuk mempertahankan visi, semakin banyak eksekutif tingkat atas yang berpengalaman bergabung dengan perusahaan. Semua orang ini membawa wawasan pasar yang sangat besar, yang sangat mudah diakses dan digunakan oleh manajer proyek dalam mengumpulkan kebutuhan pengguna.

Ini bisa menjadi keuntungan besar untuk pengembangan pribadi PM juga. Memiliki banyak kontak yang Anda inginkan membantu Anda memanfaatkannya kapan pun Anda perlu memengaruhi pemangku kepentingan lain dalam perusahaan atau memastikan proyek Anda mendapat perhatian yang cukup lebih tinggi di peringkat perusahaan.

Kelompok kolega lain, yang dapat membantu Anda dengan persyaratan pengguna, dapat ditemukan di tim penjualan, manajemen akun, atau dukungan pelanggan. Orang-orang yang bekerja di sana memiliki paparan harian kepada klien dan dapat memberi Anda banyak umpan balik tentang kebutuhan dan frustrasi pengguna. Namun, selalu ingat konteks dari mana umpan balik ini berasal. Misalnya, tim dukungan klien mungkin berurusan dengan orang-orang yang menggunakan produk Anda sementara staf penjualan dan manajer akun dapat berurusan dengan eksekutif tingkat atas yang membuat keputusan pembelian tetapi tidak benar-benar menggunakan perangkat lunak Anda.

Bangun atau Beli

Sebuah peluang, yang tidak tersedia untuk startup, adalah pertumbuhan melalui merger dan akuisisi (M&A). 2018 telah melihat rekor jumlah transaksi M&A secara global. Sebagian besar dari tren ini adalah kesepakatan besar, seperti akuisisi Time Warner oleh AT&T baru-baru ini senilai $85 miliar. Namun, sebagian dari kesepakatan itu kecil dalam hal penilaian dan mereka menghasilkan pengembalian yang lebih baik, menurut sebuah studi oleh Harvard Business Review. Ada banyak perusahaan rintisan kecil dengan solusi satu titik di luar sana, dan manajer proyek di perusahaan harus mengingat bahwa terkadang masuk akal untuk membelinya daripada mencoba menyalin solusi mereka. Manajer proyek mungkin bukan pengambil keputusan untuk skenario seperti itu tetapi bisa menjadi orang yang membawa opsi ini ke meja.

Tantangan bagi Manajer Proyek di Perusahaan

Persetujuan Memakan Waktu Lebih Lama

Seiring pertumbuhan perusahaan, hierarki pelaporan tumbuh bersamanya. Berbagai departemen, proses, dan prosedur diterapkan. Pedoman merek dibuat. Risiko hukum, yang terkadang diabaikan dalam startup, harus diperhitungkan. Kutipan untuk siaran pers bersama dengan mitra baru dapat memakan waktu beberapa minggu untuk mengumpulkan semua persetujuan yang diperlukan.

Ini berarti bahwa seorang manajer proyek perlu merencanakan lebih awal dan lebih rajin. Namun, selalu ada situasi ad hoc dan tak terduga di mana Anda perlu mendapatkan semua persetujuan secepat mungkin. Memiliki hubungan yang baik dengan departemen lain dalam situasi seperti itu akan sangat bermanfaat. Seorang manajer proyek yang mampu membantu orang lain yang membutuhkan, sebagai imbalannya, akan lebih mungkin menerima bantuan dari rekan kerja.

miskomunikasi

"Asumsikan apa-apa" harus menjadi moto manajer proyek. Sebagai kompleksitas tumbuh dalam sebuah perusahaan, pekerjaan manajer proyek menjadi lebih sulit dalam hal menjaga komunikasi yang efektif di dalam dan di luar tim proyek. Mari kita lihat contoh skenario.

Tim Anda membutuhkan beberapa ikon baru untuk fitur baru yang sedang mereka kerjakan. Anda tiba-tiba bertemu dengan pemimpin tim desain saat makan siang dan memberi tahu dia tentang ikonnya. Dia mengatakan mereka sebenarnya sedang mengerjakan ikon serupa sekarang dan akan segera menyiapkannya. Selama stand-up hari berikutnya, Anda menyampaikan informasi kepada tim dan meminta mereka untuk menghubungi tim desain saat mereka membutuhkan ikon. Fitur yang dimaksud akan jatuh tempo dalam 4 minggu sehingga semua orang menganggap ikon akan siap pada saat itu. Pengembang menempatkan placeholder untuk ikon dan hanya selama QA seseorang memperhatikan bahwa mereka lupa untuk menggantinya. Mereka berebut untuk menghubungi tim desain, yang sebenarnya telah menunda pembuatan ikon tersebut karena tugas mendesak lainnya. Tidak ada seorang pun dari tim Anda yang menghubungi mereka dan pemimpin tim desain berasumsi bahwa Anda tidak memerlukan ikon lagi. Pedoman merek tidak memungkinkan Anda untuk pergi ke produksi dengan ikon acak dan tim Anda dibiarkan duduk di sana dengan fitur lengkap yang tidak dapat digunakan.

Pekerjaan seorang manajer proyek di suatu perusahaan dipenuhi dengan momen-momen seperti itu yang matang untuk miskomunikasi. Ada dua strategi yang dapat Anda terapkan di sini:

• Gunakan retrospektif untuk mencari tahu dengan tim apakah proses baru dapat membantu menghindari kesalahan seperti itu di masa depan. Mungkin menyimpan daftar semua dependensi dari tim lain dengan tinjauan mingguan dan tindak lanjut bisa menjadi jawaban dalam skenario ini.
• Berkomunikasi berlebihan. Secara umum, ini adalah strategi yang baik bagi manajer proyek untuk berkomunikasi lebih dari yang Anda pikir perlu Anda lakukan. Membiasakan check-in dengan orang-orang, meminta pembaruan cepat di saat-saat singkat itu sambil menunggu lift atau pergi ke mobil. Ini adalah cara yang baik untuk membuat lebih sedikit hal yang lolos dari celah.

Bergerak Lambat dan Jangan Hancurkan Apa Pun

Semakin tua basis kode, semakin sulit untuk mengembangkan fitur baru. Manajer proyek mungkin mulai memperhatikan bahwa perusahaan rintisan yang lebih kecil masuk ke pasar lebih cepat dengan inovasi baru dan mengungguli mereka.

Pada saat yang sama untuk menangkis tantangan dari perusahaan rintisan kecil, perusahaan juga harus waspada terhadap pesaing berukuran sama. Saat startup dewasa, solusi satu titik menjadi platform lengkap, yang memiliki berbagai fitur dan kasus penggunaan yang berbeda. Paritas fitur dengan perusahaan pesaing besar lainnya menjadi masalah.

Sebagai manajer proyek di suatu perusahaan, Anda harus membuat keputusan, apakah akan terlibat dalam inovasi dan menciptakan proposisi nilai baru untuk klien Anda atau mencoba mencapai paritas fitur dengan pesaing Anda. Namun, sebagian besar waktu Anda tidak akan dapat membuat keputusan seperti itu sendiri dan Anda harus bekerja untuk mempengaruhi banyak pemangku kepentingan untuk membuat keputusan ini untuk Anda. Ini bisa membuat frustrasi, terutama jika pemangku kepentingan tersebut kurang paham digital, dan mereka tidak terbiasa dengan fitur yang Anda coba yakinkan untuk mereka bangun.

Kesimpulan

Dalam artikel ini, kami membahas bagaimana mekanisme yang mendasari startup dan perusahaan menciptakan peluang dan tantangan bagi manajer proyek. Saat memulai, seorang manajer proyek cenderung mengambil banyak fungsi sebagai manajer produk, tetapi kedua peran tersebut dipisahkan dengan jelas dalam suatu perusahaan. Ingatlah bahwa setiap perusahaan adalah unik dan tidak semua topik yang dibahas akan berlaku untuk setiap situasi, sehingga lingkungan yang bernuansa akan membutuhkan manajer proyek untuk memanfaatkan kualitas dan keterampilan manajemen proyek yang berbeda.

Singkatnya, startup memiliki proses yang lancar dan manajer proyek mampu membuat keputusan cepat dan memiliki dampak besar pada perusahaan secara keseluruhan. Siklus hidup pengembangan jauh lebih pendek, yang memungkinkan manajer proyek tetap gesit dan mampu beradaptasi dengan perubahan kondisi pasar.

Seorang manajer proyek di sebuah startup juga menghadapi tantangan yang cukup besar. Tanggung jawab yang tidak sepenuhnya ditentukan dapat menyebabkan banyak masalah seiring pertumbuhan startup. Klien dan co-founder mungkin mendorong manajer proyek untuk berkomitmen lebih dari yang dapat diberikan oleh tim secara wajar. Setelah itu, berbagai jalan pintas dapat dimasukkan ke dalam peta jalan, yang mengarah pada masalah warisan di masa depan. Co-founder dari sebuah startup sangat aktif dalam mendefinisikan roadmap. Keyakinan mereka, bagaimanapun, dapat menyebabkan kesalahan positif dan manajer proyek perlu didorong oleh data dan gesit untuk mengurangi tantangan ini.

Di sisi perusahaan, seorang manajer proyek dapat memanfaatkan kredibilitas dan rekam jejak perusahaan untuk menjalin hubungan kerja yang baik dengan pihak eksternal. Lebih mudah untuk mengumpulkan persyaratan dari eksekutif dan kolega berpengalaman, yang berinteraksi dengan klien secara teratur. Terakhir, kantor manajemen proyek, betapapun terbatasnya, dapat membantu mengurangi masalah dan mengelola risiko yang muncul selama pelaksanaan proyek.

Tantangan dalam manajemen proyek perusahaan pasti terkait dengan ukuran perusahaan. Berbagai persetujuan dan persetujuan berarti bahwa manajer proyek perlu merencanakan dengan sangat cermat dan melibatkan PMO untuk menghindari memperlambat pelaksanaan proyek. Miskomunikasi kemungkinan akan terjadi karena semakin banyak orang dan departemen yang terlibat dan ini harus dikurangi dengan menempatkan proses yang tepat pada tempatnya. Terakhir, siklus hidup pengembangan menjadi lebih lama, dan manajer proyek harus bersaing baik dengan perusahaan rintisan maupun perusahaan lain di pasar.

Inilah perbedaan inti, antara dua lingkungan tempat manajer proyek bekerja. Dengan memahami tantangan ini, kita dapat memprediksi dengan lebih baik apa yang mungkin kita hadapi saat berpindah dari satu lingkungan ke lingkungan lainnya.