KURUMSAL RİSK Mİ, PROJE RİSKİ Mİ? 

💭 Projelerde risk yönetiminin ne kadar önemli olduğunu biliriz. Risk planları hazırlanır - ancak çoğu matbu form şeklindedir-. Risk kayıtları oluşturulur, puanlandırılır vs. vs. 💭

👉 Bu detaylara girmek istemiyorum. Projelerde riskler belirlenirken çoğu zaman projenin riski ile kurumsal riskler birbirine karıştırılır. 🔊

‼️ Kurumsal seviyede çözülmesi gereken risklerin, projenin riski olarak yazılmasının sakıncası vardır. Kurumsal risklerin üst yönetim tarafından çözülmesi, yönetilmesi gerekir.

👉 Proje kapsamında kurumsal riskleri çözmeye çalışmak nafile çabadır.

💬 Örnek vermek gerekirse; şirketin personel sayısının yetersizliği ve personel sirkülasyonu (turnover) fazla ise bu bir kurumsal risktir. Bu risk için proje kapsamında yapılabilecek fazla bir şey yoktur. 💬

👉 Bu riskin proje riski olarak ele alınması demek, risk için bir şey yapmamak demektir. Proje yönetici riski önlemek için personel alamaz, ama ancak raporlayabilir.

‼️ Dolayısıyla riskin tanımlanmasının yanı sıra kapsamının da netleştirilmesi önemlidir.

💥 Ha! Ayrıca, projede gerçekten yönetilmeye çalışılan risklerin çoğu yazılmayan risklerdir. Yazılan riskler ise yönetil(e)meyecek olan risklerdir.. 💥

 

MAYIN EŞEĞİ

Geçmişte sınır kaçakçılığının yaygın olduğu zamanlarda mayın döşenmiş sınırlardan güvenle geçmek için eşekler kullanılırdı. Kaçakçılar mayınlı bir araziyi geçmek istediklerinde, bir mayına basıp parçalanmaktan korunmak için seçilmiş eşekleri kullanırlardı. Bu iş için seçilen eşekler geçilmek istenen mayınlı araziye öncü olarak gönderilir ve eşek yürüdükçe bastığı yerler işaretlenerek kaçakçılık hattında güvenli bir patika açılırdı.  Eğer eşek ilerlerken patlama olursa bir sonraki eşek sürülürdü. Böylece güvenli bir yol tespit edilmiş olurdu. Günümüzde artık elektronik mayın tarayıcılar kullanılıyor.

“Sözümüz Meclisten Dışarı!”

Modern iş hayatında da etrafımızda mayın eşekleri olabiliyor. Hatta bazen kendimiz de bu duruma düşebiliyoruz. Elbette sözümüz meclisten dışarı, kimse bildiğimiz anlamda eşek değildir. Kimi zaman yöneticilerimiz tarafından, kimi zaman bir arkadaşımız tarafından ya da inandığımız doğrular, fikirler nedeniyle tıpkı bir mayın eşeği gibi öne atılıp, zorlu koşullara dalabiliyoruz. Hatta bazen yaptığımız bir yanlış hareket nedeniyle bir anda kendimizi oyunun dışında bulabiliyoruz, şirketten atılabiliyoruz.

Ancak hata yapmadan hedefe ulaşabilirsek de diğerleri aynı izi takip ederek peşimizden geleceklerdir. Bu aslında bir anlamda liderlik yapmaktır. Aradaki tek fark, mayın eşekleri kendi kendine harekete geçmezler, birilerinin dürtmesi veya zorlaması ile zorlu araziye girerler. Liderleri ise kendi iç motivasyonları harekete geçirir. Onlar öne sürülmek yerine öne atılırlar. Dürtüleri onları hedefe yönlendirir. Mayın eşeklerinin temizlediği alanlar geride kalanlar için artık güvenlidir. Bu arazide patlayan mayınlar nedeniyle ölen eşekleri ise kimse umursamaz. Dokunulmadan, oracıkta öylece bırakılırlar, unutulur giderler. Acıklı olan da budur işte.

İNAN-MAYIN!

Şirketlerde mayın eşeği olup, iş hayatınızı risk etmemek için öncelikle yapılması gereken şey, sizden istenen şeylere saf bir şekilde inanmayın, sorgulamadan yapmayınız. Her talep edilen şey masumca olmayabilir. Arkasında başka şeyler yatabilir. Ucuz kahramanlık peşinde koşmamalıdır. Şunu unutmamak gerekir ki; mayın eşeklerine hiçbir zaman mayınlı bir araziye girecekleri söylenmez. Bunu bilebilseler zaten hiçbir şekilde oraya yaklaşmazlar bile. Bu nedenle, size verilen görevlerde de işin tehlikesi, riskleri ve olası kötü sonuçlar söylenmemiş olabilir. Bir görev verileceği zaman öncesinde iyice araştırıp, olası sonuçları dikkate almak gerekir. Aksi halde her şey için çok geç olabilir!

KORK-MAYIN!

Buna rağmen bir diğer durum ise, hayatta hiç risk almayan kişiler başarıya ulaşamazlar. Her şeyden korkan, çok temkinli davranan, risk almaktan çekinen kişiler ilerleyemezler, oldukları yerde kalırlar. Verilen görevin avantajlarını ve dezavantajlarını değerlendirdikten sonra elde edilecek başarıya ulaşmak için bazı riskler de alınmalıdır. Böyle durumlarda mayın eşeği olmaktan korkmayın. Çünkü başarıyı ya ilk yapanlar ya da en iyi yapanlar yakalarlar. Bir konuda sektöre ilk giriş yapan firma, ilk aşamada pazar lideri olurlar. Diğer firmalar ancak onu yakalamaya çalışırlar. Ne zaman ki, ilk giren firmadan daha iyi, daha ucuz bir ürün ya da hizmet üretebilirlerse sektörü ele geçirebilirler.  Ayrıca iş hayatında hiç tehlikenin olmadığı, mayınlardan temizlenmiş bir dünya bulunmamaktadır. Yeter ki, o arazinin mayınlı olduğunun farkına varıp,  korkmadan, cesaretle girilmelidir.

KAÇ-MAYIN!

Mayınlı arazilerde mayına basıldığında sıkıntı yoktur. Mayından ayağınızı çektiğiniz zaman patlama olmaktadır. Düzenek bu şekilde çalışmaktadır. İş hayatında da zorlu bir çalışma ortamında, riskli bir durumla karşılaşıldığı zaman kaçmaya çalışmak bazen daha kötü sonuçlara neden olabilir. Eğer ki, mayın eşeği gibi bir görev üstlendiyseniz ve bunun da farkındaysanız, mayına bastığınız zaman kaçmayınız. Sizden sonra gelecek birileri mayınları temizleyebilir. Mayını etkisiz hale getirebilir. Korkuyla ve heyecanla sağa sola kaçarak anlamsız hamleler yapmak, kötü sonuçlanabilir. Hatta mayın eşeklerinin kontrolsüz bir biçimde kaçışmaları sonucu arkadan gelen birçok kişinin de canından olmasına neden olabilir.  
 
UNUT-MAYIN!
İstemediğiniz halde sizi mayın eşeği olarak, tehlikeye atanları ise hiçbir zaman unutmayın. Eğer halen aynı ortamda kalabilmişseniz, sonraki zamanlarda tekrar aynı tehlikeli işleri yapmaya kalkışmayın. O kişilere güvenmeyin. Belki yolculuğunuzda şansınız yaver gitmiş ve hayatta kalmış olabilirsiniz. Ancak tekrarında o kadar şanslı olamayabilirsiniz. Benzer konularda aynı riskleri tekrar almak, almaya çalışmak kahramanlık değildir, ancak ve ancak cahil cesaretidir.  Kahramanlık yapmaya çalışmayınız. Ucuz kahramanlıkların sonu, çoğu zaman günah keçisi olmaktır.
 

“Önemli bir problemde, yetkinizi aştığı halde size danışılıyorsa, kahramanlık yapmayın. Çünkü mutlaka olaya çözüm değil, suçlu aranıyordur.” Erich Fromm (1900-1980) Amerikalı psikanalist , filozof ve sosyolog

 

 YÜRÜYELİM ARKADAŞLAR

Bir süredir işyerimizdeki doğa dostları kulübü üyeleriyle doğa yürüyüşlerine katılıyorum. Hem güzel zaman geçirmek hem de sağlık açısından faydalı bir faaliyet oluyor. Ancak bunların ötesinde kazandırdığı çok daha önemli faydalar bulunuyor.  Yürüyüş faaliyetlerimizde proje yönetimine yönelik birçok benzetim(analoji) kuruyorum. Projeler de ancak ekip faaliyeti ile gerçekleştirilebildiği için proje yöneticiliğinde karşılaştığım olayları, yürüyüş ekibimizde de gözlemleyebiliyorum. Yürüyüşlerimizi bazen kalabalık bir ekiple gerçekleştiriyoruz, bazen de 10-15 kişilik küçük bir tim gibi oluyoruz. Tıpkı projelerimizdeki ekipler gibiyiz. Bazen yönetilmesi zor ve kalabalık bir ekibiz, bazen de hızlı yürüyebilen esnek ve hızlı bir ekibiz.

Gelelim proje yönetimi ile ilgili benzerliklerine..

·       Öncelikle ekibimizin bir lideri oluyor ve onun belirlediği rotada yürünüyor. Rotanın başlangıç ve bitiş yeri değişmese de, ekip lideri rotayı şartlara göre uzatıp, kısaltabiliyor. Ekibin gücü, dayanıklılığı, hızı ve doğa şartlarına göre rotada değişimler yapılabiliyor. Projelerde de başlangıç ve bitiş noktası, proje başlatma (kick-off) toplantısında net olarak ortaya konulmasına rağmen sonuca giden yol planı zaman zaman değiştirilip, güncellenebilmektedir.

·       Ekip halinde yürüyüş yapılmış olsa da, aslında tek başına yürümektesiniz. O rotayı siz tamamlayacaksınız, o yokuşu siz çıkacaksınız.. Kimse sizi sırtında taşımayacaktır. Elbette çok büyük bir rahatsızlık yaşadıysanız birisi kolunuza girecek ve yardım edecektir. Ancak bugüne kadar hiç böyle bir durum yaşamadık çok şükür. Projelerimizde de ekip üyeleri, aslında görevleri kapsamında işleri yine ancak kendileri yapacaktır. Başkalarının o işi yapmasını beklememesi gerekmektedir. Zorluğuyla, kolaylığıyla işi (yürüyüşü) kendi tamamlayacaktır.

