Etkili Bir Retrospektif Nasıl Yürütülür ve Öğrenilen Dersler Gelecekteki Projelere Nasıl Uygulanır?

Transkripti Okuyun:

 

Podcast'lerimizin transkripsiyonunu bir yazılım programı kullanarak deniyoruz. Bot her zaman %100 doğru çalışmadığı için lütfen yazım hatalarını mazur görün.

Galen Low: Merhaba millet, bizi dinlediğiniz için teşekkürler. Ben The Digital Project Manager'dan Galen Low. Dijital profesyonellerden oluşan ve birbirimizin yetkinlik kazanmasına, özgüven geliştirmesine ve bağlantılar kurmasına yardımcı olmayı amaçlayan bir topluluğuz; böylece dijital dünyada proje yönetiminin değerini artırabiliriz. Bunun hakkında daha fazla bilgi edinmek isterseniz thedigitalprojectmanager.com adresine göz atın.

Bugün proje retrospektifleri hakkında konuşuyoruz: Bunları etkili bir şekilde nasıl yürütebiliriz ve retrospektiflerinizde yakaladığınız derslerin gelecekteki projeler için gerçekten iyileştirmelere dönüşmesini nasıl sağlayabilirsiniz?

Bugün konuğum, 30 yılı aşkın süredir kuruluşların proje hatalarından ders çıkarmasına yardımcı olan Catalysis Group'un kurucusu ve baş danışmanı Payson Hall.

Payson, programa katıldığın için çok mutluyum.

Payson Hall: Merhaba, burada olmaktan ve dinleyicilerle tanışmaktan mutluyum.

Galen Low: Evet, bunu belirtmene sevindim çünkü bugün biraz farklı bir şey yapıyoruz. Üyelerimiz stüdyo dinleyicisi olarak canlı yayında bizimle ve Slack topluluğumuz aracılığıyla anlık sorular alacağız. Michael da stüdyoda benimle birlikte; soruların bir kısmını o yönlendirecek. Bunları konuşmaya dâhil edeceğiz ve her şey olabilir. O hâlde biraz hareketlenelim.

Pekâlâ, başlayalım. İlginç bir soruyla başlamak istedim çünkü bunu konuşuyorduk ve sen on yıllardır her türden proje için, yazılım projeleri ve büyük ölçekli sistem entegrasyonu projeleri de dâhil olmak üzere, bir danışman olarak proje retrospektifleri yürütüyorsun. Sana şunu sormak istiyorum: Bir projenin bütün kirli küçük sırlarını ortaya çıkarmak için dışarıdan bir danışman olarak geldiğinde, proje ekipleri seni dost mu yoksa düşman mı olarak görüyor? Bu, mentorluk alıyorlarmış gibi mi hissettiriyor? Yoksa denetleniyorlar mı?

Payson Hall: Normalde dostça bir alışveriş oluyor. Bir ayrım yapmak isterim çünkü danışmanlık uygulamamın bir bölümünde proje otopsileri yapıyorum. Bir proje ciddi biçimde raydan çıkmışsa ve insanların bunun olduğunu bildikleri hâlde hiçbir şey söylemediğine dair bir endişe varsa, bu çok daha fazla denetim gibidir.

Aslında Kaliforniya'da bir eyalet denetçisiyle çalışıyorum ve milyar dolarlık BT projelerini denetledim. Orada genellikle yapmaya çalıştıkları şey, avukatların bir sistem entegratörünün peşine düşebilmesi için bir dava dosyası oluşturmaktır. Daha yaygın ve dostça bir retrospektif ise insanların şöyle demesidir: “Hey, bu projeyi bitirdik.”

“Geriye dönüp bakmayı kolaylaştırması için birini çağıralım.” Retrospektif tam olarak budur. Geriye dönüp şunları sormaktır: Ne öğrendik? Akıllıca yaptığımız ve o sırada fark etmediğimiz ne vardı? Geriye dönüp baktığımızda farklı yapmak isteyebileceğimiz ne vardı? Bu aslında dikiz aynasına bakarak yapılan bir risk yönetimi oturumudur. Bir dahaki sefere neyi daha iyi yapabilirim? Akıllıca yaptığım ve daha fazlasını yaptığımızdan emin olmak istediğim neydi?

Galen Low: Bu ayrımı ben de gerçekten beğendim çünkü dinleyen bazı kişilerin bu ayrımı o kadar net hissedemeyebileceğini düşünüyorum. Her retrospektifin otopsi gibi, mahkemede kanıt sunulacakmış gibi, biraz suçlama oyunu gibi hissettirmesi yerine, senin de söylediğin gibi dikiz aynasına bakıp hatalardan ders çıkarmak söz konusu.

Payson Hall: Retrospektifle ilgili birkaç temel kuraldan biri şudur: Bunları yapmanın çeşitli yolları vardır ama proje yöneticisi olarak kendi retrospektifini hiçbir zaman kendin yürütmek istemezsin. Çünkü iyi gitmeyen bazı şeyler senin yaptığın şeyler olabilir. İyi bir kolaylaştırıcı, kimsenin duvara çivilenmesini engelleyebilir ve konuyu “Ne oldu, ne zaman oldu, bundan ne öğrendik?” sorularına odaklayabilir. “Galen, gerçekten berbat ettin,” şeklinde değil.

Bu yapıcı değildir. İnsanlar savunmaya geçer ve süreç raydan çıkar. Bu nedenle dışarıdan birini getirsen de, kurum içinde sevdiğin ve güvendiğin, iyi bir kolaylaştırıcı olsa da, konuşmayı kolaylaştırması için projeye dâhil olmamış ve çıkar çatışması bulunmayan bir kişiyi tercih etmelisin; böylece işimiz bittiğinde yerde çok fazla kan olmaz.

Galen Low: Bu adil. Aslında bu çok ilginç bir bakış açısı çünkü birçok kişinin bunu kendi retrospektifini nasıl yürüteceğini anlamak için dinlediğini biliyorum.

Elbette bunun birçok proje ekibi için bir gerçeklik olduğunu biliyorum ve yol boyunca öğrendiğin bazı ipuçlarını ve şeyleri ele alacağız. Ancak, mümkünse başka birinin, hatta yapabiliyorsa mutlaka başka birinin, bu bakış açısını sunması ve sürecin bir suçlama oyununa dönüşmesini engellemesi yönündeki tavsiyeni çok beğendim. Sonrasında yerde çok fazla kan olmayacak.

Payson Hall: Farklı varsayımlarla gelebilecek biri olmalı. Üzerinde çalıştığın projeleri düşün. Proje boyunca sorunların nedenleri hakkında varsayımlarda bulundun. Bunlar doğru da olabilir, yanlış da. Bu varsayımlara sahip olmadan gelen biri başka bilgilere veya başka yorumlama biçimlerine açık olabilir.

Galen Low: Bunu sevdim. Evet. On iki ila on sekiz ay süren uzun soluklu bir projede yer almamış, projeye çok yakın olmadığı için ormanı ağaçlardan göremeyen birinin bakış açısını sevdim.

Belki geniş çerçeveden başlayabiliriz. Dinleyicilerimizin konuyu anlaması için biraz uzaklaşalım. Senin bakış açına göre proje retrospektifi nedir ve neden yapılmaya değerdir, açıklayabilir misin?

Payson Hall: Harika soru. Retrospektif kelimesi geriye bakmak anlamına gelir. Fikir şu: Projede önemli bir ana ya da projenin sonuna geliriz. Durup nefes alır ve şunu sorarız: “Peki, bu son bölümde ne öğrendik? Bir sonraki bölüme hangi dersleri uygulamak istiyoruz? Ya da bir sonraki projeye uygulamak istemediğimiz hangi dersler var?”

Tesadüfen akıllıca yaptığımız ne vardı? Ya da “Bunu yeniden yapacak olsaydım...” dediğimiz ne vardı? Bir zaman makinesine mesaj gönderebilseydim, kendime geri dönüp “Bunu farklı yapmak isterdim,” diyeceğim şey ne olurdu? Fikir gerçekten sadece nefes almak ve proje olaylarına bağlam içinde geriye dönüp bakmaktır.

Senin söylediğin gibi biraz uzaklaşıp büyük resmi görmektir; böylece neyin önemli, neyin önemsiz olduğunu anlayabiliriz. Bazı şeyler kara kuğudur. Beklenmedik bir olaydır; COVID gibi. Gelecekteki çoğu projede salgınları planlamayacağım ama bu senin projenin başına geldiyse büyük bir darbe olmuştur.

Belki orada bazı dersler vardır ama bazı şeyler sadece “Hayır,”dır. Örneğin, bir düzine dizüstü bilgisayara ihtiyacın olabilir ve birkaçının çalışmaması ihtimaline karşı on dört tane sipariş etmişsindir. Sonra gerçekten biri çalışmamıştır ve zaman baskısı altındayken bu çok akıllıca bir davranış olmuştur.

“Tamam, diğer iki dizüstü bilgisayarın maliyetini, kaçınılan gecikmeyle karşılaştırırsak bu gerçekten iyi bir ders olabilir,” dersin. Fazladan dizüstü bilgisayarın hurdaya çıkması da gerekmez; iade edebiliriz. Açmadığımız sürece iade etme hakkımız olduğunu belirten bir sözleşme maddesi yazabiliriz.

Belki de o bin dolar gerçekten çok iyi harcanmıştır. Bizi üç haftalık bir gecikmeden kurtarmıştır. Son üç yılda tedarik zincirleri darmadağın olmuşken donanımla çalıştıysan ne demek istediğimi çok iyi biliyorsun.

Galen Low: Kesinlikle. Bu örneği çok sevdim. İnsanların genellikle düşünmediği gerçekten önemli bir noktayı gösteriyor: Retrospektifler, çok iyi giden bir şey, harika ve akıllıca bir uygulama üzerine düşünmek için de kullanılabilir.

Bazen geriye dönüp “Ne iyi gitti?” diye sorarsın. “Ekip gerçekten iyi çalıştı, iyi iletişim kurduk,” gibi cevaplar gelir. Ancak net bir ders olarak, “O kişi diğer alternatif toplantı odasını rezerve ettiğinde hatırlıyor musun? Bir numaralı mekânımız iptal edildiğinde ya da başka bir şey olduğunda yedek bir seçeneğimiz vardı. Harikaydı,” diyebilmek gerekir.

Bu, ders çıkarmamız ve bir dahaki sefere sürecimize dâhil etmemiz gereken bir şey olmalı. Senin söylediğin gibi, fazladan bir dizüstü bilgisayar sipariş edersek açılmamış olması koşuluyla iade edebileceğimizi sözleşmeye yazmalı ve bunu gelecekteki projelerde akıllıca bir öğrenme olarak kullanmalıyız.

Ayrıca söylediğin başka bir şeyi de çok sevdim: Retrospektiflerin ya projenin sonunda ya da proje içindeki önemli bir anda gerçekleşmesi. Konuştuğum birçok kişi “Retrospektif projenin sonu demektir ve artık çok geçtir,” diyor. Dikiz aynasına bakabiliriz ama hüzünlü bir ton vardır: “Evet, daha iyi olabilirdi ama artık çok geç. Bir sonrakini beklemek zorundayız.” Oysa proje içinde retrospektif yapmak için başka noktalar da var. Buna daha sonra dönmek istiyorum.

Payson Hall: Evet, çevik yaklaşımlardan aldığımız ilginç şeylerden biri bu. Genellikle her sprintin sonunda küçük bir retrospektif yaparlar. Büyük projelerde kilometre taşı temelinde yaptığımız projeler oldu ama bence Çevik yaklaşım şunu söyledi: “Bir dakika, bunları neden aralıklı olarak yapmıyoruz?”

Daha sık yaptığımız için daha küçük olurlar. Ekip süreci anlamaya, sürece dâhil olmaya ve işi tamamlamaya başlar. Bence Çevik yaklaşımın, her sprintin sonunda retrospektif yapılmasını netleştirmesi gerçekten güzel bir yenilikti.

Galen Low: Bunu daha düzenli yapabileceğimiz ve daha küçük bir iş hâline getirebileceğimiz düşüncesindeki zihniyet değişimini sevdim. Ancak bu konuda şeytanın avukatlığını yapmak gerekirse, birçok kişinin, özellikle de birçok kuruluşun, “Öğrenmek istiyoruz, hatalarımızdan ders çıkarmak istiyoruz, hızlı başarısız olmak istiyoruz,” diyeceğini düşünüyorum.

Ama iş uygulamaya geldiğinde her kuruluş geriye bakmaya, bu dikiz aynasına yatırım yapmaya istekli değil. “Yol boyunca öğrendik. Bunun hakkında toplantı yapmamıza gerek yok. Sadece bir sonraki işe geçelim,” diyorlar. Genel yatırım açısından, senin söylediğin gibi dışarıdan bir kolaylaştırıcı getirmek bakımından bunu merak ediyorum.

Sprintler arasında ya da her kilometre taşında yapmıyorsanız belki sonunda büyük bir kapanış oturumu olur. Peki, düzgün bir proje retrospektifi yürütmek için ne gerekir? Buna değer mi? Bir kuruluş olarak “Bilmiyorum. İnsanlar proje boyunca zorluk yaşadı. İlerlemeliyiz. Payson'ı çağırmayalım, retrospektif yapmayalım, yolumuza devam edelim,” diye şeytanın avukatlığını yapsaydım, buna ne derdin?

Payson Hall: Harika bir soru. Süreç iyileştirmesi hakkında konuştuğumuzda, öğrenilen derslerin ve iyileştirmenin maliyetinin iyileştirmenin değerini aşmadığından emin olmak isteriz. Retrospektif yürütmek ne gerektirir? Sana bir örnek vereyim ve adım adım açıklayayım. Öncelikle bağlam önemlidir.

Milyonlarca ya da milyarlarca dolarlık bir projeden bahsediyorsak, küçük bir projeye kıyasla çok daha fazla çaba gerekir. Çok daha fazla veri olacaktır. Proje sorunluysa, nispeten sorunsuz ilerleyen bir projeye göre daha fazla çaba gerekir. Bir proje çöker ve avukatlar sürece dâhil olursa retrospektif yapmıyorsun; otopsi yapıyorsun ve bunlar çok pahalı olabilir.

Yakın zamanda yaklaşık on iki kişilik bir ekiple, yaklaşık on sekiz ay süren bir proje için retrospektif yaptım. Bu bir iç projeydi; projede bir düzine kişi vardı ve proje yaklaşık on sekiz ay sürdü. Gereksinimleri karşılamış, biraz gecikmişti ve bu kabul edilebilirdi. Avukatlar dâhil olmamıştı.

Soru şuydu: “Peki, sona geldik. Bir nefes alalım. Bundan ne öğrendik? Neyi farklı yapabiliriz?” Ekip üyelerinin her biri muhtemelen hazırlık, toplantıya katılma ve değerlendirme için dört ila altı saat harcadı. Kolaylaştırıcı olarak hazırlık yapmak, oturumu yürütmek ve sonunda yazılı dokümanları oluşturmak için muhtemelen on iki saat harcadım.

Proje yöneticisi bana bilgi sağlamak ve konuları gözden geçirmek için muhtemelen sekiz ila on iki saat harcadı. Yani retrospektif yaklaşık iki kişi-haftalık bir çaba tüketti. İki kişi-haftalık çaba. Şimdi on iki kişinin ve proje yöneticisinin on sekiz ay boyunca çalıştığını düşünürsek, bu yaklaşık bin kişi-haftasıdır.

Söylediğimiz şey şu: Geriye dönüp “Bundan ne öğrendik? Neyi farklı yapabiliriz? Akıllıca ne yaptık?” diye anlamaya çalışmak için harcanan süre bunun %0,2'siydi. Düşünürsen, tek yapman gereken iki kişi-haftalık çabayı karşılayacak bir yol bulmak ve yatırımından olumlu bir geri dönüş almaktır.

Bu birkaç şekilde gerçekleşebilir. Yapısal olabilir: “PMO'ya bunu farklı yapmasını önerebiliriz ve bu size zaman ve sorun tasarrufu sağlayacak.” Organik de olabilir. “Arkadaşlar, bu projede kod incelemesi yaptığımızdan emin olmak için normalden fazla çaba harcadık ve bu gerçekten yardımcı oldu,” dersin.

Bunu denedik ve gerçekten faydasını gördük. Sonraki projede ekipteki herkes bunu uygular. Çoğu zaman tohum kapsülü gibi dağılırlar; aynı projede birlikte çalışabilir veya farklı projelere geçebilirler. Öğrendikleri dersleri yanlarında taşır ve bir sonraki projede bunları savunabilirler.

Sonunda “Bulguların, önerilerin ve tavsiyelerin bir listesi var,” demediğimiz bir retrospektif görmedim. Bence bu, yatırdığımız en az iki kişi-haftalık çabaya değer.

Galen Low: Anladım. Daha büyük projelerden bahsediyoruz ama küçük projeler için bir alt sınır var mı? Projeniz yalnızca dört hafta sürdüyse, buna iki kişi-haftası ayırmanın yatırım getirisi olmayabilir. Projeyi tamamen bırakıp “Hayır, bunlar için retrospektif yapamayız,” mı dersin? Beş küçük projeyi bir araya getirip birlikte mi retrospektif yaparsınız?

Payson Hall: Hayır, bu kariyerimin başlarında yaptığım bir hataydı.

