Kategori arşivi: Risk Yönetimi

Proje Yönetiminde Anlaşmalar (Agreements)

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

PMBOK® Guide 6’da, 12 sürecin girdisi olarak anlaşmaların altı çiziliyor. Sadece Tedariklerin Yürütülmesi sürecinin çıktısı olarak belirtiliyor.

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

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ütü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 onayiara 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.

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

 

 

Paylaşın:

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

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

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.

PMBOK® Guide 6’da, Risk Yanıtlarının Planlanması sürecinde yer alan teknik 5 stratejiden bahseder;

  • Yukarıya Aktarma – PMBOK® Guide 6’da yer alan yeni bir maddedir. 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.

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

 

Paylaşın:

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

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

PMBOK® Guide 6’da, Risk Yanıtlarının Planlanması sürecinin araç ve tekniklerine eklenen Genel Proje Risklerine Karşı Stratejiler, sadece bağımsız risklere değil projeyi genel olarak ilgilendiren risklere karşı yapılabilecekleri açıklamaktadı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.

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

 

Paylaşın:

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

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

PMBOK® Guide 6’da Riske Yanıt Geliştirme sürecinde yer alan “Fırsat Stratejileri” , proje hedeflerini olumlu yönde etkileme potansiyeli olan risklere ilişkin kullanılmak üzere önerilmektedir.

Beş adet stratejiden bahsedilmektedir; Yukarıya Aktarma, yararlanma, paylaşma, geliştirme ve kabul etme.

  • Yukarıya Aktarma –PMBOK® Guide 6’da yer alan yeni bir maddedir. 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.

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

Paylaşın:

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

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

Niceliksel Risk Analizi yapılarak risklerin genel proje hedefleri üzerindeki etkisi sayısal olarak analiz edilir. PMBOK® Guide 6’da Niceliksel Risk, analizi sürecinde Belirsizlik Göstergeleri bir teknik olarak önerilmektedir. Belirsizlik Göstergeleri “Olasılık Dağılımları” olarak ele alınır.

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.

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

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

 

Paylaşın:

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

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

Hatırlatma Listeleri PMBOK® Guide 6’daki yeni konulardan biridir.  Risk Tanımlama sürecinde kullanılması önerilmektedir.

Hatırlatma listesi, ö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. Ancak 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

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

Paylaşın:

Proje Yönetimi Bilgi Sistemleri -PYBS (Project management information system-PMIS)

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

PMBOK® Guide 6’da 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.

PMBOK® Guide 6’yı incelediğimizde proje verilerinin kayıt altına alındığı yer olarak gösterilmektedir. Proje Entegrasyon Yönetimi bölümünde Proje Yöneticilerinin proje hedeflerine ulaşmak ve proje faydalarını gerçekleştirebilmek için artan veri ve bilgi hacmini ancak Proje Yönetimi Bilgi Sistemleri gibi otomasyon yoluyla çözebilecekleri belirtilmektedir.  

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

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

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ılabileceği belirtliyor.

Zaman Çizelgesinin Geliştirlmesi sürecinde aktivite girdileri, ağ diyagramları, kaynajlar ve aktivite süreleri ile PYBBS’nin zaman çizelgsinin oluşturulabileceği belirtiliyor.

Zaman Çizelgesinin Kontrolü sürecinde PYBS ile planlanan ve gerçekleşen sürelerin izlenebileceği, sapmaların ve ilerleyişin zaman çizelgesi temel çizgisi doğrultusunda raporlanabileceği, değişikliklerin zaman çizelgesine etkilerinin öngörülmesini sağlayacağı söyleniyor.

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

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

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ılabileceği belirtiliyor. Kullanılan sistemlerin özelliğine kaynak optimizasyonu için kaynak kırılım yapılarının, kaynak uygunluğunun, kaynak oranlarının ve takvimlerinin tanımlanabileceği belirtiliyor.

Proje Ekibinin Yönetilmesi sürecinde proje aktivitelerinde yer alan proje ekip üyelerinin kooridnasyon ve yönetiminde kullanlabileceği belirtiliyor.

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

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

  • 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 bir takım standart araçların kullanılabileceği belirtiliyor. Bu sistemlerde tutlna bilgilerin doğruluğu ve verimliliğinin izlenmesinin ve değerlendirilmesinin altı çiziliyor.

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

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

Paylaşın:

Proje Yönetiminde Denetimler (Audits)

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

PMBOK® Guide 6’da Denetimler önemli bir yer tutar. PMP sınavına gireceklerin hangi süreçlerde neden önerildiğini ve önemini anlamaları gerekir. Tedarik Denetimleri sözleşmenin ve sözleşmeye ilişkin süreçlerin tamlık, netlik ve verimlilik açısından değerlendirilmesi, kalite denetimleri ise proje aktivitelerinin şirket ve proje politika, süreç ve prosedürlerine uygunluğunu denetlemek için genellikle Proje Ofisi tarafından yapılan yapılandırılmış bağımsız bir süreç olarak tanımlanır.

