Kategori arşivi: Paydaş Yönetimi

Projelerde Algıların Filtrelenmesi

Proje Yöneticisi olayları nasıl görüyor ve anlıyorsa ona göre davranır. Proje ortamında bir çok durumda proje yöneticisinin filtre veya  güneş gözlüğü kullanması gerekir.

Proje Yöneticisi için en önemli tehlike bilmediğini bilmemektir. Toplum olarak “bilmiyorum” demekte sıkıntı yaşıyoruz. Bir çok şeyi bildiğimizi ya da bildiklerimizin yeterli olduğunu düşünüyoruz.

Dikkat edilmesi gerekenler;

  • Proje Yöneticisi tahmin ettiği şeylerin öyle gerçekleşmeyebileceğini düşünmeli ve hazırlıklı olmalıdır. Ne kadar deneyimli olursanız olun farklı olasılıkların farklı sonuçlar doğurabileceğini ihmal etmemek gerekir. Deneyimlerinizle benzerlik içerse dahi kesin ve mutlak yaklaşmaktan kaçınmanız gerekir.
  • Geçmiş deneyimleriniz ve bilgi düzeyiniz kararlarınızı doğrudan etkiler. Önyargılarınızın geçmiş deneyim ve mevcut bilgilerinizden kaynaklandığını unutmayın. Proje Yöneticisi olarak alacağınız kararlarda her türlü farklı deneyim ve bilgi düzeyinde proje ekip üyelerinin katkısı olabileceğini unutmayın.
  • Proje Yöneticileri, aktivitelere atadıkları personelin, fizibilitesini yapmadıkları bir işe giriştiklerini unutmamalıdırlar. İyi düşündüğünüz, filtrelediğinizden emin olduğunuz konularda görevlendirme yapmalısınız.
  • Aciliyet durumlarında düşünmeye ve temkinli davranmaya vaktinizin olmadığı düşüncesiyle harekete geçebilirsiniz. Aksine özellikle acil durumlar kaliteli düşünme ve temkinli olmanın en önemli olduğu durumlardır. Kişisel filtrelerinizle doğru işe, doğru şekilde odaklanmanız buna bağlıdır.
  • Herkesin farklı güneş gözlüğü taktığını, farklı filtrelere sahip olduğunu unutmamanız gerekir. Proje Ekibi problemleri, mevcut durumu ve aciliyeti proje yöneticisi gibi görmüyor olabilir. Proje Ekibinin sizinle aynı filtrelere sahip olduğunu varsaymayın.

Proje Yönetiminde Paydaş Haritalama/Gösterim

What is Stakeholder Mapping? Guide to Stakeholder Maps | Miro

PMBOK® Guide 6’da Paydaşların Tanımlanması sürecinde önerilen bu teknik PMBOK® Guide 5’den daha farklı yöntemler içeriyor. PMP sınavına hazırlananlar dikkat etmelidir.

Paydaş Haritalama/Gösterim, paydaşların farklı yöntemlerle kategorize edilmesidir. Paydaşların kategorize edilmesi paydaşlar arası ilişkilerin ve etkileşimlerin sağlanması açısından önemlidir.

Kullanılan yöntemler aşağıdaki gibidir;

Güç/İlgi, Güç/Etki ya da Etki/İlgi Matrisleri – Paydaşları güç seviyeleri (yetkileri), projenin çıktılarına yönelik ilgileri, projenin çıktılarına olan etkileri, planlama ve yürütmeye etki düzeyleri açısından değerlendirmek ve gruplandırmak için kullanılır. Küçük veya paydaşlar arası ilişkilerin basit olduğu projelerde tercih edilir.

Stakeholder Analysis for UX Projects

Paydaş Küpü (Stakeholder Cube) – Proje Yöneticisi ve proje ekibi için paydaşlarla etkileşimi 3 boyutlu olarak ifade etmek için kullanılır.

Stakeholder Cube Template & Examples

Önem (Salience) Modeli – Paydaşları güç ve yetkileri, aciliyet beklentileri ve katılımları açısından ele alan modeldir. Büyük ve karmaşık projelerde tercih edilir. Detaylı bilgi için tıklayınız.

Stakeholder Analysis-Salience Model in Practice | Point Prox

Etkinin Yönleri – Proje paydaşlarının projeye ya  da paydaşlara olan etkileri doğrultusunda sınıflandırılmasıdır. İki şekilde şınıflandırma yapılır;

  • Yukarı Doğru – Yönetim, müşteri, sponsor, yürütme komitesi
  • Aşağı Doğru – Ekip, uzmanlar
  • Dışarıya Doğru – Tedarikçiler, devlet, halk, kullanıcılar
  • İçeriye Doğru – Proje Yöneticileri, Fonksiyonel yöneticiler

Önceliklendirme – Özellikle çok paydaşın yer aldığı projelerde ilişkileri ve iletişimi yönetebilmek için önceliklendirme gereklidir.

Proje Yönetiminde Paydaş Katılımı Değerlendirme Matrisi

Paydaş Katılımı Değerlendirme Matrisi (Stakeholder Engagement Assessment Matrix) paydaşların mevcut ve beklenen katılım, ilgi düzeylerini karşılaştırmak için aşağıdaki süreçlerde kullanılır;

  • İletişim Yönetiminin Planlanması sürecinde mevcut ve beklenen katılım, ilgi seviyeleri arasında farkları ortadan kaldırmak için ek iletişim gereksinimleri olup olmadığının değerlendirilmesi için kullanılır.
  • Proje İletişimlerinin İzlenmesi sürecinde iletişimlerin verimliliği hakkında bilgi sağlaması açısından önemlidir. 
  • Paydaş Katılımının Yönetilmesi sürecinde paydaşların projenin hedeflerini, amaçlarını, faydalarını ve risklerini net olarak anlamalarını sağlayarak projenin başarıya ulaşma olasılığının artırılması hedeflenir. Paydaş Katılımı Değerlendirme Matrisi, paydaşların projenin aktif destekçileri olmalarına ve proje kararlarının yönlendirilmesine yardımcı olur. İnsanların projeye tepkileri önceden tahmin edilerek, destek kazanmak ve olumsuz etkileri en aza indirmek için ileriye yönelik etkin önlemler alınabilir.

Paydaşların projeyi etkileme olasılıklarının en yüksek olduğu dönem genellikle başlangıç evreleridir ve proje ilerledikçe bu etki kademe kademe düşer.

Proje yöneticisi, paydaşların projeye katılımından ve bunların yönetilmesinden sorumludur ve gerektiğinde yardımcı olması için proje sponsoruna başvurabilir. Paydaş katılımının aktif yönetimi, projenin hedeflerini ve amaçlarını gerçekleştirememesi riskini azaltacaktır.

Paydaş katılım durumu aşağıdaki gibi sınıflandırılmaktadır;

  • Habersiz – Proje ve potansiyel etkisinden habersizdir.
  • Dirençli – Projenin ve potansiyel etkilerinin bilincindedir ve değişime direnç gösterir.
  • Tarafsız – Projenin bilincindedir ancak ne destekleyici ne de dirençlidir.
  • Destekleyici – Projenin ve potansiyel etkilerinin bilincindedir ve değişimi destekler.
  • Lider – Proje ve potansiyel etkilerinin bilincindedir ve projenin başanya ulaşması için aktif katılım gösterir.

Paydaşların ilgi düzeyleri farklı proje aşamalarında değişiklik gösterir. Paydaş Katılımının İzlenmesi sürecinde paydaş katılımı ile ilgili değişiklikler izlenir.

Proje Yönetiminde Fikir/Zihin Haritalama (ldea/Mind Mapping)

Proje Yönetiminde Fikir/Zihin Haritalama (ldea/Mind Mapping), bakış açılarındaki ortak ve farklı noktaları yansıtmak ve beyin fırtınası seanslarıyla yaratılan fikirleri birleştirmek için kullanılır.

Aşağıdaki süreçler kullanılması önerilen bir tekniktir. 

  • Gereksinimlerin Toplanması sürecinde kapsamın netleştirilmesi için beyin fırtınası ile toplanan gereksinimlerin ortak ve farklı yanlarını belirlemek için kullanılır.
  • Kalite Yönetiminin Planlanması sürecinde bilgileri görsel olarak düzenlemek için kullanılır. Proje ile ilgili kalite konseptinde yapılacakların veya fikirlerin organize edilmesinde kolaylık sağlar. Ayrıca kalite gereksinimlerini, kısıtları, bağımlılıkları ve ilişkileri belirlemeye yarar.
  • Paydaş Katılımının Planlaması sürecinde paydaşlarla ilgili bilgileri, paydaşlar arası ilişkileri ve paydaşların şirket ile ilişkilerini grafiksel olarak organize etmeye yarar.

Fikir/Zihin Haritalama yukarıdaki süreçlere ek olarak aşağıdaki konularda kullanılabilir;

  • Toplantılarda, fikirleri ve toplantı notlarını derleme,
  • Kapsamı belirlerken ihtiyaçları, kısıtları, varsayımları derleme,
  • Proje aşama ve aktivitelerini belirleme,
  • Kimin hangi aktiviteyi gerçekleştireceğini belirleme,
  • Proje sunumları,
  • Proje Yönetimi Yaklaşımının ve Proje yönetimi Planlarının gösterimi,
  • Problem çözümleri,
  • Karar verme,
  • Proje portföyünü belirleme.

Fikir/Zihin Haritalamayı etkin kullanabilmek için;

  • Birden fazla projede oluşturulan haritalar birbirleri ile ilişkilendirilebilir.
  • Ortak terminoloji ve grafiklerin (renk, sembol vb.) kullanılması paydaşlar tarafından anlaşılmasını kolaylaştırır.

Proje Yönetiminde Kök Neden Analizi

Kök Neden Analizi (Root Cause Analysis), bir farklılığa, kusura ya da riske yol açan en temel nedeni belirlemeye yönelik bir analiz tekniğidir. Bir kök neden, birden fazla farklılığa, kusura ya da riske yol açabilir. (PMBOK® Guide)

Proje İşlerinin İzlenmesi ve Kontrolü sürecinde problemin ana sebeplerinin bulunması için kullanılır. Proje Yöneticisi Proje Yönetim Planına göre oluşan sapmaların sebebine odaklanarak hedefleri gerçekleştirmeye çalışır.

Kalitenin Yönetilmesi ve Kalitenin Kontrolü süreçlerinde problemin sebeleri bulunması ve önleyici faaliyetin geliştirilmesi için kullanılır. Problemden hareketle hangi tehditlerin (gecikme, bütçe aşımı vb.) gerçekleşebileceğine odaklanılır. Faydalardan yola çıkarak fırsatların bulunması aynı çerçevede ele alınabilir.

Paydaş Katılımının Sağlanması sürecinde paydaş katılımının sağlanması ile ilgili problemlerin nedenlerine odaklanılır, uygun strateji seçilerek katılımın sağlanmasına çalışılır.

Paydaş Katılımının İzlenmesi sürecinde paydaş katılımının istenen etkiyi yaratmamasının sebeplerine odaklanılır.

Genel İlkeler

  • Kök Neden Analizinin temel amacı, bir sorunun tekrarlanmasını önleyecek etkili düzeltici eylemler oluşturmak amacıyla sorunun temel neden(ler)ini belirlemektir.
  • Etkili olması için sistematik olarak, sonuçların ve temel nedenlerin belirlenip belgelenmiş kanıtlarla desteklenmesiyle yapılması gerekir. Proje ekibinin birlikte çalışmasını gerektirir.
  • Bir olayın veya sorunun birden fazla temel nedeni olabilse de zor olan, bunları ortadan kaldırmak veya düzeltmek için gereken kararlılığı göstermek ve çabayı sürdürmektir.
  • Bir soruna yönelik tüm çözümlerin belirlenmesindeki amaç, en basit şekilde en düşük maliyetle tekrarının önlenmesidir. Eşit derecede etkili alternatifler varsa en basit veya en düşük maliyetli yaklaşım tercih edilir.
  • Belirlenen kök nedenler, sorunun veya olayın nasıl tanımlandığına bağlıdır. Etkili sorun tanımları ve açıklamaları gereklidir.
  • Etkili olması için, analizin, katkıda bulunan (nedensel) faktörler, temel neden(ler) ve tanımlanan sorun veya olay arasındaki ilişkileri gelecekte önlemek için zaman boyutunda bir dizi eylemle ele alınması gerekir.
  • Kök Neden Analizi, reaktif bir kültürün (sorunlara tepki veren), sorunları ortaya çıkmadan önce çözen ileriye dönük bir kültüre (proaktif) dönüştürülmesine yardımcı olabilir. Analizin kullanıldığı ortamlarda zaman içinde ortaya çıkan sorunların sıklığı azalır.

Kök Neden Analizi doğru yapıldığında Proje Yöneticisi problemi erken fark edebilir ve önüne geçebilir. Kök Neden Analizi sürekli gelişim sağlayan bir araç olarak sürekli kullanılabilir.

Kök Neden analizinde en sık kullanılan teknik Balık Kılçığı tekniğidir. Süreç aşağıdaki gibidir;

  1. Problemi tanımlayın
  2. Problem ile ilgili bilgi toplayın.
  3. “Neden” sorusunu sorarak problemin ortaya çıkmasına sebep olan faktörleri belirleyin.
  4. Hangi sebeplerin ortadan kaldırılması durumunda problemin ortadan kalkacağını belirleyin.
  5. Sebebi ortadan kaldırabilecek, kontrol edebileceğiniz uygun çözümleri tanımlayın.

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

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

 

Projeye Birden Fazla Yönetici Müdahale Ediyorsa

Bazı projelerde her karar için farklı bir yöneticiye gidilmesi gerekebilir. Bazen bürokrasi bazen birden fazla yöneticinin koordinasyon ve işbirliği gerekliliği projelerde gecikmelere, motivasyon kaybına sebep olabilir.

Projeyi önemli ölçüde etkileyebilecek durumlarda tek karar vericinin olması tercih edilir. Projenin başında önemli konularda (değişiklik, ödemeler vb.) karar vericilerin belirlenmesi gerekir.

Alınan kararlardan etkilenen ekip üyelerinin, paydaşların sürece dahil edilmemeleri problemlere yol açabilir. Her karara herkesin dahil edilmesi ise süreyi olumsuz etkiler. İnce ayar yapılması gerekir.

Proje başında hangi konuda kimin karar yetkisi olduğu belirlenmeli, hangi konularda ortak karar alınması gerektiği netleştirilmelidir. Emir-demir ilişkisi ve zorlayıcı kontroller ekip motivasyonunu olumsuz etkiler.

Alınan kararların, kimlerin dahil olduğu bilgisi ile kayıt altına alınması gerekir.

Alınacak kararlarda danışılması ve bilgilendirilmesi gerekenler belirlenmelidir.

Projenin kısıtları net olarak ortaya konmalı, yönetiminde uyması gereken konular açıklanmalıdır.

Proje özelinde hangi konularda (satınalma, değişiklik vb.) karar sürecinin nasıl olması gerektiği belirlenmelidir.

Yönetim kendi içinde doğru karar varmak için gerekli sistematiğe sahip değilse Sponsorun Proje Yöneticisine destek vermesi gerekir.

Basit ve karmaşık kararlara aynı yaklaşılmamalıdır. Her kararın olası sonuçları yönetime yazılı ve sayısallaştırılarak açıklanmalıdır.

Yönetimin çelişkiye düşmemesi, kolay ve hızlı karar alabilmesi için ön çalışma yapılmalıdır.

Yönetimin ilgilenmesi gereken konular önceliklendirilerek sıralanmalı, sebepleri açıklanmalıdır.

Yöneticiler arasındaki güç farklılıklarının projeyi olumsuz etkileme olasılığı yüksektir. Güçlü yöneticinin yanlış kararlar alması olasıdır. Herkesin eşit olacağı bir komite yapısı düşünülmelidir.

Bir kararın hayata geçirilmesi öncesinde ilgili tüm yöneticiler dikkate alınarak bir değerlendirme yapılmalıdır.

Proje başında alınacak kararlarda yönetimin beklentisi netleştirilmelidir. Örneğin maliyet veya zaman etkin kararlar önceliklidir vb.

Herhangi bir yöneticinin proje ile ilgili “karşı çıktığı” konular masaya yatırılmalıdır. Karşı çıkmasına rağmen dikkate alınmayan yönetici ayrı bir risk oluşturur.

Farklı yöneticilerin fikir ayrılıklarını ortak bir noktada buluşturabilecek çözümler düşünülmelidir. Herkesin kazanacağı bir çözüm alternatifi araştırılmalıdır. Herkesin kazanamayacağı durumlarda olumsuz etkilerin en aza indirilmesi hedeflenmelidir.

 

Önem Modeli ile Proje Paydaş Analizi

Projelerin başarılı tamamlanabilmesi için paydaş yönetimi çok önemlidir. Paydaş yönetimi küçük projelerde kolayken büyük projelerde hiç kolay olmayan bir konudur. Her paydaşa aynı şekilde yaklaşamazsınız. Projenin başarısı için kritik olan ve olmayan paydaşları belirlemeli, kritik olanlara yakın durmalısınız.

Paydaşları etkin bir şekilde yönetebilmek için sınıflandırmalı ve stratejiler üretmelisiniz.

PMBOK®’ta sınıflandırma için aşağıdaki modeller önerilir;

  1. Güç/İlgi
  2. Güç/Etki
  3. Etkilenme/Güç
  4. Önem Modeli (Stakeholder Salience Model)

İlk 3 model, paydaşların paydaşları güç, ilgi, etkilenme faktörleri açısından ikili olarak az-çok, zayıf-güçlü ekseninde değerlendirir. Belirteç modeli ise 3 özelliğe göre değerlendirir.

Paydaş belirtecinin anlamı, yöneticilerin, karar verme sürecinde hangi paydaşlara öncelik vereceklerinin derecesidir. 3 özellik dikkate alınır; Güç,  Meşruluk ve Aciliyet.

Güç

Proje veya çıktıları ile ilgili diğerlerine iş yaptırma veya diğerlerini etkileme gücü. Zorlayıcı, fayda göstererek veya ödüllendirme vb.

Meşruluk

Proje veya çıktıları ile ilgili meşruluğu ya da uygunluğu. İstekli ve projede yer alması gereken paydaşlara daha fazla ilgi gösterilmelidir.

Aciliyet

Acil ilgi gerektiren paydaş gereksinimleri. Bu paydaşların gereksinimleri zaman hassastır, hemen ele alınması gerekir.

Bu parametreler birlikte ele alındığında önceliklendirilmiş paydaş listesi ortaya çıkar. Yüksek puanlı paydaşlara öncelik verilerek zaman kananılır.

Paydaş belirteci sabit bir değer değildir, zaman geçtikçe değişir. Düzenli olarak gözden geçirilmesi gerekir.

Belirteç Modeli için Venn grafiği kullanılır. Her özellik bir daire ile gösterilir. Dairelerin kesişim noktası paydaşların ortak özelliklerini gösterir.

Belirteç grafiği çizmek için her paydaşı için aşağıdaki 8 kategoride sınıflandırmanız gerekir;

  1. Kritik
  2. Baskın
  3. Tehlikeli
  4. Bağımsız
  5. Gizlenen
  6. Keyfi
  7. Talepkar
  8. Paydaş Değil

Kritik

Çok güçlü, yüksek aciliyet ve yüksek meşruluk sahibi paydaşlar. Koşulsuz adı da verilir.

Baskın

Yüksek güç, yüksek meşruluk ancak düşük aciliyet. Aciliyet düşük olduğu için 2. Sıradadır.

Tehlikeli

Yüksek güç, yüksek aciliyet, düşük meşruiyet olması bu grubu tehlikeli yapar. Dikkatli yaklaşmak gerekir çünkü projede kriz yaratabilirler.

Bağımsız

Yüksek aciliyet, yüksek meşruiyet ama düşük güç. Güçleri az olduğundan yakından yönetmek gerekmeyebilir.

Gizlenen

Yüksek güç, düşük meşruiyet, düşük aciliyet sergileyen potansiyeli olan ama gizlenen paydaşlar. Güçleri olması sebebiyle yakın durulması gerekir.

Keyfi

Yüksek meşruiyet, düşük güç ve aciliyet. Gereksinimleri yerine getirilmeli ancak düşük güç ve aciliyet Proje Yöneticisine sorumluluk yükler. Düzenli iletişim kurarak raporlama almak gerekir.

Talepkar

Yüksek aciliyet, düşük meşruiyet ve güç. Gereksinimleri karşılanmadığında problem yaratabilirler. Sürekli ilgi isterler. Dikkatlice yönetilmeleri gerekir.

Paydaş Olmayanlar

Vakit harcamamanız gerekenler.

  • Kritik gruba öncelik vermelisiniz.
  • Baskın, Tehlikeli ve Bağımsız grup ikinci sıradadır. Her 2 özellikte yüksek değerdedirler.
  • Keyfi, Talepkar, Gizlenen son grupta ele alınmalıdır. Dikkatli izlenmelidirler çünkü belirteçler değişkenlik gösterir.