Yazar arşivleri: savassakar

Projelerde Matris Organizasyonlar – 2

Matris organizasyonların avantajları ve dezavantajlarının dikkate alınması gerekir;

Avantajları

  • Proje Yöneticileri, Fonksiyonel Yöneticilerle koordinasyon içinde maliyet ve kaynak konusunda tam kontrol sahibidirler.
  • Şirket politika ve prosedürlerine aykırı düşmeden proje için gerekli yöntem, teknik ve araçlar belirlenebilir.
  • Proje Yöneticileri, diğer projelerle çakışmadığı sürece kaynaklar üzerinde yetkilidir.
  • Değişiklik, talep ve çatışma çözümlemede hızlı tepki verilir.
  • Proje ekip üyeleri proje bittiğinde departmanlarına dönerler.
  • Fonksiyonel departmanlar projenin birincil destekleyicisidirler.
  • Kaynak paylaşımı maliyetleri düşürür.
  • Çalışanlar farklı problemler üzerinde çalışabilirler.
  • Çalışan kontrolü daha iyi yapılır.
  • Teknik bilgi departmanlarda gelişir, bilgi her proje için kullanılabilir hale gelir.
  • Hiyerarşik müdahale gerektiren çatışmalar daha kolay çözümlenir.
  • Zaman, maliyet ve kalite dengeleri daha kolay sağlanır.
  • Uzmanlık ve Genel gelişim hızlanır.
  • Otorite ve sorumluluk paylaşılır.
  • Stres ekip ve Fonksiyonel yöneticilere dağıtılır.
  • Matris organizasyonlarda, projenin diğer projelerle kaynak çakışmaları giderildiğinde hızlı yanıt verme gücü artar. Proje Yöneticisin yetkilendirilmesi projesine özgü yöntem, teknik ve araçları belirleyebilmesini sağlar. Böylelikle zaman, maliyet ve kalite dengeleri kurulabilir.
  • Matris organizasyonlar Geleneksel organizasyonların dezavantajlarını ortadan kaldırırlar. Yönetimlerin matris yapıyı büyük bir değişim olarak algılamaları olasıdır. Fakat matris yapılarda projeler bittiğinde geleneksel yapıya dönülür.

Dezavantajları

  • Yatay ve dikey bilgi akışı gerektirir.
  • Öncelikler sürekli değişebilir.
  • Departman ve proje hedefleri farklı olabilir.
  • Çatışma olasılığı yüksektir.
  • İzleme ve kontrol zordur.
  • Projeye atanmayan ancak destek vermesi gereken personeli yönetmesi zordur.
  • Her proje kendine hastır. Tekrarlayan ve fuzuli işlerden kaçınılması gerekir.
  • Projenin gerektirdiği yöntem, araç ve tekniklerin şirket politika ve prosedürleriyle uyumu için efor harcanması gerekir.
  • Fonksiyonel yöneticiler kendi önceliklerine odaklanabilirler.
  • Fonksiyonel ve Proje Yöneticilerinin güç dengesinin sürekli izlenmesi gerekir.
  • Zaman, maliyet ve kalite dengesi sürekli gözlemlenmelidir.
  • Problemin büyüklüğüne ve çözüm dahil olması gereken paydaş sayısına göre yanıt verme yavaş kalabilir.
  • Proje rolleri, şirket içi tanımlarla çelişebilir, yanlış anlaşılabilir.
  • Çatışmalar çözümlense dahi tekrar edebilir.
  • Ekip üyeleri performanslarının doğru takdir edilemeyeceğini düşünebilir.

C.J. Middleton, “How to Set Up a Project Organization” adlı yazısında matris organizasyonların aşağıdaki istenmeyen sonuçlarından bahseder;

  • Proje öncelikleri ve rekabet şirketin dengesini bozabilir, fonksiyonel birimlerin geleneksel işleri konusunda uzun vadeli düşüncelerini olumsuz etkileyebilir.
  • Uzun vadeli planlar çok fazla toplantı gerekliliği doğurabilir, geçici olan projelerin gereklilikleri karşılamak zorlaşabilir.
  • Projeden projeye atanan personelin kendi uzmanlığında gelişimi yavaşlayabilir.
  • Projelerden çıkarılan dersler diğer projelere aktarılamayabilir.

Stanley M. Davis ve Paul R. Lawrence, Matrix adlı kitaplarında yaşanabilecek problemleri 9 maddede özetliyor;

  • Anarşi – Stres zamanlarında organizasyonel adaların oluşması
  • Groupitis – Grup karar almada sanıldığı kadar uyumlu olmama
  • Ekonomik Durum – İyi günlerde yükselme, kötü günlerde düşüş yaşanma olasılığı
  • İdari Fazlalık – Fazla veya gereksiz yönetici ortaya çıkması
  • Karar Karmaşası – Herkesi karar verme sürecine katmanın yaratacağı problemler
  • Batma – Matris yapıyı gereksiz yerlere yayma olasılığı
  • Katmanlaşma – Matis içinde matrisler yaratma
  • Ben merkezcilik – Proje Yöneticisinin kendini her şeyin merkezinde görmesi

Matris yapılar zaman ve bütçe kısıtları altında etkin yönetimi hedeflerler. Yönetim gerektiği düzeyde planlama ve kontrol süreçlerine dahil olabilirse yukarıda bahsedilen bir çok dezavantaj giderilebilir. Yönetimin projelere karşı kendini ne şekilde pozisyonladığı çok önemlidir.

Projelerde Matris Organizasyonlar – 1

Proje Yöneticisinin proje başarısı konusunda yetkilendirildiği departmanların kendi teknik uzmanlıklarını sergiledikleri organizasyon yapısıdır. Fonksiyonel Yöneticiler, proje için gerekli olan  kaynak atamalarını yaparlar. Farklı departmanlardan kişilerin bir araya gelmesi iletişimi zorunlu kılar. 

Matris yapılanmanın koşulları

  • Katılımcılar taahhüt ettikleri oranda projeye tam katılım sağlamalıdırlar.
  • Dikey ve yatay taahhütler verilebilmelidir.
  • Hızlı ve etkin çatışma çözümü yöntemleri olmalıdır.
  • İletişim kanalları açık olmalıdır.
  • Tüm ekip planlama sürecinde kendi ile ilgili girdiyi sağlamalıdır.
  • Tüm yöneticiler kaynaklar konusunda görüşmelere istekli olmalıdır.
  • Yatay seviyede ayrı birimler gibi değil, birlikte çalışılmalıdır.
  • Matris organizasyonlar proje ve departman sorumluluklarının paylaşılarak sinerji yaratılması esasına dayanır. Matris yapılanma öncesi aşağıdaki soruların sorulması önemlidir:
    • Projede yer alacak departmanlar arasında sinerji yaratacak bir ortam nasıl yaratılacak?
    • Projede önceliklere veya önemli olana kim karar verecek?
    • Fonksiyonel departmanlar isteklere nasıl yanıt verecek ve diğer projelerin arasında nasıl konunlayacak?

Bu soruların yanıtları Proje ve Fonksiyonel Yöneticilerinin yaklaşımlarını belirleyecektir. Yetki ve güç problemlerin erken safhalarda fark edilip çözümlenmesi gerekir. Her iki tarafında kendi işine gelene yönelik davranacağı unutulmamalıdır. Her iki tarafın profesyonel bakış açısının “Önemli olan şirkettir” olması gerekir (beklenir).

Projelerin ve işlerin gerçekleştirilebilmesi şirketin kültürünü ve yapısını iyi bilmeye bağlıdır. Yönetimler organizasyonel yapı içerisinde proje yöneticilerinin gücünü ve yetkilerini artırabilirler. Burada dikkat edilmesi gereken şirket içi güç dengeleridir.

Problem çözme çeşitlilik sebebiyle gelişebilir ama aksine zorlaşabilir. Proje Yöneticisinin birleştirici ve sonuç odaklı olması önem kazanır. İletişimi açık tutarak gerektiğinde daha alt seviyelerde diğer projeleri de dikkate alarak ayarlamalar yapması gerekebilir.

Proje ve Fonksiyonel ortamı ayrı olmamalı, etkileşim içinde olunmalıdır. Bu yüzden proje ve fonksiyonel departmanların lokasyonları önem kazanmaktadır.

Proje Yöneticileri, Fonksiyonel yöneticilerin atadığı kaynaklar üzerinde daha fazla kontrol sahibi olmak ister. Projenin önceliği, işgücü maliyetleri ve atanan personel konusunda çatışmalar yaşanabilir;

  • Proje Yöneticileri, projelerine en iyi kaynakların atanmasını isterler. Fonksiyonel yöneticiler atadıkları kaynaklara ilişkin fayda-maliyet hesabını gözetirler.
  • Proje Yöneticileri, Fonksiyonel Yöneticilerin iş yükünü ve sorumluluklarını tam bilmediklerinde, görmezden geldiklerinde planlanandan fazla iş yükü, ek maliyet vb. yaratabilirler.
  • Ekip üyeleri iki farklı yöneticiden direktif almakta ve raporlamaktadırlar. Ekip üyesinin projeye sadakatini sağlamak ve verdiği önceliği plana uygun yapması için motive etmek, performansının doğru ölçümlenmesi ve dikkate alınmasını sağlamak kolay değildir.
  • Departmanlar çeşitli sebeplere projelere verdikleri öncelikleri değiştirebilirler. Proje Yöneticilerinin değişken durumların projeye olumsuz yansımalarını iyi yönetmeleri gerekir.

Proje Yönetimi Yaşam Döngüleri

Projeleri bir seyahat gibi düşünün. Farklı yöntemlerle gidebilirsiniz. Yürüyerek, koşarak, arabayla, otobüsle, trenle, uçakla vb. Hangi yöntemi seçerseniz seçin hedefinize ulaşabilirsiniz. Ama önemli olan mevcut kısıtlar altında en kısa, ucuz, konforlu yöntemi seçmenizdir.

Proje Yönetiminde projeyi başarıya ulaştırmak için doğru yaşam döngüsüne karar vermeniz gerekir. 

Proje Yaşam Döngüsünü basitçe şöyle açıklayabiliriz;

  • Kapsamı Belirleme
  • Planlama
  • Yürütme (Hayata Geçirme)
  • İzleme & Kontrol
  • Kapama

Yaklaşımları Doğrusal, Kırılımlı,  Döngülü, Uyarlamalı ve Extreme diye 5’e ayırabiliriz.

Proje doğası gereği hedefinin netliği veya belirsizliği doğrultusunda soldan sağa doğru gidildiğini söyleyebiliriz.

Proje Yöneticileri uzunca bir süre kare kutuları yuvarlak deliklere sokmaya çalıştılar. “İlla böyle olmalı” mantığı ile bir yere varılamayacağı zamanla anlaşıldı. Proje Yönetimini hem teknik hem de bir sanat olarak ele almanın önemi anlaşıldı.

Geleneksel Proje Yönetimi Yaklaşımları

Eğer geçmişte benzer projeler yapılmış ve projenin başında beklenen sonuç net ise daha güzeli var mı? Müşterinin ne istediği iyi anlaşılıyor, sürprizler az, değişiklik beklentisi az.

Geleneksel Proje Yönetimi Yaklaşımlarının değişime toleransı azdır. Zaman ve bütçe kısıtları içinde hedefe ulaşılmak istenir.

Değişiklik durumunda talep analiz edilir, plana etkilerine bakılır ve güncellemeler yapılır. Değişiklik hem projeyi hem de değişiklik üzerinde çalışan proje ekibinin taahhütlerini etkiler.

Geçmiş deneyimler, yaşanan problemleri ve çözümlerini yeni projeye taşıyorsa belirsizlik ve sürprizlerle az karşılaşılacak demektir.

Benzer projelerde yer almış ekipler deneyimlidir, daha kaliteli ve hatasız iş çıkarabilirler.

Sonu belirli projeler plan odaklı ilerlerler. Başarı plana uyum ile ölçümlenir.

Doğrusal Proje Yönetimi Yaşam Döngüsü Yaklaşımı

Yaşam döngüsü bileşenlerinde (Kapsam, Planlama, Yürütme, İzleme&Kontrol, Kapama) geri dönüş yoktur. Herhangi bir süreçten geri dönmeme zayıflık olarak görülebilir. Geri dönüşün olmaması gelişim fırsatlarını kaçırmak anlamına gelir. En başa dönmek ise yapılan tüm işin değişmesi anlamına gelebilir. Aynı şekilde müşteriden gelecek kapsam değişiklikleri de süreci baştan almaya sebep olacaktır.

Doğrusal model değişime toleransı az modeldir.

Kırılımlı Proje Yönetimi Yaşam Döngüsü Yaklaşımı

Doğrusal ve Kırılımlı Yaklaşımlar arasındaki tek fark teslimatlar Kırılımlı yapılarda zaman çizelgesinde belirtilen noktalarda gerçekleştirilirler. Çözüme parça parça, kırılımlar halinde ulaşılır. Son kırılım gerçekleştirildiğinde proje tamamlanır.

Kırılımlı yakalaşım pazarın tetiklediği bir yaklaşımdır. Pazara hızlı girmek ve zamanla özellikleri artırmak vb. 

Doğrusal Yaklaşımlar değişimi istemez ve olası değişimlere karşı zaman rezervleri koyarlar. Kırılımlı yaklaşım değişimi destekler. İlk kırılımın ortaya çıkması sonrasında müşterinin de farkındalığının artması sonucu değişiklikler projenin geri kalanı için adapte edilir.

Doğrusal modellerde tam çözüme giderken aktiviteler belirli bir sıra ile gerçekleştirilmek zorundadırlar. Bu durum gelecekte ek taleplerin olması durumunda başa dönülmesini gerektirebilir.  

Kırılımlı yaklaşım beklenmedik değişikliklere kapısını açan bir yaklaşımdır.

Çevik Proje Yönetimi Yaklaşımları

Geleneksel Yaklaşımlarda gereksinimlerin netleştirilmesi ve bu doğrultuda detaylı planların yapılması gerekir.  Bir projenin yapılması gerekiyor fakat ne yapılacağı net olarak bilinmiyorsa Geleneksel Yaklaşımı tercih edemezsiniz. Bu tip bir duruma düşen proje yöneticileri tornavida yerine çekiç kullananlar gibidirler. Projeyi gerçekleştirmek için ellerindekilerle yola çıkarlar. Yönetimler bu tip değişken kapsamdan çekinirler. Kaynaklar sonucu bilinmeyen bir projeye çekilirken projenin sonucunda elde edilecek fayda kestirilememektedir.

Bu tip durumlarda şirketler avantajlarını kaybetmemek için plan-odaklı yaklaşımdan değişiklik-odaklı yaklaşımlara (çevik) yönelirler. Geleneksel  yaklaşımla yönetilen projeler değişiklikten olumsuz etkilenir, plan güncelleme ve buna bağlı efor-zaman kayıplarını yaşamak istemezler. Çevik Yaklaşımlar değişiklik olmadan başarıya ulaşamazlar. Zamanında ve anında planlama ilkesine dayanırlar. Yalın prensiplerle kaynak israfının önüne geçerler.

Çevik Yaklaşımların başarısı proje ekibinin ve müşterinin açık, dürüst ve anlamlı işbirliğine bağlıdır. Müşterinin çevik yaklaşımları ve geliştirme ortamını, proje ekibinin müşterinin işini ve nasıl iletişim kuracağını öğrenmesi gerekir. Proje Yöneticisi her iki tarafı bir araya getiren bir ortam yaratmaktan sorumludur. Sorumluluğu paylaştırır, projeye liderlik eder.

Proje ekibi çok kalabalık ise daha küçük projelere ve ekiplere bölmek daha faydalı olabilir. Daha küçük ekipler ve projeler sınırlı kapsamlarıyla üzerlerine düşeni başarmalıdırlar.  Geçici bir proje ofisi ile tüm bu projelerin koordinasyonu sağlanabilir.

Çevik Yaklaşımların iki tipte incelenebilir. Döngülü ve Uyarlamalı Yaklaşımlar.

Proje ile ilgili bazı özellikler eksik ya da net tanımlı değilse Döngülü, beklenen sonuç net değil ve buna bağlı özellikler eksik ya da iyi tanımlanmamışsa Uyarlamalı yaklaşım tercih edilmelidir.

Döngülü Proje Yönetimi Yaklaşımı

Projeden beklenen sonuca ilişkin fonksiyonlar, gereksinimler bilinmiyor veya tanımlı değilse tercih edilir. Her döngü sonunda bir prototip ya da çalışan bir çözüm çıktığını düşünebilirsiniz. Böylelikle müşteriye çalışan bir çözüm üzerinde düşünmesi ve varsa ek taleplerini alırsınız. Müşteri tamam diyene kadar süren bir süreçtir.

Döngülü yaklaşımlar öğrenmek ve keşfetmek için fırsat yaratırlar. Her döngüde daha iyi bir sonuç ortaya çıkar.

Uyarlamalı Proje Yönetimi Yaklaşımı

Projenin sonucuna ilişkin net bir bilgi yoksa tercih edilir. Döngülü Yaklaşıma benzerdir. Döngülü yaklaşımda bir zaman çerçevesi esas alınarak çözüm üretilmeye çalışılırken Uyarlamalı Yaklaşımda her bir çevrim doğrultusunda hedefe ulaşılmaya çalışılır.

Extreme Proje Yönetimi Yaklaşımı

Çözüm ve hedef net olmadığı durumlarda tercih edilir. Ar-Ge, yeni ürün geliştirme, süreç iyileştirme projeleri örnek olarak verilebilir. Yüksek risk, değişiklik ve hız içeren projeleri kapsar. Hata oranları yüksektir.

Bu tip projeler bir takım varsayımlarla ve beklentilerle başlayıp, çok farklı noktalara gidebilir. Tekrarlana süreçlerle müşterinin fikri değişebildiği gibi proje ekibinin yönüde değişir. Ara çözümler başarılı olarak Kabul edilirken, iptal edilebilirler. Sabit bir bütçe ya da zaman hedefinden bahsetmek zordur. Müşteri ve proje ekibi “en kısa süre, uygun maliyete” ye odaklanırlar.

Extreme Yaklaşımı

Hedefler net değildir, keşfedildikçe netleşir. Her fazda müşteri ve proje ekibi geleceğe dair bir şeyler öğrenirler. Çevik Yöntemlerde kapsam baştan belirlenirken Extreme Yaklaşımda her fazda yeniden gözden geçirilir.

Extreme Yaklaşımda Çevik Yaklaşımlar gibi döngülüdür. 1-4 hafta gibi kısa sürelerle sonuç, hedef netleştirilmeye çalışılır. Kabul edilebilir bir çözüm bulunabilir, hiç uğraşmadan reddedilebilir. Müşteri “Ben görene kadar bir şey söyleyemiyorum” dediğinde, hedefin çok belirsiz olması Çevik Yöntemlerden ayrıldığı noktadır.

Extreme Yaklaşım daha fazla müşteri katılımı bekler. Hatta müşterinin liderlik etmesi gerekebilir.

Extreme Yaklaşımlarda her faz diğer fazın gerçekleştirilmesi ve kapsamı için belirleyici olabilir.

Yararlanılan Kaynak: Effective Project Management: Traditional, Agile, Extreme, Seventh Edition, Robert K. Wysocki, PHD

Proje Başarısını Gerçekçi Olarak Değerlendirmek

Proje başarısını ölçümlemek zor ve tartışmalı olabilir. Her projenin farklı olması başarısını farklı değerlendirmeyi gerektirebilir. Sayılar bir çok şey söyleyebilir ama proje başarısını değerlendirmek ayrı bir şeydir. Basitçe söylemek gerekirse projenin hedeflerini tutturması diyebiliriz. Önemli olan proje yönetimi ile gerçekleştirilebilecek olan ve kontrol edebileceğiniz başarı faktörlerinin doğru belirlenmesidir.

Proje başarı ölçümlerinde planlanan-gerçekleşen veriler dikkate alınarak sapmalara bakılır. Sonuçlar performans hakkında bilgi verirken projenin geri kalanına ilişkin ayarlamalar yapmanızı, gelecekteki projelerin daha iyi planlanmasını sağlar.

Planlanan ve gerçekleşen süre, maliyet bilgileri tahminlerinizin doğruluğunu, tahmin süreçlerinizin performansınızı ve başarısını gösterir.

Eğer hedefleriniz aşağıdan yukarıya (aktivite, aşama, proje) bazında tanımlanmışsa, projenin tamamlanması ile elde edilen bilgiler tüm projeye ilişkin hedeflerin tutup tutmadığını görmenizi sağlar. Genel bir hedef belirlenmişse başarı ve başarısızlığı belirlemek zorlaşır.

Projeler, proje ekibi ile başarılır. Projelere ilişkin göstergeler proje ekibinin somut  ve soyut değerlendirilmelerini gerektirir.

Proje değerlendirilmesinde paydaş ve müşteri desteği önemli bir göstergedir.

Proje ekip üyelerinin değişme veya işten çıkma oranları önemli bir göstergedir. Proje ekip üyelerinin projede veya şirkette kalmaları önemli bir başarı göstergesidir.

Yönetimin, sponsorun, proje müşterisinin ve paydaşların proje süresince veya sadece sonunda yapacakları değerlendirmeler (memnuniyet anketleri vb.) önemli göstergelerdir.

Projenin kazanacağı ödüller, basında çıkan olumlu yazılar vb. başarı göstergeleridir.

Projenin sağlayacağı faydaların takip edilmesi, planlanan-gerçekleşen kıyaslaması Yönetimin sorumluluğundadır. Yönetim yapacağı değerlendirmelerle onay-red süreçlerini gözden geçirmeli, şirketin stratejik hedeflerine uygun, doğru projelerin seçimi konusunda sistematik, matematiksel bir süreç uygulamalıdır.

Proje Yönetimi Tarihçesi: 1985 – 2013

1985: Şirketler maliyet kadar kalite konusunda da rekabet etmeleri gerektiğini anladılar. Toplam Kalite Yönetimini yerleştirmek için proje yönetimi prensiplerini izlediler. Kalite ve Proje Yönetimi birlikteliği başladı.

1990: 1989–1993 durgunluk döneminde, şirketler zaman çizelgesi sıkıştırma ve pazarda ilk olmanın önemini fark etti. Mühendislik daha iyi çizelgeleme tekniklerini kullanmaya başladı.

1991–1992: Üst Yönetimler, karar verme ve yetkileri Sponsorlara devretmeye başladılar. Kendini yöneten ekipler çıktı.

1993: 1989–1993 durgunluk dönemi bitmiş, şirketler yeniden yapılanma sürecine girmişlerdi. Daha az adamla daha fazla iş yapılabilmesi isteniyordu. Yeniden yapılanmanın yolu proje yönetiminden geçiyordu.

1994: Proje maliyet kontrol sistemleri ile tahmin gücünün gelişeceği, gerçek maliyeti hesaplamanın önemi anlaşıldı. Proje Yaşam döngüsü maliyeti hesaplanmaya başladı.

1995: Şirketler projelerin başlangıç kapsamından çok farklı bir şekilde sonuçlandığını fark ettiler. Etkin değişiklik kontrol sistemleri geliştirilmeye başlandı.

1996: Risk yönetiminin tampon süre belirlemek olmadığı anlaşıldı. Risk Yönetimi Planları yapılmaya başlandı.

1997–1998: Proje Yöneticiliğinin profesyonel bir kariyer olduğu anlaşıldı.

1999: Eşanlı mühendislik ve hızlı ürün geliştirmenin sırf o işe ayrılmış kaynaklarla gerçekleştirilebileceğini anladılar. Bir arada çalışan ekipler ortaya çıktı.

2000: Uluslararası işbirlikleri ve ortaklıkların artması proje yönetimini zorunlu hale getirdi. Uluslararası ekipler kurulmaya başlandı.

2001: Şirketler proje yönetimi olgunluk seviyelerini metodolojilerle geliştirmeye başladılar.

2002: Proje Yönetimi şirketler için stratejik bir konuma yükseldi. Hem proje yönetimi için stratejk planlama hem de stratejik planlamalara projelerin desteği başladı.

2003: Intranet durum raporlaması vb. hızlı bilgi paylaşımları çıktı.

2004: Intranet raporlaması hangi kaynağı nerede ve ne kadar çalıştığının görülmesini sağladı. Kaynak optimizasyonları ve dağılımları yapılmaya başlandı.

2005: Akti Sigma vb. teknikler Proje Yönetimi ile uyumlu hale geldiler. Sürekli Gelişim proje yönetim metodolojilerine de yansıdı.

2006: Sanal proje ekipleri ve proje ofisleri kurulmaya başladı.

2007: Yalım üretimin kavramları proje yönetimine uyarlandı.

2008: Geçmiş deneyimlerin önemi far kedildi, Alınan Dersler toplanmaya ve saklanmaya başlandı.

2009: Proje yönetim metodolojileri daha fazla iş süreçleri içermeye başladı.

2010: Karmaşık projelerde daha fazla paydaşı yönetmek zorunda kalan Proje Yöneticileri için Proje Paydaş Yönetimi önemli hale geldi

2011: Ek paydaşların ortaya çıkması tek bir Sponsor yerine Proje Yürütme Kurullarının ortaya çıkmasına sebep oldu.

2012: Kapsam, zaman, maliyet ve kalite kadar projenin üreteceği değer bir kısıt olarak ele alınmaya başlandı.

2013: Etkin proje yönetiminin zaman ve maliyetten çok daha fazla bilgi olduğu anlaşıldı.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner

Proje Yönetimi Tarihçesi: 1960 – 1985

Proje Yönetimi istekten çok ihtiyaçtan doğmuştur. Diğer bir çok konuda olduğu gibi mevcut alışkanlıkları, kullanılan yöntem ve teknikleri değiştirdiği için yavaş yayılmıştır. 1960’ların ortalarında ve sonlarına doğru kurumlar değişikliklere kolay adaptasyon sağlayabilecekleri yönetim teknikleri ve organizasyonel yapıların arayışına girdiler.

Özellikle havacılık, savunma, inşaat, yüksek teknoloji içeren mühendislik, bilgisayar ve elektronik sektörlerinin karmaşık işleri, dinamik ortamlarda gerçekleştirmeleri gerekliliği proje yönetimini mecbur kıldı.

Proje Yönetimi, resmi olmayan bir şekilde başladı, Proje Yöneticilerinin yetkileri çok azdı. Bir çok proje, aralarındaki ilişkiler iyi olduğu için, Fonksiyonel Yöneticiler tarafından yönetildi.

1970’lerin sonunda ve 1980’lerin başında, projelerin artan büyüklüğü ve karmaşıklığı karşısında bir çok firma mevcut yaklaşımlarıyla projeleri yönetemeyeceklerini anladılar ve resmi proje yönetimine geçmeye karar verdiler.

Aşağıdaki sorular bu geçişin gerekip gerekmediğini belirlemek için kullanılabilir;

  • İşler karmaşık mı?
  • Ortam dinamik mi?
  • Kısıtlar sert mi?
  • Birden fazla işin entegre yürütülmesi gerekiyor mu?
  • Aşılması gereken birden fazla fonksiyonel sınır var mı?

Eğer cevaplar evet ise proje yönetimine geçişin vakti gelmiş demektir. İlk etapta belirli bir tip projelerde (Ar-Ge vb.) veya tek bir departmanda geçiş yapılabilir.

Proje Yönetimine bir taahhüt vermeniz gerektiğinde ihtiyacınız vardır. Kapsam, zaman, bütçe veya kalite vb. konularda taahhüt vermeniz gerekmiyorsa proje yönetimi yapmanıza gerek kalmayabilir.

Proje Yönetimine yavaş geçişin sebebi faydalarının yeterince anlaşılmamasıydı. Proje Yönetiminin getireceği değişimlerin “devrimsel” olması yönetimleri korkutuyordu ve temkinli yaklaşıyorlardı. Fark edilen şuydu: Mevcut işleri eskisi gibi yapmak ve başarmak mümkün değildi. Bir kereliğine yapılan proje aktiviteleri rutin işleri bozmayacaktı.

Proje organizasyonları geçici olduğu için mevcut organizasyonel yapı bozulmayacaktı. Projeler bir tiyatro gibi ele alınacak, herkes rolünü oynadıktan sonra yerine geri dönecekti.

Proje ve iş önceliklerinin dengelenememesi, uzun vadeli planlamaların beklenenden çok vakit alacağına dair çekinceler ve kaynakların projeden projeye aktarılarsa gelişimlerinin yavaşlayacağı gibi konular gündeme geldi.

Üst yönetimin orta kademeye yetki devri alışılmadık bir şeydi. Yönetimler proje yönetiminin ve getirdiği değişikliklerin şirketin iyiliği için olduğuna ikna olmaya başladılar, aşağıdaki durumlarda yardımcı olacağını düşünmeye başladılar;

  • Dengesiz ekonomi
  • Artan maliyetler
  • Artan karmaşıklık
  • Yükselen rekabet
  • Teknolojik değişiklikler
  • Sosyal Tepkiler
  • Müşteri Odaklılık
  • Çevre
  • İşin kalitesi

Proje Yönetimi bu problemlere çare değildi ama şirketin bu değişken ortama uyum sağlamasına yardımcı olacaktı. Eğer ortama uyum sağlanmazsa;

  • Karlar azalacak
  • İşgücü ihtiyacı artacak,
  • Maliyet artacak, gecikmeler yaşanacak, cezai yaptırımlara maruz kalınacak,
  • Teknolojinin gerisinde kalınacak,
  • Ar-Ge çalışmaları zamanında ve istenilen sonuçlarla sonuçlanmayacak,
  • Pazara geç girilecek,
  • Yanlış kararlar alınacak,
  • Yatırımlar geri dönmeyecek,
  • Hedefli işler başarılamayacak,
  • Zamansal ve parasal problemler yaşanacaktı.

Şirketler birden fazla ürün ile rekabete girdiklerinde, ürünler birbirlerinden farklı olduğunda organizasyonel karmaşıklığında arttığını gördüler. Fonksiyonel krallıklar yıkılacaktı.

1970’te havacılık, savunma ve inşaat proje yönetimine geçmeye başladı. NASA ve Savunma Bakanlığı tedarikçilerini proje yönetimi yapmaya zorladı.

Fonksiyonel yöneticiler kaynaklarını birden falza projeye yönlendirmekte ve kontrolde zorlanmaya başladılar. Proje Yönetiminin resmi olarak yapılması ve üst yönetimin destek vermesi gereklilikleri ortaya çıktı. Proje Yöneticilerinin rolü netleştirilmeye çalışıldı. Tüm bunlar yönetim için 4XL baş ağrısı anlamına geliyordu.

Proje Yöneticileri için biçilen rol;

  • Proje sorumluluğunun tek bir kişide toplanması
  • Departmana değil projeye odaklılık,
  • Fonksiyonel birimler arasında koordinasyonu sağlama,
  • Entegre planlama ve kontrol yapma.

Proje Yönetiminden önce bu dört rol yöneticiler tarafından yapılmaktaydı. Böyle bir karar yönetimin çalışanlardan beklentilerini değiştirmişti;

  • Karar verme aşağı kademelerde yapılmalıydı,
  • Her şey üst yönetime çıkarılmamalıydı,
  • Tarafların kararlarına güvenilmeliydi.

Yönetimler bu kararların doğruluğunu zaman içinde görmeye başladılar;

  • Değişken ortama kolay adaptasyon,
  • Belirli bir zaman diliminde birden fazla disiplini kolayca yönetmek,
  • Yatay iş akışları,
  • İş sorumluluklarının kolayca tanımlanabilmesi
  • Karar vermenin birden fazla disiplin tarafından yapılması,
  • Organizasyonel yapının değilmesi.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner

Proje Yönetimi Tarihçesi: 1945 – 1960

Türkiye’de eğitim ve danışmanlık verdiğim firmalar neredeyse yıllardır proje yöneten firmalar. Dünya’da neredeyse 70-80 yıl önce yaşanmış ve çözümü bulunmuş problemleri bugün hala yaşayan firmalar gördüğümde üzülüyorum. Proje Yönetimi’nin tarihçesini yazarak bu konuda olgunlaşma sürecini biraz açmak istiyorum;

Eğitimlerimde ilk projeler alarak Piramitleri söylerim. O kadar uzağa gitmeyeceğim, yakın tarihten başlayacağım.

1940’larda projeler “çitin üstünden bakan” departman yöneticileri ile gerçekleştiriliyordu. Departman yöneticileri Proje Yöneticisi rolünü oynarlardı. Üst yönetim departman yöneticilerini toplar ve projenin gerçekleştirilmesi talimatını verirdi. Departman yöneticileri kendi aralarında konuşur, görev paylaşımı yapar, her departman yöneticisi üzerine düşen işi yaptığında topu çitin karşı tarafına atar, karşı tarafın yakalamasını beklerdi. Topu karşı tarafa attıktan sonra sorumluluk almazlar, sorumluluğun karşı tarafta olduğunu düşünürlerdi. Proje başarısız olduğunda top elinde olan departman yöneticisi suçlu olurdu.

Proje ile ilgili bilgi almak için tek bir sorumlu yoktu. Bilgi alınmak istendiğinde ilgili departman yöneticisine gidilmek zorunda kalınıyordu. Küçük projelerde problem yoktu ama projeler büyüdükçe ve karmaşıklaştıkça sıkıntılar artmaya başladı.

2. Dünya Savaşının ardından başlayan soğuk savaş dönemi önemli savunma sanayi projelerini ortaya çıkardı. Böylesine önemli ve büyük projeleri (B52, Polaris Denizaltısı vb.) çitin üstünden bakarak yönetmek mümkün değildi. Devlet projeler konusunda tek bir kontak kişi olmasını istiyordu. Savunma Sanayi öncelikle küçük projelerde proje yönetimi mantığına geçmeyi tercih etti. NASA, uzay programındaki tüm işlerde proje yönetimi kullanma kararı aldı.

Havacılık ve savunma sanayinde bütçeler %200-300 aşılıyordu. Proje Yönetimi olmaması bir yana, öngörüler, tahminler konusunda çok başarısız sonuçlar alınıyordu.

1960’ların başında havacılık ve savunma sanayinde proje yönetimi oturmaya başlamış, tedarikçilerinde bu mantıkla çalışması istenir olmuştu.

Devlet standartlaştırma beklentisi içindeyken, yüzlerce tedarikçinin planlama ve raporlama süreçlerini standartlaştırmaları kolay değildi. Devlet, proje yaşam döngüsü ve maliyetler ile ilgili planlama ve kontrol süreci geliştirdi. Böylelikle ayrılan bütçelerin planlandığı gibi harcanması sağlanabilecekti. Devletin başlattığı bu çalışma zamanla tüm devlet çalışmalarına sadapte edilmeye başlandı.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner

Kamu Projelerinde Dikkat Edilmesi Gerekenler

Kamu projeleri etkiledikleri alan ve kişi sayısı açısından çok önemlidirler. Çoğu zaman özel sektör projelerinden daha zordurlar;

  • Çoğunluk için yapılan projeler çatışmalara yol açarlar.
  • Çok fazla paydaş ve paydaşların alt paydaşları söz konusudur.
  • Diğer politik görüşlerin eleştirileri ve baskıları söz konusudur.
  • Hata toleransı azdır.
  • Çıktının faydalarını sayısallaştırmak zordur.
  • Kanun ve bürokrasi kısıtları altında gecikmeler yaşanabilir, kaynak bulmak zorlaşabilir.
  • Dış Kaynaklarla koordinasyon zordur.
  • Mevcut kaynaklarla proje gerçekleştirilmek zorundadır.
  • Destek vermesi gereken paydaşların öncelikleri değişebilir, proje başarısını farklı algılıyor olabilirler.
  • Politik reklamlar zorlayıcı koşullar doğurabilir.
  • Kamu projeleri kısa-orta-uzun vade de olabilir. Uzun vade projeleri gelecek kuşaklar için yapılan yatırımlardır. Bunun yaratacağı problem bugün projeyi tanımlayan tarafların gelecek nesli temsil etmeleridir. Gelecek neslin ihtiyaçlarını belirlemeye çalışırlar.
  • Kamu projeleri özel sektör projelerinin çoğundan daha karmaşıktır. Bazı projelerin çıktıları proje başında tanımlanırken bazı projelerde yürütme esnasında netleştiriliyor olabilir. Kamu projeleri değişen politik ortam ve çevreye göre hızlı adaptasyon konusunda yavaş kalabilirler.
  • Kamu projelerinde sadece ekibi yönetmeniz yetmez, kamu ve özel sektör şirketlerini, STK’lar vb. diğer kuruluşları da yönetmeniz gerekir.
  • Kamu projelerinde proje ekipleri izole çalışırlar ve belirli dönemler haricinde yapılanlar izlenemeyebilir. Özel sektör projelerinde projelere daha yakın durulur ve ilgili tüm paydaşların izlemesi sağlanır.
  • Kamu projelerinde Proje Yöneticileri resmi olarak görevlendirilir ve gereken yetki verilir.
  • Verilen yetki doğrultusunda ilgili paydaşlar bilgilendirilir ve desteklemeleri istenir.

Kamu projelerinin başarı ya da başarısızlığı özel sektör projelerini doğrudan etkiler. Kamu projelerinde aşağıdaki hataların yapılmaması gerekir;

  • Projeden etkilenecek (vatandaşlar, şirketler) ve etkileyecek (paydaşlar) tarafların ihtiyaçlarının iyi tanımlanamaması,
  • Gerçekçi olmayan bitim tarihleri ve buna ek olarak gecikmelere tolerans gösterilmemesi,
  • Proje gerçekleştirecek nitelikli kaynaklar olmadan harekete geçmek, kaynakları sağlamamak,
  • Planlamaya gerekli vakti ayırmamak,
  • Doğru teknoloji, ekipman vb. seçiminde profesyonel tekniklere başvurmamak,
  • Doğru ve nitelikli tedarikçilerle çalışmamak,
  • Proje risklerini tanımlamamak, analiz etmemek, gerekli yanıt planlarını üretmemek,
  • Gerçekçi olmayan varsayımlarla yola çıkmak,
  • Paydaşlararası çatılmaları görmezden gelmek, çözümlememek,
  • Beklenmedik durumlarda harekete geçmemek, yavaş kalmak, karar verme ve problem çözme süreçlerini proje özelinde ele almamak,
  • Proje Yönetimi Metodolojilerini kullanmamak,
  • Deneyimli proje yöneticileri yetiştirmemek, nitelikli proje yöneticileri ile çalışmamak,
  • Proje sürecine paydaşları gerektiği gibi dahil etmemek
  • Geçmiş proje deneyimlerinden alınan dersleri yeni projelere adapte etmemek, bu konuda bir yöntem geliştirmemek,
  • İyi tanımlanmamış kapsamla yola çıkmak sayılabilir.

Kamu’nun özel sektör projelerine olumsuz etkilerine aşağıdaki örnekleri verebiliriz;

  • Bürokratik süreçlerin çokluğu ve uzunluğu,
  • Onay, Kabul vb. konularda kamunun yeterli personeli olmaması,
  • Kanun, yönetmeliklerdeki kısıtlayıcı güncellenmemiş kurallar,
  • Ödemelerin gecikmesi,
  • Devlet kademelerindeki değişikliklerin yaratabileceği otorite boşlukları,
  • Proje özelinde yaklaşılmaması sayılabilir.

Yararlanılan Kaynak: Project Management: A Systems Approach to Planning, Scheduling, and Controlling – 11th Edition – Harold Kerzner

 

Raporlama Yapmak İçin Vakti Olmayan Proje Ekip Üyeleri

Proje ilerleyişinin izlenebilmesi, problemlerin, olası gecikme ve bütçe aşımlarınının fark edilebilmesi için Proje Ekip Üyelerinin  gerçekleştirdikleri aktiviteler ile ilgili raporlama yapmaları gerekir.

Raporlamaların başarıyla gerçekleştirilebilmesi için tüm paydaşların üzerlerine düşenleri yapmaları gerekir;

  • Proje Ekip Üyelerinden beklenen raporlamanın basit ve kolay olması gerekir.
  • Hangi aktiviteler ile ilgili ne zaman ve nasıl raporlama yapılacağı bildirilmelidir.
  • Raporlamalarda opsiyonel olarak görüş bildirme imkanı tanınmalıdır.
  • Proje Ekip Üyesinin raporlama konusunda görüşleri alınmalı, iyileştirme konusunda öneriler getirmesi istenmelidir.
  • Raporlama sürecinde ihtiyaç duyulan bilgilerin gerekliliği açıklanmalı, alınan raporlamanın nasıl değerlendirildiği açıklanmalıdır.
  • Raporlamayı unutanlar için hatırlatma yapılmalıdır.
  • Kronik olarak geciken veya göndermeyenlerle birebir görüşmeler yapılmalı, durum masaya yatırılmalıdır.
  • Raporlama yapılmamasının arkasındaki gerçek sebepler (kötü haber vermekten çekinme vb.) değerlendirilmelidir.
  • Proje Ekip Üyesinin işi gerçekleştirme ve raporlamayı birlikte düşünerek tahmin yapması istenmelidir.

  • Raporlama konusundaki tutum ve davranışlar izlenmeli, Proje Gözden Geçirme Toplantılarında gündem edilmelidir.
  • Raporlamanın zamanında ve düzgün yapılmamasından kaynaklanan problemler izlenmeli, Ekip Üyelerine açıklanmalıdır.
  • Bazı istisnai durumlarda Proje Ekip Üyelerinin Yöneticileri ile veya Sponsorunuz ile görüşerek duruma çözüm üretmelerini isteyebilirsiniz.
  • Raporlama konusunda bilgi ihtiyacı olanlara eğitim verilmeli, örnek bir rapor hazırlanarak süreç kolaylaştırılmalıdır.
  • Projenin başından sonuna kadar aynı düzende raporlama yapılmasına gerek olmayabilir. Örneğin projenin başında haftalık, yürütme sürecinde 15 günde bir raporlama iş görebilir. Raporlama sürecinizin etkinliğini değerlendirmeniz önemlidir.
  • Raporlama sadece yazılı değil, birebir görüşme veya telefon ile yapılabilir.
  • Büyük ve karmaşık projelerde raporlama ile ilgili özel bir kişi görevlendirilebilir.
  • Proje Ekip Üyesi aktivitesi ile ilgili yöneticisine bir rapor oluşturuyorsa mükerrerlik olmaması adına o rapor proje için değerlendirmeye alınabilir.
  • Proje kapanışında kimin kaç adet rapor gönderdiği vb. istatistikler, değerlendirme notuyla birlikte alınan dersler olarak kaydedilmelidir.