Retrospektifte projeye dâhil olmayan hiç kimsenin bulunmasını istemezsin. Ekibin kendi içinde savaş hâlinde olmadığını varsayalım. İşe yarayan ve yaramayan şeyler hakkında açık bir konuşma yapacaksan ve “Evet, bunu berbat ettim. Bunu farklı yapabilirdim,” diyeceksen, insanlar bunu birlikte çalıştıkları samimi bir ekiple yaparken bir grup yabancıya kıyasla çok daha rahat olurlar.

Bu nedenle projeleri bir araya getirmeyi asla düşünmem. Bir dizi küçük retrospektifi tamamladıktan sonra proje yöneticilerini bir araya getirip ortak noktaların neler olduğunu sormak, PMO'nun yapmak isteyebileceği ilginç bir şey olabilir.

Ancak retrospektif için turist istemem. Yalnızca ekibin olmasını isterim. Küçük ölçekte bunu yapabilir miyiz sorusuna gelince: Kesinlikle. Birazdan konuşacağımız resmî süreci sana adım adım anlatacağım. On sekiz aylık bir projede insanlar her gün gelip on sekiz ay boyunca bir koşu bandına çıkmış gibi hissederler. Bazı önemli olaylar vardır ama bağlamı kaybetmek kolaydır.

Senin söylediğin gibi ormanı ağaçlardan görememek kolaydır. Bu nedenle biraz zaman ayırıp “Yol boyunca bazı önemli gelişmeler yaşandı,” demek gerçekten yardımcı olabilir. Bahsettiğimiz iki haftalık yatırım, üç ya da dört haftalık bir projede belki bir saatlik bir toplantıyla ihtiyaç duyulan şeylerin çoğunu karşılayabilir.

Biraz hazırlık yapmak ve projeyi anlamak isterim. Proje yöneticisinden ne aradığını öğrenirim. Ama evet, böyle bir retrospektifi oldukça gayriresmî biçimde bir veya iki saat içinde yapabilirsin.

Galen Low: Bunu daha önce de gündeme getirdin. Çevik bir çerçevede, her sprintte bir tür retrospektif yapıyor olabilirsin. Belki projenin sonunda bütün öğrenmeleri bir araya getirip bunlardan öneriler çıkarmak için bir değerlendirme daha gerekir. Ancak o iki kişi-haftasının tamamının projenin sonunda gerçekleşmesi gerekmediği fikrini sevdim.

Bu, on iki kişilik ve oldukça büyük ölçekli bir projeydi; ama bunu yapmanın daha küçük yolları da var. Sürece geldiğimizde bunu daha ayrıntılı ele almak istiyorum.

Payson Hall: Sekiz kişilik bir ekibin bütün üyelerini bir saatliğine aynı odaya getirirsen, sekiz kişi-saat elde edersin. Birkaç saat hazırlık, proje yöneticisiyle birkaç saatlik görüşme eklenince bütün işi on iki saatte tamamlayabilirsin. Buna, yol boyunca öğrendiklerimizi madde madde özetleyen tek sayfalık bir liste oluşturmak da dâhil.

Galen Low: Burada fırsat maliyeti de var, değil mi? Daha önce şeytanın avukatlığını yapıyordum ama o saati harcayıp her seferinde yarım milyon dolar tasarruf ettirecek bir ders ortaya çıkarırsan, yatırım kendini on katıyla karşılamış olur. Retrospektif yapmamanın maliyeti de var. Üzerinde düşünülmesi gereken bir şey.

Daha önce iç ekipleri örnek olarak kullanmıştın. Dinleyen birçok kişinin ajanslarda çalıştığını biliyorum. Sıkça karşılaşılan bir durum var: Bir müşteri için çalışıyorlar ve müşteri retrospektif için ödeme yapmak istemiyor çünkü “Bu, kuruluş olarak sizin gelişiminiz,” diyor.

Bu arada liderlik ekibi de yatırım yapmak istemiyor çünkü “Bu faturalandırılabilir zaman değil. Bir projenin nasıl gittiğini konuşmak için sekiz ya da on iki kişiyi belirli bir süre boyunca işlerinden alacağız ve para kazanmayacağız. Hayır, bunu yapmayalım,” diyorlar. Ben de böyle bir durumda bulundum. Bir retrospektif yapıyordum.

Bir CEO odaya girip “Herkes dışarı çıksın. Bu zaman kaybı. Faturalandırılabilir işlere dönün,” demişti. Bu benim için büyük bir uyanıştı: Bir ajansın işleyişi içinde herkes bunu değerli bulmuyor. Ancak bir projeye liderlik eden ve retrospektifin değerini gören kişiler, bu tür bir öğrenmeyi nasıl savunabilir? Ajans sahiplerini ve liderlik ekiplerini faturalandırılabilir olmayan bir retrospektifin değerini görmeye nasıl ikna edebilirler?

Payson Hall: Kibar olmak istiyorum ama CEO'nun gelip “Bir sonraki projeyi bundan daha iyi yapmamıza gerek yok,” dediği bir yerde çalışıyor olsaydım, özgeçmişimi hazırlardım. Öğrenilecek daha iyi hiçbir şey olmadığını düşünmek beni ciddi şekilde rahatsız ederdi.

Catalysis Group'u kurmadan önce dört yıl boyunca IBM profesyonel hizmetlerinde, milyonlarca dolarlık projeler üzerinde çalıştım. Haklısın; genellikle müşteri bunun için ödeme yapmaz. Kuruluş ödeme yapar.

Kuruluş ödeme yapar çünkü müşteri memnuniyeti açısından neyi daha iyi yapabileceğimizi, verimlilik açısından neyi iyileştirebileceğimizi ve süreç iyileştirmesi yapmak için nerede hata yaptığımızı anlamak ister. Özellikle danışmanlık firmalarında şunu düşünmelisin: Saat başına ne kadar ücret alıyorsun?

Değer yaratması için kaç saat tasarruf etmen gerekir? Danışmanlık yapmayanlar için belirtmek gerekirse, Mike'ın günlük faturalandırma ücreti 2.000 dolar. Bu benim kazandığım ücret değil. İdari işler yaptığımda kuruluşa maliyeti günlük 2.000 dolar olmuyor. Altı kişilik bir grupla bir saatlik idari çalışmada “Bir sonraki projede dört gün tasarruf etmemizi sağlayacak bir yol bulduk,” dersek retrospektifin maliyetini fazlasıyla karşılamış oluruz.

Bağlamı bilmiyorum. Bahsettiğin kuruluş para kaybediyor olabilir. CEO'nun sizin gelir üretmenizi istemesi anlaşılabilir. Ancak genel olarak deneyimlerime göre bunu satmak zor değildir. Yapabileceğin şeylerden biri küçük başlamaktır. Kısa bir projeyse harika; öğle yemeğinde bir araya gelelim. Bir saat ayarlayalım.

Ben daha gençken Price Waterhouse'da çalışıyordum. Her ay ortakların çalışanlar için özel bir kahvaltı düzenlemesi bana komik gelirdi ve bu kahvaltı sabah yedide başlardı.

Hepimiz sabah yedide oraya gider, bize kahvaltı ısmarladıkları için çok şanslı olduğumuzu düşünürdük. Oysa ortakların hepsi “Bu insanları personel toplantısı için iki saat erken işe gelmeye ikna ettim. Üstelik onları doyurduğum için mutlular,” diye düşünüyordu.

Profesyonel hizmet ajanslarının genellikle işlerini geliştirmeye çalıştığını düşünüyorum. Hafifletici koşullar olabilir. Bir şey yanıyorsa CEO'nun “Önce bu yangını söndürün, sonra geri dönün,” demesini anlayabilirim. Ancak küçük başlamak gerektiğini düşünüyorum. Retrospektiflerin değeri kendini gösterecektir.

Risk yönetimine benzer şekilde, retrospektiften bir kazanım elde ettiğinde veya bir risk yönetimi oturumundan bir sonuç çıkardığında ve bu seni birçok sorundan kurtardığında insanlara şunu söyle: “Bu retrospektifi yaptık, şu fikri ortaya çıkardık, bir sonraki projede uyguladık ve bize iki hafta kazandırdı.” Yöneticileri bunun zamanı iyi kullanmak olduğuna ikna etmenin yolu budur.

Ama küçük başla ki büyük bir yatırım olmasın.

Galen Low: Küçük başlayıp kanıt elde etmek, değil mi? “Bakın, bunu son yaptığımızda değer yarattı,” diyebileceğin kanıt noktaları. Bazı durumlarda izin istemek yerine af dilemek gerekebilir. Sonra elde ettiğin kanıt noktalarını göstermek bence çok güçlü.

