En İyi Proje Yöneticilerinin 5 Vazgeçilmez Niteliği

Yayınlanan: 2022-03-11

Bu makalenin sesli sürümünü dinleyin

En iyi PM olmak sizi öne çıkarır ve en iyi PM olarak tanınırsanız, yüksek talep görürsünüz. Paydaşlar size daha çok güvenecekler, sizinle çalışmak isteyecekler ve tavsiyelerinizi daha çok dinleyecekler. İnşa etmeye yardım ettiğiniz şey ne olursa olsun, en iyi PM'ler dünyanın her yerindeki kuruluşlarda her zaman talep görmektedir. Bu, en iyi proje yöneticilerinin bazı temel niteliklerinin bir listesidir. Umarım, bir olmanıza yardımcı olurlar veya bu alışkanlıklara zaten sahip olup olmadığınızı kontrol ederler.

1. Ekibinizde güven inşa etmek

Bir takımın diyagramı.

Güven, her takımın önemli bir yönüdür. Hakkında sıkça konuşulur ve yazılır, ancak bir projeyi yürütmek söz konusu olduğunda nadiren eylemde bulunur. Proje yönetimi sürecinde güvenin önemi, çeşitli Proje Yönetimi organizasyonları tarafından bile kabul edilmiştir.

Uluslararası Proje Yönetimi Derneği, proje, program ve portföy yönetiminde bireysel yetkinlikler için küresel standart olan ICB4 sertifikalarına güven ile ilgili bölümleri kısa süre önce dahil etti.

Benzer şekilde, Scrum'ın Ampirizmin Üç Sütunu uzun zamandır güvenin ampirik proje kontrolünü sürdürmek için en önemli üç faktörden biri olduğu fikrine dayanmaktadır. Aynı güven oluşturma eğilimi, LEAN ve diğer geleneksel proje yönetimi metodolojilerinde de mevcuttur. Bu, uzun süredir bu kadar acil bir konu olduysa, PM'lerin ekipleri içinde gerçek bir güven oluşturmasını engelleyen ana engeller nelerdir?

Bu soruya en çok tekrarlanan yanıtlardan biri “suçlama kültürü”dür. Güven kültürüne ulaşmanın anahtarı, bu kültürden uzaklaşmak ve bunun yerine her hatayı bir öğrenme fırsatına dönüştürmektir.

Bunu gerçeğe dönüştürmek için, PM'ler ekipleri içinde doğru şeffaflık ve rahatlık ortamını kolaylaştırmalıdır, çünkü çoğu insan ekip üyelerinin kendilerini ifade edebildiği ve hata yapabildikleri ortamda çok daha iyi performans gösterir.

Üst düzey bir PM, ekibine bu ilkeleri, yanlarında yaşayarak, hatalarını paylaşmaya teşvik ederek ve bunları öğrenme için örneklere dönüştürerek öğretir. Üst düzey PM'ler, alçakgönüllülük ve kırılganlık göstermenin bir güç işareti olduğunun farkındadır. Özellikle iş kendi hatalarınızı kabul etmeye gelince, insanların savunmaya geçme ya da suçu başka yere taşıma eğiliminde oldukları genellikle doğrudur. Bir hata yaptığınızı ve neden kendinizi savunmasız hissetmenize neden olabileceğini açıklamak, ancak bu hataları açıkça kabul edip analiz ederseniz, bu alışkanlık başkalarının gelecekte hatadan kaçınmasına yardımcı olacak ve herkesin güven inşa etmesine ve hatalarını ortaya çıkarmasına yardımcı olacaktır. . Örneğin, önemli bir paydaşa bir dönüm noktasını mümkün olandan daha erken bitirme sözü verdiyseniz, o konuda sahip olduğunuz teknik derinlik eksikliği nedeniyle, takıma hatanızı kabul etmek ve suçlamak yerine yanlış tahmin ettiğinizi bilmelerini sağlamak için sorun değil. teknolojiyi istediğiniz kadar hızlı teslim edemedikleri için. Bu, başkalarına açılmaları ve sizinle ve takım arkadaşlarıyla daha güçlü bağlantılar kurmaları için ilham verebilir.

