Kategori arşivi: Paydaş Yönetimi

Proje Yönetimi Tarihçesi: 1985 – 2013

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

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

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Proje Yönetimi Tarihçesi: 1960 – 1985

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

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 yönetimler 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ştirimeleri 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

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Kamu Projelerinde Dikkat Edilmesi Gerekenler

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

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

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

 

Paylaşın:

Proje Odaklı Firmalar Nasıl Pazarlama Yapmalı?

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Proje odaklı firmalarda yeni projelerin alınması gerekir. Ürün pazarlamak ile proje pazarlamak farklıdır. Geleneksel ürün satışından farklı pazarlama, teknik, operasyonel bilgi ve beceri gerekirken müşterinin katılımının sağlanması gerekir.

Yazılım firmalarının satış departmanları çoğu zaman olmadık vaatlerde bulunup, işi almayı yeterli görürler. İş alındıktan sonra problemler başlar. Dikkat edilmesi gerekenler;

Sistematik Çalışma – Alınacak projeye aktarılacak kaynaklar mevcut projelerlerden kaydırılacak ise hem satıcı firma hem de alıcı firma tarafında sistematik bir şekilde yapılmalıdır. Yeni projenin diğer projeler arasına veya sonrasına yerleştirilmesine ilişkin zaman planlamasına dikkat edilmelidir.

Özel Tasarım – Müşterinin ne istediğinin tam anlaşılması, müşteriye her şeyi yaparız gibi boş taahhütler verilmemesi, gereksinimlerin mevcut altyapı ve kaynaklar açısından değerlendirilmesinin yapılması gerekir. Müşteri memnuniyeti esas alınmalıdır.

Proje Yaşam Döngüsü – Projeye özgün yaşam döngüsü dikkate alınmalı, süreç iyice düşünülmelidir. Her müşterinin ve projenin farklı olduğu unutulmamalıdır.

Teslimatlar – Projelerde belirli noktalarda teslimatlar belirlenmeli, müşteri onayı alınarak ilerlenmelidir. Onay vb. konularda olası gecikmeler dikkate alınarak bekleme süreleri ve toleranslar projeye dahil edilmeli, sözleşmede bu hususlar yer almalıdır.

Riskler – Projeyi kapsam, zaman, maliyet ve kalitesini olumsuz etkileyebilecek riskler masaya yatırılmalı, sözleşmeye ilgili maddeler konulmalıdır. Ör. Değişiklik taleplerinin nasıl bir süreç izlenerek yönetileceği vb.

Ödeme planı – Projeden elde edilecek kar ve fayda tanımlanmalı, zaman çizelgesi üzerinde görülebilmelidir. Projenin ilerleyişi finansman açısından ele alınmalıdır. Projeden elde edilecek faydalar erken safhalarda belirlenmeli ve izlemelidir.

Sözleşme – Her iki tarafı da koruyan, projenin başarıyla tamamlanması için gereken tüm maddeleri içermelidir.

Büyüme potansiyeli – Projelerin gerçekleştirilmesi gelecek için fırsatlar yaratabilir. Ör. Müşterinin istediği ek bir modül ileri de ana yazılımın bir parçası olabilir.

Müşteri – Her müşteriye aynı yaklaşılamaz. Müşteri iyi analiz edilmeli, yaklaşım belirlenmelidir.

Proje Satıcıları kendilerini fonksiyonel yönetici gibi konumlandırmalıdırlar. Satışını yaptıkları proje ile ilgili tüm sektör bilgilerine, mevut kapasite ve teknik konulara hakim olmalıdırlar. Müşteriler için fırsatları tanımlayabilmeli, yaratılacak ek faydalar konusunda yol gösterici olmalıdırlar.

Pazarlama planlanmalı ve stratejik yaklaşılmalıdır. Aşağıdaki şekilde teklif kararlarının verilmesi, kaynak taahhütlerinin yapılması, teknik farkındalık ve müşteri ile etkin bağlantı kurulmasına ilişkin sistematik yaklaşım görülebilir;

projesatis

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Proje Yöneticisi ve Fonksiyonel Yöneticiler

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Proje Yöneticisinin, proje hedeflerini gerçekleştirmek üzere şirket kaynaklarını kontrol etmesi gerekir. Şirket kaynakları para, işgücü, ekipman, tesis, malzeme, teknoloji olarak sayılabilir.

Proje Yöneticileri bu kaynakları doğrudan kontrol edemezler. Kaynaklar Fonksiyonel Yöneticiler(Departman Yöneticileri) tarafından kontrol edilirler. Fonksiyonel Yöneticilere Kaynak Yöneticileri de diyebiliriz.

Proje Yöneticileri tüm ihtiyaç duydukları kaynaklar için Fonksiyon Yöneticileri ile görüşmeler yaparlar ve geçici olarak (proje süresince) kaynakların kontrolünü tamamen veya kısmen alırlar.

Eskiden projelere çok deneyimli ve bilgili Proje Yöneticileri seçilir, proje ile ilgili tüm sorumluluk verilirken, atanan kaynakların yönetiminden de tamamen sorumlu olurlardı. Artık uzmanlıklar o kadar gelişti ki projenin başarısı Proje Yöneticileri ile Fonksiyonel Yöneticilerin ortak sorumluluğu haline geldi. Bu durum Fonksiyonel Yöneticilerin proje yönetimini bilmeleri, öğrenmeleri gereğini doğurdu.

Proje Yöneticileri, proje ekibine teknik yön verme ve destekleme fonksiyonundan teslimatların başarıyla yönetilmesi ve sonuçlandırılması sorumluluğa geçti. Öte yandan Proje Yöneticileri sadece projeyi başarıyla tamamlamak değil doğru iş kararları vermek ve fonksiyonlar açısından projeyi ele almakla yükümlü hale geldiler.

Teknolojinin hızlı yükselişi proje yöneticilerinin daha fazla iş odaklı olmalarına gerektiriyor.

Dr. Hans Thamhain’e göre iş liderleri ve proje yöneticileri teknoloji odaklı ortamlara girdikçe;

  • Sıradan ve standart süreçlerden dinamik, değişken ve entegre süreçlere,
  • Verimliliği artıracak verimliliğe,
  • Şirket genelinde sahiplenilecek ve yürütülecek proje yönetimine,
  • Yönetim kontrolünden kendini kontrole ve yetki-sorumluluk vermeye,
  • Her konuda teknolojiye geçiş ve adapte olmak zorundalar.

Proje Yöneticilerinin iş konusunda daha aktif olmalarını Gary Heerkens şöyle açıklıyor;

  • Eğer yanlış proje üzerinde çalışıyorsanız nasıl başarılı yürüttüğünüz önemli değildir.
  • Bütçe aşımının ve gecikmelerin arkasında akıllı bir iş kararı varsa iyidir.
  • İş bakış açısıyla, proje ekibini gerçekçi olmayan bir bitiş tarihine her zaman iyi değildir.
  • Portföydeki tüm projelerin pozitif nakit akışına sahip olması şirket için iyi bir yatırım olmayabilir.

Başarılı proje yönetimi için;

Projeye kaynak atayan Fonksiyonel Yöneticiler ile Proje Yöneticisi arasında iyi bir iş ilişkisi, fonksiyonel birimlerden gelen ekip üyelerinin hem kendi yöneticilerine hem proje yöneticisine raporlayabilme becerilerinin olması önemlidir. Çünkü ekip üyeleri kendi yöneticilerine dönük çalışacaklar ve aldıkları talimatlar doğrultusunda çalışacaklardır.

Yönetimler, Proje Yöneticilerinin kendilerine çalıştıklarını düşünselerde aslında proje yöneticileri fonksiyonel yöneticilere çalışırlar. Proje sonunda belirlenen ödüllendirmelerin sadece Proje Yöneticisine yapılması tepkiler çeker. Ödülün paylaştırılması gerekir.

Proje Yöneticileri ile Fonksiyonel Yöneticiler arasındaki anlaşmazlıklar projeleri başarısızlığa sürükler. Üst yönetimin iki taraf arasındaki iyi ilişkiler konusunda çaba sarf etmesi gerekir.

Proje Yöneticilerinin şirketin her departmanını, organizasyonel işleyiş ve davranışlar açısından, kendi yetik ve sorumluluklarının nerede başlayıp bittiğini çok iyi bilmeleri gerekir. Fonksiyonel ve Proje Yöneticileri arasında kavram, rol ve sorumluluk karmaşası olmamalıdır.

Yayınlanan yazıların e-postanıza gelmesini istiyorsanız aşağıdaki formu doldurunuz;

Paylaşın:

Proje Yönetimi ve 360° Geri Bildirim

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

360° Geri Bildirim (360° Feedback), takım üyelerinin, proje sponsorlarının ve diğer paydaşların anonim olarak tarandığı ve proje yönetiminin performansı hakkında görüşlerinin alındığı geri bildirim türüdür. Yeterliliklerdeki boşlukları tespit etmek, gelişim veya eğitim planı oluşturmak için dayanak olarak kullanılır.

Basitçe söylemek gerekirse 360° Geri Bildirim bir çalışanın yöneticisini, yöneticisinin çalışanını değerlendirmesidir. Proje Yönetiminde birbirini değerlendirecek tarafları şöyle sıralayabiliriz;

  • Proje Müşterisi
  • Sponsor
  • Proje Yöneticisi
  • Proje Ekibi
  • Fonksiyonel Departmanlar
  • Dış Kaynaklar

Bu değerlendirmede aşağıda yer alan konular sorgulanabilir;

  • Proje Yöneticisi, projenin paydaşlara olan etkisini yeterince anlamış mıdır?
  • Proje ekip üyesi rol ve sorumluluklarını etkin bir şekilde yerine getirmekte midir?
  • Proje Yöneticisi, Proje Ekibine destek olmakta mıdır?
  • Proje Sponsoru gerekli kaynakları sağlamakta mıdır?
  • Dış Kaynak raporlamalarını düzenli yapmakta mıdır?
  • Ekip üyeleri kendi aralarında etkin iletişim kurmakta mıdır?
  • Fonksiyonel Yönetici doğru kaynağı, doğru zamanda atamakta mıdır?

Proje ekipleri yöneticileri için bu yöntemin bazı artı ve eksi tarafları vardır. Bazı ekip üyeleri başarılarının ve gayretlerinin tek bir kişi tarafından değerlendirilmesini istemezler. Tüm ekip üyelerinin gözlemlerinin ve düşüncelerinin dikkate alınmasını tercih ederler. Belirli kişilerle yaşadığı olumsuz durumların tüm performanslarına yansıtılmasını doğru bulmazlar. Böyle değerlendirmelerde “kişisel” görüşlerin “profesyonel” görüşlerin önüne geçmesine izin verilmemelidir.

Yapılacak değerlendirme herkese aynı formatta yapılmalı, haksızlıklara ya da yanlış anlaşılmalara imkan vermemelidir. Değerlendirmede yer almayan konular ilgili taraflarca yazılı halde ayrıca toplanmalıdır.

Değerlendirmenin amacı birini iyi ya da kötü göstermek değil gelişim, eğitim vb. konularda yol gösterici olması olmalıdır.

Yapılan değerlendirmeler bir kenara bırakılmamalı, değerlendirmenin sonucunda gerekli aksiyonlar alınmalı ve raporlanmalıdır.

Değerlendirme esnasında tarafların soruları dinlenmeli ve dürüstlükle yanıtlanmalıdır.

Değerlendirmeya tabi olan konular ilgili paydaşlarla değerlendirme öncesi paylaşılmalı, değerlendirme kriterleri ve başarı ölçütlerinin iyi anlaşıldığından emin olunmalıdır.

Değerlendirmenin negative olması durumunda paydaşın yanlış anlayabileceği, performansının düşebileceği olasılığı göz ardı edilmemelidir. Bu değerlendirmelerin cezalandırma değil değerlendirme amaçlı olduğu açıklanmalıdır.

Değerlendirme sonuçları bağımsız denetleyiciler tarafından gözden geçirilmeli (hepsi çok iyi ya da kötü işaretlenmiş olabilir vb.) herhangi bir uygunsuzluk durumunda değerlendirmenin tekrarlanması istenmelidir.

Örnek Rapor

Paylaşın:

Proje Paydaşları Nasıl Tanımlanır?

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Proje Yönetiminin ana amacı paydaş gereksinimlerinin karşılanmasıdır. Bu sebeple paydaş tanımlama süreci büyük öneme sahiptir.

Paydaş, projeye aktif olarak dahil olan ya da projenin gerçekleştirilmesi ya da tamamlanması ile çıkarları olumlu ya da olumsuz yönde etkilenebilecek kişi veya organizasyonlardır. (örneğin müşteri, sponsor, çalışan organizasyon ya da kamu).

Projenin başarıyla tamamlanabilmesi tüm proje paydaşlarının gereksinimlerinin gerçekleştirilmesiyle olur.

Proje paydaşlarının proje başlatma belgesi yayınlanır yayınlanmaz belirlenmesi ve tüm proje yaşam döngüsü boyunca yönetilmeleri gerekir.

Proje Başlatma Belgesi, projenin başlatıcısı ya da sponsoru tarafından yayımlanan, projenin varlığını resmi olarak onayiayan ve proje yöneticisine organizasyonun kaynaklarını proje aktivitelerine tahsis etme yetkisi veren bir belgedir. Bu belgede üst düzey proje hedefleri, bütçe, zaman çizelgesi, varsayımlar ve kısıtlar, sponsorun, proje yöneticisinin adı ve ilgili paydaşların adları vb. bilgiler yer alır.

Proje bir sözleşme ile başlamışsa, sözleşmede ilgili paydaşlar (tedarikçiler vb.) yer alıyor olabilir.

Organizasyonel yapıyı inceleyerek projeden etkilenecek ya da etkileyecek paydaşları görebilirsiniz.

Geçmiş projelere ilişkin kayıtlar, alınan derslere ilişkin belgelerden paydaşlar belirlenebilir.

Benzer proje deneyimine sahip uzman kişilere danışılabilir.

Projeyi ilgilendiren yasa, kural vb. incelenerek ilgili paydaşlar belirlenebilir.

Çeşitli uzman ve departmanlarla beyin fırtınası yapılarak paydaşlar belirlenebilir. Sorulması gereken sorular aşağıdaki gibidir;

  • Projeye doğrudan katılması gerekenler kimlerdir?
  • Projeden kim(ler) etkilenecek?
  • Projenin çıktılarından kim(ler) etkilenecek?
  • Projenin başarıyla tamamlanması durumunda kim kazanacak kim kaybedecek?
  • Projenin başarıyla tamamlanmasını isteyecekler, istemeyecek olanlar?
  • Tedarikçiler kimlerdir?
  • Rakiplerimiz kimlerdir?
  • Hissedarlarımız kimlerdir?
  • Projeyi veya çıktısını etkileyecek yasal bir otorite veya organizasyon var mıdır?
  • Proje başarısında yetkisi olanlar kimlerdir?
  • Kimler projeyi başarısızlığa uğratabilir?

Paydaş tanımlama proje süresince devam eden bir süreçtir. Proje boyunca proje paydaşları izlenmelidir. Bazen yeni proje paydaşları ortaya çıkabileceği gibi mevcut bir paydaşın projeyle ilgisi kalmayabilir. Paydaşların projeye ilgisi veya proje fazlarındaki güçleri zaman içerisinde değişiklik gösterecektir.

Tüm paydaşlar, Paydaş Listesinde yazılı halde tutulmalıdır. Paydaş Listesinde paydaşın ad ve soyadı, iletişim bilgileri, güç, etkilenme, beklenti, gereksinimleri yer almalıdır.

Paylaşın:

Belirteç Modeli ile Proje Paydaş Analizi

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

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. Belirteç 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. 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.

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Paylaşın:

ISO 21500 ve PMI Standartları – 5 – Paydaşlar ve Kapsam

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Paydaşlar

Projeyi olumlu veya olumsuz etkileyebilecek ve/veya projeden etkilenebilecek tarafların belirlenmesine, etkilerinin analizine ve beklentilerinin yönetilmesine Proje Paydaş Yönetimi adı verilir.  

 

ISO 21500 PMBOK®
4.3.9 Paydaşları Tanımlama 13.1 Paydaşların Tanımlanma
  13.2 Paydaş Yönetiminin Planlanması
4.3.10 Paydaşların Yönetilmesi 13.3 Paydaş Katılımının Yönetilmesi
  13.4 Paydaş Katılımının Kontrolü

ZatenPMBOK® 5 ile gelen yeni iki konu dışında bir fark bulunmamaktadır: Paydaş Yönetiminin Planlanması ve Paydaş Katılımının Kontrolü  

Kapsam

ISO 21500 PMBOK®
  5.1 Kapsam Yönetiminin Planlanması
  5.2 Gereksinimlerin Toplanması
4.3.1 Kapsamın Tanımlanması 5.3 Kapsamın Tanımlanması
4.3.12 İş Kırılım Yapısının Oluşturulması 5.4 İş Kırılım Yapısının Oluşturulması
4.3.13 Aktivitelerin Tanımlanması 6.2 Aktivitelerin Tanımlanması*
  5.5 Kapsamın Onaylanması
4.3.14 Kapsamın Kontrolü 5.6 Kapsamın Kontrolü
* Zaman Yönetimi bölümünden alınmıştır.  

ISO 21500’de Gereksinimlerin Toplanması ayrı bir süreç olarak ele alınmamış Kapsamın Tanımlanması içersinde düşünülmüştür. Kapsamın Onaylanmasına yönelik bir süreç bulunmamaktadır. Kapsamın Onaylanması “Onaylanmış Teslimatların” çıkması anlamına gelir ve çok önemlidir. ISO 21500’de hiç bir sürecin çıktısı olarak Onaylanmış Teslimatların yer almaması şaşırtıcıdır.

Aktivitelerin tanımlanmasıPMBOK®’da Proje Zaman Yönetimi altında yer alırken ISO 21500 Proje Kapsam Yönetimi altında ele almaktadır.

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Ad Soyad*
E-posta:*
Teslimat Adresi *
Telefon*
-
Miktar*
İşlemin sonucunu yazınız

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın:

Proje Müşterisi Ne Bekler?

Hayatımız Proje - Proje Yöneticisinin El Kitabını (Gökrem Tekir - Savaş Şakar) KREDİ KARTI ile almak için tıklayınız

Projeyi isteyen kurum içi ya da dışı müşterilerin beklentilerinin yönetilmesi çok önemlidir. Proje Yöneticilerinin aşağıdaki en temel müşteri beklentilerini karşılamaları gerekir;

Sık İletişim – Proje Yöneticileri projenin gidişatı konusunda müşterilerini bilgilendirmelidirler. Müşteriler ne olup bittiğini, projenin ilerleyişini bilmek isterler. Özellikle dış müşteriye iş yapıldığında proje yöneticisinin ne yapıldığını aktarmaması iş yapılmadığı ya da yeterince çalışılmadığı düşüncesine yol açabilir. Düzenli raporlama ya da toplantılar bu ihtiyacı giderecektir.

Uygunluk – Proje müşterisi istediğinde Proje Yöneticisine ulaşabilmek ister. İletişim bilgilerinin projenin başında paylaşılması gerekir.

İyi Raporlama – Net, güncel ve bilgilendirici bir raporlama yapılması gerekir. Müşterinin hangi bilgileri istediği projenin başında belirlenmelidir. Her müşteriye gönderilen standart bir rapor müşterinin beklentilerini karşılamayabilir. Rapor müşterinin yanlış anlamasına yol açmamalıdır. Raporlar kapsam ve zaman konusunda ilerleyişi, olmulu ve olumsuz durumları açıkça göstermelidir.  Proje Yöneticisi bir süre gönderdiği raporun iş görüp görmediğini, beklentileri karşılayıp karşılamadığını sorgulamalıdır.

Zamanında bilgilendirilme – Proje müşterilerinin onay vb. yapmaları gereken işler olduğundsa zamanında bilgilendirilmeleri önemlidir.

Uyum – Proje müşterileri, projeyi gerçekleştiren ekip ile kendi ekipleri arasında uyumlu bir çalışma gerçekleştirilmesini beklerler. Olası çatışma ve anlaşmazlıkların zamanında far kedilip çözümlenmesi Proje Yöneticisinin sorumluluğundadır. Proje ekibinin davranış şekli ve yaklaşımı proje müşterisinin beklentileri doğrultusunda olmalıdır.

Fırsatlar ve Öneriler – Proje müşterileri kendi göremedikleri fırsatların önerilmesini beklerler.

>—————————————————————————————-<

Hayatımız Proje – Proje Yöneticisinin El Kitabı

Gökrem Tekir – Savaş Şakar
 65 TL (Yurtiçi gönderimlerde kargo dahil)

Sipariş formu

Diğer sipariş yöntemleri: LinkedinFacebook veya Twitter hesabımdan mesaj gönderebilir savassakar@gmail.com adresine eposta atabilirsiniz. Göndereceğiniz mesajlarda; Adınız – Soyadınız, Telefon numaranız, Teslimat Adresi ve kaç adet kitap istediğinizi belirtmeniz yeterli olacaktır. 

Uyarı: Yayınevlerinde ya da kitapevlerinde yoktur.

Paylaşın: