Kategori arşivi: Risk Yönetimi

PMBOK7’yi Beraber Okuyalım – 22 – Proje Yönetim İlkeleri – 11

10 – RİSK YANITLARININ OPTİMİZE EDİLMESİ

Projelerde, beklenen sonuçlar üzerindeki olumlu etkilerin en üst düzeye çıkarılması ve olumsuz etkilerin en aza indirilmesi için hem fırsatlar hem de tehditler açısından riskler sürekli  değerlendirilmelidir.

Temel Prensipler

  • Tekil ve genel riskler projeleri etkileyebilir.
  • Riskler, pozitif (fırsatlar) veya negatif (tehditler) olabilir.
  • Riskler proje boyunca sürekli olarak ele alınır.
  • Organizasyonun risk tutumu, iştahı ve eşiği, riskin nasıl ele alınacağını etkiler.
  • Risk yanıtları
    • Riskin önemine uygun,
    • Maliyet etkin,
    • Proje bağlamında gerçekçi,
    • İlgili paydaşlar tarafından kabul edilen
    • Sorumluluğu bir kişiye ait olmalıdır.

Risk ortaya çıktığında, bir veya daha fazla hedef üzerinde olumlu veya olumsuz bir etkisi olabilir. Olumsuz etkinin gerçekleşmesine sorun (problem) denir ve problem yönetimi ile ele alınmalıdır. Belirlenen riskler projede gerçekleşebilir veya gerçekleşmeyebilir. Proje ekipleri, yaşam döngüsü boyunca hem proje içinde hem de dışında bilinen ve ortaya çıkan riskleri belirlemeye ve değerlendirmeye çalışırlar. Her risk gerçekleşmeyebilir her ana yeni riskler ortaya çıkabilir.

Proje ekipleri, olumlu risklerin (fırsatları) etkilerini en üst düzeye çıkarmaya ve olumsuz risklerin (tehditler) etkilerini kaldırmaya veya azaltmaya çalışırlar. Tehditler gecikme, maliyet aşımı, teknik arıza, performans düşüşü veya itibar kaybı gibi sorunlara neden olabilirler. Fırsatlar, azaltılmış zaman ve maliyet, geliştirilmiş performans, artan pazar payı veya itibar gibi faydalara yol açabilirler.

Proje ekipleri genel proje riskini de izlerler. Genel proje riski, belirsizliğin bir bütün olarak proje üzerindeki etkisini ifade eder. Genel risk, tekil riskler de dahil olmak üzere tüm belirsizlik kaynaklarından kaynaklanabilir.  Paydaşların hem olumlu hem de olumsuz proje sonucu değişikliklerinden etkilenmelerine sebep olur. Genel proje risklerinin yönetilmesindeki amaç, proje riskinin etkisini kabul edilebilir bir aralıkta tutmaktır.  Yönetim stratejileri, tehdit faktörlerini azaltmayı, fırsatları teşvik etmeyi ve proje hedeflerine ulaşma olasılığını en üst düzeye çıkarmayı içerir.

Proje ekibi üyeleri, risk iştahlarını ve risk eşiklerini anlamak için ilgili paydaşlarla iletişim kurarlar. Risk iştahı, organizasyonun veya bireyin kabul etmeye istekli olduğu belirsizlik derecesini tanımlar. Risk eşiği, organizasyonun ve paydaşların risk iştahını yansıtan bir hedef doğrultusundaki kabul edilebilir değişkenliğin ölçüsüdür. Risk eşiği, risk iştahını yansıtır. Bu nedenle, maliyet hedefi etrafında ±%5’lik bir risk eşiği, ±%10’luk bir risk eşiğinden daha düşük bir risk iştahını yansıtır. Risk iştahı ve risk eşiği, proje ekibinin bir projedeki riski nasıl yönetceğini ve risklere nasıl yaklaşması gerektiğini belirler. 

Etkili ve uygun risk yanıtları, tekil ve genel proje tehditlerini azaltırken fırsatları artırabilir. Proje ekipleri, aşağıdaki özellikleri göz önünde bulundurarak potansiyel risk yanıtlarını tutarlı bir şekilde belirlemelidir:

  • Riskin önemine uygun ve zamanında,
  • Uygun maliyetli,
  • Proje bağlamında gerçekçi,
  • İlgili paydaşlar tarafından kabul edilen
  • Sorumluluğu bir kişiye ait.

Genel Proje Risklerine Karşı Stratejiler

Tehditlere Yönelik Stratejiler

Fırsatlara Yönelik Stratejiler

Riskler organizasyon, portföy, program, proje ve ürün içinde mevcut olabilir.

Proje, riskin faydaların gerçekleşmesini, değerin artmasını ve azalmasını sağlayabileceği bir programın bileşeni olabilir. Proje, riskin potansiyel olarak portföyün toplam değerini ve iş hedeflerinin gerçekleştirilmesini artırabileceği veya azaltabileceği portföyün bileşeni olabilir.

Tutarlı risk değerlendirmesi, planlama ve proaktif risk uygulaması uygulayan proje ekiplerinin maliyeti, risk gerçekleştiğinde sorunlara tepki veren (reaktif yaklaşım) organizasyonlardan daha az maliyetlidir.

Türkçe eğitimler

İngilizce eğitimler

 

Paylaşın:

PMBOK7’yi Beraber Okuyalım – 21 – Proje Yönetim İlkeleri – 10

9 – KARMAŞIKLIĞI YÖNETMEK