Ekip üyelerinizi anlayın: yeteneklerini, korkularını, hayal kırıklıklarını, neyi sevip neyi sevmediklerini ve diğer insanlarla nasıl etkileşime girdiklerini. Ekip üyeleri kendilerine değer verildiğini hissettiklerinde, değeri daha kolay teslim edeceklerdir. Ekibinizi hedeflerinize doğru zorla zorlamak yerine elinizdeki görevle motive etmenin yollarını bulun. Bunu yapmak için, proje ve proje ekibi rolleri ve sorumlulukları için başarının nasıl göründüğünü açıkça belirtin, ancak ardından kendi alanlarında uzman olmalarına izin verin. Ekip üyelerinizin size ne yapılması gerektiğini söylemelerini bekleyin. Onları dinleyin, ekibinizi güçlendirmek için karar vermeyi merkezden uzaklaştırın, ancak gerektiğinde zor kararlar almaya hazır olun.

Sonuçta, ekibiniz etkileşimde bulunmanız için orada. Çok fazla PM, doğrudan yazma görevlerine dalarak ve bu sorumluluğun çoğunu kendi başlarına üstlenerek hatalar yapar. Bu bazen bu ekipler içindeki güven ve anlayış eksikliğinden kaynaklanır. Ekibinizin güvenini kazandığınızda, onların işin kapsamını belirlemeye, kullanıcı hikayeleri yazmaya ve genel olarak önemli olduğunu düşündükleri konularda size tavsiye vermeye dahil olduklarından emin olun.

En iyi PM'ler, ekiplerinin en iyi varlıkları olduğunun farkındadır ve onlarla güçlü ilişkiler kurmak için her fırsatı değerlendirecektir. Müzakereci ve kolaylaştırıcı olun, ancak her şeyden önce ekiple bir olun. Kendileriyle çalışıyormuşsunuz gibi hissetmeleri gerekiyor, yukarıdaki biri için değil. Bu, bu makaledeki daha teknik ipuçlarından bazılarının habercisidir, çünkü bu güven olmadan projeniz büyük olasılıkla bir dizi sorunla karşılaşacaktır.

Anahtar Çıkarım: “Herkesin hata yaptığını göstermek sorun değil. Hatalarınızı yaptığınızda paylaşın, ekibinize onların yanında olduğunuzu gösterin ve ekibinizin içindeki güveni bir öncelik haline getirin.”

2. Paydaşlarınızın gerçekten ihtiyaç duydukları şeyi elde etmelerini sağlamak

Hedefleri aşmanın genel çubuk grafiği.

Bir PM olarak, birçok yazılım projesinin sonunda paydaşların istedikleri veya ihtiyaç duyduklarından farklı bir şey sunduğu gerçeğinin muhtemelen farkındasınızdır. Bu sorun birçok farklı faktörden kaynaklanmaktadır ve bu sorunu çözmeye çalışan bir dizi yeni metodoloji ortaya çıkarmıştır.

Ancak, Çevik geliştirme çağında bile, bazen hala yanlış şeyi inşa etme tuzağına düşüyoruz. Paydaş analizi esastır ancak genellikle yanlış soruyla başlar. “Bunu neden yapıyoruz?” sorusu sorulmadan, birçok proje başlatılır ve yanlış tanımlanır, gerçek iş ihtiyacına asla cevap vermeyen bir çözüm üretme tuzağına düşer.

"Neden" ile bağlantılı olarak, en iyi PM'ler "kime?" sorusunun takibini sormalıdır. Çözümü sunmak için hangi paydaşları destekliyoruz, onların “neden?”

Üst düzey bir Başbakan'ın önemli bir ayrımı tanıdığı yer burasıdır. Çözüm, bir çıktı veya çıktı olarak tanımlanabilir, ancak üst düzey bir PM, herhangi bir çözümün kendisinin mutlaka orijinal iş ihtiyacını karşılamayacağını anlar. Örneğin, paydaşlar iş ihtiyaçlarının bir ERP sistemi uygulamak olduğunu düşünüyorlarsa, PM'nin ERP gibi bir çözümü kullanmanın ardındaki gerçek iş ihtiyacını ortaya çıkarmalarına yardımcı olması gerekir. ERP'nin kendisi bir iş ihtiyacı değil, bir çözümdür.

Gerçek iş ihtiyacını tanımak, bağlamı ve paydaşları, tutumlarını, güç veya etki düzeylerini, ilgi düzeylerini, proje üzerindeki etkilerini, projenin onlar üzerindeki etkisini, endişelerini ve elbette neyi kabul edeceklerini derinlemesine anlamayı gerektirir. bir projenin başarısı.

Bu nedenle, projeleri amaçlarına ulaşmada daha başarılı hale getirmek için (iş hedeflerini etkileyen çözümler yaratmak) proje yöneticisinin sorumlulukları, çözüm yaratmanın ötesine, çözümlerin hayata geçtiği yere, üretilen değerin beklenen hedeflerle uyumlu olup olmadığını açıkça ölçerek genişler. hedef tanımında.

PM'ler, tüm süreç boyunca projeyi teslim etmenin gerçek faydalarının gerçek iş ihtiyaçları, hedefleri ve hedefleri ile uyumlu olması gerektiğini daima akıllarında tutmalıdır.

Çoğu zaman, iş hedefleri geliştirme ve gereksinim değişikliklerinin ortasında unutulur. Çoğu zaman, projeler, başlangıçta ürünün geliştirilmesine yol açan gerçek iş ihtiyaçlarının bazılarını çözen, ancak tüm gerçek iş ihtiyaçlarını çözmeyen işlevsel ürünler sunar. Paydaşlar doğru yönetilirse ve sık sık ürün yinelemeleri sunulursa bu önlenebilir.

Üst düzey PM'ler ayrıca projeye liderlik etmedeki rollerinin farkındadır ve bu nedenle paydaşların projenin başlangıcında tüm gereksinimleri iletmesini beklemezler. Bazı paydaşların ihtiyaçlarını her zaman nasıl ifade edeceklerini bilemediklerini anlarlar ve ihtiyaçların belirlenmesinden proje teslimine kadar paydaşların ihtiyaçlarını ifade etmelerine yardımcı olmak onların görevidir. Gereksinim belirleme süreci sırasında yalnızca paydaşlardan gereksinimleri değil, onların endişelerini de ortaya çıkarmamız gerektiğini hatırlamak da önemlidir.

Örneğin, daha az olgun organizasyonlarda, genellikle yeni projelerin başlangıcında ilginç bir paradoks meydana gelir. Proje başlatma aşamasında, geliştirme ekibi paydaşların geliştirecekleri çözüm için tüm gereksinimleri ve ihtiyaçları net bir şekilde belirlemelerini bekler. Aynı zamanda, paydaşlar teslimat ekibinin hem zaman hem de maliyet açısından doğru tahminler sunmasını bekler.

Bununla birlikte, proje kapsamı belirlemenin en başında, bu tahminleri tutturmak için çok fazla belirsizlik vardır - ve bunu yaparken gerçekçi olmayan tahminler yaratma tehlikesi vardır. Zaman zaman, paydaşlar, şu anda daha az somut olan bir çözümün belirsizliğine uyum sağlamak için mümkün olduğunca çok gereksinim içerir. Bu arada, teslimat ekibi bilinmeyen için çok yaklaşık bir tahminde bulunur.

Bunun sonucu, büyük olasılıkla, tüm gereksinimlerinin yalnızca %20'sini paydaşlar tarafından kullanılan bir çözüm olacaktır. Gerisi, projeyi bütçeyi aşan ve aynı zamanda aşırı zamanlamayı yapan akılda net bir amaç olmadan geliştirilecektir.

Neyse ki, üst düzey PM'ler, paydaşları nasıl dahil edeceklerini ve projelerinin VUCA (volatilite, belirsizlik, karmaşıklık ve belirsizlik) dünyasının her adımında onlara nasıl rehberlik edeceklerini tam olarak biliyorlar. Proje yöneticileri, projeyi daha somut artışlara bölebilir ve öğrenmeleri aktif olarak oluştururken ve gözden geçirirken paydaşların katılımını sağlayabilir.

Buradaki temel çıkarım şudur: “Çözümler iş ihtiyacını çözmek için oluşturulmuştur, Proje Yönetimi'nin proje oluşturulduğunda bu hedefin kaçırılmadığından emin olması gerekir. Paydaşlarınızın temel ihtiyaç ve endişelerini ele almak için onlarla bağlantı kurarak doğru şeyleri inşa etmek istediğinden emin olun.”

3. Proje risk yönetimini organik bir uygulama haline getirmek

3 genel riskin kontrol listesini içeren PM diyagramı.

Çoğu proje, proje başlatmanın başlangıcında ortaya çıkan bir dizi genel riske sahiptir.

Hemen hemen her proje, kullanıcıların değişime karşı direnci, kaynak eksikliği ve olgunlaşmamış teknoloji de dahil olmak üzere bu genel risklerle başlar. En iyi PM'ler ekiplerini yalnızca ortak riskleri değil, aynı zamanda en acil ve benzersiz riskleri belirlemek için görevlendirir, öyle ki risk tanımlaması projenin başlangıcında önemsiz bir görev değil, proje yaşam döngüsü boyunca bir reflekstir.

Üst düzey PM'ler, riskleri tanırken, genellikle riskleri gereksinimlerinde ve endişelerinde açıkça veya dolaylı olarak tanımlayan kilit paydaşlarla işbirliğine de bakar. Büyük PM'ler, bu sürecin gereksinim belirleme adımından tüm proje yaşam döngüsüne kadar gerçekleştiğini anlar ve bunu süreç boyunca riski tanımlamanın bir değeri olarak görür.

Uzman PM'ler ayrıca ekiplerine güvenir ve ayrıca uzmanlık bilgilerini bir risk azaltma kaynağı olarak kabul eder. Ekip üyelerinin riski proaktif olarak tespit etmelerini sağlamak için, Proje Yöneticisi ekiplerine projenin sahipliğini alma ve risk tanımlama ve yönetimine aktif olarak katılma yetkisi verir.

Pratik açıdan, günlük bir stand-up sırasında üçüncü soru, “Yolunuza ne çıkıyor?” bir ekip projenin başarısına katkıda bulunmak üzere yetkilendirildiği için daha ihtiyatlı yanıtları yansıtır. Elbette, bazı engelleyiciler geçici olabilir veya saldırının hemen ardından kaldırılabilir, ancak bazıları önemli risklere dönüşebilecek potansiyel adaylardır. Ekip üyeleri, bu potansiyel riskleri belirlemeye teşvik edilmelidir ve proje yaşam döngüsünün sonunda bile küçümsemek yerine bunların dahil edilmesi kutlanmalıdır.

Risk tanıma, riski belirtmek ve ilerlemek kadar basit değildir. Risk tanıma, olasılık, ciddiyet ve bazen unutulan bir ölçü açısından düzenli olarak değerlendirilmelidir: yakınlık. İkinci metrik, ekibin, "Bir sonraki risk tanıma adımına kadar hiçbir şey yapma" veya risk daha yakın olması durumunda daha somut bir şey olsun, doğru eylem öğelerini tanımlamasına olanak tanır. Burada bilinmesi gereken önemli nokta, üst düzey PM'lerin riskleri nasıl eyleme geçirilebilir hale getirebileceklerini anlamalarıdır, çünkü yönetilmezlerse herhangi bir risk yararsızdır. Ek olarak, eylem öğelerinin listesi yalnızca reaktif değil, aynı zamanda doğası gereği proaktif olmalı ve sonuçta Risk Ayarlı Ürün İş Listesini bilgilendirmelidir.

Kısacası, üst düzey bir PM, deneyim veya yetki ne olursa olsun, risk tanıma ve yönetimi için tek kaynak olmadığını ve olmaması gerektiğini kabul eder. Paydaşlar, onların ekipleri ve diğer önemli proje katılımcıları, yalnızca erken aşamalarda değil, aynı zamanda proje yaşam döngüsü boyunca düzenli olarak risk tanıma ve yönetimine dahil edilmelidir. Bu önemlidir çünkü projenin başlangıcında tanımlanan ancak o zamandan beri yönetilmeyen risklerin çok az kullanımı vardır.

Buradaki anahtar çıkarım şudur: "Başarılı bir proje yönetimi elde etmek için, tüm ekip riskleri belirlemekten sorumlu olmalıdır. Risk keşfi, bir projenin tüm ömrü boyunca gerçekleşen sürekli bir süreç olmalıdır.”

4. Çevreyi Anlamak

PM ortamının şeması.

Üst düzey bir Başbakan, Çin mağazasındaki bir boğa gibi bir projeye başlamamalıdır. Bir metodoloji veya proje yaklaşımını zorlamak yerine, proje yöneticisi eldeki çevre, resmi yapı, gayri resmi yapı, kültür, alışkanlıklar, araçlar, yetenekler ve organizasyonel varlıkların derinlemesine bir analizini yapmalıdır. Ancak o zaman değişim yolculuğuna başlayabilir.

Herhangi bir PM, üstlendiği projelerin kuruluş üzerinde bir etkisi olacağını anlasa da, üst düzey PM'ler, kuruluşun benzer şekilde projeleri üzerinde bir etkisi olduğunu kabul eder.

Kusurlu, tek boyutlu bir zihniyet yerine, en iyi PM'ler yaklaşımlarını çevrelerini anlayarak uyarlar. Bunu yaparken, en acil iş ihtiyaçlarını, kuruluşların bir çözümü nasıl adapte edeceklerini veya kabul edeceklerini, benimsemeyi ve hedeflere ulaşmada doğru uyumu elde etmek için çözümde hangi değişikliklerin yapılacağını daha iyi anlayabilirler.

Etkili bir proje yönetimi yaklaşımını uyarlarken, üst düzey PM'ler, yalnızca farklı PM yaklaşımları hakkında değil, aynı zamanda iş analizi metodolojileri, değişiklik yönetimi çerçeveleri, kurumsal mimari çerçeveleri ve diğer faydalı analiz yöntemleri hakkında da farklı metodolojiler hakkında derinlemesine bir anlayışa sahip olmalıdır. Bu, bir PM'ye üstlendikleri projeyi teslim etmek için eldeki şirket için en uygun çözümü bulma yeteneği verir.

Örneğin, çok sayıda farklı onay seviyesinin olduğu son derece katı hiyerarşik bir organizasyonda bir projeye başlıyorsanız, en iyi yaklaşım karma veya hibrit proje yönetimi yaklaşımı olabilir. Önceden yapılmış gereksinim onayları ve ardından projeyi resmi aşama kapıları ile aşamalara bölerek yapılandırılmış bir gereksinim belirleme aşaması gerçekleştirebilirsiniz. Buna paralel olarak, Proje Yöneticisi, daha geleneksel bir proje yürütmesine rağmen, yinelemeli geliştirmenin en iyi uygulamalarını yakalamak için geliştirme ekipleri içinde Çevik benzeri yinelemeli yürütme kurabilir.

Özetle, üst düzey PM'ler şirket kültürüne saygı gösterirken, saygılı bir şekilde yeni yaklaşımlar önerir ve organizasyonlara proje yönetimi uygulamalarını iyileştirmede koçluk yapacaktır. Pek çok organizasyonun farklı olgunluk ve değişime hazır olma noktalarında olduğunun farkındalar ve bunu her şirketin proje yönetimi en iyi uygulamalarını uygulama becerisini olumlu yönde etkilemek için bir tehditten ziyade bir fırsat olarak görüyorlar.