·       Rota üzerinde çoğu zaman düz bir yolda yürünmüyor. Sert yokuşlar çıkılabiliyor, dik inişler olabiliyor. Hatta bazen inişler, çıkışlardan daha zorlayıcı olabilmektedir. Projelerimizde de bazen ekibimiz motive olup, zorlukları aşarken, bazen de inişler yaşayabilmektedir. Hiçbir zaman stabil(durağan) bir ekip faaliyeti olamamaktadır. İşin zevki bu iniş ve çıkışlarda karşılaşılan zorluklarda olmaktadır.

·       Arkada kalan ekip üyeleri beklenmektedir. Yürüyüş başladığı ekiple gerçekleştirilip, aynı ekiple tamamlanır. Asla birisi ya da bir grup geride bırakılıp ilerlenmez. Dolayısıyla en önde olmak ya da en arkada olmak yürüyüşü tamamlamak için önemli değildir. Ekibin tüm üyeleri bitiş noktasına ya da ara duraklara gelene kadar beklenilir. Projelerimizde de işlerin arkasında kalan proje ekibi üyeleri beklenilmelidir. Hiç kimse yavaş olduğu için, beceriksiz olduğu için ya da zayıf, güçsüz olduğu için ekibin dışına atılmamalıdır.

·         Yürüyüş için mutlaka uygun kıyafet ve aletler alınmalıdır. Yürüyüşe günlük kıyafetlerle gidilmesi, yürüyüş ayakkabısı olmaması, baton, gözlük, tozluk vb destek ekipmanları alınmaması yürüyüşü zorlaştıracaktır. Öyle ben güçlüyüm, ben hızlı yürürüm, ben zaten spor yapıyorum, ben her akşam evde yürüyüş yapıyorum diyerek yürüyüşe çıkılması durumunda sonuçlar hüsran olabilmektedir. Projelerimizde de işin yapılması gereken uygun araçların alınması gerekmektedir. Ne kadar iyi proje yöneticisi olursanız, olun; uygun araçlar olmadığı zaman işleri yürütmek, yönetmek hiç de kolay olmamaktadır.

·      Dağın ardında ne olduğunu bilemezsiniz. Rotanın üzerinde her zaman güzelliklerle, zorluklarla karşılaşılabilmektedir. Yürüyüşün zevkli yanı da budur aslında. Bazen geçmeniz gereken bir dere karşınıza çıkabilir. Ya da vahşi hayvanların ayak izi, ya da sesi ile karşılaşabilirsiniz. Bunlara hazırlıklı olmalıdır. Projelerimizde de karşımıza hiç beklemediğimiz zorluklar çıkabiliyor. Hiç hesapta olmayan sorunlarla, risklerle karşılaşıyoruz.

·     Yürüyüşler cesaretli olmayı gerektirir ancak gereksiz yere riskler de alınmamalıdır. Yapılacak küçük bir hata sonucunda metrelerce aşağı yuvarlanabilirsiniz. Başınıza her şey gelebilir. Cahil cesaretine hiç yer yoktur. Projelerimizde de riskleri yönetmemiz gerekiyor. Ancak gereksiz yere riskli kararlar almamalıyız. Tüm projeyi batırabilirsiniz.

·     Yürürken doğaya asla zarar verilmez. Bir çiçeğin bile bilerek üstüne basılmaz. Çevrenin kirletilmemesine özen gösterilmektedir. Planlı olmadıkça, ateş yakıp, mangalda köfte, et gibi faaliyetler yapılmaz. Amaçtan asla sapılmaz. Rota bellidir ve çok uzundur. Küçük molalar haricinde asla oyalanılmaz. Çünkü zamanında rotanın tamamlanması çok önemlidir. Gecikme olması durumunda, gecenin karanlığında yürünmesi gerekecektir, tehlikeler artacaktır. Projelerimiz de insana, çevreye ve toplum sağlığına dikkat etmemiz gerekmektedir. Projenin zamanında tamamlanması beklenmektedir. Gecikmelerin sonuçları hep kötü olmaktadır.

İşte böyle, “zorlukta güzellik vardır” diyerek nice zirveler diliyorum.

 

Risk İştahı

RİSK İŞTAHI

Herkesin hayali sıfır riskle yaşamını sürdürmek ve kazanmaktır. Ne yazık ki, bu durum gerçekçi değildir ve hayalden öteye gitmeyecektir. En basit kararımızda ve yaptığımız hareketlerde / aktivitelerde mutlaka risk vardır. Çünkü riski oluşturan çevre, toplum ve organizasyonlar her zaman aktiftirler ve risk üretmeye devam ederler. Birçok riskin olasılığı çok düşük olduğu için düşünmeye bile gerek duymayız. Evimizde otururken sokakta bir patlama olması, binanın yıkılması, yangın çıkması, silahlı saldırı olması vb riskler elbette vardır. Bunlardan birkaçı zaman zaman gerçekleşir ve hayatımızı değiştirir. Ancak bu riskleri önlemeye çalışarak yaşamı sürdürmek de hayatı epey zorlaştıracaktır.

Aynı durum firmalar için de geçerlidir. En küçük olasılıklı riskleri bile düşünerek karar alamayan, her türlü risklerden korkan bir patronun işlerini devam ettirmesi elbette çok zordur. Firmalar aslında insanlardan daha yıkıcı, telafi edilmeyecek riskleri göze alarak büyümeye çalışırlar. Firmalarda risk yönetimi kapsamında ele alınması gereken kavramlardan birisi de “risk iştahı” seviyesidir. Her firma risk almalıdır ancak firmaların alacakları risklerin büyüklükleri farklı düzeylerde olabilir. Buna göre “Risk İştahı”; firma yönetiminin amaçları doğrultusunda kabul etmeye (tolere etmeye/maruz kalmaya/önlem almamaya) hazır olduğu en yüksek risk düzeyidir. Risk iştahı kavramı, bu düzeyin üzerindeki risklerin kabul edilemeyeceğini ve önlem alınması gerektiğini ifade eder.

Firmaların risk iştahı düzeyini hem firma mali gücü hem de dış etkenler belirler. Risk İştahı; iç ve dış çevre, insanlar ve politikalardan etkilenir. Bu kapsamda risk iştahı, Risk Yönetimi Stratejisi çerçevesinde, kurum/birim/alt birim düzeylerinde yukarıdan aşağıya doğru belirlenir. Dolayısıyla firma içindeki alt birimlerin risk iştahı düzeyleri birbirinden farklı olabilir. Ancak hiçbir alt birimin risk iştahı, firma genel risk iştahını aşamaz.  Üst yönetimin kurum düzeyinde belirlenen risk iştahı sınırları içinde kalınması şartıyla birimler/alt birimler tarafından farklı iştah düzeylerinin belirlenmesi mümkündür. Çok risk almak kadar, az risk almak da başarısızlığa neden olabilir. Risk iştahının düşük olması güvenilir bir yönetim tekniği olarak görülse de yaratıcılık, yenilikçilik (inovasyon) ve fırsatlardan yararlanma konusunda firmayı sınırlayabilir. Riskin aslında bir fırsat olduğu gerçeğini de dikkate almak gerekir.

Benzer yaklaşım, kurum içinde yürütülen projeler için de geçerlidir. Firmanın stratejik planları, uzun vadede hedefleri ve projenin geliştirildiği müşteri portföyüne uygun olarak projelerde izin verilecek risk iştahı düzeyleri de farklılaşacaktır. Her proje, tüm kuruma tanınan risk iştahına aynı düzeyde sahiptir diye düşünülmemelidir.

Proje yöneticilerinin, projelerini yürütürken farklı risk iştahlarına sahip olması gerekir. Proje yöneticilerinin bunun farkında olması lazımdır. Her projenin risk iştahı farklı düzeylerdedir. Projenin başarısını alınacak risk düzeyleri belirleyecektir. Proje yöneticisinin riskleri göze alma adına sahip oldukları inisiyatif, risk iştahı sınırını aşmamalıdır. Aksi halde üst yönetim tarafından müdahale edilecektir. Ancak proje yöneticisi korkak bir tavır içinde bulunarak; kurumun veya projenin risk iştahının çok altında riskler almaya çalışırsa da projenin veya firmanın fırsatlarını elinden kaçırabilir. Genelde projelere üst yönetim tarafından, projenin risk iştahı düzeyi şu kadardır diyerek bir bildirim (deklarasyon) yapılmaz. Proje yöneticisinin bu düzeyi öğrenmesi en uygunu olacaktır. Ancak bunun belirgin veya net olmadığı durumlarda da karşılıklı görüşmelerle birlikte tahmin etmesi gerekecektir.

Özetle; her kademede bir çalışanın risk iştahı düzeyi, aslında bağlı olduğu yöneticisinin risk iştahı düzeyidir. Ne gereksiz yere riskler alarak iş hayatını riske sokmalıdır, ne de fazla korkak davranarak fırsatları elinden kaçırmamalıdır. 

"Zaten" Hastalığı

"Zaten" Hastalığı

Tıp literatürüne girmemiş ancak tüm çalışanların ve şirketlerin yaşam sürecinde birkaç kez yakalandığı bir hastalık: "ZATEN" Psikolojik incelemesinin detaylı yapılması faydalı olacaktır.

Şirketlerde ve projelerde çalışanların tutulduğu bu hastalık kan ve nefes yoluyla bulaşmasa da davranışlar aracılığıyla etrafa kolayca yayılmaktadır. Özellikle yönetici-çalışan arasında çok kısa sürede etkisini arttırarak bir süre sonra tüm organizasyona sirayet edebiliyor.

Kişisel performanstan tutun da şirket performansına kadar tüm aşamalarda bu kelimeyi içeren semptomlarla karşılaşabiliyoruz. Çalışandan bir örnek: "Ben zaten bu şirketin en iyi çalışanıyım" der.
Yönetici ise "Ekibim zaten uyumlu, işbirliğine açıktır" der. Genel müdür "Şirketim güçlü, ben zaten istediğim zaman adam bulurum" der. Böyle devam eder.

Proje yöneticileri bu hastalığa en kolay yakalanan fazla iyimser (optimistik) kişilerdir. İşte örnekler: "Ben zaten proje planını hazırlamıştım", "Zaten bu işi eski projede test etmiştik", "Proje sponsoru zaten istediğim bütçeyi vermez", "Sistemi ayarlamıştık zaten, 24 saat çalışacak", "En iyi tasarımcılarımız bu projede çalışıyor zaten", "Bu malzemeyi zamanı gelince zaten kolay buluruz"...

Bunların temel sorunu "varsayımlar" olabilir. Her şeyi baştan var/yok saymak, "zaten hastalığının" ilk belirtisidir. Ancak "zaten" içeren tüm varsayımları "risk" olarak değerlendirirsek, bu hastalığın tedavi süreci de "riski yönetmek" olacaktır. Dile kolay ama riski yönetmek o kadar da kolay bir çalışma değil. Risk yönetimi denilince birkaç form doldurmak anlaşılmamalıdır. Başlı başına bir iş. Hem de proje yönetimi açısından bana kalırsa en önemli faaliyettir.

Şirket düzeyinde bir "zaten hastalığı" teşhisi varsa bunun tedavisi daha zor. Kurumsal bir risk önleme ve düzeltme faaliyeti gerektirecektir. Bu ise ancak risk önleme ve azaltma planlaması ile üst yönetim seviyesinde yapılmalıdır. Özellikle çalışanların bu hastalığa tutulmadan bazı önlemleri almak en iyisi olacaktır.

Her şeyin bir ihtimali var, "zaten hastalığı" da zaten bu ihtimalleri görmemek değil mi? :)

Görüşmek üzere.

PROJE YÖNETİM OFİSİNDE İTME VE ÇEKME STRATEJİLERİ

Yoğun proje geliştirilen işletmelerde projelerin birlikte alınıp bir program çerçevesinde yönetilmesini kolaylaştıran yapılardan olan Proje Yönetim Ofislerinin (PMO) yapısı, amacı ve yararları konusunda daha önce bir yazımı paylaşmıştım.

Bu yazımızda, PMO yönetiminde itme (push) ve çekme (pull) stratejilerinin nasıl uygulanması gerektiği ele alınacaktır. PMO yöneticilerinin, bu stratejilerden hangisini tercih etmesinin uygun olacağı değerlendirilecektir. Günümüzde birçok PMO bölümü başarısız olmakta, yöneticileri sıklıkla değişmekte veya işletmelerin geneline yayılamadan dar bir fonksiyonla, rutin bazı işlerin gerçekleştirildiği birimler halinde devam etmektedirler.

Asıl sorun “Bir PMO nasıl başarılı olabilir” sorusuna kesinlik içeren bir cevap verilememesidir. Çünkü böyle organizasyonların başarı kriterlerini ortaya koymak da zordur. Başarı için neler yapılabileceği konusunda bazı gözlemleri ve çözüm önerilerini paylaşabiliriz. Bunlar genel olarak tüm PMO yöneticilerinin karşılaştığı problemlerdir.

Küçük kazanımlarla büyük işler başarmak

Birçok kurumlarda PMO, bir işletme için genel gider mali yükü (overhead)  olarak görülmektedir. Tüketilen kaynak ve zaman maliyetinin parasal bir getirisi olmadığı için böyle bir algı oluşmaktadır. Bu nedenle PMO yöneticileri, üzerlerinde bir yük hissederler. Sürekli tüketen bir kaynak olmanın verdiği rahatsızlıkla bu maliyeti karşılayacak büyük getiriler sağlamanın yollarını aramaya çalışırlar. Yılsonu hedeflerine, erişilmesi zor ve yüksek hedefler koyarak tabiri caizse kendilerini maddi anlamda aklamak çabasında olurlar.   

Dolayısıyla PMO yöneticileri; işletmenin süreçlerinde, organizasyon yapılanmasında ve iş yapılarında köklü ve çok sayıda değişiklikler yaparak, projelerin verimliğini arttırmak ve bu sayede PMO’nun değerini yükseltmek isterler. Süreçlerde ve/veya organizasyon yapılarında büyük değişiklikler yapılması, geri dönüşü olmayan zararlara yol açabilecektir. Böyle bir başarısızlık başta PMO yöneticisi olmak üzere PMO’nun kendisini de ortadan kaldıracaktır.

Bu nedenle, küçük ancak etkili değişiklikler/dokunuşlarla zaman içerisinde büyük değişimlerin sağlanması hem işletme hem de PMO açısından faydalı olacaktır. Ayrıca, yapılan değişikliklerin işletme içinde yaygınlaşması, kabullenilmesi için de zaman kazandıracaktır. Küçük kazanımlarla büyük değişiklikler gerçekleştirilirken, personelin büyük değişimlere verdiği tepkilerden de kaçınılmış olunacaktır.

PMO yöneticileri, ellerinde sihirli değnek olmadığının farkına varıp, büyük değişim hedeflerini zamana yayarak, önceliklendirerek küçük değişimlerle gerçekleştirmelidir. Örneğin, kullanılmakta olan proje yönetim aracının yerine yeni bir araç kurulmasını sağlamadan önce pilot uygulama yapılması, yeni araçla ilgili oluşabilecek risklerin tespit edilmesi ve önlenmesi sağlanmalıdır. Bu konularda PMO yöneticisinin “al bunu kullanın” demesi yerine “bu aracı şu pilot projede denedik, avantajları ve dezavantajları şunlardır” diye değişimi başlatması uygun olacaktır. Benzer köklü değişimleri işletme süreçlerinde yapılan değişikliklerde de görebiliyoruz. PMO yöneticileri başta proje yönetim süreçleri olmak üzere genel işletme süreçlerinde farklı iş yapış şekilleri tanımlayarak uygulanamaz süreçler tanımlayabilmektedir. Kurum kültüründen veya kurum organizasyonundan bağımsız olarak yapılmaya çalışılan süreç tanımlamaları zaman içinde kadük kalıp kullanılmaz olmaktadırlar. PMO yöneticisinin süreçlerdeki değişiklikleri, yaşanan değişimlere uygun olarak iyileştirme önerileri doğrultusunda köklü olmayacak şekilde, hatta pilot projelerde uygulayarak hayata geçirmesi gerekmektedir.

