PMI Proje Yonetim Egitimi 2. Gun

Bugün PMI adlı dünya çapındaki en büyük proje yönetim derneğinin resmi proje yönetim eğitiminin 2. gününe katıldım. İlk günün eğitim notlarını dün yazmıştım.

Aşağıda eğitimde aldığım bugünkü notları bulabilirsiniz.


25 Mart 2007

Belirsizlik payına management reserve denir. Bu sponsor veya müşteri tarafından kontrol edilir. Bu %10-50 arasında değişir. Çıkacak sonuç ne kadar netse, o kadar 10'a yakındır. Ama asla sıfır olmamalıdır, çünkü her zaman projelerde belirsizlik her zaman vardır. Bunu proje ekibi bilemez, sponsor veya müşteri bilir. Ortaya çıkan sonuç hiç detaylandırılmamışsa, %50'ye doğru gider. Bu rakam fizibilite çalışmasının sonucunda sponsor veya müşteri tarafından belirlenir. Fizibilite çalışmaları yapılırken, daima tecrübeli insanların dahil olması gerekir. Varsayımların gerçekçi olması için bu şarttır. Proje ekibi buna dokunamaz, ancak buradan ek bütçe isteyebilir.

İkinci bir pay var, alınan. Bunun adı risk payı. Bu proje ekibinin işi. Bunun İngilizcesi "Contingency Reserve". Bu da %10-20 arasında oynar. Lucent Teknolojide yönetim rezervi için, bilinmeyen bilinmeyenler derler. Risk için ise, bilinen bilinmeyen derler. Bu rakamlar keyfi harcanan rakamlar değildir. Bunlar yasal, uygun, doğru yaptırımlar için kullanılacak bütçelerdir. Neler olabilir bunlar?

Risk payını düşünelim. Bir projeye başladınız. Veritabanı uzmanı arkadaşınız var. İşi çok iyi biliyor. Sonra birine kafası kızıyor ve hiç kimseye bir şey söylemeden işten ayrılıyor. Onun yerine birini bulacaksınız. Evvelden risk planlaması yapmışsanız, b planı hazırdır. Ahmet'in yerine Mehmet hazırdır. Mehmet vakit harcayarak, Ahmet'in neler yaptığını anlayacak. Mesela bir haftada işi anladı ve koşmaya başladı. Bu 40 saatlik maliyet, risk payından çıkacak. Olabileceğini tahmin edersiniz, olup olmayacağını bilmezsiniz. Risk payı var.

Server alacaksınız, 100 K dolar ayırdınız bu işe. Piyasada oynamalar oldu, fiyatlar yükseldi. Şimdi 120 K dolara ihtiyaç var. Bu para nereden gelecek? Risk payından. Bunlar bilinen bilinmeyenlerdir. Bu parayı kullandığınızda, hemen kayıt düşeceksiniz.

Gelelim yönetim rezervine. Bu ne için lazımdır? Ürün tanımı oldukça iyi yapıldı zannediyorsunuz, %15 pay var. Proje ekibindesiniz. İhtiyaç analizini yapmaya başlıyorsunuz. Kullanıcılar diyor ki, bize kimse danışmadı, yöneticilerimiz kendi başlarına karar verdiler. Aslında bu sistemin vergi stopajlarını da dikkate alması lazım. Bunu yapmak için, programlama mimarisini değiştireceksiniz. Bu risk payında aranmaz, çünkü risk payı projenin tarifi üzerinde öngörülmüş bir şeydir. Şimdi projenin tarifi değişti. Onun için hem zaman hem de para olarak ek bütçe gerekir. Nereden gelecek bu? Sponsorun arka cebinden gelecek.

Bir anımı anlatayım. Aramco'da çalıştığımda 1979 yılında, projenin planını hazırladık. Proje planına göre, yalın bütçe 720 M dolar, 72 aydır. Biz buna projenin kontenjanı olarak 100 M, 6 ay koyduk. Bu planı Suudi Arabistan'da sponsora sunduk. Adam kendi ekibine inceletti ve projeyi onaylıyorum dedi. Ben bunu yönetim kuruluna götürünce, bunun onaylanması hemen hemen 100% gibi düşünebilirsiniz. Yalnız dedi, bilginiz olsun, ben buna yönetim rezervi olarak 140 M dolar ve 8 ay kattım. Böylece toplam 960 M dolar ve 86 ay oldu. Biz dedik, karar sizin, ama neden bu kadar yüksek aldınız. Adam dedi, zamanı gelince, bana teşekkür edersiniz. Gayet sevinçli döndük biz. Bir iki ay geçti, her biri bu odanın boyutunda iki tane enjeksiyon makinesi var. Bunlar deniz suyunu toprağa basıp, petrol üretimini artırıyorlar. Bunlar 1.5 yıl önceden ısmarlanmış, ancak ilk başlangıçta mühendisliği yapılmakta, daha üretime geçilmemiş. O sırada teknolojide ilerlemeler olmuş. Biz ısmarladığımızda sabit devirli ısmarlamışız, o zaman içinde değişken devirli pompalar daha ekonomik ve bakımı kolay hale gelmiş. Bu değişiklik 3 ay gecikmeye kritik hat üzerinde de toplam 2 ay gecikmeye sebep oluyor, maliyette de 22 M dolarlık artış olacaktı. Bu planı Houston'da herkes kabul etti. Bunu sponsora sunmuşlar. Sponsor, ekibe sormuş, herkes istemiş, adam da imzalamak üzere kararı istemiş. Sormuş bu 22 M dolarla 2,5 ayı nereden bulacaksınız. Bizimkiler, mırın kırın etmişler. İşte ben kaç ay önce yönetim rezervi ayırdığımda, bunları düşünerek ayırmıştım. Yönetim rezervi, böyle beklenmedik değişiklikler için yapılır.

Buna change management diyoruz.

Proje onaylandı, şimdi sponsorun projeyi başlatması gerekiyor. Sponsorun projeyi başlatması için bir duyuru yayınlaması lazım. Bu duyuruya project charter deriz. Burada sonucun tarifi, proje yöneticisinin kim olduğu, projenin aşılmaması gereken zaman ve maliyet bütçeleri duyurulur. Sponsor projenin hamisi, koruyucusu durumundadır. Eğer proje yöneticisi, bir bölüm yöneticisiyle sorun yaşıyorsa, bu sorunları o çözer.
Ürünün tarifini burada kısa kesmek bence en güzelidir. Bir sayfayı aşmayacak bir doküman olmalı.
Proje yöneticisi seçildikten sonra, projenin berat dokümanının hazırlanmasını ondan sponsor rica eder. Bu hazırlanınca charterı tüm yöneticilere, muhasebeye (çünkü projeye yapılan harcamalar ayrı bir hesapta toplanmalı), varsa proje yönetim ofisine ve insan kaynakları bölümüne bu charterdan bir kopya gider. Proje yöneticisi bu berata dayanarak, ekibin üyelerini ilgili yöneticilerden ister ve alır.

Başlatma yapıldıktan sonra, proje yöneticisi ekibini toplayıp kick-off toplantısı yapar. Bu beratın yayınlanmasından 7-10 gün içinde yapılmalıdır. Bunun birkaç sebebi var, hemen size vaat edilen kaynakları almazsanız, bir başkası onları alır. İkinci sebep, duyuru çıktığı anda projenin zaman bütçesi çalışmaya başlar.

Dünyadaki her 100 projenin 75'i böyle bir duyurudan yoksun olarak hayata geçiyor.

Bundan sonra kick-off toplantısında herkesi birbiriyle tanıştırmalı ve takımlaşmaya başlamalı. Bu toplantıyı sponsorun açması nezaketen normaldir. Proje yöneticisini desteklediğini bildirir. Sponsor, proje yöneticisi ve proje liderleri toplantıyı yapar. Bunlar projenin planlamasını yaparlar. Bunun süratli yapılması lazımdır, çünkü ürünün geliştirilmesine başlanmıyor. Ama plansız giderseniz, dönüp dönüp plan yaparsınız. Başında gereken zamanı verip, planı doğru yapmak lazım. Toplam Kalite Yönetiminin ana prensiplerinden biri, "İlk seferde doğru yap"tır. PMI'ın PMP sınavında sık sık sorulur: "Project plan is done by ..." cevap proje ekibi olmalı.

Proje ekibi oturuyor, beraber, projenin bütçesi nedir, kısıtlamaları nedir, organizasyonumuz nasıl olsun, ana parçaları nedir diyerek, farkında olarak veya olmayarak bir ekip ruhuna sahip oluyorlar ve projeyi sahipleniyorlar.
Benim hayatımdaki en ilginç tecrübelerden biridir, ABD'ye ilk gittiğimde bir mühendislik şirketinde çalıştım. Ben planlama mühendisiydim, proje yöneticilerine destek verirdim. Devamlı beraber çalıştığım Kent diye bir İngiliz vardı. Devamlı benden şikayet ederdi, amirime iletirdi. 2. senenin sonunda yine bir proje almıştı, Tayvan'dan. Bunu proje yöneticisi olarak getirdiler, ama hep pislik yapardı. Kent geldi ve dedi ki, Ahmet projenin planlamasını yapacağız, 3-4 gün bir arada çalışacağız, gelir misin, dedi. Ben de beni adam yerine koydu, diye sevindim. Adam bizi kütüphaneye kapattı. Günde 10 saat. Dışarı çıkmak yok. 4 gün burnumuzdan ter damlayarak çalıştık. Projenin her tarafını didikledik. Birçok şeyi Kent de bilmiyor. Soruyor, hep beraber nasıl yapılacağını ortaya çıkardık. Çok şanslı görürüm kendimi o toplantıda bulunmaktan. Bir projenin nasıl beraber planlandığını yaşadım. 4 günün sonunda herkes büyük bir huzur içindeydi. Ama bunu yaparken herkes sık sık tartışıyordu, ama oradan çıkarken, herkes çok mutluydu ve o proje çok başarılı olmuştu. Ondan sonra Kent'le benim aramdaki bütün buzlar eridi. Birbirini hiç sevmeyen iki insan gayet yakın dost olabiliyor. Bütün mesele beraber bir şeyi üretmekte. Ondan evvel o bana talimat veriyordu, ben de kızıyordum. Onun için proje ekibinin birlikte planı hazırlamasında çok fayda var.

Proje tanımlama dokümanı, buradan işin sonuna nasıl gideceğiz, ne kadar zamanda, hangi riskler olabilir. Bunları tanımlar. Bunun ardından, projenin kapsamını tanımlayan, work breakdown structure oluşturulur. Türkçe’de iş kırılım ağacı derler. Daima bunu yapın, bir kere ne yapacağınızı gözünüzün önüne koyar, sorumlulukları da ona göre dağıtırsınız. Sorumlu tanımazsanız, ona komite çalışması derim. Ben komite çalışmalarını hiç sevmem. Komitenin içi dışı belli değil. Proje ekibi olacaksınız. Nedir bu kırılım ağacı?

Gelin bir proje yapalım. Tekirova tatil köyünü oluşturalım. Bu projenin ne gibi parçaları var?
Tekirova Tatil Köyü
Proje yönetimi. Çok fazla işi yok, ama maliyet var.
Diyelim ki, şirket yeri belirledi. İlk olarak ne lazım, bir tasarım lazım. Tasarım
İzin ve ruhsatlar
Tedarik. Malzeme ve ekipman siparişi
İnşaat
İç mimari
Çevre düzenlemesi
İnsan kaynakları
Teknoloji altyapısı
Güvenlik
Açılış
Şimdi bunların alt kırılımlarını yapacaksınız.

(İki saatlik kısımda yoktum.)

İleriye yönelik yapılan her çalışmada daima işlerin önemli bir kısmı bilinmiyor. Onun için planlama yapılan her yerde risk için çalışma yapmak gerekir. O kadar ki, mesela vapur iskelelerinde insanlar hep koşar. Ulan, 5 dakika erken çıksana evden, birader. Bu memlekette herkes hep koşuyor. Risk planlaması yapılmıyor. Tutum da genellikle, öyle bir şey olmaz şeklinde. Bence risk planlaması en önemli parçalardan biri. Risk planlamasında, PMI'ın risk yönetim bilgi alanında 6 tane süreç var. Risk yönetim planlaması, risk tanımlama, kalitatif risk analizi, kantitatif risk analizi, risk response planlama, risk izleme. Bunlardan üçü çok önemli: risk tanımlama, niceliksel risk analizi. Niceliksel analizde, tanımladığınız risklerin boyutlarını ve ihtimallerini tahmin ediyorsunuz. Üçüncüsü de risk response planning. Riskleri nasıl karşılayacaksınız?

Risk tanımlama nasıl yapılır? İş kırılım ağacı nerelerde kullanılır? Risk tanımlamasında iş kırılım ağacını nasıl kullanırsınız? Her yapılacak işin üzerinden ekip olarak gidersiniz, dersiniz ki, burada risk var mı, varsa ne gibi riskler var, bunlar başımıza ne gibi işler açabilir? Ondan sonra bunların boyutlarını tahmin edersiniz.

Bir tablo hazırlıyorsunuz. Kolonları şu şekilde:
WBS Tarif Etki (Outcome) Olasılık Beklenen Parasal Değer Riski Karşılama Yöntemi

WBS Numaralarıyla gittiğinizde, bunları sıralarsınız.

Bir risk olayı ele alalım. Kasım ayında temel çukurunu açtınız, beton dökeceksiniz. Kasım ayında yağmur yağabilir. Yağmur yağarsa, suyu temizlemek bize kaça mal olur? Bu riskin etkisidir. Diyelim ki, 10 K $ dedik. Şimdi en zor kısma geldik, olasılık. Son 10 senede Kasım ayında kaç gün yağmur yağmış, mesela 40% olsun. Buna göre olasılığı bulursunuz. Beklenen parasal değer, bu ikisinin çarpımıdır. Burada 4 bin dolar olur. Bunu hesapladığınızda, ne gibi önlem alacağınıza karar verirsiniz. Diyelim ki, çukurun üstüne branda döşerseniz, yağmurdan korunursunuz. Bu brandayı alıp sermenin ve kaldırmanın maliyeti, 4 bin dolardan fazlaysa, ben riski tercih ederim. Buna risk acceptance deniyor. Olasılık burada önem kazanıyor. Olasılığı doğru tahmin etmek lazım, çünkü yanıtınızın nasıl olacağına ona göre karar veriyorsunuz. Başka nerede kullanılır beklenen parasal değer? Diyelim ki, brandayı sermek 5000 dolara çıktı, riski kabullenirim dediniz. O zaman ne yapacaksınız? Risk payı demiştik. Eğer riski kabulleniyorsanız, o zaman o temel çukuru açma hesabına 4000 dolarlık bir kontenjan koymanız gerekir. Diyeceksiniz ki, risk 10000 dolar, ben 4000 koyuyorum. Riskin tamamını koymanıza izin vermezler. Onun için risk havuzu oluştururuz. Bütün risk masraflarını oradan karşılarız. O havuz tükendi mi ne olacak? Unutmayın, bunu plana koydunuz ve sponsor da bunu kabul etti. Bu durumda sponsora gideceksiniz ve ek kaynak isteyeceksiniz.

S: Yazılım projelerinde bu işi nasıl yapacaksınız?
C: Orada önemli olan zaten zamandır. Diyelim ki Ali hastalandı, Veli bu işe geldi. Veli'nin bu seviyeye gelmesi için, 10 gün zaman harcaması gerekir. Yine aynı şekilde olasılığını öngörüp, onun beklenen maliyetini bulursunuz.

Bir şey daha var, zamanda yaptığımızda zaman para gibi değil. Para additivedir. Toplarsınız. Zaman öyle değil. Bir projede dört beş tane paralel hat vardır. Eğer kritik hattaysa, proje süresi uzar, değilse, proje gecikmez. O yüzden kontenjanları hesaplarken, kritik hattakilere özellikle dikkate almalısınız. Yalnız bütün verilen kararların bir yerde kaydı olması lazım ki, onu izah edebilesiniz.

S: Politik istikrarsızlıklardan dolayı risk planı yapıyor muyuz?
C: Bunlar "act of god" bilinmeyen bilinmeyenler. Bunlar sponsorun ihtiyat payına ait.

S: Mesela bir yazılım projesinde bütün sistem çöktü? Bu kime ait?
C: Bu da sponsorun risk alanına ait. Ama bizim network bağlantılarımızı kurarken, ihmalkarlık göstermemiz, bunlar kendi performansımızdan doğan şeylerdir. Eğer biz zamanında ısmarlayıp tedarikçi geciktirmişse, risk payını kullanırız. Eğer zamanında ısmarlamamışsak, o zaman risk payını da kullanabiliriz.

S: Performans değerlendirmesi, her aşama ayrı ayrı mı yapılıyor, toptan mı?
C: Genellikle uzun soluklu projelerde aşama aşama değerlendirmek daha iyi. Çünkü uzun zaman geçerse, birçok şey hatırlanmayabilir. Ben 6 aylık bir performans değerlendirmesi yapılması taraftarıyım. Sponsor, proje yöneticisinin performansını, proje yöneticisi, proje liderlerini, proje liderleri, ekip üyelerini değerlendirir.

S: Bu değerlendirmelerin objektif olması nasıl sağlanacak?
C: Her verilen değerlendirmenin izahı yapılmalı ve kayıtlara bağlanmalı. Son 10 yılda en çok proje yapan bölümlerden bir tanesi insan kaynakları. Son 20 yılda insan kaynakları, %80'den fazla hanım oldu. Hanımlar çok daha ciddi bu işlerde.

Risklerin ana unsurları, risk olayı, etkisi ve olasılığı. Etkiyle olasılığı çarptığınızda ortaya çıkan değer beklenen parasal değer diyoruz. Bu bir karar vermede (risklere karşı önlem geliştirme), iki risk payı tespiti, üçüncüsü karar ağacı analizi.

Karar ağacı analizi nedir? Birden fazla çözüm olduğu zaman, alternatifler arasında seçim yapmakta kullanılır. İhalelerde kullanılır. Ali'nin mi teklifi daha iyi, Veli'ninki mi?

THY 20 adet yeni uçak alacak. İstanbul-New York arası uçuş yapılacak. Teklif alınacak iki firma var: Boeing ve Airbus. Diyelim ki, Airbus 800 milyon dolarlık teklif ediyor. Boeing 900 milyon dolarlık teklif ediyor. Şimdi hemen 800 milyonluk teklifi tercih eder misiniz? Ömür boyu maliyet analizi yaparsınız. İlk alım maliyetine ilaveten, operasyonel bakım maliyetlerini hesaplamak, kredi alıyorsanız kredi maliyetlerini hesaplamak ve öyle karşılaştırmak. Tabi ileri yıllardaki maliyetleri hesaplarken, belli bir yüzde ile indirgeyerek karşılaştırmalısınız. Diyelim, Airbusta bakım sözleşmesinin şimdiki değeri 80-120 milyon dolar. Eğer tek rakam olarak ortaya koyabilseydik, karar ağacı analizine gerek yoktu. 10 yıllık işletme masrafı: 200-240 milyon. 10 yıl sonra 20 uçağın satış fiyatının şimdiki değeri 160-200 milyon. 10 yıllık finansman ve idari masrafların şimdiki değeri, 60 milyon. Boeinginkileri de hesaplıyorsunuz.

A320 için üç tane outcome hesaplıyorsunuz: A, B, C. Bunlardan birin en iyi diğeri orta, öbürü en kötü sonuçları içeriyor. Sonuç itibariyle A durumunda Airbusın maliyeti 940, B'de 1000, C'de 1060 milyon. Boeingde 906, 1006, 1106. Şimdi bir grup seçilir THY'de. Bunlar konuşurlar ve A, B, C'nin gerçekleşme olasılıklarını bulurlar. Airbusta A, B, C 30/40/30 % olasılıklara sahip, Boingde 40/40/20. Bunları A,B,C'nin maliyetleriyle çarparsınız. Çıkan rakam Airbus için 1000 milyon, Boeing için 986 milyon. Boeing daha avantajlı uzun dönemde.

S: En son karar belirlenirken, tek fiyatlar mı dikkae alınıyor.
C: Başka çok şey var. Mesela gelirleri de önemli. Her iki uçak da eşit miktarda yolcu taşımayabilir. Başka daha şeyler de var. Sigorta primleri. Sigorta primlerini ne etkiler, Boeing'in ve THY'nin geçmişi. Başka personelin, bu uçaklarla olan rahatlığı. Personelin tercihi. Satış elemanları da önemli. Onlar ne görmüş, müşterinin tercihleri var mı, uçak tipinden dolayı.

Bunu kendi hayatımda üç defa yaptım. Boston'da çalışıyordum, Aramco'dan teklif geldi. Boston'daki paketin değeri yıllık 32 bin dolar değerindeydi. Aramco 40 bin dolar değerindeydi. Fakat Boston daha istikrarlı ve yerimiz çok güzeldi. Futbol koçluğu yapıyordum. Şehrin çocuklarını eyalet şampiyonu yapmıştım. Bütün çocuklar bana koç derdi. Winchester diye bir mahalleydi. Ev alacağım vakit, yıldız oyuncumun babası bana çok iyi koşullarda kredi verdi. Bir de mutluluk analizi yaptım. Boston daha iyi görünüyordu. Ama ona rağmen parayı tercih ettim.

Proje planının diğer elemanları:
Değişiklik yönetimi:
Projelerin kapsamlarında olan değişiklikleri nasıl yönetiriz? Hiçbir proje başladığı gibi bitmez. Başında neyse, sürekli kullanıcılardan, müşterilerden istekler gelir. Sizin onaylattığınız proje yavaş yavaş büyür. Bir change request formu doldurursunuz. Bu formda, bu iş WBS'in neresine ait o numarayı kullanmanızı tavsiye ederim. Sonra kim isteği yapmış, istenen nedir ve sebep. Bu cr formu bir etki değerlendirmesinden (impact assessment) geçer. Burada zaman, maliyet, risk, kaynak etkileri değerlendirilir. Bu etki değerlendirmesini bir karara sunarsınız. Buna change review committee, change evaluation board gibi isimler verilir. Orada olsun mu, olmasın mı kararı verilir. Eğer kabul edilirse, bu cr'den change order durumuna dönüşür ve bütçeye ilave edilir. Eğer kabul edilmezse, çöp tenekesine gider veya bazen de üzerinde tekrar çalışmak için başa geri gönderilir. Bu süreç, bizim 960 milyon dolarlık Aramco projesinde uyguladığımız süreçti. O Arabistan’daki sponsor, bizim projemizin onayını almak için Houston'a geldi. Ne yaptığımızı merakla inceledi. Bu kadar basit bir süreç.
Bunlar büyük projelerdeki süreçler. Sizin kendi okul hayatınızdaki işler, bunlardan çok ufak süreçler.

Bu iş bitince, projenin baseline planını çıkarırız. Projenin WBS'sine göre, her birimin bütçesini -unutmayın proje planı onaylandığı zaman artık o bütçe oluşur-. Bütçeyi alırsınız ve aylara haftalara dağıtırsınız. Ocak ayında 25 bin dolar değerinde iş yapmamız gerekiyor. Şubat ayında 65 bin dolar. Kümülatif olarak şubat sonunda 90 bin dolar değerinde iş bitirmemiz gerekir. Bu yapılacak harcama değil, yapılan işin değeri anlamında. Kümülatif değerleri bir grafiğe koyduğunuzda, projenin ilerleme eğrisi çıkar. Türkçe’de buna hakediş eğrisi derler, inşaatçılar.

Bütçe formu, şu kolonlardan oluşur
WBS No İş ismi İşçilik maliyeti Malzeme maliyeti Diğer maliyetler Ara toplam maliyeti

Bu ara toplam maliyetlerine bir de risk payını eklediğinizde, bütçe ortaya çıkar. Proje performans değerlendirmesinde ara toplam alınır, risk payı ele alınmaz. Risk payı, performans değerlendirme için değil, risk olayları meydana geldiğinde tedbir almak için konulur. Bunun bir de zamansal olarak yapılması gerekir.

Motivasyon tipleri:
Üç kutuplu bir motivasyon modeli biliyorum, senelerdir ayakta: Güç, başarı, insancıllık. İnsanlar bu üç motivasyonun karışımına sahiptirler. Beraber çalıştığınız bir insan burada nerede. Onu anlarsanız, o insanla olan ilişkilerinizi ona göre düzenlersiniz.
Başarım motivasyonu yüksek insanlar, tek başlarına çalışmaktan hoşlanırlar. Güç motivasyonu yüksek insanlar, lider olmayı seven, insan gruplarını başarıya götürmekten hoşlanan insanlardır. Proje yöneticileri için en iyi motivasyon bu tarafın kuvvetli olmasıdır. Başarı motivasyonları yüksek insanlardan çok iyi proje yöneticileri olmaz. Ne onlar memnun olur, ne de ekipleri memnun olur. Bazen çok iyi bir mühendisi, yönetici yaparlar. İyi bir mühendisi kaybeder, kötü bir yöneticiyi elde edersin. İnsancıllık motivasyonu, ne lider olmaya, ne uzman olmaya meraklı, sadece burada çalışan insanlar birbirini sevsin, mutlu olsun. Son 15-20 senede buna verilen değer arttı. Bir liderde bu aranmaya başlandı. Biri iyi lider olacaksa, her şeyi bir kenara koyup, gel arkadaş bir kahve içelim diyebilecek zamanı ayırması lazım. Benim başıma geldi bu. Ben hep çalış çalış derken, baktım, kendine güveni olmayan idari memur seviyelerinden gelmiş, bir kişiyi fena halde ihmal ettiğimi fark ettim. Bu beni şikayet etti. Amirime gitti. Amirim bana dedi, yanında çalışan insanları memnun etmenin değerli olduğunu söyledi.

Beni insancıl buldular. Bana davranış değişikliği yapacaksın dediler. Akdeniz’den mi geldin dediler. Evet dedim. Belli dediler. Bu memlekette hakiki hislerini belli etmeyeceksin dediler. Yani böyle doğdum diye böyle kalmak şart değil.

Proje kontrolü:
Performans kontrolü. Earned value management sistemini anlatacağım. Bu Amerikan Savunma Bakanlığının tedarik sisteminin kontrol altına alınmasından geliyor. Bu sisteme göre, projelerin tedarik sistemlerinin kontrolünde 3 ana unsur vardır: PV (planned value), buna karşılık hakiki harcamalar ölçülüyor, buna AC (actual costs) deniyor. Bu ikisini kıyaslayarak, projenin nereye gittiğini söyleyebilir misiniz? Hayır neden? Bu paraya karşılık ne yapmışsınız, burada yok. O miktara earned value (kazanılmış değer) deniyor. Her projenin rüyası EV'nin PV ve AC'den yüksek olmasıdır, ama her zaman tam tersi olur. Önce AC değerini yakalamak hedeflenir, sonra da P'nin üstüne çıkması için uğraşılır. Şöyle diyorlar, bir projenin ortasına geldiğinizde, ne kadar gerideyseniz, ondan iyisini yapamazsınız. Mesela orta noktada %10 gerideyseniz, bitirdiğinizde de en az 10% geride olursunuz. Kurtarmak çok zordur.

Bu üç rakamı karşılaştırarak, projenin performansını ölçmek. CV (cost value) maliyette ne kadar gerideyiz, SV (scheduled value) zaman olarak ne kadar gerideyiz. FCST (forecast). Mümkün mertebe erkenden performans değerlendirmesini yapmanız lazım.

Projenin kapanışı.
Bunları yapınca, projenin nerede olduğunu anlarsınız, sonra düzeltici tedbirler alınır.

---
Şu ana kadar anlattıklarım büyük projelerde kullanılan araçlardı. Şimdi sizin kendi işlerinize bakalım.

Evvela, proje ekibinin kurulması. Proje değişik bilgi alanlarından gelen insanların aynı amaca odaklanması diye düşünürseniz, bu çeşit bir organizasyonun ismi neydi? Matris. Kendi çalışmalarınızda, nasıl çalışıyorsunuz? Tek başınıza veya matris.
Tek başınıza çalıştığınızda, ona mikro proje diye bakabilirsiniz. Burada proje yönetimi pek çalışmaz. Onu bir kenara koyalım.
Birden fazla insanla çalıştığınızda, en az üç kişi olduğunda, insan ilişkileri ve grup dinamiği işin içine girer. O zaman matrisi uygulamaya başlayacaksınız. Matrisi uygulamaya başladığınızda, neleri kendi projelerinizde kullanabilirsiniz?
1. Planlamayı hep beraber yapmak. Organizasyonda takımlaşma. Karar yetkisini paylaşarak yürütmek.
S: Bir konuda bir işin ehli vardır? Esas sorumlu o değil midir?
C: Dediğiniz doğru, proje liderinin sorumluluğu da işi insanlara paylaştırmak. Ama bütün projeyi ilgilendiren konularda, bir kişinin karar almasındansa, hep beraber düşünmek daima daha iyidir.
2. Planlama.
2.1. Ürün/sonuç tanımlaması. Çıkacak sonucu tanımlamanız lazım.
2.2. İş kırılım ağacını muhakkak yapın. Bu sonuca varmak için neler yapmam lazım.
Size zaman tahdidi verilse bile, siz proje ekibi olarak zaman planınızı bağımsız bir şekilde yapın. Ben size dedim, işi 10 günde bitirin. Siz bakın bakalım, bu iş 10 günde bitebilir mi. 12 gün mü çıkardınız, o zaman bu işi nasıl 10 güne indirirsiniz onu düşünün. Süre kısaltma tekniklerinde ilk olarak nereyi bulacaksınız? Kritik aktivitelere bakacaksınız. Kendi zaman planınızı çıkarırsanız, neyin kritik olduğunu bileceksiniz.
2.3. Zaman planlaması.
2.3.1. Şebeke kurmak, ilişkileri ve süreleri koymak.
2.3.2. Kaynak ihtiyacını belirlemek. Bunu size göstermedim. MS Project'te çok kolay yaparsınız.
2.3.3. Süre kısaltmak, gerekiyorsa eğer.
2.4. Maliyet tahmini yapmak, WBS'i kullanarak.
2.5. Risk planlaması. Kendi talebe projelerinizde bile çok riskler vardır.
3. Uygulama ve kontrol
Uygulama dediğimiz şey, işi yapmak. İşin esası budur. Makale mi yazıyorsunuz, araştırma mı yapıyorsunuz. O uygulamadır. Kontrol de uygulama esnasında nerede olduğunuzu ölçmek. Yani earned value management sistemini uygulamak. Yalnız bu sistemi uygulamak için bütçe lazım. Bütçesiz projelerde nasıl uygulayacaksınız? Zamana göre yapabilirsiniz veya WBS'in her bir büyük parçasına ağırlık verirsiniz. A parçası 25, B parçası 50 dolar. O zaman ben A'yı bitirdiğime göre ne kadarlık iş yapmışım bulursunuz. Her şeyin efor (emek) olarak ağırlığına bir yüzde verirsiniz. Çünkü işi yürüten efordur. Yani insan gün veya insan-saat.