Projelerde risk yönetimi proje içi bir konu olarak düşünülürdü. Yeni standartta önce projenin belirsizliğinin daha sonra proje içi belirsizliklerin ele alınması gerektiğinin altı çiziliyor. 

Projeye yaklaşımın ve planların proje yaşam döngüsünde başarılı bir şekilde uygulanmasını sağlamak için proje ekibinin, proje karmaşıklığını sürekli olarak değerlendirmesi gerekir.

Temel Prensipler

  • Karmaşıklık, insan davranışının, sistem etkileşimlerinin, belirsizliğin ve muğlaklığın sonucudur.
  • Proje sırasında herhangi bir noktada karmaşıklık ortaya çıkabilir.
  • Değeri, kapsamı, iletişimi, paydaşları, riski ve teknolojik yeniliği etkileyen olaylar veya koşullar karmaşıklığı ortaya çıkarabilir.
  • Proje ekipleri, karmaşıklık unsurlarını belirlemek için tetikte olmalı, karmaşıklık miktarını veya etkisini azaltmak için çeşitli yöntemler kullanmalıdır.
  • Proje, birbiriyle etkileşime giren öğeler sistemidir. Karmaşıklık, insan ve sistem davranışının belirsizliğinden kaynaklanır. Etkileşimlerin doğası ve sayısı, projedeki karmaşıklık derecesini belirler.

Karmaşıklık, proje öğelerinden, aralarındaki etkileşimlerden, diğer sistemler ve proje ortamıyla olan etkileşimlerden ortaya çıkar. Karmaşıklık kontrol edilemese de proje ekipleri, karmaşıklığın sonucu olarak ortaya çıkan etkileri ele alabilirler.

Proje ekipleri, riskler, bağımlılıklar, durumlar veya ilişkiler gibi birçok etkileşimin sonucunda  ortaya çıkan karmaşıklığı öngöremeyebilirler. Birkaç neden tek bir karmaşık etki üretmek için birleşebilir, karmaşıklığın nedenini belirlemek zorlaşabilir.

Proje karmaşıklığı, proje ve proje sistemi içindeki unsurların bütünsel sonucu olarak ortaya çıkar. Örneğin, proje içindeki karmaşıklık, düzenleyici kurumlar, finans kurumları, tedarikçiler, vb. daha fazla sayıda veya çeşitlilikte paydaşla artabilir. Paydaşlar, projenin karmaşıklığı üzerinde önemli bir etkiye sahip olabilirler.

Yaygın karmaşıklık kaynaklarından bazıları şunlardır:

  • İnsan davranışı – İnsan davranışı, tavır, tutum ve deneyimlerinin etkileşimidir. Projenin amaç ve hedefleriyle çelişen kişisel gündemler, çıkarlar vb. karmaşıklığa katkıda bulunabilirler. Farklı lokasyonlardaki paydaşlar, farklı zaman dilimlerine sahip olabilir, farklı diller konuşabilir ve farklı kültürel normlara sahip olabilirler.
  • Sistem davranışı – Proje unsurları arasındaki karşılıklı bağımlılıkların sonucudur. Örneğin, farklı teknoloji sistemlerinin entegrasyonu, proje sonuçlarını ve başarısını etkileyebilecek sıkıntılara neden olabilir. Proje bileşenleri arasındaki etkileşimler, risklere yol açabilir, sorunlar yaratabilir, belirsiz ve orantısız neden-sonuç ilişkileri üretebilirler.
  • Belirsizlik ve muğlaklık. Muğlaklık, belirsiz olma, ne bekleyeceğini veya bir durumu nasıl kavrayacağını bilememe durumudur. Muğlaklık, birçok seçeneğe sahip olmaktan veya optimal seçimde netlik eksikliğinden kaynaklanabilir.  Ortaya çıkan sorunlar veya durumlar da muğlaklığa yol açabilir. 
Belirsizlik sorunlar, olaylar, izlenecek yollar veya çözümler konusunda anlayış ve farkındalık eksikliğidir. Alternatif eylemlerin, tepkilerin ve sonuçların olasılıklarıyla ilgilenir. Belirsizlik, bilinmeyen bilinmeyenleri ve siyah kuğuları içerir.
 Karmaşık bir çevrede, belirsizlik ve muğlaklık birleşerek nedensel ilişkilerin (olasılıkların ve etkilerin) tam olarak tanımlanamamasına yol açabilir. Bu tip durumlarda belirsizliği ve muğlaklığı, etkileşimlerin iyi tanımlanabileceği ve dolayısıyla etkin bir şekilde ele alınabileceği noktaya kadar azaltmak zorlaşabilir.
  • Teknolojik yenilik – Ürünlerde, hizmetlerde, çalışma şeklinde, süreçlerde, araçlarda, tekniklerde, prosedürlerde ve daha fazlasında aksamalara neden olabilir. Yeni teknoloji, bu teknolojinin nasıl kullanılacağının belirsizliği ile birlikte karmaşıklığa katkıda bulunur. İnovasyon, karmaşıklığın artmasına neden olma potansiyeline sahiptir.

Karmaşıklık sonradan ortaya çıkabilir ve projeyi herhangi bir alanda ve proje yaşam döngüsünün herhangi bir noktasında etkileyebilir. Proje ekipleri, karmaşıklık belirtilerini fark edebilmek için proje bileşenlerine ve projeye bir bütün olarak sürekli bakmalıdırlar.

Sistem düşüncesi, geçmiş proje çalışmalarından elde edilen deneyimler, deneyler ve sistem etkileşimiyle ilgili sürekli öğrenme vb. yaklaşımlar karmaşıklık olan bir ortamda yürütme becerisinin artmasını sağlar. Karmaşıklık belirtilerine karşı tetikte olmak, proje ekiplerinin yaklaşımlarını ve planlarını uyarlamalarına olanak tanır.

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Planlama Risklerini Öngörebilmek

Aşağıdaki sorular tahminler, varsayımlar, kapsam ve beklenmedik durumlara ilişkin planlama risklerini ele almakta yardımcı olabilir;

  • Geçmişte gerçekleştirilmiş bir projedeki benzer tahmin verileri (toplam süre, efor, maliyet  vb.) bu projede tahmin yapmak için uygun ve eksiksiz midir?
  • Proje için doğru tahminleme yöntemi belirlenmiş midir? Yukarıdan aşağıya? Aşağıdan Yukarıya? Benzer Tahminleme? Parametrik? PERT? Veya birden fazla mı?
    • Proje büyük, karmaşık ve riskli mi?
    • Stratejik önemi var mıdır?
    • Performans incelenecek midir? (Kurum içi veya müşteri)
    • Tahmin doğruluğunun kontrol edilmesine yardımcı olabilecek geçmiş performans verileri (belgelenmiş veya uzman görüşü) mevcut mudur?
    • Benzer tahminler dikkate alındı ise geçmiş proje verilerinin mevcut proje ile uyumuna nasıl karar verildi?
  • Proje planı riskleri dikkate almış mıdır? Gereksinimlerdeki eksikliğe bağlı riskler nelerdir? Uygulanabilir acil durum önlemleri var mıdır? Plana yerleştirilmiş midir?
  • Bütçe ve zaman çizelgesi bilinmeyen bilinmeyenleri dikkate alıyor ve yönetim rezervi içeriyor mu? Bilinmeyen bilinmeyenlerin önceki benzer projeler üzerindeki etkisi değerlendirilmiş ve gerçekçi bir rezerv belirlenmiş midir?
  • Proje Ekibi, proje başlangıcında ve planlamada proje kapsamını anlama konusunda kendisine ne kadar güveniyor?
  • Herhangi bir risk dikkate alındı mı? Örneğin; Başarı odaklı bir plana ulaşmak için bütçeyi ve süreyi ne kadar azaltabiliriz? Eğer azaltamıyorsak, riskler çok yüksek demektir.
  • Bu tür bir proje için tipik tasarım, analiz, geliştirme, test yinelemeleri vb. sayısı nedir? Proje karmaşıklığını gidermek için herhangi bir ilave yineleme gerekli mi? Etkili fırsatlar yaratmak için ek yinelemeler ekleyebilir miyiz?
  • Tüm kapsam ve gereksinimlerin objektif olarak doğrulanması için yapılması gerekenler planlara dahil edildi mi? Teslimatların tam olarak gerçekleştirilmesi ile ilgili hususlar konusunda tüm ekip hem fikir midir?
  • Açık uçlu gereksinimler var mıdır? Eğer varsa ekibi performans açısından güvenceye almak için ne yapılıyor?
  • Matris yapıda çalışan kurumlar için: Projede yer alan tüm departman yöneticileri proje planını onayladı mı? Hayırsa, katılımlarını sağlamak için ne yapmak gerekiyor?
  • Planda birden fazla kritik yol var mıdır? Varsa zaman risklerini önlemek için plan değiştirilebilir mi? Riskleri belirlemek için modelleme ve simülasyon analizi yapılabilir mi?
  • Proje ile ilgili hangi temel varsayımlar yapıldı? Projenin başarıyla tamamlanmasını etkileyebilir mi? Tüm paydaşların görüşleri alındı mı? Gelecekte yanlış anlaşılma olmaması için belgelendiler mi?
  • Tüm riske yanıt planları kapsama dahil edilmiş midir? Risk Olasılık ve Etki Matrisi yanıt planlarının etkisini yansıtacak şekilde güncellenmiş midir?
  • Proje aktivitelerinin tamamlanmasından sorumlu ekip üyeleri riskleri incelediler mi?
  • Bütün teslimatların, kabul edilebilirliğine dair açık ve net tanımlar var mıdır? Bunlar hem alıcı hem de satıcı tarafından kabul edilmiş midir?
  • Proje planı, yürütme risklerini içeriyor mudur? İçeriyorsa belgelenmiş ve tüm paydaşlarca kabul edilmiş midir? İçermiyorsa, proje planının uyum sağlayacak şekilde değiştirilmesine ilişkin prensipler belirlenmiş midir?
  • Acil durum planlarının uygulanmasını gerektirecek kadar yüksek (paydaş risk eşiğinin ötesinde) herhangi bir risk var mıdır? Örneğin, kritik veya riskli bir teslimat için yedek tedarikçi veya alternatif teknoloji var mıdır?
  • Genel bir proje takvimi tamponu (veya rezervi) oluşturulmuşsa, programa bağlı proje destek personeli için (örneğin, proje yöneticisi, idare, finans personeli, vb.)?

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Proje Yönetiminde Anlaşmalar (Agreements)

Anlaşmalar, projenin ilk amaçlarını tanımlayan herhangi bir doküman veya iletişim olarak tanımlanır. Sözleşme, mutabakat zaptı (MOU), anlaşma mektupları, sözlü anlaşmalar, eposta vb. şeklinde olabilir.