Birçok kişinin “elbette zaten öyle yapılması lazım” dediğini düşünüyorum ancak birçok PMO yöneticisinin yukarıda bahsettiğim nedenlerden dolayı hızlı bir değişimi zorladığı görülmektedir. Çünkü zamana yayılarak yapılacak değişimlerin üst yönetimde farkındalık yaratmayacağını düşünmektedirler. Bunun birçok örneği ile işletmelerde karşılaşılmaktadır.

İtme (push) ve Çekme (pull) stratejilerini kullanmak

PMO liderlerinin gerçekte müşterileri, projelerdeki ekip üyeleri ve projelerin paydaşlarıdır. PMO liderlerinin PMO araçlarını ve süreçlerini bu “müşterilerine” satmaları gerekmektedir. Bu amaç doğrultusunda genel pazarlama stratejilerinden birisi olan İtme (push) ve Çekme (pull) stratejilerini PMO yöneticileri de kullanabilirler.

Pazarlamada “İtme” yönteminde ürün veya hizmetler satış noktasına yığılır, itilir ve satılması için satıcının müşterilere öncelikle sunması beklenir. Örnek vermek gerekirse, yeni bir ilaç firması ilacını eczanelere daha uygun fiyatla vererek ilaçlarını yükler. Eczacı da bu firmanın ürünlerini satmak için bazı yöntemler uygular. Genelde muadil ilaç diye satılmak istenen ilaçlarda “itme” yöntemi uygulanmıştır. Pazarlamada “çekme” yönteminde ise reklam, promosyon gibi argümanlarla müşterinin tercih etmesi, bir anlamda çekmesi beklenir.

Bu stratejileri PMO yöneticileri uygulamadan önce bazı bilinmesi gerekenler vardır. Hiç kimse değişimlerin içine itilmek istemeyecektir. Bunun için önce adaptasyon gerekecektir. Bazı değişimler ise ekip üyeleri tarafından talep görecektir ve değişikleri uygulamak için çekeceklerdir. “İtme” yöntemini uygulayan PMO yöneticileri, otoritelerine dayanarak kısa zamanda küçük kazançlar sağlayabilirler. Proje ekibine ne yapılacağını ve nasıl yapılacağını anlatıp yaptırabilirler. Bu değişim hızlı ve tartışmasızdır. Sorgulanması veya değiştirilmesi istenilmez. Ancak uzun dönemde güçlü kazanımlar elde etmek için yavaş yavaş gerçekleşse de  “Çekme” yöntemi uygulanmalıdır.

PMO yöneticileri, proje yönetim süreçlerini yaygınlaştırırken veya yeni araçların devreye alınması esnasında itme stratejisi yerine çekme yöntemini tercih etmelidirler. “En iyi uygulama ödülü” alması, “X firmasında uygulanan süreç modeli” olması veya “Tüm sektörde bu uygulamalar yaygın” gibi gerekçeler, araçların veya süreçlerin proje ekibine zorla uygulatılmasına imkan vermemelidir. Ancak küçük değişimlerle ve yapılanların etkilerinin proje ekibi tarafından da görülebileceği uygulamalarla ilgili süreçlerin ve araçların çekilmesi sağlanmalıdır.

Bunu yaparken de değişimin organizasyonun en altından en üstüne kadar hissedilmesi sağlanmalıdır. PMO yöneticileri değişiklikleri proje liderlerine aktarıp, kendilerinden bunu tüm ekibe uygulatmalarını beklememelidirler. Bu itme yöntemidir ve organizasyon içinde kabul edilip uygulanması kolay olmayacaktır. Bir seviyede veya bir bölümde aksayacaktır. Bunun yerine tüm ekibin kullanmasını sağlayacak faydalı uygulama örnekleri sunularak proje ekibinin kabullenmesi kolaylaştırılmalıdır.

Etkili Analistlerin Davranışları -3

Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim

Etkili Analistlerin Davranışları -3

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.  

İşbirliği Ortamı Yaratma

Yazılım geliştirme sürecinde, kullanıcılar, geliştiriciler, pazarlamacılar ve yöneticiler arasında zoraki de olsa bazı ilişkilerin doğması sağlanır. Bütün bu gruplar birbirlerinin yaptığı işin değerini anlamayabilir veya işe verdikleri öneme,  kısıtlarına ve ihtiyaçlarına inanmayabilir. Gerçekte ise birçok ortak amaç ve zorluklara sahiptirler. Bütün bu gruplar aynı iş ortamında çalışmaları nedeniyle sistemin getirilerinden baştan sona ortak bir şekilde faydalanacaklardır. Ürünün başarısı için tüm bu grupların birbirlerini tetiklemesi gerekecektir. Herşeyin kazanmak-kazanmak  felsefesi için yapılması gerekir. Kazanmak-kazanmak başarımı için ise öncelikle dürüst olmak gerekecektir. Proje ekibindeki tüm grupların, yöneticiden geliştiriciye kadar herkesin bilgi paylaşımında bulunması gerekecektir. Böyle bir ideal ortamı sağlamak elbette zordur ama mantıksız kişileri bir araya getirmek, işbirliği ortamını baştan yok etmek demektir.

