Bir Teslimat Liderinin Gerçek Etkiyi Ölçmeye Dair Görüşleri
Metriklerin Ötesinde: Demir üçgen, teslimat kısıtlarını yönetir; ancak kalıcı etki, bir projenin gerçekten başarılı olup olmadığını belirler.
Sonuçları Ölçün: Ölçülebilir KPI'ları daha kapsamlı hedeflerden ayırın, ardından zor hedefleri kullanıcı testleri ve paydaş kanıtlarıyla doğrulayın.
Erken Uyumlanın: Proje ve ekip sözleşmeleri, teslimat çalışmaları başlamadan önce paydaş önceliklerini, kişisel motivasyonları ve başarı koşullarını ortaya çıkarır.
Uzun Ömürlülüğü Planlayın: Ürünlerin aylar veya yıllar sonra da kullanışlı, anlaşılır ve değerli kalıp kalmadığını değerlendirmek için lansman sonrası ölçütler belirleyin.
Değiş Tokuşları İletin: Liderler değişiklikleri açıklar ve gerekçelerini paylaşırsa esnek kapsam, takvimler ve bütçeler başarıyı destekleyebilir.
*Bu makale, Galen Low'un sunuculuğunu yaptığı DPM Podcast bölümünden uyarlanmıştır: "Projelerinizin Gerçek Etkisi Nasıl Ölçülür?".
Her proje lideri demir üçgeni bilir: kapsam, takvim ve bütçe. Bu, proje yöneticilerine ilk günden öğretilen varsayılan puan kartıdır. Ancak üçünü de tutturmak bir projenin gerçekten önemli olduğunu garanti etmez; birini kaçırmak da projenin başarısız olduğu anlamına gelmez.
Horizontal Digital'ın kıdemli başkan yardımcısı Pam Butkowski, kariyeri boyunca kurumsal müşteriler için teslimat yönetimi yaptı. Bunlar arasında 74 kişinin ve yaklaşık 25.000 saatlik çalışmanın yer aldığı, 20 ay süren bir LPGA web sitesi yeniden tasarımı da bulunuyor. Onun görüşü şu: demir üçgen, başarının tanımı değil, riskleri ve beklentileri yönetmeye yarayan bir araçtır.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Demir Üçgen Hikâyenin Tamamı Değildir
Butkowski, kâğıt üzerinde her kısıtı karşılayan ancak projeyi teslim eden insanlar açısından yine de başarısız olan projeler gördü. Ekip tükenmişse veya müşteri ilişkisi proje boyunca ayakta kalamamışsa, zamanında ve bütçeye uygun teknik başarı pek bir anlam ifade etmez.
Ayrıca riskin tamamen mühendislik yoluyla ortadan kaldırılabileceği fikrine de karşı çıkıyor. "Her projede işler ters gidecek, değil mi? Her riski azaltamazsınız," dedi. Ona göre başarılı bir projeyi başarısız bir projeden ayıran şey sorunların hiç yaşanmaması değil, bu sorunlara verilen tepkidir. "Bir şeyler ters gittiğinde yaptıklarınız da bir şeyin başarılı olup olmadığına katkıda bulunur," dedi.
Her projede işler ters gidecek, değil mi? Her riski azaltamazsınız.
Butkowski için başarının en açık göstergelerinden biri, müşteriyle ilişkinin ilk iş kapsamından daha uzun sürüp sürmediğidir. "Tek seferlik işler yapmak istemiyoruz," dedi. "Bir siteyi yayına alırsak ve müşteriyle ilişkimiz bundan sonra da devam ederse, bu başarılı olmuş demektir."
KPI'lar Ölçülebilirdir. Hedefler Öyle Değildir.
Teslimat liderleri genellikle iş hedefleri ile KPI'ları birbirine karıştırır; Butkowski ise bu ikisi arasında kesin bir ayrım yapıyor. Hedefler ilham verici olabilir; KPI'lar olamaz. "Sadece yatırım getirinizi artıracağız diyemeyiz," dedi. "Hayır, bunun ölçülebilir olması gerekir. Trafiğiniz şu kadar artacak. Reklam tıklamalarınız şu kadar artacak. Çok açık ve yine ölçülebilir olmalı; KPI'lara ulaştık mı, ulaşamadık mı?"
Bu ayrım, temel hedefin doğrudan ölçülmesinin zor olduğu durumlarda en çok önem kazanır. LPGA projesinde ekibin temel amacı, tek ve net bir metriğe indirgenmesi zor olan hayran etkileşimini artırmaktı. "Bunu ölçmek gerçekten zor," dedi Butkowski. "Bu nedenle hayran etkileşimini artıracağına inandığımız epey sayıda işlev geliştirdik ve bunu kullanıcı testleriyle kanıtladık. Paydaş görüşmeleriyle kanıtladık." Ekip, hayran etkileşimine doğrudan somut bir KPI bağlayamadı ancak hipotezi başka bir yolla doğruladı. "Hipotezimizi kanıtladık, ardından bunu uygulamaya koyduk ve bazen bu yeterince iyi olur."
Rolün Neden Var Olduğuyla Başlayın
Butkowski, taktiklere geçmek yerine teslimat liderlerinin öncelikle işlevin arkasındaki amacı tanımlayarak başlamasını öneriyor. Bu çalışmayı kendi ekibiyle yürüttü ve risk azaltma şeklindeki refleksif cevabın ötesine geçti. "Kelimenin tam anlamıyla karşı çıktım ve ekibime şunu sordum: Neden varız? Proje yöneticileri bu organizasyonda neden var?" dedi. Ekip, amacını beş maddede özetledi: "Ekibi yönetmek ve oyun kurucusu olmak, müşterilerimize değer sağlamak ve hedeflerine ulaşmalarına yardımcı olmak, doğru bilginin kaynağı olmak, karmaşayı ortadan kaldırmak ve ajansı korumak için varız."
Buradan hareketle bu beş temel ilkenin her biri somut uygulamalara dönüşür. Örneğin "ekibi yönetmek" kapsamında beklentilerden biri "oyun planını uygulamak"tır; bu da pratikte "net bir proje planı" yürütmek, "her hafta sırada ne olduğunu açıkça gösteren personel ve kaynak planlarını" korumak ve "son derece net ve öz günlük toplantılar" düzenlemek anlamına gelir.
Proje Beyannameleri Doğru Konuşmaları Erken Aşamada Zorunlu Kılar
Butkowski, işe başlamadan önce bir projenin paydaşları için neyin önemli olduğunu ortaya çıkarmak üzere iki tür proje tanımlama belgesine başvuruyor. İlki, müşteriyle birlikte hazırlanan proje tanımlama belgesi. "Proje tanımlama belgelerini paha biçilmez buluyorum," diyor, "çünkü müşterinizle birlikte bir tanımlama belgesi hazırlama eylemi bile sizi neyi önemsediğiniz hakkında konuşmaya zorluyor." Müşteriler, aksi takdirde açıkça dile getirmeyebilecekleri önceliklerini ortaya koyuyor — bir yöneticiyi etkilemek, para tasarrufu yapmak veya ekiplerinin itibarını korumak istemek gibi. "Şirkete para kazandırmayı gerçekten önemsiyorum," tipik bir yanıt, diyor. "Ekibimle ilgilenmeyi ve iyi görünmelerini sağlamayı gerçekten önemsiyorum."
Ekibimle ilgilenmeyi ve iyi görünmelerini sağlamayı gerçekten önemsiyorum.
İkincisi, işi gerçekleştiren kişilerle birlikte hazırlanan ekip tanımlama belgesi. "Ürünü gerçekten teslim eden ekip üyelerinin her biri için, birlikte çalıştığınız bu kişilere bunun ne fayda sağlayacağını bulalım. Bundan ne elde etmeye çalışıyorlar?" diyor Butkowski. Bu girdiler, planın nasıl oluşturulacağını şekillendiriyor; böylece proje, müşterinin yanı sıra ekibe de değer sağlıyor.
Projenin Ötesine Geçen Etkiyi Ölçmek
En anlamlı etkilerden bazıları, bir proje tamamlandıktan, hatta teslimat lideri görevinden ayrıldıktan çok sonra ortaya çıkar. Butkowski'nin ekibi, başarının nasıl görünmesi gerektiğini lansmanın çok ötesini kapsayacak şekilde tanımlayarak buna hazırlanıyor. "Ürünün uzun vadede nereye gidebileceğini anladığımızdan emin olmak istiyoruz," diyor. "Bu şey bundan altı ay, bir yıl, iki yıl, beş yıl sonra nasıl görünecek?"
Bu uzun vadeli bakış, elinde kesin trafik rakamları olmasa bile daha sonra geri dönebileceği bir ölçüt haline geliyor. "Geri dönüp bu hedef göz önünde bulundurularak oluşturulmuş bir pazarlama sitesine baktığımda, bir yıl sonra ona bakıyor ve içeriğin hâlâ kolayca anlaşılabildiğini görüyorsam, bunu başardık demektir," diyor. "Hâlâ karşılığını veriyor."
Ürünün uzun vadede nereye gidebileceğini anladığımızdan emin olmak istiyoruz. Bu şey bundan altı ay, bir yıl, iki yıl, beş yıl sonra nasıl görünecek?
Üçgen, Bunu Yüksek Sesle Söylerseniz Esneyebilir
Butkowski, demir üçgeni göz ardı etmiyor; onu sabit değil, ayarlanabilir bir yapı olarak görüyor. "Üçgenin tüm kenarlarının aynı uzunlukta olması gerektiğini kimse söylemiyor," diyor. "Ayrıca teslimat sürecinde üçgenin kenarlarının uzunluğunun değişemeyeceğini de kimse söylemedi." Bütçe genişleyebilir. Takvim değişebilir. Kapsam daralabilir. Ona göre gerçekleşemeyecek olan tek şey, bunların herhangi birinin müşterinin bilgisi olmadan yapılması.
"İnsanlar bunu yaptığınızı bildiği sürece üçgeni bozup projeyi yine de başarılı olarak nitelendirebileceğiniz bir durumun var olduğunu düşünüyorum," diyor. Bir kısıt aşılmadan önce, sonrasında değil, liderliğin süreçten haberdar edilmesi gerekir. "Üçgeni neden bozduğunuzun ardındaki gerekçe, en başta onu bozuyor olmanızdan daha önemli."
Bu ilke, başlangıç toplantılarını yürütme biçiminde doğrudan kendini gösteriyor. "Ne zaman bir proje başlatsak, müşterinin demir üçgene öncelik vermesini sağlarım," diyor. "Onlara şunu söylettiririm: Bu kenar benim için en önemli, bu ikinci en önemli ve bu da en az önemli." Buradan sonra üçüncü kenarın sorumluluğunu üstleniyor: "Üçüncü kenarın sorumluluğu bende. Üçüncü kenar üzerinde kontrolünüz yok. Bende var. Bununla ne yaptığımı size söyleyeceğim, ancak sizin için birinci ve ikinci kenarı teslim edebilmek için üçüncü kenarın sorumluluğunu üstlenmeliyim; böylece bu şekilde esneyebilirim." Ödünleşim ilk günden itibaren şeffaf: "Size ikisini sunabilirim, söz veriyorum."
Gelişim İşin Bir Parçasıdır, Ekstra Bir Unsur Değil
Butkowski için ekibi geliştirmek, teslimattan ayrı bir şey değil; rolün içine yerleştirilmiş durumda. "Unvanımızda yönetici kelimesinin bulunmasının bir nedeni var," diyor. "Doğamız gereği lideriz." Teslimat liderlerini, planın kendisi içinde aktif olarak gelişim fırsatları yaratmaya teşvik ediyor: "İçerik yazarınızın QA'ya geçme konusunda gerçekten istekli olduğunu görüyorsanız, bırakın geçsin. Onu plana dâhil edin. QA ekibinizi gözlemlemesini sağlayın." Tek koşul koordinasyon — bu fırsatların yine de her kişinin daha geniş hedefleriyle bağlantılı olması gerekiyor: işin "kurumdaki genel hedeflerine ve kariyerinde gitmek istediği yere uyduğundan" emin olmak.
Sonuç
Butkowski için demir üçgenin hâlâ bir işlevi var: riski yönetiyor ve beklentileri belirliyor — ancak bir projenin gerçekten önemli olup olmadığını ölçmek için hiçbir zaman tasarlanmadı. Gerçek etki, müşterinin tekrar tekrar başvurduğu şeyde, bir ekibin daha iyi yapmayı öğrendiği işlerde ve bir ürünün lansmandan bir yıl sonra hâlâ sürdürdüğü işlevde ortaya çıkar. Bunu ölçmek, kapsamı, takvimi ve bütçeyi takip etmekten fazlasını gerektirir. İşin en başta neden var olduğunu sormayı gerektirir.
Bunun gibi daha fazla içgörü mü istiyorsunuz? Bu uzmanlar gibi daha fazla uzmanın görüşlerini almak için ücretsiz bir DPM hesabı oluşturun.