Çoğu zaman karar vericilerin bunun değer yaratacağına dair kanıtı olmuyor. Oysa masada alınmayı bekleyen bir para var. Şu anda faturalandırılabilir saatlerle yürüyen bir proje var; odadaki sekiz kişinin tamamı o işi yapabilir ve retrospektifin bir işletmeyi geliştirebileceğini, çok değerli bir şekilde optimize edebileceğini henüz göremeyebilirler.

Payson Hall: Retrospektifin sık görülen çıktılarından biri, önemli noktaları anlatan bir doküman veya sunumdur. Bu, yöneticiler için arındırılabilir. Kurum içi sürüm ve paylaşacağınız başka bir sürüm olabilir. İyi hazırlanmışsa, yöneticilerin bazen sorunların nedeninin kendileri olduğunu anlamalarına yardımcı olabilir.

Kaynakları çok az uyarıyla yeniden dağıtmak ya da yanlış yerden tasarruf etmek gibi. “O otelin bir gecelik ücretini ödemek istemiyoruz, seni buradan doğu kıyısına gece uçuşuyla gönderelim,” demek gibi. “Tamam, vardığımda zihnen tamamen tükenmiş olacağım,” diye düşünürsün. Bu tür dersleri nazik biçimde ele almak, yöneticilerin daha verimli etkileşimlere yönelmesine yardımcı olabilir.

Galen Low: Bunu özellikle stratejik iletişim açısından beğendim. Belki aynı sürümü almıyorlardır. Liderlik ekibi, ekip sürümündeki bütün kirli çamaşırlar yerine öğrenmeleri içeren kendi sürümünü alır.

Payson Hall: Kesinlikle. Kirli çamaşır benzetmesini pek sevmiyorum. Birinin bana söylediği en akıllıca şeylerden biri şuydu: İnsanların çoğu, sahip oldukları bilgilerle ellerinden gelenin en iyisini yaparak doğru şeyi yapmaya çalışır. İstersen bir zorba gibi davranıp retrospektife şöyle girebilirsin:

“Bunu yapmadınız. Bunu da yapmadınız. Şunu yapmayı da ihmal ettiniz.” Ama mesele bu değil. İnsanların mevcut bilgilerle ellerinden gelenin en iyisini yaptığını varsayarsın. O zaman soru şu olur: Elinizde hangi bilgiler vardı? Bu bilgileri size nasıl daha erken sağlayabiliriz?

Buna yapıcı bir yaklaşım getirmeliyiz çünkü insanlar senin birini çarmıha germek istediğini düşünürse hiçbir yere varamazsın. Bunun hiçbir değeri olmaz.

Galen Low: Anladım. Sürece girmek istiyorum. Herkesi ikna ettiğimizi ve bir proje retrospektifi yapacağımızı varsayalım. Proje retrospektifi sürecin nasıl işliyor? Söz konusu projedeki proje yöneticisi benmişim gibi beni adım adım yönlendirebilir misin?

Payson Hall: Bir yıldır devam eden bir projeyi tamamladığımızı varsayalım. Büyük bir proje ve kapsamı belirlemek için on ila on iki kişilik bir ekibimiz var. Yapacağım ilk şey seninle bir toplantı düzenlemek.

Sen proje yöneticisisin. Seninle bir toplantı yapmak isterim. Temel olarak güven ilişkisi kurarız. Beni sen davet ettiysen bu kolaydır. Eğer yöneticiler veya proje ofisi tarafından sana dayatıldıysam, yapmam gereken şeylerden biri bana güvenmeni sağlamaktır. Ne bekleyeceğini bilmen için sürecin ne olduğunu açıklamam gerekir.

Sana şunu vaat etmeye çalışırım: “Seni şaşırtmayacağım. Elde ettiğim bütün bulguları başkalarından önce sen göreceksin. İtiraz etme şansın olacak. Belki fikrimi değiştirebilirsin. Bana başka veriler sunabilir veya konuya farklı bir açıdan bakmamı sağlayabilirsin.”

Bu, proje yöneticisi üzerindeki stresin büyük bölümünü azaltır. Bu ikimiz için de iyidir. Benden korkmalarını istemem. Gerçekleri saklamalarını istemem. Karşılaşacağım en büyük sorunlardan biri, insanların gerçekleri saklamaya başlamasıdır.

Bir polisle konuştuğunu ve şüpheli davranmaya başladığını düşün. Polisin kulakları dikilir, ensesindeki tüyler ürperir ve dinamiği yönetmeye başlar. Bir konuşma yürütüyorsak çok daha iyi olur. Güven ilişkisini kurduktan sonra süreci açıklar ve yapmak istediğim ilk şeyin “Neyi gerçekleştirmek üzere yola çıktığınızı anlamak,” olduğunu söylerim.

Tanım dokümanları var mı? Raporlar veya yazışmalar var mı? Projenin tanımı neydi? İyi proje yönetimi uygulamalarında, neyi başarmaya çalıştığımızı belirten bir proje sözleşmesi veya proje tanımı bulunur. Bazıları bunu diğerlerinden daha iyi yapar ama ne yapmaya çalıştığınızı düşündüğünüzü anlamam gerekir.

Sonra bunun nasıl değiştiğini anlamak isterim. Genellikle dokümantasyon ararım. “Neyi yapmaya çalıştığınızı düşünüyordunuz?” diye konuşuruz. Sonra “Bu herhangi bir yerde yazılı mıydı? Yapmaya çalıştığınız şeyin yazılı bir tanımı var mıydı?” diye sorarım.

Bu bir gereksinim dokümanı, proje sözleşmesi veya başka bir şey olabilir. Seninle projenin yol boyunca nasıl değiştiğini konuşurum. Değişiklik emirleri var mıydı? Bunları benimle paylaşabilir misin? Gerçekten anlamaya çalıştığım şey, nereden başladığınız ve zaman içinde nasıl geliştiğinizdir.

Bütün projeler gelişir. Proje ne kadar uzun sürerse, kullanılan araçlar değişir ve yazılım sürümleri güncellenir. Bu nedenle geriye çekilip bunları anlamam çok yararlı olur.

İleriye dönük olarak, uzman biri olarak yapabileceğim şeylerden biri de şu: Bir yıllık bir proje üzerinde çalıştığınızı düşünelim. Projenin üçüncü ayında PeopleSoft güncellemesi gerektiği için bir engele çarptınız. Bütün kralın atları ve bütün kralın adamları bunu yeniden kurmak için bir ay uğraştı ve projeniz bir ay gecikti.

Bulguların bir parçası olarak şunu söyleyebilirim: “Bu sizin hatanız değil. Bu talihsiz bir olaydı. Gelecekte bu yazılımı proje sırasında güncelleyip güncellemeyeceğimizi önceden belirlemeliyiz. Güncelleyeceksek takvimde buna zaman ayırmalıyız.”

Buna, senin yapamayacağın bir açı kazandırabilirim çünkü “Bir dakika, bunu projenin ortasında güncellediler,” dediğinde savunmaya geçiyormuşsun gibi görünebilir. Ben ise gelip “Bu tür şeyler olur. Evet, talep berbattı ama mevcut bilgilerle makuldü,” diyebilirim.

Her neyse, seninle konuşup ne beklemen gerektiğini anlatırım. İlk adımım, seni fazla meşgul etmemek için mümkün olduğunca çok ön çalışma yapmaktır. Tanım, değişiklik emirleri, risk yönetimi ve hazırladığın durum raporlarının tümü incelenir.

Dinleyicilerine küçük bir not: Proje yönetimi eğitimi almanın en iyi yollarından biri bir yıllık durum raporlarını okumaktır. Bir kahve al, otur ve bir yıllık durum raporlarını baştan sona oku.

Bazen ikinci ayda küçük bir olay yaşandığını, üçüncü ayda biraz daha büyüdüğünü ve dördüncü ayda tam anlamıyla bir soruna dönüştüğünü görürsün. İnsanlar gerçeği saklamıyordu; önemini fark etmemişlerdi.

Bir proje incelemesinde üzerinde çalıştığım bir proje vardı. Bu daha çok bir otopsiydi. Ekiple çalışmadım, yalnızca verileri aldım. Yeni bir sistem kurması gereken bir hastaneydi.

İlk ay “Ay sonunda yeni binamıza taşınacağız,” dediler. İkinci ay “Yeni binaya taşınmamızla ilgili bir sorun var ama ay sonunda taşınabilmeliyiz,” dediler. Üçüncü ay “Başka bir sorunla karşılaştık ama...” dediler.

Bu bir yıllık bir projeydi ve çalışmaları gereken tesise sahip olmaları gerekiyordu. Proje yöneticisini suçlamıyorum ama aciliyet duygusu yoktu. Gerçeklere tepki veriyordu. “Bu benim kontrolüm dışında. Bir ay daha sürecek,” diyordu.

Ben olsaydım alarm zilleri çalmak ve büyük bir aciliyet yaratmak isteyebilirdim: “Burada bir sorunumuz var. Bunu tırmandırmamız ya da bir yıllık proje hakkındaki beklentilerinizi yeniden düzenlememiz gerekiyor.”

Her neyse, durum raporlarını inceleyeceğim. Bir süre kendimi dışarı kapatacağım. Nedense bunun her zaman bir cumartesi günü olduğunu düşünürüm. Hepsini inceler ve anormalliklerle ilgili notlar alırım. Takvim nerelerde sıçramış? Durum raporlarında, risk günlüğünde veya değişiklik günlüğünde bu sıçramayı açıklayan bir konuşma var mı?

Kenara notlar alırım ve Excel'de veya Word'de kaba bir zaman çizelgesi oluştururum. Çünkü orada değildim; olaydan sonra tarih yazmaya çalışan bir tarihçi gibiyim. Sonra proje yöneticisiyle konuşup boşlukları doldurmaya ve ek bilgi almaya çalışırım.

Proje yöneticisi yardım etmek için orada olduğumu anladığında ve ben de projeye yöneldiğimde, ekipten hazırlanmak için 60 ila 90 dakika ayırmasını isteriz. Onlardan üç şeyi düşünmelerini isterim.

İnsanların evlenmesi ve çocuk sahibi olması gibi hangi ilginç olaylar yaşandı? Proje sırasında neler oldu? Şanslı veya akıllıca yaptığımız şeyler nelerdi? “Bunu tesadüfen yaptık ama gerçekten iyi bir fikirdi,” dediğimiz ne oldu?

Ya da sahaya gittik ve yanımızda branda getirmedik. Neyse ki Galen'in bagajında tesadüfen bir branda vardı. Yağmur yağdığında suyun çukuru doldurmasını önlemek için yanımızda bir branda taşımak iyi bir fikir olurdu.

Karşımıza çıkan engeller nelerdi? Hangi sorunlar bizi yavaşlattı? Yazılım sorunu önemsiz sanılmış ama çok zor çıkmış olabilir. Yazılım proje ortasında güncellenmiş ve bizi geriye atmış olabilir. Veritabanı yöneticisi Mary Sue kritik bir zamanda COVID olmuş ve iki hafta işe gelememiş olabilir.

Ekipten yalnızca iki veya üç ilginç olayı, akıllarında kalan şeyleri belirlemelerini isterim. Çünkü Rashomon etkisinde olduğu gibi herkes olanlarla ilgili farklı bir bakış açısına sahip olacaktır.

Sonra duvara kâğıtlar asıp, durum raporlarından çıkarabildiğim önemli kilometre taşları ve olaylarla kaba bir zaman çizelgesi oluştururum. Böylece herkes konuya hâkim olur. İnsanlar geldiğinde süreci açıklar, herkese yapışkan notlar verir ve “Hangi olaylar yaşandı?” diye sorarım.

Susan evlendiğinde çok eğlenmiştik. Harika, bunu zaman çizelgesine ekleyelim. Böyle olayların güzel tarafı, insanları zamana göre konumlandırmalarıdır. Susan'ın evlenmesinden önce olan şeyler ve sonrasında olan şeyler vardır. Mayıs olduğunu hatırlamayabilirler ama Susan ne zaman evlendiğini bilir.

Sonra “Susan evlendikten hemen sonra şu olay yaşandı,” diyebilirler. Bu olayları zaman çizelgesine ekleriz. Bu bir ısınma çalışmasıdır. Bunlara, zaman içindeki anlar olmaları dışında bir anlam yüklenmez.

Sonra iyi şeylerden bazılarını konuşabiliriz. “Jim'i işe aldık. Ekibe yeni katılmıştı ve düşündüğümüzden çok daha fazla becerisi vardı.” Bu gerçekten faydalıydı. Bunu da ekleyelim.

Bizi yavaşlatan engeller nelerdi? Yağmur, elektrik kesintisi veya başka bir şey olabilir. Projenin nasıl geliştiğini insanların görsel olarak anlayabilmesi için bir zaman çizelgesi oluştururuz. Bu da insanların başka konuları hatırlamasını ve konuşmasını sağlar.

Belirli bir örnek hatırlıyorum. Zaman çizelgesini oluşturuyorduk ve ortalara doğru proje yöneticisi “Burada gerçekten yavaşladık. Birkaç önemli paydaştan çok fazla soru almaya başlamıştık ve bu çok zamanımızı aldı,” dedi.

Başka neler olduğunu konuştuklarında fark ettiler ki yeni bir paydaşın yerine başka biri getirilmişti ve bu paydaşı konuya dâhil etmek için zaman ayırmamışlardı.

Bu bir hata değildir. Mermilerden kaçıyor, saatte yüz kilometre hızla koşuyorsundur. “Mary Sue yok, Jim geldi,” diye bir not alırsın. “Tamam, onu arayıp konuşmalıyım,” dersin ama aslında bir saat ayırıp “Neyi başarmaya çalışıyoruz? Senin rolün ne? Benim rolüm ne? Şu anda neredeyiz? Zorluklarımız neler?” diye anlatman gerekebilir.

Bunu atlamak kolaydır ama çok tehlikeli olabilir. Zaman çizelgesini oluştururken paydaş değişikliğinin birkaç ay boyunca dalgalanmalara ve karmaşaya neden olduğunu fark ettiler. Ekip sürekli işinden alınıyor ve farklı sorulara cevap vermesi isteniyordu.

Zaman çizelgesini görünce biri “Sponsor değişikliğinin olduğu dönem bu,” dediğinde “Şimdi anladım,” dersin. Fikir, zaman çizelgesini oluşturduğumuzda insanların önemli olayları zihninde konumlandırmasıdır.

Sonra geçmişe dönük risk yönetimi yaparız. Bu, şimdiye kadarki en kolay risk yönetimi oturumudur. Bir yazı tahtasına gidip “Önemli olaylardan bazıları bunlar. İyi veya kötü haberler,” deriz.

Sonra üç soru sorarız. Bunu daha erken tespit etmek için ne yapabilirdik? Fırsatı, riski veya sorunu daha erken görmek için ne yapabilirdik? Bazen hiçbir şey yapamazdık. Bunu konuşur ve not alırız.

İyi şeylerin olma ihtimalini artırmak veya kötü şeylerin olma ihtimalini azaltmak için ne yapabilirdik? Bazen yine hiçbir şey yapılamaz.

Kötü şeylerin etkisini azaltmak veya iyi şeylerin faydasını azaltmak için ne yapabilirdik? Örneğin on dört dizüstü bilgisayar almamız harikaydı. Gelecekte bunları iade etme hakkımız olmalı.

Hepsi tamamen kullanılabilir durumdaydı ve elimizde fazla stok kalmıştı. Fazladan iki bin dolar harcamamızın nedenini açıklamak zorunda kalmayız.

Bunun sonucunda ekip katkı sağlar. Bu, geleceği tahmin etmek değildir. Geçmişe bakıp “Kendimize şişe içinde bir mesaj gönderebilseydik bunları farklı yapardık,” demektir.

Bu, nihai raporun ilk taslağıdır: Ekip ne yapmak üzere yola çıktı? Neyi başardı? Maliyeti ne oldu? Ne kadar sürdü? Yol boyunca takdire değer şekilde yaptığı şeyler nelerdi? Talihsiz olan veya takvim, kapsam ya da kaynak baskısı yaratan olaylar nelerdi?

Gelecekte bunları hafifletmek veya azaltmak için ne yapılabilir? Retrospektif raporunda telefon rehberi gibi uzun bir doküman istemezsin; kimse okumaz. Bir veya iki sayfa ya da “Süreç iyileştirmesi için kullanabileceğimiz birkaç önemli çıkarım,” diyen kısa bir özet slaytı yeterlidir.

Galen Low: Derinlik hakkında konuşalım. Proje boyunca gerçekleşen kilometre taşlarını ve olayları toplamaktan bahsediyoruz. Herkes zaman çizelgesini anlamaya çalışıyor. Bazı kişiler on, on beş, yirmi olayla gelebilir. Bunları tahtaya eklerken ayrıntılı biçimde tartışıyor musunuz? Yoksa çoğunlukla tespit edip daha sonra dönerek üç soruyu sormak mı söz konusu?

Payson Hall: Bu bir değerlendirme meselesidir. İnsanlara bir aydınlanma yaşamaları için yeterli zaman vermek isterim. Toplantının gereğinden fazla uzamasına veya konuşmanın kesilmesine neden olacak bir tavşan deliğine girmek istemem.

Kök neden analizini ne kadar yapacağız? Verimli olduğu sürece üç veya beş dakika konuşalım. Üç dört dakikanın sonunda konuşma artık verimli olmuyorsa “Bunu ele alalım ve bu küçük araştırmayı konuyla en yakından ilişkili kişilerle toplantı dışında yapalım. Sonuçları tekrar aktarırız,” derim.

Galen Low: İşte bu yüzden kolaylaştırıcılık becerisine ihtiyaç var. Toplulukta sıkça şu konuyu konuşuyoruz: Bir proje yöneticisinin veya proje ekibindeki herhangi bir kişinin kolaylaştırıcılıkta iyi olması gerekir mi? Bunun yardımcı olduğunu söylemeye devam edeceğim çünkü kolaylaştırmıyor olsan bile dünyadaki bütün sorunların o oturumda çözülemeyeceğini anlarsın.

Bazı şeyler toplantı dışında ele alınır ama büyük konular hakkında konuşmak, iyileştirme alanlarını görmek ve projenin kendisi sırasında ortaya çıkan iyi uygulamalardan veya akıllıca fikirlerden yararlanmak istersin.

Payson Hall: Kesinlikle. Bunun faydalarından biri, ister kuruluş dışından ister proje dışından biri olsun, iyi bir kolaylaştırıcıya sahip olmaktır. Ben iyileşmekte olan bir mühendisim. Gerçekten iyi bir problem sunulduğunda, herkes gibi ben de derinlemesine incelemek ve hakkında konuşmak isterim.

“Bunu daha önce görmüştüm, şöyle çözülmüştü. Evde bu konuda harika bir kitap var,” diye düşünürüm. Ama bu yardımcı olmaz. Birinin “Yapıcı bir ilerleme kaydediyor muyuz? Bu, gerçekleştirmeye çalıştığımız daha büyük hedefe nasıl uyuyor?” demesi gerekir.

Galen Low: Bunu, gelecekte başka projeleri üstlenecek kişilerle veya bu projeye ileride geri dönecek gelecekteki hâlinle paylaşabileceğin bir raporun ilk taslağı olarak görme fikrini sevdim. Kimse kök nedeni incelemek için büyük bir Ishikawa diyagramına dalmak istemez.

Tüm oturumda çözdüğümüz tek sorun bu olurdu. Retrospektifimizden bir ders çıkardık ama en azından kök nedeni biliyoruz. Derinlik konusunda bir değerlendirme yapmanın gerekliliğini anlıyorum ve bunu gerçekten sevdim.

Ayrıca birçok kişinin buna böyle bakıp bakmadığını bilmiyorum ama önemli olduğunu düşünüyorum. Bunun geçmişe dönük risk yönetimi olduğunu söyledin. Birçok kişi risk yönetimini geleceğe dönük bir iş olarak görüyor: Gelecekte iyi şeylerin gerçekleşmesine nasıl yardım ederiz ve kötü şeylerin gerçekleşmesini nasıl önleriz?

Herkes retrospektifi risk yönetimiyle ilişkilendirmiyor olabilir. Ancak yinelemeli retrospektifler hakkında, projenin belirli bir aşama kapısında veya proje sonrasında söylediklerin bunu birbirine bağlıyor.

Bu, geçmişteki hâline göndermek istediğin ama gelecekteki başkalarına gönderdiğin şişe içindeki mesaj gibi. Böylece yaşanan kötü bir olaydan nasıl kaçınacaklarını veya gerçekleşebilecek iyi bir şeyden nasıl yararlanacaklarını öğrenebilirler.

Payson Hall: Kesinlikle. Buradaki temel fikir, konunun kimin iyi veya kötü çalıştığı değil, neyin işe yarayıp neyin yaramadığı olmasıdır.

Kolaylaştırıcının bütün görevi budur. Bu bir suçlama meselesi değildir. Sana şunu söyleyeyim: Bir podcast'te ne kadar akıllı olduğumu ve bütün bu akıllıca şeyleri nasıl yaptığımı anlatmak kolaydır. Bir ekiple çalışıyordum. Ekip bir projeyi yeni bitirmişti ve bir sonraki projeye başlamalarına yardımcı oluyordum.

Yeni bitirdikleri proje hakkında retrospektif yapacaklardı ve gerçekten aptalca bir şey yaptım. Kendimi davet ettim. “Gelmem uygun olur mu?” dedim. Sana turist istemediğini, yalnızca projeye dâhil olan kişileri istediğini söylemiştim.

Ekipten biri retrospektife katılmayacağını söyledi. “Projenin ters giden her şeyinden beni sorumlu tutacaklar,” dedi. Bu sözler dikkatimi çekti. “Peki, bunu merak ettim,” dedim.

Retrospektife gittim. Ben gözlemciydim ve oturumu yöneten kişi berbattı. Gerçekten kötü bir kolaylaştırıcıydı. “Bundan kim sorumluydu?” diye sormak istiyordu. Oysa retrospektifte sorduğumuz soru bu değildir.

Ekibe hayran kaldım. “Şu oldu, sonra bu oldu, şu parça hazır değildi,” diye konuştular. Kolaylaştırıcı “Bunu kimin yapması gerekiyordu?” diye sordu. Ekip, kendisine büyük saygı duymamı sağlayacak şekilde, “Bunu kimin yaptığı gerçekten önemli değil. Olan buydu,” dedi ve adamı hedef göstermeyi reddetti.

Daha sonra bu kişinin alkolik olduğunu ve ciddi bir sorunu bulunduğunu öğrendim. Bütün bunlardan gerçekten o sorumluydu ama ekip bunun bu kolaylaştırıcıyla paylaşılacak bir şey olmadığını biliyordu. Ayrıca bunun konuyla ilgisi yoktu.

Birinin ilgilenmesi gereken kişisel bir sorun vardı. Projede ne öğrendiğimiz hakkında konuşalım. Orada olmayan kişiyi suçlamamak için yorgun ve öfkeli bir grup insana bu kadar disiplin ve empatiyle davranacağı konusunda asla güvenemezsin.

Bu olağanüstü bir ekipti. Bu nedenle turist istemezsin. Kolaylaştırıcının ne yaptığını ve konunun ne olduğunu bilmesini istersin. “Süreci nasıl geliştirebiliriz?” diye konuşmak gerekir; “Kimi suçlayacağız?” diye değil.

Bence temel kural şu: Herkesin sahip olduğu bilgilerle elinden gelenin en iyisini yaptığını varsay. Doğru becerilere sahip olmayabilirler. Bu proje yöneticisinin hatasıdır. Ancak bana yapay zekâ konusunda uzman olduğunu belirten bir özgeçmiş verdiysen ve sana basit bir yapay zekâ görevi verip bunun altında ezildiysen, bu proje yöneticisinin hatasıdır. Beceri ile görev arasında yanlış eşleşme vardır.

Bunun proje yöneticisinin hatası olduğunu söylememize gerek yok. “Bu alanda sahip olduğumuzu düşündüğümüz becerilere sahip değildik,” deriz. Mesele Simon'un bu eğlence parkı aracına boyunun yetmemesi değildir; benzer bir projeyi yürüteceksek bu alandaki becerilerimizi güçlendirmemiz gerekir.

Galen Low: Bunların çoğu, süreci nasıl tasarladığının dokusuna işlenmiş durumda.

Birçok kişi bana “Bir oturumda psikolojik güvenliği nasıl yaratabilirim?” diye soruyor. Cevabın bir kısmı şu: Oturumdan önce çekinceleri olabilecek kişilerle otur, konuş, güven ve ilişki kur, süreci açıkla ve temel kuralları belirle.

“Şimdi başlayacağımız bu oturumda kimin yaptığını değil, ne olduğunu soracağız,” dersin. Herkesi bu fikre dâhil eder ve sonrasında bunu sürekli pekiştirirsin.

Diyelim ki o oturumda kolaylaştırıcı sen olsaydın ve bir katılımcı “Bu muhtemelen Brad'in hatasıydı,” diyerek suçlama oyununa başlasaydı, insanlar parmak göstermeye ve toplantı bir cadı avına dönüşmeye başlasaydı, ortamı nasıl yeniden yönlendirirdin?

Payson Hall: İlk seferinde sarı kart gösterirsin. “Bu kimin ne yaptığıyla ilgili değil. Herkesin elinden gelenin en iyisini yaptığını varsayacağız. Ne olduğunu ve sonuçlarının ne olduğunu konuşmak istiyoruz,” dersin.

Bağlama göre ikinci kez de sarı kart gösterebilirim. “Bir ara verelim,” der ve o kişiyi kenara çekip konuşurum. “Bu kimin hata yaptığıyla ilgili değil. Bunu daha sonra seninle ve proje yöneticisiyle konuşabiliriz ama bu toplantı ne öğrendiğimiz, neyin işe yaradığı ve neyin yaramadığı hakkında. Kimin iyi, kimin kötü çalıştığı hakkında değil. Çünkü bu yapıcı değil. Geçmişi değiştiremeyiz; ondan ders çıkarabiliriz,” derim.

Galen Low: Bunu sevdim. Diğer taraftan, çerçevelemeden bahsediyoruz. “Belki doğru becerilere sahip değildik,” diyoruz ve bu rapora giriyor. Sonra yönetim ekibinden biri bunu okuyup satır aralarını yorumluyor ve “Evet, bu muhtemelen Brett'in hatasıydı,” diyor.

Bu yorumu önlemek için yapabileceğin bir şey var mı?

Payson Hall: Brett'in bu eğlence parkı aracına boyunun yetmemesi kişisel bir sorunsa, onunla ilgilenmemiz gerekir. Bunun rapora girmesini istemem. Proje yöneticisinin bunu ele almasını tercih ederim.

Rapora giren şeyler genellikle şunlardır: Yöneticilerin, proje yöneticisinden farklı öncelikleri olabilir. Daha yüksek öncelikli bir proje kontrolden çıkmaya başlar ve senin en iyi çalışanlarından birini sorunu çözmesi için başka yere gönderirlerse bu onların tercihidir.

Retrospektifin fikri şudur: “Bu projenin bir sonucu oldu.” Yöneticileri suçlamadan şöyle diyebiliriz: “Proje için bir kadro planımız vardı ama çeşitli nedenlerle insanlar projenin ortasında yeniden görevlendirildi. Birisi COVID oldu veya biri kaçtı ve projede kaynak sorunları yaşadık.”

Gelecekte daha iyi anlaşmalar yapmalı ve kaynakların başka yere yönlendirilmesi gerektiğinde proje yöneticisine mümkün olduğunca önceden haber vermeliyiz. Böylece proje yöneticisinin tepki vermek ve yerine başka kaynak bulmak için daha fazla zamanı olur.

Bu kişilerin yanlış bir şey yaptığını söylemiyorsun. “Bu oldu ve bir sonucu vardı. Bundan kaçınmak için gelecekte şunları yapabiliriz,” diyorsun.

Galen Low: Raporda ne olması gerektiğiyle ilgili bu ölçütü sevdim. Elbette projeye dâhil olan ekibe başvurmak gerekir ama öğrenebileceğimiz proje sorunlarıyla, bu raporda yeri olmayan kişisel sorunlar arasında fark var. Bunların proje yürütme biçimiyle değil, personel alımı ve uygun kişilerin seçilmesiyle ilgisi var.

Payson Hall: Raporun dili de diplomatik olmalı. Bir danışman olarak, bebeğin çirkin olduğunu söylemem için para alırım ama bunu durumu alevlendirmeyecek şekilde söylemenin yolları vardır. Öğrenilen dersleri anlatırken kullandığın dilde diplomatik olmalısın.

Temel olarak yapmak istediğin şey, bunu mümkün olduğunca olumlu hâle getirmektir. “Bunu yaptık. Gelecekte farklı yapmak için önerilerimiz şunlar,” de. “Tanrım, bunu gerçekten berbat ettik,” deme. Bu yardımcı olmaz. İnsanlar o zamanki mevcut bilgilerle ellerinden gelenin en iyisini yapıyorlardı.

Galen Low: Bunu sevdim. Retrospektife hazırlanma, dokümantasyonu inceleme, kilometre taşlarını zaman çizelgesine yerleştirme, bunları tartışma ve gelecekte gerçekleşen iyi şeylerden nasıl yararlanabileceğimizi veya kötü şeylerden nasıl kaçınabileceğimizi konuşma sürecinden geçtik.

Sonra bunlar rapora giriyor. Ancak insanlardan en sık duyduğum şey şu: “Retrospektif yapmayacağız çünkü ne yapacağız? Bir rapor hazırlayacağız, kimse okumayacak veya yanlış yorumlayacak, sonra da bir yerde rafta duracak.”

Sonra diğer proje ekiplerinin, hatta bizim kendi ekiplerimizin, aynı sorunlara tekrar tekrar çarptığını izleyeceğiz. Kolaylaştırıcı olarak veya kuruluşlar genelinde bu önerilerin tozlanmak yerine gerçekten değişime yol açmasını nasıl sağlayabiliriz?

Payson Hall: Söylediklerini parçalara ayıralım. Büyük sorunlardan biri, bulgular ve öneriler içeren otuz sayfalık bir rapor hazırlarsam kimsenin okumayacak olmasıdır. Bu nedenle kısa olmalıyız. Önceliklendirmeliyiz.

Proje yöneticisi olarak “Daha iyi yapabileceğimiz altı şey var,” diyebilirsin. Ben de “Bunlardan ikisini veya üçünü seç. Bunları düzenleyip mesajın yöneticilere ulaşmasını sağlayalım,” derim.

İnsanları eylem maddeleriyle bunaltmadığımızdan emin olmalıyız. Özellikle hâlâ öğrenme aşamasındaki genç kuruluşlar için bu zor bir dengedir. Seçim yapmalıyız. Diğerlerini bir dahaki sefere ele alırız ama yine de onları bilirsiniz ve ekip de onları bilir.

Resmî olarak PMO'ya veya yönetim ekibine “Kuruluşumuzun daha iyi yapabileceğini düşündüğümüz iki veya üç bulgu var,” dersin. Listeyi önceliklendirmelisin ki insanlar bunalmayıp “Tamam, iyi,” diyerek bir kenara bırakmasın.

Daha kapsamlı bulgular ve akıllıca yaptığınız şeyler retrospektife katılan herkes tarafından bir sonraki projeye taşınır. Resmî ve gayriresmî olmak üzere iki bölüm vardır. Bence geminin yönünü değiştiren asıl şey gayriresmî kısımdır.

Retrospektif yapıp sonuçları herkes için büyük bir kurumsal veritabanına yüklediğinize dair bir efsane var. Bulunduğum hiçbir kuruluşta bunun başarıldığını görmedim. Fikir güzel: “Bunu PMO'ya göndereceğiz, onlar da öğrenilen dersler listesini tutacak.” Ama bunun yapıldığını hiç görmedim çünkü çok bunaltıcı ve bağlama çok özgü.

Bu nedenle en iyi şeyin, yönetim ekibine iletilecek iki veya üç öneri olduğunu düşünüyorum. Toplantı odalarını yeniden planlamaktan bahsettin. Önemsiz olmayan projelerde sıkça öğrenilen derslerden biri, özel bir savaş odasına sahip olmaları gerektiğidir.

Toplantıları anlık olarak yapabilecek bir yere sahip olmanın ne kadar değerli olduğunu düşün. COVID'den sonra çok fazla boş alan olabilir ama çoğu ofisin kalabalık olduğunu ve eğitim veya toplantı odası bulmak için uzun süre arama yapman gerektiğini düşün.

Küçük ve özel bir savaş odası ekip için büyük bir tasarruf sağlayabilir. İnsanların toplantının nerede olduğunu bulmaya çalışarak ne kadar zaman kaybettiğini düşün. Özel bir odaya sahip olarak hızlıca kişi-haftaları tasarruf edebilirsin.

Bu, listenin üst sıralarına çıkabilecek bir şeydir. Yöneticiler bunu ilk veya ikinci seferde duymayabilir ama üçüncü ya da dördüncü kez gördüklerinde “Bunu sürekli söylüyoruz ama yapmıyoruz,” diyebilirler. Belki sonunda mesajı alırlar.

Galen Low: Bu ayrımı da sevdim. Bazıları için mantıklı olabilir ama evet, stratejik öneriler ve stratejik iletişim var. Uzun bir roman yazmamalı, ele alınacak yüksek öncelikli konuları seçmelisin. Bir de ne olursa olsun gerçekleşen gayriresmî bir öğrenme düzeyi var.

Bence birçok kişi bunu yeterince takdir etmiyor. Daha önce retrospektife katılan herkesin yanında bir tohum taşıyacağını ve bunu bir sonraki projesine götüreceğini söylemiştin. Bu çok büyük ve muhtemelen ölçülemeyen ama sürecin bir parçası olarak kesinlikle konuşulması gereken bir şey.

Bir rapor hazırlayacağız ama konuştuğumuz her şeyi insan olarak, zihnimizde, bir kâğıda yazmak zorunda kalmadan öğreniyoruz. Ortak deneyimimize katkıda bulunuyoruz. İnsanların farklı şeyleri hatırlayacağı o zaman çizelgesi bile buna dâhil.

Söylediğin Rashomon etkisi de bunun bir parçası. İnsanlar bundan da ders çıkarıyor ve deneyimi yanlarında taşıyor. O anda hatırlasalar da hatırlamasalar da bunu tartışma fırsatı buldular. Etkisinin ne olduğunu ve gelecekte bunu nasıl iyi kullanabileceklerini veya kötü sonuçlardan nasıl kaçınabileceklerini öğrendiler. Bence gerçekten harika.

Payson Hall: Risk yönetiminden bahsettiğimiz konuşmamızın başına dönersek, çoğu planlama sürecinde çekirdek ekibi bir odaya getirip “Gelecekte karşılaşabileceğimiz riskleri konuşalım,” deriz.

Son iki ay içinde bir retrospektiften çıktıysanız, bu olayları risk olarak düşünmeye hazırsınızdır. Şunu söyleyebilirsiniz: “Son projemizde bunu yaptık ve kendimizi zor durumda bıraktığımızı fark ettik. Keşke şöyle yapsaydık.”

Üstelik bu düşünce zihninizin en üstündedir ve varsayımsal değil, gerçek bir deneyimden gelir. “Bununla karşılaştık, şunu yaptık ve harika bir fikirdi. Bununla karşılaştık, şunu yaptık ve berbat bir fikirdi,” diyebilirsiniz.

Bunları masaya yatırmak iki şey yapar. Birincisi, o projedeki risk yönetimini iyileştirir. İkincisi, odadaki herkes hikâyenizi duyar. Böylece deneyim kuruluş içinde organik olarak yayılmaya devam eder.

Galen Low: Hikâye kelimesini de sevdim çünkü gerçekten olan bu. Veritabanı zihnimizdir ve bir projede olanlar, birbirimizle paylaşabileceğimiz ve bilgi aktarabileceğimiz bir hikâyedir.

Bence bu iyi bir geçiş oldu çünkü sonunda dinleyicilerden bazı sorular almak için zaman ayırmayı planlamıştım. Sorulardan biri perspektif veya bazı kişilerin deyimiyle ön otopsi fikriyle ilgiliydi. Bence bunu bir açıdan cevapladın: Evet, bu risk yönetimidir.

Sonrasının yerine öncesini yapabilirsin. Peki ikisini birden yapmak hakkında ne düşünüyorsun? Risk yönetimi yinelemeli retrospektiflerle nasıl ilişkilidir? Çevik çalışıyor, sprintler yürütüyor ve retrospektif yapıyorsanız, ayrıca geleceğe dönük ayrı bir risk yönetimi toplantısı da yapıyor musunuz, yoksa bunlar birbiriyle birleşiyor mu?

Payson Hall: Bence birleşiyorlar. Çevik bir retrospektifte çoğu zaman şunu sorarsın: Engeller neler? “Keşke farklı yapsaydık,” dediğiniz şeyler neler? Verimsiz yaptığınız şeyler neler? Bunlar bir sonraki sprintte riskleri azaltmak için yapılacak işlere dönüşür.

Çevik bağlamda retrospektif ve risk yönetiminden aynı anda söz ederiz. Öğrenilen dersleri alıp “Bunu bir sonraki sprinte nasıl uygulayabiliriz?” diye sorarız. Bence bu gerçekten sağlıklı.

Galen Low: Kesinlikle. Bu konuşmaları yapmak önemli çünkü ilişki burada. Bir sonraki sprinte, geleceğe gidiyorsun. Her şey yalnızca dikiz aynasına bakmak değil ama aynı konuşma devam ediyor.

Bir soru daha almak istiyorum. Çok fazla zamanımız kalmadı ama birçoğuna yol boyunca değindiğimizi düşünüyorum. Bu soru özellikle öne çıktı.

Proje sırasında olan şeylerden bahsediyoruz. Bazen bunlar proje ekibindeki kişilerin yaptığı seçimlerdir ama bazen sorunlar proje ekibinin aldığı kararların ötesine geçer. Daha çevresel olabilir.

Örneğin, sorunun kök nedeni proje ekibinin kilit kaynaklarının başka bir projeye aktarılmasıysa, bunu nasıl yakalar ve projenin dışındaki değişimi etkileyebilecek şekilde yukarıya raporlarsın? Bu, proje ekibinin yaptığı bir şey değil, dışarıdan gelen bir etkidir.

Bunu önerilerde ve raporlarda nasıl gösterirsin? Proje bağlamının dışında değişimi nasıl etkilersin?

Payson Hall: Bulgular açısından düşünme eğilimindeyim. Bulgu şu olabilir: “Ekip üyeleri daha yüksek öncelikli bir projeye yönlendirildiği için proje zorluklarla karşılaştı.”

Bu, durumu ifade etmenin oldukça tarafsız bir yoludur. Yöneticilere şüphe payı tanımak için bunların daha yüksek öncelikli projeler olduğunu varsayar.

Bulgu şu olur: “Kaynakların bazıları projenin ortasında başka konulara yönlendirildiği için proje kaynak zorlukları yaşadı.”

Öneri ne? Projeye daha fazla personel eklemeyi veya personel sayısını artırmayı düşünmek. Böylece biraz daha fazla kaynak esnekliğiniz olur.

Bir diğer öneri, personeli başka yere yönlendirmeniz gerektiğinde proje yöneticisine mümkün olduğunca önceden haber vermenizdir. Böylece daha fazla tepki verme ve yerine kaynak bulma zamanı olur.

Bunu böyle çerçevelersen kimsenin yanlış bir şey yaptığını söylemezsin. “Bu oldu, bir sonucu oldu ve gelecekte bundan kaçınmak için şunları yapabiliriz,” dersin.

Galen Low: Bulgu kavramını sevdim. Son bir soru soracağım. Bir retrospektifte odaklanılması gereken en önemli konular nelerdir? Birçok kişi finans, süreç, uygulama veya yöntem gibi farklı alanlarla ilgileniyor ama zaman sınırlı. Bu sınırlı zamanla en iyi sonucu almak için neye odaklanmayı önerirsin?

Payson Hall: Bunun bir kısmı bağlama bağlıdır. Ancak deneyimlerime dayanarak şunu söyleyebilirim: Paydaşlar, sponsor ve müşteriyle birlikte net biçimde tanımlanmış ve onaylanmış bir hedef var mı?

Bu hedef geliştikçe etkili bir değişiklik yönetimi sürecimiz var mı? Bu bilinçli bir seçimdir. “Noel ağacına birkaç süs daha eklemek istiyorsanız bunun maliyeti daha yüksek ve süresi daha uzun olur,” dersin.

Bu tek günah değildir ama birçok zincirleme soruna kılık değiştirerek neden olan ilk günahlardan biridir.

“Bunu gerçekten hafife aldık.” Hayır, tahmin konusunda iyi iş çıkardın. Sonra proje büyüdü ve sahaya bayrak dikerek “İş miktarını artırıyorsunuz ama bize daha fazla kaynak vermiyorsunuz,” demedin.

Galen Low: Evet, bunu sevdim. Bunların hepsi arasında bir ilişki var. Paydaşlarla ortak zeminin ne olduğunu ve bu konuşmaya uygulanacak en değerli bakış açısının ne olacağını söylemeni sevdim. Çok güzel.

Sanırım süremiz doldu. Payson, bugün bizimle olduğun için çok teşekkür ederim. Seni programda ağırlamak büyük bir onurdu. Dinleyicilerimizin gitmesine izin vermeden önce, Catalysis Group'da yaptıkların hakkında daha fazla bilgi edinmek isteyenler sana nasıl ulaşabilir?

Payson Hall: catalysisgroup.com adresine gidersen eğitim ve danışmanlık hakkında bilgi bulabilirsin. Kaynaklar bölümüne gidersen risk yönetimi hakkında indirebileceğin birkaç makale var. Bunlar risk yönetimi oturumunun nasıl yürütüleceğini anlatıyor ve retrospektif için de çok yararlı bir kaynak olacaktır.

Galen Low: Harika. Payson'un çok eğlenceli bir yazar olduğunu doğruluyor. Senden okuduğum her makalede yüksek sesle güldüm ama aynı zamanda o hikâyeyi de yanımda taşıdım. Retrospektiflerin ve risk yönetiminin sıkıcı olduğunu düşünenler için Payson'un çalışmalarına göz atın. Bağlantıyı aşağıdaki program notlarına ekleyeceğim.

Dinleyicilerimiz için umarım bu konuşmadan çok şey almışsınızdır. Ulaşamadığımız birkaç soru oldu; bunları toplulukta gündeme getirip üzerine konuşacağız.

Payson Hall: Ayrıca bana e-posta göndererek soru iletmek isterseniz, görüşmeyi bitirdikten sonra aklınıza gelen soruları memnuniyetle yanıtlarım.

Galen Low: Pekâlâ millet, işte böyle. Her zamanki gibi, binden fazla benzer düşünceli proje yönetimi savunucusuyla sohbete katılmak isterseniz topluluğumuza katılın! Daha fazla bilgi edinmek için thedigitalprojectmanager.com/membership adresine gidin. Bugün duyduklarınızı beğendiyseniz lütfen abone olun ve thedigitalprojectmanager.com üzerinden iletişimde kalın.

Bir sonraki sefere kadar, dinlediğiniz için teşekkürler.