Öncelikle iş gereksinimlerini tanımlamak, müşteri ve geliştiriciler için beklenilen kazançların daha fazla açığa vurulmasını sağlayacaktır. Tüm katılımcılar da projenin maliyeti ve kısıtları hakkında dürüst olup, bilgi paylaşımına fazlaca katkıda bulunacaklardır. Analistler, müşterinin zaman planı ve maliyetlerini gerçekçi bulmaz ise bunun sebepleriyle birlikte açıklamasını yapması gerekecektir. Anlamsız maliyetlendirme ve zaman planı, tüm paydaşların teknoloji, zaman ve kaynak açısından alacağı tüm kararlarını etkileyecek ve beklentilerini değiştirecektir. Bu noktada analistin proje yönetimi ile iletişimli olarak geri beslemelerde bulunması gerekecektir.

Analistin müşteri ile konuşmak için zamanının olmaması veya neler istenildiğini biliyor zannetmesi düşünülecek şey değildir. Analist müşteri ortamındaki anahtar konumdaki tüm kişilerle uygun işbirliği ortamını hazırlamak zorundadır. Müşteri temsilcileri, kendilerinden tam olarak ne istendiği belirtilmedikçe, katılımcı olmak konusunda tereddütlü davranabilirler. Bu durumda müşteri temsilcilerine katılım konusunda bir yazı yazıp, her seviyedeki işbirlikçilerle görüşmek ve onları ortamın içine çekmek istenmelidir. Vizyon dokümanı, doğru kişilerle konuşmayı seçmeyi sağlar ayrıca müşteriye ürün daha anlaşılır kılar.Yetersiz kullanıcı katılımı projeyi başarısızlığa götüren temel nedenlerden biridir. Bu noktada gereksinim görüşmeleri için zaman harcamak istemeyen dik kafalı kullanıcı ve yöneticilere dikkat etmek gerekir. Yetersiz kullanıcı katılımı nedeniyle problemler yaşanılan önceki projeleri hatırlamak ve müşterilere örnekler sunmak çözüm açısından yardımcı olacaktır. Hemen hemen her organizasyonda yeni sistemin istenilenleri karşılamayacağı, kullanılabilirliğinde sorunlar yaşanacağı, performans sorunları oluşacağı şeklinde kötümser hikayeler yaratılır. Kullanıcı ihtiyaçlarının yeterince anlaşılması ve paylaşılması, projenin başarımını da etkileyecektir.

Becerileri Yenileme ve Etkinleştirme

Gereksinim analistinin temel fonksiyonu, geliştirici ile müşteri arasıdaki projeye olan bakış açılarından kaynaklanan boşlukta bir köprü görevi görmektir. Yetenekli bir analist, iletişim kurabilme, basitleştirebilme, kişiler arası becerilere sahiplik ve teknik açıdan işin etki alanına hakim olabilme yeteneklerini kendisinde toplamalıdır. Çok iyi bir programcı ile sisteme hakim bir kullanıcının bir analist olabilmesi için uygun hazırlıktan geçmesi gerekir. Bütün bu üstün özellikler analist olmak açısından yeterli olamamaktadır. Kazanılması gereken bazı önemli yetenekler şunlardır:

•    Kolaylaştırıp, basitleştirebilme
•    Görüşme Teknikleri
•    Dinleme yeteneği
•    Yazma yeteneği
•    Organizasyonel yetenekler
•    Kişiler arası beceriler
•    Modelleme yeteneği

Etkili bir analist, elindeki araçların hangisini nerede kullanıp kullanmayacağını iyi bilir.  Bu araçlar çok geniş bir yelpazeye dağılmıştır. Örneğin, içerik diyagramı, veri-akış diyagramı, UML gösterimleri bu araçlardandır ve bir analistin koleksiyonunda gerektiğinde kullanılmak üzere beklemelidirler. Etkili bir analist yolu üzerindeki engelleri tespit edip, uygun araçları seçerek bu engelleri ortadan kaldırmaya çalışır. Bunlara rağmen tecrübenin yerini hiçbir şey  tutamaz. Tecrübeli bir analist tarafından yazılacak bir gereksinim dokümanı, acemi biri tarafından yazılacaktan iki kat daha hızlı ve daha az hata içerecek şekilde yazılır. Geliştiricilerinin gereksinimleri yazabileceğini isteyen bir organizasyon ise, kalite ve organizasyon yapısından gitgide uzaklaşır.

Yazılım ürünleri için gereksinimler, analist şapkası giymiş birinin toplaması için ortada yayılmış durumda beklememektedir. En azından gereksinimler kullanıcıların, geliştiricilerin kafalarında çekip çıkarılmak ve uygun formlara dönüştürülmek için beklemektedirler. Gereksinimler, kullanıcıların ihtiyaçlarını belirlemek konusunda yardımcı olan, kullanıcıların ne istediklerini ortaya çıkarıp, geliştiricilerin de ihtiyaçlarına göre bunları düzenleyen bir analist tarafından keşfedilmeye ihtiyaç duyarlar. Gereksinim analistlerinin projede az ama önemli bir rolü vardır.

Kaynaklar: 

 Habits of Effective Analysts /Karl E. Wiegers - Process Impact www.processimpact.com 

To Be Reqirements Analyst /Karl E. Wiegers -Process Impact www.processimpact.com

Etkili Analistlerin Davranışları -2

Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim

Etkili Analistlerin Davranışları -2

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.

Çizgileri Belirlemek

Birçok projenin sınırları yazılı olarak belirlenmediği için neyin kapsam içinde, neyin dışında olduğu bilinemez ve bunun sıkıntıları zamanla ortaya çıkar. Yeni sistemin gereksinimlerini tanımlamaya öncelikle sistemin veya ürünün vizyonunu ve ne olup neler yapması gerektiğini ortaya koymakla başlanmalıdır. Sistemin iş gereksinimlerini tanımlamak ve vizyonu ortaya çıkarmak  için projenin pazarlama sorumlusu ve/veya finansal destekçisiyle iletişim içinde olmak, gerekirse hazırlanmış uygun bir doküman sunmak gereklidir. Son ürünün vizyonu tanımlamak zor olduğundan başlangıçtan son ürüne kadar her bir sürüm ve aşamanın vizyonlarını tanımlamak gerekecektir.

Gereksinimleri ortaya çıkarma görüşmelerinde önemli olan kullanıcıların sistemle neleri başarmak istedikleridir. Görüşmeler daha çok fonksiyonellik, kalite kriterleri ve çözüm önerileri odağında geçer. Bu kriterlerdeki ufacık bir bilgi bile kullanıcıların kafasından geçenleri anlamak için gerekli ve önemlidir. Bununla birlikte kullanıcıların bu sistemi kullanma hedefleri, bu sürecin verimli olmasında ve fonksiyonel gereksinimlerden tasarım arayüzlerinin çıkarılmasında oldukça etkilidir.

Açığa Çıkaran Sorular Sormak

Analist olarak çalışırken, kullanıcılarla yapılan oturumları kolaylaştırmak ve basitleştirmek gerekir. Müşteri temsilcisinin  daha önce hiç bahsetmediği bir görev hakkında alternatif yolları deneyerek kullanıcılara sorular sormak ve diğer görevlerle olan ilişkileri ortaya çıkarmak gerekir. Kullanıcının sorulara verdiği cevaplar o senaryo için olmazsa olmaz ve yapılsa iyi olur gibi ifadeler içerir. Böylece kullanıcı senaryolarının da iş akışı ortaya konulmuş olur. Kullanıcılar, sistemin doğru ve beklenildiği gibi çalışmasına odaklanırlar. Analist bunun yanı sıra beklenilmeyen durumlar için de uygun senaryoları hazırlamalıdır.  Hata durumlarında uygulama geliştiricinin ele alması gereken kontrolleri, zaman zaman kullanıcılardan da yardım alarak tanımlamalı ve hata durumlarını yönetmelidir. Bu öncelikle sistemin güvenilirliği ve tutarlılığı açısından önemlidir.

Yaratıcı ve bilgili bir analist, kullanıcıların söylediklerini birebir kaydetmek yerine alternatif bakış açıları ve öneriler sunar. Kullanıcılar bazen uygulama geliştiricilerin yeteneklerinin farkında olmayabilirler. Önerilecek fikirler ile sistemin daha kullanışlı olması sağlanabilir. Zaman zaman da kullanıcıların iş yapışını izleyerek, otomatikleştirilebilecek olan süreçler hakkında bilgiler verilerek, kullanıcıların sistemin kullanılabilirliğine olan bakışı arttırılabilir. Önceki sistemlerde kullanılmış bir fonksiyonel yapının tekrar kullanımının sağlanması, kullanıcıların gereksinimlerini yeniden gözden geçirmesini ve düzenlemesini sağlayacak ve yeni yapılar üzerinden yeni gereksinimleri düşünecektir.

Etkili bir analist birçok düzeyde soyutlama yapabilmelidir. Kullanıcının bildirdiği belirgin özellikteki gereksinimlerin, diğer kullanıcıların gereksinimleri ile ilgili olup olmadığını ve aralarındaki ilişkileri sağlamalıdır.  Bir konudaki önemli noktaları ortaya çıkarmak, belirsizlikleri yok etmek, anlaşmazlıkları ortadan kaldırmak, öngörü ve varsayımları belirlemek, beklentileri karşılamak için soru sorma sanatına hakim ve yetenekli olmak gerekir ve bu da çoğunlukla tecrübeye dayanır.

Önceliklendirme

Gereksinim geliştirme süreci, bulanık, her bir aşama için belirsiz tanımlardan detaylı belirtimlere giden döngüsel-artımlı bir süreçtir. Her aşamada doğru soyutlama düzeyine odaklanmak gerekir. Birden tasarıma dalmak veya detaylara girmek, sistemin ve sürecin hataya düşmesine neden olabilecektir. Kullanıcı arayüz ekranlarından veya prototiplerden gereksinimleri ortaya çıkarmak ve her aşamada gerektiği kadar detaya girmek sistemi doğru anlamak açısından önemlidir. Temel yapılması gereken şeylerin yapılmamış ve daha az önemi olan özelliklerin yapılmış olması, yazılım takımının cesareti kırıp, müşteriye ümitsizliğe yöneltir. Bu sebepten analist elde ettiği gereksinimleri önceliklendirmelidir. Herkes kendi işini çok önemli ve öncelikli görür. Analist bu noktada tüm kullanıcı sınıfları ve geliştiriciler arasında gerekli iletişim ve işbirliğini sağlayarak hassas öncelikli kararları almalıdır.

Gereksinim geliştirmede öncelikle katkıda bulunabilecek kullanıcı sınıfları oluşturulmalıdır. Bunu yaparken beğenilen, gözde ve beğenilmeyen gruplarla gereksinim geliştirmeye katkıda bulunmayacak grupları ayırt etmek gerekecektir. Tabii olarak beğenilen ve gözde sınıfın gereksinimleri de varolan çatışmalardan arındırıldıktan sonra öncelikli olacaktır.

Devam edecek.