Proje başlangıcında süreç denetimleri, proje kapanışında proje sonu tetkikleri yapılır.

Entegre Değişiklik Kontrolünde konfigürasyon kalemlerinin doğrulanması için yapılır. Konfigürasyon doğrulama ve denetimleri proje konfigürasyon kalemlerinin bir bütün olarak doğru olduğunu denetlemek, değişikliklerin kayıt altına alınmasını, değerlendirilmesini, onaylanmasını, izlenmesini ve doğru uygulanmasını güvence altına almayı amaçlar. Böylelikle konfigürasyon dokümanında yer alan fonksiyonel gereksinimlerin gerçekleştirilmesi sağlanmaya çalışılır.

PMBOK® Guide 6’da Kalitenin Yönetilmesi sürecinde denetim, yapılandırılmış ve bağımsız bir süreç olarak proje aktivitelerinin şirket ve proje politika, süreç ve prosedürlere uygunluğunu denetlemek için önerilen bir yöntemdir. Kalite Tetkikleri genellikle proje dışından kişi(ler) veya şirketin iç kontrol departmanı, Proje Ofisi ya da dış kaynak tarafından gerçekleştirilir. Kalite denetimlerinin hedefleri aşağıdakilerdir;

  • İyi ve en iyi deneyimlerin uygunlandığını garantilemek,
  • Uygunsuzlukların, farkların ve eksikliklerin tanımlanması,
  • Şirket içi deneyimlerin benzer projelerde uygulanabilmesi için paylaşılmasını sağlamak,
  • Ekip verimliliğini artırıcı pozitif beslemeleri proaktif olarak gerçekleştirmek,
  • Denetim sonuçlarının Alınan Derslere kaydını sağlamak

Eksikliklerin giderilmesi kalite maliyetini düşürecek, proje ürününün sponsor ve müşteri tarafından onaylanma olasılığını artıracaktır.

Kalite Denetimleri planlı veya rastgele, iç ve dış denetçiler tarafından yapılabilir.

Kalite Denetimleri, Onaylanmış değişiklik taleplerinin (güncellemeler, düzeltici eylemler, kuruların giderilmesi ve önleyici eylemler) hayata geçirildiğini onaylar.

PMBOK® Guide 6’da Risklerin İzlenmesi Sürecinde Risk Denetimleri risk yönetimi sürecinin verimliliğini değerlendirmek için kullanılır.

Proje Yöneticisi Proje Risk Yönetimi Planında yer aldığı şekli ile belirli aralıklarla risk denetimleri yapmaktan sorumludur. Risk Denetimleri proje gözden geçirme toplantılarında yapılabilir ya da konya özel toplantı düzenlenebilir. Risk Denetimleri yapılmadan önce hedefleri ve format netleştirilmelidir.

Risk Denetimlerine ilişkin sonuçlar risk raporlarında yer almalıdır.

PMBOK® Guide 6’da Tedariklerin Kontrolü sürecinde tedarik sürecinin yapılandırılmış gözden geçirmesi için önerilen yöntemdir. Tedarik Denetimleri içeriği ve kuralları tedarik sözleşmesinde yer alır. Denetim sonuçları alıcı ve satıcı Proje Yöneticileri ile paylaşılarak projede gerekli ayarlamaların yapılması sağlanmaya çalışılır.

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

Paylaşın:

Projelerde Paydaş Riskleri ve Sosyal Ağ 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

Paydaşların davranışlarını doğru anlarsanız proje risklerini daha iyi yönetebilirsiniz. Risklerin büyük bir kısmı insan davranışlarından kaynaklandığı için çözüm sizin tutumunuzda yatar.

Paydaşlar, projeye farklı bakış açıları ile yaklaşırlar, fırsat ve tehditleri kendilerince yorumlarlar. Eğer üzerlerine düşen sorumluluklar konusunda taahhüt vermezlerse proje başarısı tehdit altındadır.

Paydaş kaynaklı risklerin olasılık ve etkilerini dikkate almak, belirsizliklerin nasıl yönetileceğine karar vermek önemlidir.

Paydaşlara yönelik iki tür riskten söz edilebilir; kişisel ve ilişkisel. Kişisel riskler paydaşın kişiliğine yönelik tutum ve davranışları, ilişkisel riskler projedeki rol ve sorumluluklarına ilişkin iletişimsel ve etkileşimsel risklerdir.

Paydaşların rol bazlı risklerini “Sosyal Ağ Analizi” ile ele alabiliriz.  Sosyal Ağ Analizinde paydaşları noktalar halinde gösterir, diğer paydaşlarla aralarındaki etkileşimi çizgi ile belirtiriz. Çizgi boyu ve adedi etkileşimin yakınlığını ve çokluğunu sembolize eder.

Herkes tek bir kişi ile etkileşimde ise o kişiye bağımlılık artar. Bağımlı olunan kişi diğerlerinin kısıtlarını önemsemeyebilir. Her onay ve karar vermede Sponsora gidilmesi vb.

Belirli konularda belirli kişilere bağlılık var ise denge vardır. İlgili konu ilgili ağda çözülebilir. Satınalma sorumlusu, Proje Yöneticisi vb.

Eğer paydaşlar arasında olması gereken etkileşim yoksa bağ kopmuş demektir. İletişim ve etkileşimin sağlanması başka ağ üzerinden yapılmaya çalışır. Bir problem olarak görülmeli ve ilgili bağ kurulmalıdır.

Kilit noktalardaki paydaşların iletişim ve etkileşim sorumluluğunu gerektiği gibi yerine getirip getirmediği denetlenmelidir.

Değişen durumlara göre hangi bağın nasıl değişmesi gerektiği belirlenmelidir.

Ağın işlevselliği ve performansı izlenmeli, gerektiğinde yeniden düzenlenmelidir.

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

Paylaşın:

Proje Risk Kategorileri ve Risk Kontrol Listesi

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

Projelerde riskler tanımlanmadan önce risk kategorilerinin netleştirilmesi ve doğrultuda ilerlenmesi gerekir. Bazı risk kategorileri aşağıdaki gibidir;

Teknik, kalite, performans riskleri – Yeni teknoloji, endüstri standartları, yüksek performans beklentisi vb.

Zaman Çizelgesi Riskleri – Süre, agresif bitiş tarihi, başarılması gereken kilometer taşları vb.

Proje Yönetimi Riskleri – Yetersiz ve uygun olmayan kaynaklar, metodoloji olmayışı, proje yöneticisinin yetersiz yetkisi vb.

Organizasyonel Riskler – Zayıf mali yapı, şirket içi bürokrasi, projelerin önceliklendirilmemesi vb.

Dış Riskler – Pazar değişiklikleri, yasal değişiklikler, müşteri, hava koşulları vb.

Her şirket geçmişte yaşadığı projelerden çıkardığı derslerden yola çıkarak Risk Kontrol Listesi hazırlamalıdır. Risk listeleri zamanla olası problemlerin erken fark edilmesini, ortadan kaldırılmasını veya olumsuz etkilerinin azaltılmasını sağlayacaktır. Örnek bir liste aşağıdadır;

Organizasyonel Riskler

  • Yönetim ve departmanların desteği istenilen düzeyde midir?
  • Benzeri bir proje daha önce yapılmış mıdır?
  • Proje Yönetimine yönelik bir metodoloji var mıdır?

Finansal Riskler

  • Yeterli bütçe ve mali kaynaklar var mıdır?
  • Ayırılan bütçe proje ile ilgili tüm gereksinimler düşünülerek hazırlanmış mıdır?
  • Finansal kısıtlamalar var mıdır?
  • Yapılan maliyet tahminleri gerçekçi midir?

Personel Riskleri

  • Yeterli personel var mıdır?
  • Mevcut personelin yetenekleri projenin gerektiridiği gibi midir?
  • Proje ekibindekiler daha önce birlikte çalışmışlar mıdır?
  • Proje ekibi projenin başarılı olacağına inanıyor mu*
  • Proje müşterisini temsil eden ekip üyesi gerekli yetkilere sahip mi?

Zaman Çizelgesi Riskleri

  • Zaman çizelgesi gerçekçi mi?
  • Zaman kısıtlarına uyum sağlayacak esneklik sağlanmış mıdır?
  • Proje teslim tarihi ne kadar kesindir?
  • Değişikliklere uyum sağlanabilecek midir?
  • Proje başarısı değerlendirme ölçütleri belirli midir?
  • Proje gereksinimleri proje ekibi ve paydaşlar tarafından anlaşılmış mıdır?
  • Kapsam zaman içinde değişebilir mi? Sabit mi?

Teknolojik Riskler

  • Kullanılacak teknoloji ile ilgili geçmiş deneyimler var mıdır?
  • Mevcut teknolojiyi kullanmak akıllıca mıdır? Mecburiyet midir?
  • Altyapı uygun mudur?
  • Spesifik teknolojik gereksinimler var mıdır?
  • Yeni bir teknoloji kullanılıyor mu?
  • Entegrasyon gerekliliği var mı?
  • Güvenlik ve gizlilik beklentileri yüksek mi?
  • Müşteri talep ettiği teknoloji konusunda deneyimli mi?
  • Projenin, diğer projelere, dış kaynaklara vb. bağımlılığı var mı?
  • Kullanılacak teknoloji özel bir bilgi, yetenek gerektiriyor mu?
  • Gerekli bilgi ve deneyim şirkette mevcut mu?

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

Paylaşın: