Proje Yönetiminin Evrimi: Startup'lara Karşı İşletmeler

Startup'lar poker oynar, büyük şirketler satranç oynar.

Google'da Geliştirici Avukatı Don Dodge tarafından yapılan bu alıntı, bir girişimde proje yöneticisi olmakla bir kuruluşta proje yöneticisi olmak arasındaki farkları özetliyor.

Startup'lar bir olasılık oyunu oynuyorlar. Poker oyuncularında olduğu gibi, en iyiler sürekli olarak kazanır, ancak zaman zaman amatörlere kaybeder. Başlangıç ​​proje yönetiminde harika bir uygulamaya ihtiyacınız var, ancak gerçek şu ki en iyi girişimciler bile başarısız olabilir. Satrançta olduğu gibi, bir kurumsal proje yönetim sisteminin çok daha stratejik olması, iki adım ilerisini planlaması ve daha az risk alması gerekir.

Hepsi Siyah Beyaz Değil

Bu konuya girmeden önce bir uyarı, her türden şirket olduğudur. 100 çalışanı olan bir şirkete artık startup diyebilir misiniz? Ya 200 veya 300 çalışana çıkarsa? Bazen Uber'e medyada hala startup deniyor, ancak Uber'in şu anda 12.000 çalışanı var. Diğer bir ayrım ise, lisans öğrencileri tarafından başlatılan bir girişimin, 20 yılı aşkın mesleki deneyime sahip, daha önce işletmede çalışmış ve oradan en iyi uygulamaları girişimlerine geri getirmiş olabilecek seri girişimcilerin başlattığı girişimden çok farklı olmasıdır.

Bu nedenle, 5 kişilik ortak konumlu bir girişim ile dünyanın her yerinde ofisleri olan çok uluslu bir şirket arasında değişen birçok durum vardır. Bu makale çoğunlukla iki uç noktaya odaklanacak olsa da, hepsini bir tuz tanesi ile alın ve paket servislerin sizin özel durumunuz için geçerli olup olmadığını eleştirel olarak düşünün.

Startup'lar ve İşletmeler

Bu uyarıyı ortadan kaldırarak, tartışmamıza zemin hazırlamak için iki uç noktayı tanımlamaya çalışalım. Bu makalenin amaçları doğrultusunda, bir girişimin özellikleri şunlardır:

• Genellikle tüm meslektaşlarınızı isimleriyle tanıyacağınız ortak bir ekip (~1-50 çalışan).
• Roller gevşek bir şekilde tanımlanmıştır.
• Kurucu ortaklar, kararların çoğunda çok aktiftir.
• Şirket para kaybediyor ve uzun bir pist kalmadı - hayatta kalmak büyük bir sorun.

Yelpazenin diğer ucunda bir işletme şöyle görünür:

• Birden fazla departman ve konum.
• Yalnızca doğrudan iş arkadaşlarınızı iyi tanıyorsunuz ve diğer departmanlardan bir avuç insanla etkileşim kuruyorsunuz.
• Herkesin net sorumlulukları ve hiyerarşileri vardır.
• Şirket halka açık olabilir.
• Karlılık ve kısa vadeli hayatta kalma muhtemelen bir endişe kaynağı değildir.

Başlangıç ​​​​Proje Yönetimi

Proje Yöneticisi ≈ Ürün Yöneticisi

Teoride, proje yöneticilerinin ürün yöneticilerine karşı önemli ölçüde farklı sorumlulukları vardır. Ancak, bir başlangıç ​​ortamında iki rol genellikle iç içe geçer. Bir girişimde proje yöneticisiyseniz, bir kuruluşta geleneksel olarak yapacağınızın dışında çok daha fazla görev üstlenmeniz olasıdır.

Startup'larda Proje Yöneticileri için Fırsatlar

Hızlı Kararlar ve Büyük Etki

Başlangıç ​​proje yönetiminde, süreçler, diğer ekipler, müşteriler vb. açısından çok fazla bağımlılık olmadığı için önemli kararlar almak oldukça kolaydır. Yeni bir iş arkadaşı işe almak, ana sayfayı değiştirmek, yeni özellikler eklemek veya bir son tarihi uzatmak bir toplantı veya Gevşek bir konuşma olabilir. Bu, bir proje yöneticisi için güçlendiricidir ve bir özerklik duygusu yaratır.

Başlangıç, fikirlerinizi denemek ve profesyonel olarak büyümek için iyi bir yerdir. Arkadaşınızın size şirketinde kullandığını söylediği yeni bir proje yönetim aracını deneyebilirsiniz. Scrum'dan Kanban'a geçmeye ne dersiniz? Sizi daha hızlı teslim eden her neyse, diye yanıtlıyor CEO. Google Analytics'inizi doğal dilde sorgulamanıza olanak tanıyan bu yeni sohbet robotunu uygulamaya geçirme konusunda ne düşünüyorsunuz? Bunun için bir geliştiriciye ihtiyacınız yok, diye açıklıyor CTO'nuz öğle yemeğinde. Bir kuruluşta, bunların tümü, özel bir proje yöneticisi tarafından yönetilen ayrı, büyük ve uzun girişimler olacaktır.

İşler Hızlı Yapılır

Startup'larda geliştirme yaşam döngüsü, işletmelere göre çok daha kısadır. Bugün fikir yürütebilir ve gelecek hafta üretimde bir şeyler olabilir. Çok fazla eski kod yok, bu nedenle geliştiriciler, kod tabanının yeniden düzenlenmesi gerektiğinden şikayet etmiyorlar ve bu nedenle sonuçları hızlı bir şekilde sunabiliyorlar. Bu, müşterilerinizle sürekli bir geri bildirim döngüsü içinde olmanızı ve gerçekten çevik olmanızı sağlar.

Uyarlanması veya Döndürülmesi Kolay

Aynı teslimat hızı ve bağımlılık eksikliği, bir başlangıç ​​ekibinin rotayı hızla değiştirmesine olanak tanır. Ünlü bir örnek PayPal'dır. “Telefonlar için kriptografi” çözümü olarak başlangıcından bu yana ilk 15 ayda Paypal, 5 kez pivot yaptı. Ödeme piyasası hızla değişiyordu ve PayPal, Billpoint adlı kendi ödeme çözümünü geliştiren eBay'i geride bırakabildi. PayPal'ın çevikliği, eBay alıcıları ve satıcıları ile daha iyi bir çekişe sahip olmasını sağladı ve sonunda eBay'in Paypal'ı almasına yol açtı.

Akışkan Prosesleri

Genellikle, bir startup içindeki insanların nasıl çalıştığına dair çok fazla titiz süreç ve prosedür yoktur. Birçoğu sağduyuya ve iç müzakereye bırakıldı. Bu, yukarıda bahsedilen noktaların gerçekten işe yaramasının en önemli nedenlerinden biridir, yani daha hızlı karar verebilirsiniz ve sayısız onaya ihtiyaç duymazsınız. Tabii ki, bu makalenin ilerleyen bölümlerinde göreceğimiz gibi, ileride başka sorunlara neden olan kaçınılmaz olarak bir değiş tokuştur. Bununla birlikte, ürün-pazar uyumu arayan ve daha iyi finanse edilen ve daha büyük rakipleri geride bırakmaya çalışan bir girişim için, sahip olmak makul bir takastır.

Startup'larda Proje Yöneticileri için Zorluklar

Sorumluluklar Tam Olarak Tanımlanmadı

Akışkan bir süreç, hızlı ve sezgisel kararlar alınmasını sağlar. Bu, işler iyi gittiğinde sorunsuz bir seyirdir, ancak ters taraf hatalara ve kaotik bir ortama neden olur. Parçalanmış, bir süreç aslında bir kontrol listesidir - bir sonuca ulaşılması için hangi adımların atılması gerekir. Süreçler genellikle bazı başarısızlıkların bir sonucu olarak ortaya çıkar, iş arkadaşları bir şeyi umursamadıkları için birbirlerini suçlamaya başladığında ve bir şirket, bu tür sorunların meydana gelme riskini azaltmak için karar vermeyi açıkça tanımlanmış adımlara dönüştürmek için bir süreç yaratmaya başladığında ortaya çıkar. gelecek.

Örneğin, yeni bir sürüm bir müşterinin web sitesini çökertti. Şirketteki herkes yaklaşan sürümden haberdardı, ancak kimse müşteriyi bilgilendirmedi. Proje yöneticisi veya kilit müşteri yöneticisi müşterinin geliştirme ekibiyle iletişime geçmeli miydi? CTO daha proaktif olmalı mıydı? Hararetli bir tartışmadan sonra, ilgili kişiler, bir dahaki sefere, bunun tekrar olmamasını sağlamak için serbest bırakılmadan önceki belirli eylemlerden belirli çalışanların sorumlu olacağı konusunda hemfikirdir.

Bu örnek, bir girişimin nasıl bir şirkete dönüştüğünün bir mikrokozmosudur. Girişimdeki karmaşıklık gün geçtikçe arttıkça, bu tür kararlar alınır ve günlük operasyonlardaki belirsizlik ortadan kalkar. Ancak bu duruma ulaşılıncaya kadar genellikle birçok acı verici hata yapılır.

Zayıf Pazarlık Gücü

Bir girişimde proje yöneticisi olarak, dış görüşmelere katılma olasılığınız daha yüksektir. Kurucu ortaklar, sahanın teknik veya ürün tarafını temsil etmek için sizi daha sonraki aşamadaki müşteri toplantılarına götürüyor olabilir. Bu toplantı sırasında birçok soru ve yeni gereksinimler ortaya çıkabilir ve bir proje yöneticisi, çıktılar üzerinde çok erken anlaşmaya varmadığından emin olmalıdır. Kurucu ortaklar, potansiyel müşteriyi kazanma konusunda endişeli olabilir ve toplantı sırasında bile, yeni birikmiş iş kalemlerinin maliyetini tam olarak anlamadan koşullarını kabul edebilirler. Müşteri, girişiminizin uzun bir geçmişe sahip olmadığı gerçeğini, makul bir şekilde sunabileceğinizden daha fazlasını taahhüt etmenizi sağlamak için kullanıyor olabilir.

Bir proje yöneticisi, geliştirme ekibiyle yeni gereksinimleri değerlendirmek için geri adım atabilmeli ve daha fazla zaman isteyebilmelidir. Ekipten en azından kabaca tahminler aldıktan sonra, bunları kurucu ortaklara sunun ve anlaşmanın yeni koşullarını kabul etmek hala mantıklıysa bir tartışma yapın.

Kısayollar Eski Sorunlar Yaratıyor

Bir başlangıçta, sürekli MVP modunda olmak çok kolaydır. Bir proje yöneticisi olarak, geliştirme ekibini daha sıkı teslim tarihlerini kabul etmeye ve yol haritası öğeleri için kısayollar almaya zorlamak çok cezbedicidir. Kurucu ortaklar sürekli arkanızdayken, neredeyse gerekli görünüyor. Ancak, popüler bir sözde olduğu gibi – büyük güç büyük sorumluluk getirir. Bu gücü kötüye kullanırsanız, sonunda ekibiniz eski sorunlarla karşılaşmaya başlayacaktır. Ve bu, gelecekte bir zaman olacağı anlamına gelmez – muhtemelen hala başlangıç ​​modundayken bunlarla karşılaşacaksınız.

Örneğin, şirketinizin bir ürün listeleme sayfası oluşturmaya karar verdiğini varsayalım. Sonuçları daraltmak için birden fazla filtreye sahip olması gerekir. Ayrıca çeşitli niteliklere göre sıralama seçeneklerine sahip olması gerekir. İlk tahmin çok büyük ve gerekli filtreleri ve sıralama seçeneklerini daraltmaya çalışıyorsunuz. Sonunda, tahminin çoğunluğunun tüm sistem olduğu ortaya çıktı - arama ve sonuçları döndürme. Daha basit bir sürümü daha hızlı sunmanın bir yolu olup olmadığını soruyorsunuz. Bir geliştirici, aylık abonelikle üçüncü taraf bir çözüm kullanmanızı önerir. Diğer geliştiriciler, bağımlılık sorunları ve eski endişeler hakkında konuşur. Sizin için mükemmel görünüyor, çünkü MVP'nizi daha hızlı alırsınız ve daha sonra projeyi rafa kaldırmaya karar verirseniz abonelik iptal edilebilir. Scrum yöneticisi, üçüncü taraf çözümünü yalnızca proje hurdaya çıkmazsa kodu yeniden yazma şansı bulursa kullanmayı kabul eder.

Gerçek şu ki, scrum master daha sonraki bir sprintte teknik bir borç görevi üstlenmedikçe ve zamanı geldiğinde onu savunmadıkça bu anlaşma neredeyse hiçbir zaman yerine getirilmez. Listeleme sayfası için ilk geri bildirim olumluysa, proje yöneticisinin doğal tepkisi, MVP yalnızca bir test olduğu için ek özellikler geliştirmektir. 6 ay sonra, yeni özellikler eklemenin çok maliyetli olduğu, ancak yeniden düzenlemenin daha da maliyetli olduğu bir noktaya ulaşırsınız ve daha sonra daha önemli hale gelen ve başlangıçtaki amacı gölgede bırakan başka öncelikler vardır.

Yanlış Pozitifler

BT proje yönetimi durumunda yanlış bir pozitif, ekibiniz bir MVP geliştirdiğinde ve ürün-pazar uygunluğunun kanıtı olarak ilk olumlu geri bildirimi aldığınızda olur. Paydaşınız size "Çözümümüzü sektörümüzdeki en büyük müşteriye sundum ve bunu kesinlikle bizden alacaklarını söylediler." Onu geliştirirsiniz ve sonra aslında sizden satın almazlar.

Yanlış pozitifler büyük bir zorluktur, ancak bunları azaltmanın bir yolu vardır. Validately'nin Kurucusu Steve Cohn, çözümünüz için talebi doğrulamanız gerektiğini önerir. Size yardımcı olabilecek üç sinyal vardır:

1. Müşterileriniz, siz tam çözümü sunmadan önce bile para harcamaya veya taahhütte bulunmaya istekli mi? Çözümü teslim etmeden önce bir sözleşme almak, muhtemelen alabileceğiniz en iyi doğrulamadır.
2. Müşterileriniz çözümü geliştirmek için sizinle zaman harcamak istiyor mu? Vakit nakittir ve herkesin sonsuz bir görev birikimi vardır. Bir müşteri gereksinimleri belirleme, diğer meslektaşlarını tartışmaya dahil etme, bir MVP'yi kapsamlı bir şekilde test etme ve bol miktarda geri bildirim sağlama konusunda sizinle ne kadar aktif olarak ilgilenirse, doğru yolda olma olasılığınız o kadar artar.
3. Müşterileriniz itibarlarını sizi tanıtmak için kullanmaya istekli mi? İster sosyal medyada, ister profesyonel bir etkinlikte veya başka bir biçimde, bir müşteri sizi tanıtırken, gerçek ilgilerini doğrulayan itibarlarını size ödünç veriyorlar.

Paydaş yönetimi

Bir proje yöneticisinin bir startup'taki en önemli paydaşları genellikle kurucu ortaklardır. Fırsatlar bölümünde gördüğümüz gibi, kurucu ortaklar sağduyuya dayalı hızlı karar vermeyi sağlayabilir. Bununla birlikte, sorun şu ki, birçok kurucu ortak karar verme konusunda çoğunlukla içgüdülerine güveniyor. Bu, özellikle belirli bir sektörde alanın profesyonelleri olarak çalışmış ve işlerinde karşılaştıkları bir sorunu çözmek için bir BT çözümü oluşturmaya karar vermiş kurucu ortaklar için geçerlidir.

Derin pazar bilgisi, herhangi bir girişim için son derece yararlıdır, ancak bir yol haritası oluştururken yalnızca ona güvenilemez. Çoğu girişimin arzusu, uluslararası ölçekte ölçeklenecek bir çözüm yaratmaktır. Aynı pazarda birden fazla şirket olsa bile, sorunlarını aynı şekilde çözmeleri gerekmez. Kurucu ortak, önceki şirketinin işleri nasıl yaptığı konusunda samimi bilgiye sahip olabilir, ancak bu, diğer şirketlerin, özellikle diğer ülkelerdeki aynı zorlukları nasıl çözdüğü hakkında bilgi sahibi olduğu anlamına gelmez.

Kurucu ortaklar genellikle inançlarına bağlı kalırlar ve görüşlerini dengelemek için bağımsız bir proje yöneticisine ihtiyaç duyarlar. Ürün keşfinin ilk aşamalarında veriye dayalı karar verme ve çevik geliştirmenin önemi konusunda kurucu ortakları eğitmek bir proje yöneticisinin görevidir.

İşletmelerde Proje Yönetimi

Proje Yöneticisi ≠ Ürün Yöneticisi

Bir girişim olgunlaştıkça ve büyük bir girişim haline geldikçe, iş daha spesifik hale geldikçe farklı pozisyonların rolleri giderek daha fazla tanımlanır. Bir işletmede bile proje yöneticileri ile ürün yöneticilerinin örtüştüğü durumlar vardır. Bununla birlikte, proje yöneticisi bir projenin operasyonel yönlerine daha fazla odaklanma eğilimindedir, oysa ürün yöneticisi yürütmeden sorumludur.

Proje Yönetim Ofisi (PMO)

Bir şirket büyüdükçe, proje portföyü de onunla birlikte büyür. Yeni proje yöneticileri katılır ve onlarla birlikte yeni proje yönetimi araçları ve metodolojileri getirir. Başlangıçta işler biraz karışır ve bir proje yönetim ofisine (PMO) ihtiyaç duyulur. PMO, proje yönetimi yaşam döngüsü ile ilgilenir ve en iyi uygulamaları tüm şirkete yayabilir veya uygulayabilir.

Bir kuruluşta proje yöneticisi olarak, bir PMO ile arayüz oluşturmanız gerekecektir. Her PMO farklıdır, ancak karşılaşabileceğiniz şeylerden bazıları şunlardır:

• Proje başlatma ve kapatma için çeşitli formların doldurulması.
• Bütçeleri gözden geçirilmek üzere gönderme.
• Düzenli ilerleme güncellemeleri sağlamak.
• Kilometre taşları veya çeşitli süreç adımlarında imzaların alınması.

Halihazırda çok fazla planlama ve takip yapan bir proje yöneticisi için, özellikle projeyi yavaşlatmaya başlarsa, PMO gereksinimlerinin çoğu gereksiz bürokrasi gibi görünebilir. Bu bürokrasi bir hayal kırıklığı kaynağı olsa da, proaktif bir proje yöneticisi ek yükü en aza indirebilir ve hatta PMO'dan proje için değer elde edebilir:

• Raporlama gereksinimlerini anlamak için PMO'yu erken devreye alın. Bunlar daha sonra zaman kazanmak için proje yürütme sırasında üretilen malzemelerle eşleştirilebilir.
• Bir süreç şampiyonu olun. Proje yöneticilerinin hayatını kolaylaştırmak için süreçlerin nasıl değiştirilebileceği konusunda PMO'ya geri bildirim sağlayın. PMO'nun ana hedeflerinden biri, ürün yöneticisinin etkili olmasına yardımcı olmaktır.
• Projeniz sorunla karşılaştığında yardım için PMO'dan yararlanın. PMO, tüm projelere şirket çapında bir bakış açısına sahiptir ve proje yürütme sırasında ortaya çıkan çeşitli sorunlar veya risklerle başa çıkma konusunda deneyime sahiptir. Onların bilgisini kendi yararınıza kullanın.

İşletmelerde Proje Yöneticileri için Fırsatlar

güvenilirlik

İşletmelerin istikrarı ve uzun vadeli planlaması, müşterilere ve ortaklara güvenilirlik gösterir. Şirketinizle bağlantı kurmak isteyen kişiler, verdiğiniz sözleri tutabileceğiniz ve uzmanlık alanınızda çok fazla deneyime sahip olduğunuz iyi bir sicile sahip olmak isterler. Bu, bir işletmenin yeni başlayanlara göre sahip olduğu en büyük avantajlardan biridir. Yeni müşteriler ve ortaklar bulmayı kolaylaştırır.

Bu güven, istemciyle daha fazla entegrasyona sahip olmanızı sağlar. Bir teknoloji satıcısı olarak müşterilerinize olanak sağlıyorsunuz ve karşılığında onlar da yeni özellikleri mümkün olan en kısa sürede sunabilmek için kendi yol haritalarını sizinkine göre ayarlayabilirler. Yeni başlayanlar çok değişken ve güvenmek zor olduğundan, böyle bir ilişki bir girişimin başarması çok zor olacaktır.

Gereksinimleri Toplamak Daha Kolay

Bir girişim, bir girişime kıyasla pazarda çok daha büyük bir varlığa sahiptir. Bir şirket büyüdükçe ve iş giderek daha spesifik hale geldikçe, giderek daha fazla uzman profesyonel işe alınmaktadır. Aynı zamanda, vizyonu sürdürmek için giderek daha fazla deneyimli üst düzey yönetici şirkete katılıyor. Tüm bu insanlar, bir proje yöneticisinin erişmesi ve kullanıcı gereksinimlerini toplamada kullanması çok kolay olan muazzam bir pazar bilgisi sağlar.

Bu, PM'nin kişisel gelişimi için de büyük bir avantaj olabilir. Çok sayıda bağlantıya sahip olmak, kuruluştaki diğer paydaşları etkilemeniz veya projenizin şirket sıralamasında yeterince dikkat çekmesini sağlamanız gerektiğinde onlarla bağlantı kurmanıza yardımcı olur.

Kullanıcı gereksinimleri konusunda size yardımcı olabilecek başka bir meslektaş grubu, satış, hesap yönetimi veya müşteri destek ekiplerinde bulunabilir. Orada çalışan insanlar, müşterilere günlük olarak maruz kalmaktadır ve size kullanıcı ihtiyaçları ve hayal kırıklıkları hakkında birçok geri bildirim sağlayabilir. Ancak, bu geri bildirimin geldiği bağlamı daima aklınızda bulundurun. Örneğin, müşteri destek ekibi ürününüzü kullanan kişilerle ilgilenirken, satış görevlileri ve hesap yöneticileri satın alma kararlarını veren ancak aslında yazılımınızı kullanmayan üst düzey yöneticilerle ilgilenebilir.

İnşa Et veya Satın Al

Yeni başlayanlar için mevcut olmayan bir fırsat, birleşme ve satın almalar (M&A) yoluyla büyümedir. 2018 şimdiden dünya çapında rekor miktarda M&A anlaşması gördü. Bu eğilimin büyük bir kısmı, AT&T'nin Time Warner'ı 85 milyar dolara satın alması gibi mega anlaşmalardır. Ancak, Harvard Business Review tarafından yapılan bir araştırmaya göre, anlaşmaların bir kısmı değerleme açısından küçük ve daha iyi getiri sağlıyor. Tek nokta çözümleri olan birçok küçük girişim var ve işletmelerdeki proje yöneticileri bazen çözümlerini kopyalamaya çalışmak yerine onları satın almanın mantıklı olabileceğini unutmamalıdır. Bir proje yöneticisi böyle bir senaryo için karar verici olmayabilir, ancak bu seçeneği masaya yatıran kişi olabilir.

İşletmelerde Proje Yöneticileri için Zorluklar

Onaylar Daha Uzun Sürer

Bir şirket büyüdükçe, onunla birlikte bir raporlama hiyerarşisi de büyür. Birden fazla departman, süreç ve prosedür devreye girer. Marka yönergeleri oluşturulur. Startuplarda bazen gözden kaçan yasal riskler hesaba katılmalıdır. Yeni bir ortakla ortak basın açıklaması için bir teklifin, gerekli tüm imzaları toplaması birkaç hafta sürebilir.

Bu, bir proje yöneticisinin çok daha önceden plan yapması ve daha gayretli olması gerektiği anlamına gelir. Ancak, tüm onayları olabildiğince hızlı almanız gereken geçici ve beklenmedik durumlar her zaman vardır. Bu gibi durumlarda diğer departmanlarla iyi ilişkilere sahip olmak çok değerli olacaktır. İhtiyacı olan başkalarına yardım edebilen bir proje yöneticisi, karşılığında meslektaşlarından daha fazla iyilik alacaktır.

iletişimsizlik

“Hiçbir şey varsaymayın” bir proje yöneticisinin sloganı olmalıdır. Bir şirket içinde karmaşıklık arttıkça, proje yöneticisinin işi, proje ekibi içinde ve dışında etkili iletişimi sürdürmek açısından daha zor hale gelir. Örnek bir senaryoya bakalım.

Ekibinizin üzerinde çalıştıkları yeni özellikler için birkaç yeni simgeye ihtiyacı var. Öğle yemeğinde beklenmedik bir şekilde tasarım ekibi lideriyle tanışır ve ona ikonlardan bahsedersiniz. Aslında şu anda benzer simgeler üzerinde çalıştıklarını ve yakında hazır olacaklarını söylüyor. Ertesi günkü stand-up sırasında, bilgileri ekibe aktarır ve simgelere ihtiyaç duyacakları zaman tasarım ekibine ulaşmalarını söylersiniz. Söz konusu özellikler 4 hafta içinde kullanıma sunulacak, bu nedenle herkes simgelerin o sırada hazır olacağını varsayıyor. Geliştiriciler simgeler için yer tutucular koyarlar ve yalnızca QA sırasında biri bunları değiştirmeyi unuttuğunu fark eder. Diğer acil görevler nedeniyle bu simgelerin oluşturulmasını gerçekten erteleyen tasarım ekibine ulaşmak için çabalıyorlar. Ekibinizden hiç kimse onlara ulaşmadı ve tasarım ekibi lideri artık simgelere ihtiyacınız olmayacağını varsaydı. Marka yönergeleri, rastgele simgelerle üretime geçmenize izin vermiyor ve ekibiniz, bunları dağıtamayan tamamlanmış özelliklerle orada oturuyor.

Bir işletmedeki proje yöneticisinin işi, iletişimsizlik için olgunlaşmış anlarla doludur. Burada uygulayabileceğiniz iki strateji vardır:

• Yeni bir sürecin gelecekte bu tür hatalardan kaçınmaya yardımcı olup olmayacağını ekiple birlikte anlamak için retrospektifi kullanın. Belki de haftalık inceleme ve takiplerle diğer takımlardan tüm bağımlılıkların bir listesini tutmak bu senaryoda cevap olabilir.
• Aşırı iletişim. Bir proje yöneticisinin ihtiyaç duyduğunuzu düşündüğünüzden daha fazla iletişim kurması genellikle iyi bir stratejidir. Asansör beklerken ya da arabaya giderken o kısa anlarda insanlarla check-in yapma, hızlı güncellemeler isteme alışkanlığına girmek. Daha az şeyin çatlaklardan kaymasını sağlamanın iyi bir yolu.

Yavaş Hareket Edin ve Hiçbir Şeyi Kırmayın

Kod tabanı ne kadar eski olursa, yeni özellikler geliştirmek o kadar zorlaşır. Bir proje yöneticisi, daha küçük girişimlerin yeni inovasyonlarla daha hızlı pazara girdiğini ve onları geride bıraktığını fark etmeye başlayabilir.

İşletmeler, küçük girişimlerin zorluklarını savuştururken aynı zamanda benzer büyüklükteki rakiplere karşı da dikkatli olmalıdır. Başlangıçlar olgunlaştıkça, tek noktalı çözümler, çeşitli farklı özelliklere ve kullanım durumlarına sahip tam teşekküllü platformlar haline gelir. Diğer büyük rakip işletmelerle özellik paritesi bir sorun haline gelir.

Bir kuruluşta proje yöneticisi olarak, ister inovasyonla meşgul olmak ve müşterileriniz için yeni değer teklifleri yaratmak, ister rakiplerinizle özellik eşitliği sağlamaya çalışmak konusunda kararlar almanız gerekecektir. Ancak çoğu zaman bu tür kararları kendiniz alamayacaksınız ve bu kararları sizin yerinize vermeleri için birden fazla paydaşı etkilemek için çalışmak zorunda kalacaksınız. Bu, özellikle bu paydaşlar dijital olarak daha az bilgiliyse ve onları oluşturmaya ikna etmeye çalıştığınız özelliklere aşina değilse, sinir bozucu olabilir.

Çözüm

Bu makalede, bir girişimin ve bir girişimin altında yatan mekaniklerin bir proje yöneticisi için nasıl fırsatlar ve zorluklar yarattığını tartıştık. Bir girişimdeyken, bir proje yöneticisinin bir ürün yöneticisinin birçok işlevini üstlenmesi muhtemeldir, ancak bir kuruluşta iki rol açıkça ayrılmıştır. Her şirketin benzersiz olduğunu ve tartışılan konuların hepsinin her durum için geçerli olmayacağını, bu nedenle nüanslı ortamların bir proje yöneticisinin farklı proje yönetimi niteliklerini ve becerilerini kullanmasını gerektireceğini unutmayın.

Özetlemek gerekirse, bir startup'ın akıcı süreçleri vardır ve proje yöneticisi hızlı kararlar verebilir ve tüm şirket üzerinde büyük bir etkiye sahip olabilir. Geliştirme yaşam döngüleri çok daha kısadır, bu da proje yöneticisinin çevik kalmasını ve değişen piyasa koşullarına uyum sağlayabilmesini sağlar.

Bir başlangıçtaki proje yöneticisi de önemli zorluklarla karşı karşıyadır. Tam olarak tanımlanmamış sorumluluklar, bir girişim büyüdükçe birçok soruna yol açabilir. Müşteriler ve kurucu ortaklar, bir proje yöneticisini ekibin makul bir şekilde sunabileceğinden daha fazlasını taahhüt etmeye zorluyor olabilir. Bunu takiben, gelecekte eski sorunlara yol açan yol haritasına çeşitli kısayollar eklenebilir. Bir girişimin kurucu ortakları, yol haritasının belirlenmesinde çok aktiftir. Bununla birlikte, inançları yanlış pozitiflere yol açabilir ve proje yöneticisinin bu zorlukları azaltmak için veri odaklı ve çevik olması gerekir.

Kurumsal tarafta, bir proje yöneticisi, dış taraflarla iyi çalışma ilişkileri kurmak için şirketin güvenilirliğini ve geçmişini kullanabilir. Müşterilerle düzenli olarak iletişim kuran deneyimli yöneticilerden ve meslektaşlarından gereksinimleri toplamak daha kolaydır. Son olarak, bir proje yönetim ofisi, ne kadar kısıtlayıcı olursa olsun, proje yürütme sırasında ortaya çıkan sorunları azaltmaya ve riskleri yönetmeye yardımcı olabilir.

Kurumsal proje yönetimindeki zorluklar kaçınılmaz olarak şirketin büyüklüğü ile ilgilidir. Çeşitli onaylar ve onaylar, bir proje yöneticisinin proje yürütmesini yavaşlatmaktan kaçınmak için çok dikkatli bir şekilde planlama yapması ve PMO'yu devreye sokması gerektiği anlamına gelir. Gittikçe daha fazla insan ve departman dahil olduğu için yanlış iletişimin ortaya çıkması muhtemeldir ve bu, doğru süreçleri devreye sokarak hafifletilmelidir. Son olarak, geliştirme yaşam döngüleri uzar ve bir proje yöneticisi hem yeni başlayanlarla hem de piyasadaki diğer girişimlerle rekabet etmek zorundadır.

Proje yöneticilerinin çalıştığı bu iki ortam arasındaki temel farklar bunlardır. Bu zorlukları anlayarak, bir ortamdan diğerine geçerken nelerle karşılaşabileceğimizi daha iyi tahmin edebiliriz.