DAMLAYA DAMLAYA YIL OLUR

Proje yöneticilerinin önemli işlerinden birisi proje planına uygun olarak takvim oluşturmak ve bunu kontrol altında tutmaktır. Başlangıç aşamasından itibaren takvim güncellenir ve detaylandırılır. Bazı işler daha alt işlere bölünerek hem zaman planlaması hem de kaynak planlaması açısından takip edilir. 

Elbette ilk yapılan zaman planına göre ilerleyen zamanlarda sapmalar ortaya çıkar. Proje yöneticisinin görevi bu sapmaları kontrol altında tutup, etkisini azaltmaktır. Değişmeyen proje planı yoktur ancak önlenebilir, telafi edilebilir sapmaları da yönetebilmek gereklidir.

Proje takvimi oluşturulurken öncelikle iş listesi oluşturulur.  Burada iki yöntem izlenir. Ya genelden, detay işlere doğru kırılım yapılır. Bu "Üstten-aşağıya" (top-down) yöntemidir. Diğer yöntem ise detay işlerden genel işlerin ortaya çıkarılmasıdır. Buna da "aşağıdan yukarıya" (bottom-up) yöntemi denir. İşlerin niteliğine göre bu yöntemlerin ikisi de birlikte kullanılabilir. 

İş listesi belirlendikten sonra işler arasındaki bağımlılıklar/ilişkiler belirlenir. Çoğunlukla bir iş tamamlandıktan sonra diğeri başlar. Ancak bazı özel durumlarda işlerin birlikte başlaması veya birlikte bitirilmesi gerekebilir. Projelerde takvim oluşturulurken Gantt Chart dediğimiz bir iş akış diyagramı kullanılır. Gantt Chart üzerinde genelde bir iş(ler) tamamlandıktan sonra diğer iş başlayacak biçimde FS (Finish to Start) olarak ilişkilendirilir. Çok az iş tipi için ise FF (Finish to Finish) veya SS(Start to Start) ve SF(Start to Finish) ilişkileri kurulur. Bu tip bağımlılıkların detayına girmeye gerek yoktur, konumuzun dışında ele alınabilir.

Projede işler arasındaki bağımlılıklar nedeniyle, bir işin bitirilmesinde gecikmeler olursa, diğer işin başlaması da gecikecektir. Bu tür durumları önlemek için bazı kritik işler arasında proje yöneticileri tampon zamanlar tanımlar. Böylece gecikmeler telafi edilmeye çalışılır. Ancak tampon zamanlar da aşılırsa, diğer işlerin de başlama zamanları öteleneceği için takvim kayması önlenemez hale gelir. 

Üstelik her işte böyle gecikmeler olursa, gecikmeler katlanarak artar. İşlerdeki birkaç günlük gecikmeler bir süre sonra haftalar, aylar ve yıllar seviyesine çıkar. 

Gecikmeler "damlaya damlaya yıl olur"!

Dolayısıyla bir süre sonra proje ekibinde takvim ötemelesinden kaynaklı olarak "zaten" hastalığı ortaya çıkar. "Zaten bu iş de gecikecek!", "Bu takvim zaten gerçekçi değildi!", "Bizim işler zaten hep gecikir!", "Ben zaten bu işin çok daha uzun süreceğini söylemiştim!", "Proje yöneticisi zaten fazla iyimser", "Zaten bu Gantt chart, baştan hatalı hazırlanmıştı!" diye bir sürü gerekçeler ortaya konulur.

Proje yöneticisi küçük gecikmelerde bile riski öngörüp, önlem almaya çalışmazsa bir süre sonra takvim kaymalarının önüne geçemez olur. Bu durumda çoğu kez takvim yeniden hazırlanarak yönetim onayı alınmaya çalışılır. Ancak hedef tarihlerden sapmanın bir çok maliyetleri olur. Ya sapmaları önlemek için ek kaynaklar alınması gerekir, ya da bütçe revizyonu yapılır. Bunlar ise çok sancılı süreçlerdir.

Damlaya damlaya yıl olmaması için iş sıkı tutunuz..

Kestirmeden Gidelim

 

Kestirmeden Gidelim

Birkaç kişi bir araya gelip, bir yolculuğa çıktıkları zaman genellikle içlerinden birisi hemen  “abi kestirmeden gidelim, ben kısa bir yol biliyorum daha kısa sürer” diye önerir. Bazen bu önerilen yol işe yararsa da, çoğu zaman işi daha da uzatır. Ekip içindekiler huzursuzlanmaya başlar ve süre ve yakıt maliyeti artar.

Proje yönetimi yolculuğu da böyle başlar. Özellikle projenin iş geliştirme ve planlama aşamalarında sıklıkla işçilik ve maliyet tahminleri yapılması gerekir. İngilizce “estimation” kelimesi için “tahminleme” kullanılabileceği gibi bazen “kestirim” de kullanılır. İşgücünü ve malzeme, hizmet maliyetini kestirmeye çalışmak anlamında düşünülebilir.

İyi, güzel ama kestirim yapmak kolay mıdır? Projelerimizde kestirimleri nasıl yapmalıyız?

Proje yönetimi açısından en zor konulardan birisi işgücünün ve maliyetlerin kestirimlerini yapmaktır. Çok risk içermektedir. Özellikle proje kapsamında teklif verilmesi veya sözleşme yapılması gerekiyorsa, yapılacak hatalı kestirimin telafisi kolay olmayacaktır. Hem işi alabilmek için kabul edilebilir bir teklif sunulmalıdır hem de maliyetler olabildiğince gerçeğe yakın öngörülmelidir. Gerçekten çok zor bir iştir, ayrı bir yetenek ve uzmanlaşma gerektirmektedir.

Projede kestirim yaparken aşağıdaki 4 yöntemden birkaçı uygulanır:

• Uzman görüşü almak
• Önceki projelerdeki verileri kullanarak benzetim yapmak
• Global verilere dayalı hesaplamalar yapmak, modeller geliştirmek
• Proje ekiplerinin tahminlerini bir arada değerlendirmek

Bu yöntemlerin hepsinin avantajları ve dezavantajları var. Şimdi bunları ele alalım.

Uzman görüşü almak: Projeyle veya çalışılan alanla ilgili daha önceden deneyimi olan uzmanlardan kestirim yapması istenebilir. Kulağa hoş gelen bir yöntem olsa da, hepimizin bildiği üzere ülkemizde herkesin “usta” olduğunu düşünürsek, şirketlerimizdeki “uzmanların(?!)” da sayısı epey fazladır. Çoğu da, yolculuk örneğimizde bahsettiğimiz o kısa yolu öneren kişiler olurlar. Üstelik bir de “abi ben ZATEN daha önce bu işi yapmıştım” diyorsa, vah ki vah!..

Önceki projelerdeki verileri kullanarak benzetim yapmak:  Şirketlerin veri havuzlarında geçmiş projelerdeki veriler kullanılarak yeni proje için benzetimler yapılmaya çalışılabilir. Sıklıkla benzer projeleri yapan firmalar için bu yöntem çok uygun ve kullanımı kolaydır. Ancak daha önce hiç tecrübe edilmemiş bir konuda çalışılması durumunda bu veriler tutarsız olacaktır. Bir diğer konu ise veri havuzundaki verilerin doğruluk değeridir. Verilerin toplanmasında, girişinde ve işlenmesinde hatalar yapılıyorsa, her defasında hatalı kestirimler yapılacaktır. Yazımızın başındaki yolculuk örneğindeki “kısa yol” ifadesi gibi hatalı verilere dayalı kestirimler, “çıkmaz yol” olabilir..

Global verilere dayalı hesaplamalar yapmak: Kestirimler konusunda dünya çapında toplanan verilere dayalı hesaplama yöntemleri önerilebiliyor. En bilinen örneği yazılım geliştirme faaliyetlerinde kullanılan “Function Point” ve COCOMO (Constructive Costing Model) yöntemleridir. Detaylarına girmeye gerek yok. Bazen kurumsal verileri kullanarak modeller de geliştirilebilir. Örneğin bir mekanik parçanın belli özelliklerini girerek bir formülle yaklaşık işyükü ve maliyet kestirimi yapılan modeller oluşturulabilir. En ideal kestirim yöntemi olarak görünse de modelin hatalı kurgulanması sonucu hatalı kestirimler yapılabilir. Ayrıca bu tür modellerin sürekli iyileştirilmesi ve geliştirilmesi gerekmektedir. Bu da ayrı bir uzmanlık gerektirir. Modeller geliştirilirken “bir elbise dikelim, herkese uysun ve güzel görünsün” temennisi olduğu için her model her projeye uygun olamayabilir, ne yazık ki..

Proje ekiplerinin tahminlerini bir arada değerlendirmek: Bu yöntemde  projedeki ilgili kişilerden iyimser, kötümser ve en olası tahminleri alınır. PERT yönteminden esinlenerek geliştirilen Üç Nokta yöntemi böyledir. Bazen bu üç verinin ortalaması alınır, bazen de başka bir  şekilde formül kullanılır. Detayları araştırılıp, öğrenilebilir. Yöntemin en önemli riski, tahmin yapanların birbirlerini etkilemesidir. Birbirleriyle konuşup, “galiba ben fazla iyimser ya da kötümser söylemişim, biraz değişiklik yapayım” diyerek sonuçlar etkilenebilir (manipulasyon). 

Geriye bir yöntem daha kaldı:”Hissikablelvuku” Yani kalbinden geldiği gibi, altıncı hissine ve sezgilerine dayanarak bir kestirim yapmaktır. 

Tutar mı? Ya tutarsa!

Proje yolculuğunda kestirmeden gitmeyi önerenlere fazla şans vermeyip, uygun yöntemler kullanılması gerekmektedir.

Kazasız, belasız iyi yolculuklar..

Proje Takip, İzleme ve Yürütme

 

Proje Takip, İzleme ve Yürütme

Proje yönetiminde sıkça duyduğumuz terimlerden birkaçıdır: "Takip, İzleme, Yürütme". Zaman zaman birbirlerinin yerlerine kullanılabilmektedirler. Bu üç terimin temel amacı aslında projenin gelişmesini "kontrol" altında tutabilmektir. Proje yönetimiyle ilgili konuşmaya başlanılınca, cümlelerin içinde bunlardan birkaç tanesi mutlaka geçer. Bir de cümlenin içinde "süreç" kelimesini kullanılırsa, iyice pekiştirilmiş olur.

Pekala gerçekten bu "Proje Takip, İzleme ve Yürütme" aynı şeyler midir?

Temel amaç projenin kontrolü olsa da aslında bunlar birbirlerinden çok farklıdırlar. Öncelikle her birinin farklı roller tarafından gerçekleştirilmesi gerekmektedir. Hemen kolaycılığa kaçıp da "hepsini proje yöneticisi yapar/yapmalıdır" demeyelim. 

Proje izleme (monitoring) aktivitesi tek yönlü, interaktif olmayan bir kavramdır. Tıpkı sinemada veya televizyonda film izlemek gibi bir şeydir. Sinemada filmin senaryosuna müdahale edemediğimiz gibi proje izlemede de doğrudan gelişmelere, olaylara, hususlara müdahale yapılamaz. Bir monitörün karşısında oturup, ancak bir uyarı (alert) geldiği zaman birilerine haber veren operasyon odasındaki görevlilerin yaptığı gibi projeyi izleyenler de aynı şekilde davranırlar. Projenin verileri izlenir ve bunlar kullanılarak raporlar hazırlanır. Projelerde "izleme" rolünün "Proje Yönetim Ofisi (PYO)" tarafından gerçekleştirilmesi uygun görünmektedir.

Proje takip (tracking) aktivitesi ise projede ortaya çıkan hususların takip edilmesini içermektedir. İnteraktif olan ve çift yönlü bir aktivitedir. Ancak "proje takip" aktivitesi tepkisel (reaktif) bir çalışmadır. Projede bir sorun/husus çıkmadıkça takip edilecek bir aktivite de olmayacaktır. Proje takibi "planlı" bir çalışma değildir. Ancak ve ancak birilerinin ya da bir olayın dürtmesi sonucunda gerçekleştirilir. Örneğin toplantı notlarında yer alan hususların takibi buna bir örnektir. Toplantıda bir husus ortaya çıkmıştır (mısır patlaması gibi) ve çözülmesi için takibi gerekir. Projelerde "takip" rolünün "proje yönetim ekibindeki proje uzmanları" tarafından gerçekleştirilmesi daha uygun görünmektedir. 

Proje yürütme (execution) aktivitesi ise diğer aktivitelerde daha kapsamlı ve oldukça farklıdır. Çok yönlü ve proaktif bir aktivitedir. Proje yürütme çalışmasında öncelikle planlamanın yapılması gerekmektedir. Olaylar akışına bırakılmadan, gerçekleşmeden önce inisiyatif alınmalı ve sezgisel bir tavır sergilenmelidir. Proje yürütme aktivitesinde harekete geçmek için bir dürtü gerekmez. Proje planına uygun olarak aktiviteler planlanır, gerçekleştirilir ve yönetilir. Risklerin yönetilmesi dahi yürütme aktivitesi içinde gerçekleştirilir. Projedeki kilometre taşları belirlenir ve bu hedeflere ulaşılması için takip ve izleme faaliyetleri gerçekleştirilir. Dolayısıyla projelerde yürütme aktivitesinin proje yöneticisi tarafından gerçekleştirilmesi daha uygun görünmektedir.

Proje yöneticisi sadece reaktif biçimde projesindeki hususları takip ederse, ya da proje takibinden sorumlu uzmanlar projeyi sadece dışarıdan izlemeye çalışırsa, proje yönetim ofisi sorumluları projede yürütme görevini üstlenmeye çalışırlarsa her şey bozulur ve projenin yönetimi gerçekleştirilemez. Her bir rol kendi kapsamı içinde kalmaya çalışmalıdır. 

Evet, "Proje Takip, İzleme ve Yürütme" aynı aktiviteler olmadığı gibi bir kişinin tek başına üstlenebileceği kadar da basit değildirler. Ancak her ne olursa olsun, tüm bu aktivitelerin gerçekleştirilmesinde ana sorumluluk her zaman olduğu gibi proje yöneticisindedir. Ne yazık ki, proje yöneticisinin "izlemem, takip etmem, planlamam" deme lüksü hiçbir zaman yoktur! İzleme, takip ve planlama işlerinin yapılmasından veya yaptırılmasından sorumludur.

PROJE VİRÜSLERİ

 

PROJE VİRÜSLERİ

Uzun zamandır gündemimiz hep Covid-19 virüsü oldu. Biz proje yöneticileri aslında projelerimize bulaşan virüslerle yıllardır mücadele ediyoruz. Projelerimize bulaşan çok değişik tipte virüs var. Bu virüsler projelerimizi ya geciktiriyor ya da tamamen yarıda bırakıyor. İşte bu virüslerden bazı örnekler:

Plansızlık Virüsü (CAMEL-WAY):

Semptomları:"Bize plan değil, pilav lazım", "Kervan yolda düzülür .." Ülkemizde çok sık görülür. Birçok korunma yöntemi ve planlama aracı olsa da, genellikle ülkemizde tüm proje yöneticileri bu virüse yakalanırlar. Fazla bulaşıcıdır.

Delegasyon Virüsü (DLG-EX):

Semptomları: Projedeki bütün işler bir kişiye yüklenir, delege edilir. İlerleyen zamanda tüm işlerin delege edildiği kişi ya işlerini geciktirir ya da çekip gider (tıbbi ifadeyle "ex" olur). "Ekip yönetimi" konusunda yetersiz proje yöneticileri genellikle bu virüse sıkça yakalanırlar. Az görülür ama öldürücüdür.

Kapsamı Büyütme Virüsü (CREEP-X2):

Semptomları: "Sözleşmede yok ancak bu özelliği sağlamalıyız", "Şunu da yapıverseniz.." Ülkemizde her projeye bulaşan bir virüstür. Her yeni eklenen gereksinim nedeniyle kapsam büyür ve proje iki katına çıkıverir. Fazla bulaşıcıdır.

"Zaten" virüsü (ALREADY-OPT):

Semptomları: "Zaten bizim ekibimiz tecrübeli", "Elimizde zaten çözümü var". Fazla iyimser(optimistik) proje yöneticilerinin yakalandığı bir virüstür. Öldürücü etkisi vardır.

Bitmeyen Proje Virüsü (INFINITE-999):

Semptomları: Proje yıllarca sürer. Tüm ekip değişir ama proje hala devam eder. Hep yeni bir şeyler istenir ve sonsuza kadar bunlarla uğraşılır. Ülkemizde böyle çok proje vardır. Bu virüs öldürmez ama süründürür.

İşte bunlar gibi daha başka birçok virüs projelerimizi tehdit ediyor. İyi bir proje yöneticisinin bu virüslere karşı aşılanmış olması gerekiyor. Ancak o zaman her türlü zorluklara dayanabilen çetin ceviz proje yöneticileri başarıya ulaşabilecektir.