Buradaki temel çıkarım şudur: “Proje Yöneticileri körü körüne kendi gündemlerini zorlamamalı, kuruluşların çalışma biçimlerine uyum sağlamalı ve gerekirse değişikliği yavaş yavaş gerçekleştirmelidir.”

5. LEAN İlkelerini Uygulamak

5 LEAN ilkesinin şeması

En iyi PM'ler, yolculuğun hedef kadar önemli olduğunu bilir. Zaman zaman, proje yolculuğu, işlerin nasıl yapılması gerektiğini tanımlayan bir süreç tarafından özellikle hantal hale gelir. Bu, gereksiz yere ağır şablonlarda, anlamsız toplantılarda veya yolculuğu engelleyen dikkat dağıtıcı çevre birimlerinde oluşabilir, ancak bu engellerin ekibinizi mümkün olduğunca az etkilemesini sağlamak PM olarak sizin sorumluluğunuzdadır.

Üst düzey PM'ler, LEAN metodolojisinde iyi tanımlanmış çevik proje yönetimi ilkelerinden yola çıkarak ekip için daha verimli ve etkili süreçler belirlemelidir.

LEAN'in yalnızca üretim için uygun olduğu yaygın bir yanılgıdır ve bu kesinlikle doğru değildir. LEAN proje yönetimi yöntemleri, her projeyi ve her süreci iyileştirebilir. Bu sadece bir maliyet azaltma programı değil, daha çok ekibiniz için bir düşünme ve hareket etme yöntemidir.

LEAN ilkelerini uygulamanın faydaları Toyota CEO'su Katsuaki Watanabe'nin bir alıntısında çok iyi özetlenmiştir: “Mükemmel süreç yönetimi bizim stratejimizdir. Mükemmel süreçleri yöneten ortalama insanlardan mükemmel sonuçlar alıyoruz. Rakiplerimizin genellikle bozuk süreçleri yöneten zeki insanlardan ortalama (veya daha kötü) sonuçlar aldığını gözlemliyoruz.”

Gereksiz proje gürültüsünü ve işini ortadan kaldırma eğilimine sahip bir üst düzey yönetici, doğal olarak süreci LEAN ilkelerine doğru yönlendirecektir. Üst düzey bir PM, Ürün Sahibi, ekibi ve ilgili paydaşlarla, ihtiyaçlarını ve bu ihtiyaçlara yanıt olarak beklenen değeri düzenlemelerine ve belirlemelerine yardımcı olmak için sıkı bir şekilde çalışmalıdır.

Projeniz için en iyi PM uygulamalarını ödünç almak için LEAN'in ötesine bakmak da yararlıdır. Örneğin, yalnızca PRINCE2 metodolojisi , projenin başlangıç ​​aşamasında öğrenilen dersleri yakalamak gibi zorunlu bir göreve sahiptir. Bu, yeni bir proje başlatılırken başkaları tarafından nadiren kullanılacak olan bir projenin sonunda bir belge yazmak yerine, önceki projelerden öğrenilen tüm dersleri yakalar. Gereksiz adımları ortadan kaldırmak ve gerçek değer katanlara odaklanmak için süreci değiştirmekten korkmamak önemlidir.

Bu, süreçlere yardımcı olmak ve süreçleri yeniden şekillendirmek veya ekibin en baştan doğru olanları seçmesine yardımcı olmak için iyi bir fırsattır. Bu net performans göstergeleri, proje başarısına ilişkin net bir kılavuz tanımlamak için ilgili herkesle şeffaf bir şekilde paylaşılmalıdır.

Buradaki anahtar çıkarım şudur: "Doğru çözümleri bulmak, bu çözümleri sunmak için doğru ve düzenli bir sürece sahip olmak kadar önemlidir."