Proje Başlatma Belgesinin Geliştirilmesinin geliştirilmesi sürecinde projenin ilk amaçlarını belirlemek amacıyla kullanılır. Sözleşme, ortak niyet bildirgesi, hizmet seviyesi anlaşması, anlaşma mektubu, niyet mektubu, sözlü anlaşma, e-posta ya da başka yazılı anlaşmalar şeklinde olabilir. Genel olarak, harici bir müşteri için yapılan projelerde sözleşme kullanılır.

Proje İşlerinin İzlenmesi ve Kontrolü sürecinde işi yapan dış kaynaksa,  Proje Yöneticisi anlaşma doğrultusunda ilerlenmesini güvence altına almaya çalışır.

Proje ya da Faz Kapanışı sürecinde Tedarik Yönetimi Planında da yer alan ve anlaşma ile belirlenmiş resmi faz ya da proje kapanış kurallarını içerdiği için ihtiyaç duyulur. Büyük ve karmaşık projelerde birden fazla anlaşma olabilir.

Gereksinimlerin Toplanması sürecinde proje ve ürün gereksinimlerini içerdiği için kullanılır.

Zaman Çizelgesinin Geliştirilmesi sürecinde tedarikçilerin taahhüt ettikleri zaman çizelgelerine erişebilmek için gereklidir.

Bütçenin Belirlenmesi sürecinde anlaşmalar, satın alınmış veya alınacak ürünler, hizmetler veya sonuçlarla ilgili geçerli anlaşma bilgileri ve maliyetler için gereklidir.

Kalitenin Kontrolü sürecinde proje Belgeleri altında anlaşmalar girdi olarak kabul edilir. Aynı sürecin çıktısı olarak anlaşmaların güncellenebileceği belirtilmektedir.

Kaynakların Kontrolü sürecinde özellikle dış kaynaklara yönelik olarak yeni ve planlanmamış kaynak ihtiyaçlarının karşılanması veya mevcut kaynaklardan dolayı ortaya çıkabilecek problemlerde ne yapılacağına yönelik prosedürleri içerdiği için girdi olarak kullanılır.

Risklerin Tanımlanması sürecinde eğer dışarıdan kaynak tedariği söz konusuysa kilometre taşı tarihleri, sözleşme tipi, onay kriterleri, ödül ve cezaları içeren anlaşma içerikkeri girdi olarak kullanılır.

Proje tedarik yönetimi süreçleri, alıcı ile satıcı arasında hukuki belgeler olan sözleşmeler de dahil anlaşmaları kapsar Sözleşme, satıcıya, değeri olan bir şeyi (örneğin, belirlenmiş ürünleri, hizmetleri ya da sonuçları) temin etme, alıcıya da para ya da başka değerlerle ödeme yapma yükümlülüğü getiren, karşılıklı olarak bağlayıcı bir anlaşmadır. Anlaşma basit ya da karmaşık olabilir.

Tedarik sözleşmeleri, alıcının ve satıcının yerine getirmesi gereken şartları içerir. Tüm tedariklerin projeye özel ihtiyaçları karşılamasını ve aynı zamanda organizasyonun tedarik politikalarına uygun olmasını sağlamak, proje yönetim ekibinin sorumluluğundadır.

Uygulama alanına bağlı olarak sözleşme yerine, anlaşma, kontrat, mukavele, alt sözleşme ya da satın alma emri terimleri kullanılabilir.

Tüm proje belgeleri belli şekillerde gözden geçirme ve onaylara tabi olmakla birlikte, sözleşmeler veya anlaşmalar yasal olarak bağlayıcı olmalarından dolayı , genellikle daha kapsamlı onay süreçlerine tabidirler.

Tedariklerin yürütülmesi sürecinin çıktısı olarak Anlaşma  belgelerinin başlıca içeriği aşağıdaki gibidir;

  • Çalışma bildirimi ya da teslimatlar,
  • Zaman çizelgesi ve kilometre taşları,
  • Performans raporlama,
  • Fiyatlandırma ve Ödeme koşulları,
  • Tetkik, kalite ve onay kriterleri,
  • Garanti ve Ürün Desteği,
  • Cezalar ve Teşvikler,
  • Sigorta ve teminat mektupları ,
  • Alt yüklenici onayları ,
  • Genel kural ve koşullar,
  • Değişiklik taleplerinin nasıl ele alınacağı ve
  • Fesih ve alternatif ihtilaf çözümü mekanizmaları.

Tedariklerin Kontrolü sürecinde anlaşmalar, taraflar arasındaki şartlardır ve her bir tarafın görevleriyle ilgili şartları içerir. Anlaşmanın içerdiği değişiklik kontrolü hükümleri uyarınca, sözleşme kapanışından önceki herhangi bir tarihte karşılıklı rızayla değiştirilebilir. Bu değişiklikler genellikle yazılı hale getirilir.

Paydaşların Tanımlanması sürecinde anlaşmanın taraflarını ve ihtiyaç duyulabilecek ek paydaşları belirleyebilmek için anlaşmalara ihtiyaç duyulur.

Paydaş Katılımını Sağlama Planlama sürecinde, dış kaynakların ve satıcıların etkin katılımını sağlamak için yapılacak planlama için şirketin satın alma departmanı ile koordine bir şekilde çalışılması gerekir. Bu sağlamak için anlaşmalara ihtiyaç duyulur.

Türkçe eğitimler

İngilizce eğitimler

 

Paylaşın:

Proje Yönetiminde Tehditlere Yönelik Stratejiler (Strategies for threats)

Gerçekleşmesi durumunda proje hedeflerini olumsuz etkileyebilecek tehditler ya da risklere yönelik stratejilerdir. Uygun strateji, riskin gerçekleşme olasılığı ve etkisine uygun olarak seçilmelidir. Kaçınma ve azaltma stratejileri genellikle yüksek etkili kritik risklere; devir ve kabul etme ise daha az kritik ve düşük etkisi olan tehditlere uygun stratejilerdir.

Risk Yanıtlarının Planlanması sürecinde 5 strateji kullanılabilir;

  • Yukarıya Aktarma – Proje ekibinin veya sponsorun fark ettiği fırsat proje kapsamının dışındaysa veya önerilen yanıt stratejisi Proje Yöneticisinin yetki sınırını aşıyorsa tercih edilir. Yukarıya Aktarma, proje seviyesinde değil, program, portföy veya organizasyonun diğer yönetim seviyelerinde yönetilir. Proje Yöneticisi, tehdit ile ilgili kişi ya da grubu bilgilendirir, detayların iletişimini sağlar. Tehditler genellikle etkiledikleri yönetim seviyesine taşınırlar. Önemli olan yukarıya aktarılan tehditlerin ilgili kişi ya da grup tarafından kabul edilmesidir. Yukarıya aktarılan tehditler, risk kayıtlarına eklenir ancak proje ekibi tarafından takip edilmeyebilir.
  • Kaçınma – Proje ekibinin tehdidi ortadan kaldırmaya veya projeyi tehdidin etkisinden korumaya yönelik kullandığı stratejidir. Bu stratejide, proje yönetimi planı, tehdidi tamamen devre dışı bırakacak şekilde değiştirilir. Proje yöneticisi, proje hedeflerini riskin etkisinden yalıtma ya da hedefi değiştirme yollarını izleyebilir. Örneğin, zaman çizelgesinin uzatılması, stratejinin değiştirilmesi ya da kapsamın azaltılması En radikal kaçınma stratejisi, projeyi tamamen durdurmaktır. Projenin erken safhalarında ortaya çıkan bazı risklerden, gereksinimler netleştirilerek, bilgi edinilerek, iletişim iyileştirilerek ya da uzmanlık bilgisi ile kaçınılabilir.
  • Devir – Proje ekibinin tehdidin olumsuz etkisinin bir kısmını ya da tamamını, yanıtın sahipliğiyle birlikte üçüncü bir tarafa aktarmasıdır. Riski devretmek, riski ortadan kaldırmayıp, sadece riskin yönetilmesi sorumluluğunun başka bir tarafa devredilmesini sağlar. Devir, riskin sonraki bir projeye ya da başka bir kişiye bilgisi ya da onayı olamadan devrederek riski reddetme anlamına gelmez. Risk devri, çoğunlukla riski üstlenen tarafa bir bedel ödenmesini gerektirir. Örneğin sigorta, teminat mektupları, ve garantiler sayılabilir. Belirlenmiş riskler için yükümlülüğü devretmek amacıyla sözleşmeler veya anlaşmalar yapılabilir. Örneğin, alıcı, satıcının sahip olmadığı bazı yeteneklere sahipse, çalışmaların bir kısmını ve bunlara paralel riskleri sözleşmeyle yeniden alıcıya devretmek tedbirli bir davranış olabilir.
  • Azaltma – Proje ekibinin bir risk olasılığını veya etkisini azaltmaya yönelik tercih edebileceği stratejidir. Olumsuz bir risk olasılığını ve/veya etkisini azaltarak kabul edilebilir eşik sınırlarının içine çekmek anlamına gelir. Projede gerçekleşebilecek bir riskin olasılığını ve/ veya etkisini azaltmak için erken bir aşamada eylemde bulunmak, genellikle, risk gerçekleştikten sonra oluşan hasarı onarmaya çalışmaktan daha etkindir. Örneğin, daha az karmaşık süreçler benimsemek, daha çok test yapmak ya da iyi bir tedarikçi seçmek. Riski azaltma, bir prototipin geliştirilmesini gerektirebilir. Böylece, bir süreç ya da ürünün küçük ölçekli modelinden daha büyük ölçekli çalışmalara geçmenin riski azaltılabilir. Olasılığı azaltmanın mümkün olmadığı durumlarda etkiyi belirleyen bağlantılara odaklanılır. Örneğin, bir sistemi yedekli bir şekilde tasarlamak.
  • Kabul etme – Proje ekibinin riski kabullenip, risk meydana gelmedikçe herhangi bir eylemde bulunmamaya karar verdiği stratejidir.  Kabul etme stratejisi tercih edilmişse, proje ekibinin bu riskle başa çıkmak için proje yönetimi planını değiştirmemeye karar vermesi ya da başka bir uygun yanıt stratejisi belirleyememiş olduğu düşünülür. Bu strateji ya pasif ya da aktif olarak uygulanır. Pasif kabul, stratejiyi belgelemek dışında hiçbir eylem gerektirmez, böylece proje ekibi riskleri ortaya çıktıkça ele almak ve tehdidin önemli ölçüde değişmemesi için zaman zaman tehdidi gözden geçirmek zorunda kalır. En yaygın aktif kabul stratejisi, riskle başa çıkmaya yönelik zaman, para ya da kaynak tutarları içeren beklenmedik durum yedekleri oluşturmaktır.

Türkçe eğitimler

İngilizce eğitimler

 

Paylaşın:

Proje Yönetiminde Genel Proje Risklerine Karşı Stratejiler (Strategies For Overall Project Risk)

Genel Proje Risklerine Karşı Stratejiler, sadece bağımsız risklere değil projeyi genel olarak ilgilendiren risklere karşı uygulanır.

  • Kaçınma – Genel proje riski, ciddi anlamda negatif ve risk eşiklerinin dışındaysa uygulanmalıdır. Belirsizliğin negatif etkileri düşürülerek projenin kabul eşiklerine geri dönmesine çalışılır. Örneğin, yüksek riskli bileşenler proje kapsamından çıkarılabilir. Proje, risk eşiklerine geri çekilemiyorsa proje iptal edilebilir. Bu durum tüm projeyi tehdit eden durumun Kabul edilemez olduğunu gösterir.
  • Yaralanma – Genel proje riski, ciddi anlamda pozitif ve risk eşiklerinin dışındaysa uygulanmalıdır. Belirsizliğin pozitif etkilerinin tüm proje için elde edilmesine çalışılır. Örneğin tüm paydaşlara fayda sağlayacak bileşenlerin kapsama eklenmesi. Alternatif olarak paydaşların onayı ile risk eşikleri yenilenerek, fırsatların elde edilmesi sağlanabilir.
  • Transfer/Paylaşma – Genel proje riski yüksek fakat şirket yönetmekte zorlanıyorsa başka bir firma şirket nezdinde riski yönetebilir. Risk negatif ise yapılacak transfer karşılığı bir bedel ödenir. Risk pozitif ise faydalar paylaşılır. Ortaklıklar, dış kaynak tutmak örnek olarak verilebilir.
  • Azaltma/İyileştirme – Genel proje riskinin seviyesini değiştirilerek proje hedeflerini başarma olasılığını artırılmaya çalışılır. Genel proje riski negatifse Azaltma, pozitifse İyileştirme yapılır. Projeyi yeniden planlamak, kapsamı değiştirmek, proje önceliğini yeniden ele almak, kaynak dağılımlarını değiştirmek, teslimat sürelerini yeniden ayarlamak örnek olarak verilebilir.  
  • Kabullenme – Genel proje risklerine, kabul edilmiş risk eşiklerini geçene kadar müdahale edilmez. Aktif ya da pasif kabullenme olabilir. Aktif kabullenmede zaman, maliyet ve kaynaklar ile ilgili rezervler ayrılır. Pasif kabullenmede genel proje riski düzenli olarak gözden geçirilerek değişiklik olup olmadığı izlenir.

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Proje Risk Yönetiminde Fırsat Stratejileri (Strategies for opportunities)

Riske Yanıt Geliştirme sürecinde yer alan “Fırsat Stratejileri”, proje hedeflerini olumlu yönde etkileme potansiyeli olan risklere ilişkin kullanılır.

Beş adet stratejiden bahsedebiliriz; 

  • Yukarıya Aktarma – Proje ekibinin veya sponsorun fark ettiği fırsat proje kapsamının dışındaysa veya önerilen yanıt stratejisi Proje Yöneticisinin yetki sınırını aşıyorsa tercih edilir. Yukarıya Aktarma, proje seviyesinde değil, program, portföy veya organizasyonun diğer yönetim seviyelerinde yönetilir. Proje Yöneticisi, fırsat ile ilgili kişi ya da grubu bilgilendirir ve detayların iletişimini sağlar. Fırsatlar genellikle etkiledikleri yönetim seviyesine taşınırlar. Önemli olan yukarıya aktarılan fırsatların ilgili kişi ya da grup tarafından kabul edilmesidir. Yukarıya aktarılan fırsatlar, risk kayıtlarına eklenir ancak proje ekibi tarafından takip edilmeyebilir.
  • Yararlanma – Organizasyonun yüksek öncelikli olarak gördüğü ve gerçekleştirilmesinin %100 garanti altına alınmasının istendiği stratejilerdir.  Örneğin en yetenekli çalışanların süresinin kısaltılması istenen projeye aktarılması, maliyeti düşürmek için yeni teknoloji kullanılması vb.
  • Geliştirme – Bir fırsatın olasılığını ve/veya olumlu etkilerini arttırmak için kullanılır. Erken geliştirme aksiyonları, fırsat ortaya çıktıktan sonra iyileştirme çalışmaları yapmaktan daha etkilidir. Olumlu etkide bulunan bu risklerin başlıca sebeplerini belirlemek  ve odaklanmak gerçekleşme olasılığını artırır. Eğer olasılık artırılamıyorsa sonucun etkileri ve fayda artırılmaya çalışılır. Örneğin daha fazla kaynak ekleyerek süreyi kısaltmak vb.
  • Paylaşma – Fırsatın sahipliğinin bir kısmını ya da tamamını, fırsattan en iyi şekilde yararlanacak bir üçüncü tarafa devretmektir. Dikkat edilmesi gereken, fırsatı istenilen düzeyde sağlayacak doğru tarafın seçilmesidir. Yatırım riskinin yabancı ortakla paylaşılması vb. Risk paylaşımı, karşı tarafa belirli bir ödeme yapılmasını gerektirebilir. Örneğin sigorta şirketi vb.
  • Kabul etme – Bir fırsatı kabul etmek, ortaya çıkarsa bu fırsattan yararlanmaya istekli olmak, ama aktif olarak fırsatın peşinden koşmamak anlamına gelir. Düşük fırsat içeren durumlarda, daha maliyet etkin yöntemler olduğunda tercih edilir. Kabul etme aktif ya da pasif olabilir;
    • Aktif Kabullenme – Zaman, maliyet ve kaynaklar konusunda Beklenmedik Durum Yedekleri ayırılır.
    • Pasif Kabullenme – Düzenli gözden geçirmeler yapılarak fırsat izlenir.

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Proje Yönetiminde Belirsizlik Göstergeleri (Representations of uncertainty)

Risklerin genel proje hedefleri üzerindeki etkisi Niceliksel Risk Analizi yapılarak sayısal olarak analiz edilir. Niceliksel risk analizi sürecinde Belirsizlik Göstergeleri, “Olasılık Dağılımları” olarak ifade edilebilir.

Modelleme ve simülasyonda yaygın olarak kullanılan olasılık dağılımları, zaman çizelgesi aktivitelerinin süreleri ve proje bileşenlerinin maliyetleri gibi değerlerdeki belirsizliği temsil eder.

Bir testin, kontrolün sonucu ya da gerçekleşmesi mümkün bir senaryo gibi belirsiz olaylar için münferit dağılımları izlemek kullanılabilir.

Aşağıda yaygın olarak kullanılan dağılımlar (beta, üçgen (triangle), normal ve tekbiçimli (uniform)) için dört örnek görülebilir;

Bu dağılımlar, genellikle niceliksel risk analizinde geliştirilen verilerle uyumludur.

Tek biçimli dağılımlar ancak, tasarımın konsept aşamasının başlarında olduğu gibi, belirlenen üst ve alt sınırlar arasında olması diğer değerlere göre daha olası olan belli bir değerin yokluğunda kullanılabilir.

Uygun olasılık dağılımı seçimi planlanan aktiviteler için uygun olan değerlerin aralığına bağlıdır.

Bağımsız proje riskleri de olasılık dağılımları ile ele alınabilir.

Alternatif olarak riskler, zaman ve maliyet etkileri ortaya çıkabilecekse olasılıksal dallarda ele alınabilir. Dallara ayırma planlanan aktivitede riskin bağımsız ortaya çıkması durumunda kullanışlıdır. Örneğin ortak sebebe dayalı riskler veya riskler arasında mantıksal bir bağ var ise bu ilişki ve bağlantı olasılık dağılımı ile görülebilir. Dallar projedeki alternatif yolları da gösterecektir.

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Proje Yönetiminde Hatırlatma Listeleri (Prompt lists)

Hatırlatma Listeleri Risk Tanımlama sürecinde kullanılır. Özel proje risklerine yol açabilecek önceden belirlenmiş risk kategorileri listesidir. Genel proje riskinin kaynağı olarak görülebilir.

Hatırlatma listesi, proje ekibine risk tanımlama tekniklerini kullanırken fikir üretmede yardımcı olacak bir çerçeve olarak kullanılabilir.

Risk kırılım yapısının en düşük seviyesindeki risk kategorileri, projeye özel riskler için bir hatırlatma listesi olarak kullanılır.

Bazı ortak stratejik çerçeveler riskleri tanımlamak için yaygın olarak kullanılmaktadır;

  • PESTLE – Politik, ekonomik, sosyal, teknolojik, yasal, çevresel
  • TECOP – Teknik, çevresel, ticari, operasyonel, politik
  • VUCA – Volatilite, belirsizlik, karmaşıklık, belirsizlik

Aşağıdaki liste bir hatırlatma listesi olarak kullanılabilir. Bu liste sadece örnektir, şirket ve proje yöneticisi özelinde deneyimlerle geliştirilmesi gerekir;

Aşama ya da Aktivite Bazında;

  • Müşteri, diğer projeler vb. nin girdilerine bağımlı mıdır?
  • Daha önce benzeri bir konuda deneyiminiz var mı?
  • Gecikme veya bütçe aşımında ne yapacaksınız?
  • İstediğiniz bilgiler zamanında size iletilmezse ne yapacaksınız?
  • Beklenmedik Durum Planlarınız var mı?
  • Planlamayı bitirmeye yönelik bir tarih belirlenmiş midir?
  • Verilen süre ve bütçe yeterli mi?
  • Gereksinimleri ve kapsamınızı net olarak biliyor musunuz?
  • Kalite gereklilikleri belirli mi? Ulaşılabilir mi?
  • Şirket kültürü ve ortam proje için uygun mu?
  • Proje ile ilgili iletişimlerde sıkıntı yaşanabilir mi?
  • Karar alma süreci belli mi?
  • Proje ile ilgili rol ve sorumluluklar net olarak anlaşılmış mıdır?
  • Gerekli yetkilere sahip misiniz?
  • Proje için gerekli altyapı mevcut mudur?
  • Proje için gerekli olan kaynakların uygunluğu var mıdır?
  • Projeniz şirket içinde ihtiyacı olan önceliğe sahip midir?
  • Var olan kaynaklar gereken niteliklere sahip midir?
  • Uymanız gereken kalite standartları ve yasalar var mıdır?

Bu konuda internette bulduğum tek örnek aşağıdadır; https://ppl.app.uq.edu.au/sites/default/files/UQ%20Risk%20Prompt%20List%20-%20Form.pdf

Türkçe eğitimler

İngilizce eğitimler

Paylaşın:

Proje Yönetimi Bilgi Sistemleri -PYBS (Project Management Information System-PMIS)

Proje Yönetimi Bilgi Sistemleri (PYBS), proje yönetimi süreçlerinin çıktılarını toplamak, entegre etmek ve yaymak için kullanılan bilgi sistemi olarak tanımlanmaktadır.

Proje Yönetimi Bilgi Sistemleri (PYBS), proje verilerinin kayıt altına alındığı yerdir. Proje Entegrasyon Yönetiminde Proje Yöneticileri, proje hedeflerine ulaşmak ve proje faydalarını gerçekleştirebilmek için artan veri ve bilgi hacmini Proje Yönetimi Bilgi Sistemleri gibi otomasyon yoluyla çözebilirler.  

Proje Yönetimi Bilgi Sistemleri  Organizasyonel Çevre Faktörü olarak aşağıdaki süreçlerin girdisidir;

  • Aktivitelerin Tanımlanması,
  • Aktivitelerin Sıralanması,
  • Maliyet Yönetiminin Planlanması sürecinde maliyet yönetimine ilişkin alternatifler sağlama,
  • Kalite kontrol sürecinde süreç ve teslimatlara ilişkin hata ve sapmaların izlenmesi.

Proje İşlerinin Yönlendirilmesi ve Yönetilmesi sürecinde PYBS, yazılımlara (MS Project vb.), iş onay sistemlerine, konfigürasyon yönetim sistemlerine, bilgi toplama ve yayma sistemlerine, bilgi tabanlarına erişime olanak sağlaması açısından öneriliyor. Otomatik veri toplama ve kilit performans göstergeleri ile ilgili raporlamada systemin bir parçası olarak görülüyor.

Aktivitelerin sıralanması sürecinde zaman çizelgesi geliştirme yazılımlarının aktivitelerin planlama, organize etme ve sırlamada kullanılabileceği, mantıksal ilişkilerin, öteleme ve öne çekmelerin PYBS ile yapılabilir.

Zaman Çizelgesinin Geliştirilmesi sürecinde aktivite girdileri, ağ diyagramları, kaynaklar ve aktivite süreleri ile zaman çizelgesi oluşturulabilir.

Zaman Çizelgesinin Kontrolü sürecinde planlanan ve gerçekleşen süreler izlenebilir, sapmalar ve ilerleyiş zaman çizelgesi temel çizgisi doğrultusunda raporlanabilir, değişikliklerin zaman çizelgesine etkilerinin öngörülmesini sağlanabilir.

Maliyetlerin Tahmin Edilmesi sürecinde tablolar (Excel vb.), simülasyon yazılımları ve istatistiksel analiz araçları maliyet tahminlerine destek olabilir. Bu araçlar maliyet tahminlerini basitleştirip, alternatiflerin hızlı değerlendirilmesini sağlar.

Maliyetlerin Kontrol Edilmesi sürecinde Kazanılmış Değer Yönetimine ilişkin 3 parametre (Planlanan Değer, Kazanılmış Değer ve Gerçekleşen Harcama) izlenebilir, grafiksel eğilimlere ve farklı proje sonuçlarına ilişkin öngörülere erişilebilir.

Aktivite Kaynaklarının Tahmin Edilmesi sürecinde kaynak havuzlarının planlanlaması, organize edilmesi ve yönetilmesi, kaynak tahminlerinin yapılması için kullanılabilir. Kullanılan sistemlerin özelliğine göre kaynak optimizasyonu için kaynak kırılım yapıları, kaynak uygunluğu, kaynak oranları ve takvimler tanımlanabilir.

Proje Ekibinin Yönetilmesi sürecinde proje aktivitelerinde yer alan proje ekip üyelerinin koordinasyon ve yönetiminde kullanılabilir.

Kaynakların Kontrol Edilmesi sürecinde doğru kaynakların, doğru aktivitelerde, doğru yer ve zamanda dağılımını güvenceye almak için kullanılabilir.

İletişimlerin Yönetilmesi sürecinde paydaşların ihtiyaç duydukları bilgiye zamanında erişebilmeleri için kullanılır. Proje bilgileri aşağıdaki çeşitli yollarla yönetilip dağıtılabilir;

  • Elektronik Proje Yönetimi Araçları – Proje yönetimi yazılımları, toplantı ve sanal ofis destek yazılımları, web arayüzleri, proje portal ve göstergeleri, ekip çalışması araçları
  • Elektronik İletişim Yönetimi– E-posta, faks, sesli mesaj, telefon, video konferans
  • Sosyal Medya Yönetimi – Web siteleri, bloglar, forum siteleri

İletişimlerin İzlenmesi sürecinde iletişim yönetimi planı doğrultusunda iç ve dış paydaşların ihtiyaç duydukları bilgilerin toplanması, saklanması ve dağıtılması için kullanılabilir. Bu sistemlerde tutulan bilgilerin doğruluğu ve verimliliği izlenmeli ve değerlendirilmelidir.

Risk Yanıtlarının Uygulanması sürecinde zaman çizelgesi, kaynak ve maliyetlere yönelik yazılımlar riske yanıt planlarını ve ilgili aktiviteleri projeye entegre bir şekilde diğer aktivitelerle birlikte güvenceye almayı sağlar.

Türkçe eğitimler

İngilizce eğitimler

Paylaşın: