Kategori arşivi: Proje Kapanışı

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 İptal Edilirse Ne 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

Her proje planlandığı gibi gitmez. Beklenen faydaların sağlanamayacağının anlaşılması vb. durumlarda iptal edilebilirler. İyi Proje Yönetiminin kaynağı deneyimlerdir. İptal edilen projeler, sonraki projeler için önemli deneyim kaynaklarıdır.

İptal edilene kadar ki dönemde gerçekleştirilenleri, başarılanları yazılı hale getirin.

İptal durumunda bile Proje Kapanış raporunuzu hazırlayın.

İptalin sebeplerini mümkünse sayısal verilerle yazılı hale getirin.

Proje sürecince çıkardığınız dersleri paylaşın. Gelecekteki projelerde dikkat edilmesi gereken hususları belirtin.

Proje ile ilgili tüm belgeleri arşivleyin.

Çözülmemiş problem kalmamasına dikkat edin. Son bir toplantı ile açık kalmış konuları değerlendirin ve tamamlama konusunda planınız yapın, sorumlulukları belirleyin.

Proje ekip üyeleri ile birebir görüşmeler yaparak teşekkür edin. Proje süresince gösterdikleri çaba ve başarıları yazılı hale getirin, yöneticileri ile paylaşın.

Proje ekibi ve diğer paydaşların gelecekteki projelerde dikkat edilmesi gerekenler konusunda görüşlerini alın.

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

Paylaşın:

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

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

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

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

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

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

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

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

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

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

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

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

Paylaşın:

PMBOK® Guide 6 Süreç Haritası

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 6’da nelerin değiştiğini aşağıdaki tablodan görebilirsiniz. Kırmızı olan kelimeler yenileri ifade etmektedir. Kılavuzun türkçesi hazır olmadığı için ingilizce olarak paylaşmak istedim.

pmbok6-surec-haritasi

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

Paylaşın:

Proje Yönetiminde Varyans 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

PMBOK® Guide 6’da Varyans (Variance), bilinen bir temel çizgi veya beklenen değerden sayısal sapma, ayrılma veya uzaklaşma, Varyans Analizi (Variance Analysis) ise temel çizgi ve mevcut performans arasındaki farklılık derecesi ve nedenini belirleme tekniği olarak tanımlanmaktadır.

PMBOK® Guide 6’da aşağıdaki süreçlerde Rezerv Analizi yapılabileceği belirtilmektedir. PMP sınavına hazırlananlar için önemli bir konudur.

Proje İşlerinin İzlenmesi ve Kontrolü, Faz ya da Proje Kapanışı süreçlerinde Veri Toplama Tekniği olarak önerilmektedir.

Planlanan ve gerçekleşen performansın gözden geçirilmesinde kullanılır. Bu açıdan bakıldığında süre ve maliyet tahminleri, kaynak dağılımı ve oranları, teknik performans gibi örnekler verilebilir.

Varyans Analizinin Proje Yönetiminin her bilgi alanında ilgili değişkenler üzerinden yapılabileceği belirtilmektedir. Örneğin proje işlerinin izlenmesi ve kontrolü sürecinde maliyet, zaman, kaynak ve teknik değişkenlerinin entegre bir şekilde tüm proje üzerinden varyansları izlenebilmektedir. Bu sayede önleyici ve düzeltici eylemler planlanıp, uygulanabilmektedir.  

Kapsamın Kontrolü sürecinde planlanan kapsam ile gerçekleşen kapsam arasındaki farka bakılarak önleyici ya da düzeltici eyleme gerek olup olmadığı belirlenir.

Zaman Çizelgesinin Kontrolü sürecinde planlanan ve gerçekleşen başlangıç ve bitiş tarihlerini, süreleri ve bollukları Varyans Analizi ile değerlendirebiliriz. Temel çizgiye göre sapmaların nedeni ve büyüklüğü gelecekteki işlerin tamamalanabilmesi, önleyici-düzeltici eylemlerin ne olması gerektiği gibi konular açısından önemlidir. Örneğin kritik yolda olmayan bir aktivitenin sapması proje süresini etkilemeyebilir.

Varyans analizi sonucunda değişiklik talepleri oluşabileceği unutulmamalıdır.

Maliyetlerin Kontrolü sürecinde uzman görüşü ve Kazanılmış Değer analizinde kullanılır. Aktivitelerin planlanan maliyeti ile gerçekleşen maliyeti karşılaştırılır. Sapmanın nedenleri ve büyüklüğü değerlendirilir.  

Varyans analizinin yapıldığı projeler için;

  • Satınalma Fiyatı Varyansı – Ürüne yapılan ödeme ile ürün fiyatı arasındaki fark
  • Çalışan Oranı Varyansı – Planlanan efor maliyeti ile gerçekleşen efor maliyeti arasındaki fark
  • Genel Gider Varyansı – Planlanan ve gerçekleşen genel giderler arasındaki fark
  • Sabit Maliyet Varyansı – Planlanan ve gerçekleşen sabit maliyetler arasındaki fark
  • Malzeme Miktarı Varyansı – Planlana ve Gerçekleşen Malzeme miktarı arasındaki fark.
  • Personel Verimlilik Varyansı – Standart performans ölçütlerine göre gerçekleşenlerin karşılaştırılması örnek olarak verilebilir.

Varyans Analizinin etkin yapılabilmesi eğilimlerin incelenmesi ile mümkündür. Sapma bir eğilim gösteriyorsa (artma ya da azalma) gerekli önlemler alınması kolaylaşacaktır. Tekil ya da sürpriz sapmalar ayrıca ele alınmalıdır.

Varyans analizinde sapmayı doğru belirlemek için karşılaştırılan değişkenlerin aynı parametreyi (gün, saat vb.) ve zaman dilimini (Ocak, Şubat vb.) içermesine dikkat edilmelidir.

Proje Yönetimi Ekibi kapsam, zaman ve maliyet sapmalarına odaklanmalı, sapmanın sebepleri farklı ise ayrı ayrı, ortak ise bir bütün olarak üzerine gitmelidirler.

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

Paylaşın:

Hayatımız Proje – Proje Yöneticisinin El Kitabı PDU Kazandırıyor

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

Hayatımız Proje Proje Yöneticisinin El Kitabını satın alıp okuyanlar 9 PDU kazanabilecekler.

PDU bilgisinin PMI sitesine kaydı ile ilgili aşağıdaki bilgileri dikkatlice okuyunuz;

Kitabımızla ilgili pdu girişi için aşağıdaki adımları izleyiniz;

PDU girişi içinhttps://ccrs.pmi.org/claim/new/Read sayfasına PMI üyelik bilgileriniz ile giriş yapınız.

  • Author (Yazar) bölümüne Gökrem Tekir – Savaş Şakar yazınız.
  • Title (Başlık Bölümüne Hayatımız Proje – Proje Yöneticisinin El Kitabı yazınız.
  • Description (Açıklama) ve URL bölümleri opsiyoneldir, boş bırakabilirsiniz.

  • Date Started (Okumaya Başladığınız Tarihi) ve Date Completed (Okumayı tamamladığınız tarihi giriniz.)
  • Kitabı okumaya ayırdığınız her saat için 1 PDU yazabilirsiniz. Örneğin kitabı okumaya 8 saat ayırdıysanız;
    • Technical (Teknik) – 7 PDU
    • Leadership (Liderlik) – 1 PDU
    • Strategic and Business (Strateji ve İş) – 1  PDU

Son olarak “I agree this claim is accurate” (Beyanım doğrudur) seçeneğini işaretleyiniz.

Kitabı Okurken Dikkat Edilmesi Gerekenler

  • Ne zaman okumaya başladığınızı ve bitirdiğinizi not alın.
  • Tüm kitabı okumadıysanız okuduğunuz sayfaları not alın.
  • Hangi içerikten, ne öğrendiğinizi not alın.
  • Kitapta yer alan içerikten hemfikir olduklarınızı belirleyin.
  • Kitapta yer alan içerikten karşı olduklarınızı belirleyin.
  • Kitapta yer alan içerikleri doğrulamak için başvurduğunuz kaynakları not alın.

Uyarı: Eğer PMI’ın denetlemesine tabi olursanız yukarıda bahsi geçen notlarınızı paylaşmanız gerekebilir.

Hemen Sipariş Verin:

EFT ile sipariş için : http://www.savassakar.com/index.php/hayatimiz-proje-proje-yoneticisinin-el-kitabi/

Kredi Kartı ile Sipariş İçin: https://www.gittigidiyor.com/arama/?satici=savassakar

Paylaşın:

Proje Yönetiminde Regresyon 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

PMI, PMBOK 6’da Proje ve/veya Fazın Kapanışı aşamasında proje çıktılarına etki eden farklı proje değişkenlerinin gelecekteki proje performansı geliştirmesi amacıyla Regresyon Analizi ile değerlendirilebileceğini söylemektedir.

Proje Yöneticilerinin proje sürecinde elde ettikleri bilgileri değerlendirmeleri önemlidir. Mevcut ortam ve proje değişkenleri gelecekteki proje çıktılarına ilişkin öngörüler yapılabilmesini sağlar. Bu amaçla kullanılan araçlardan birisi Regresyon Analizidir.

Regresyon analizi, aralarında sebep-sonuç ilişkisi bulunan iki veya daha fazla değişken arasındaki ilişkiyi belirlemek ve bu ilişkiyi kullanarak o konu ile ilgili tahminler (estimation) ya da kestirimler (prediction) yapabilmek amacıyla yapılır.

İki ya da daha çok değişken arasında ilişki olup olmadığını, ilişki varsa yönünü ve gücünü inceleyen “korelasyon analizi” ile değişkenlerden birisi belirli bir birim değiştiğinde diğerinin nasıl bir değişim gösterdiğini inceleyen “regresyon analizi” Proje yönetiminde kullanılan istatistiksel yöntemlerdir.

İki değişken arasındaki ilişkiyi Proje Yöneticisi bir grafik üzerinde görebilir. (Bakınız: Proje Kalite Yönetiminde Dağılım Şemaları)  

Güçlü bir ilişki olması gelecekte dikkat edilmesi gerektiğini gösterir, doğru kararlar alınmasını sağlar. Örneğin gereksinimlerin net olması ile projenin zamanında tamamlanması, değişikliklerin az olması ile projenin az gecikmesi arasındaki ilişki vb.

Regresyon Analizi ile hazırlanmış iki doktora tezi konuyu anlamanıza yardımcı olacaktır;

İnşaat Firmalarinda Proje Müdürlerinin İş Yükü, İş Stresi, İş Tatmini Ve Motivasyon İlişkisi – Gülce ÖĞRÜÇ ILDIZ

Eğitim Ve Sağlık Yapılarında Regresyon Yöntemiyle Maliyet Analizi – Arş. Gör. Metin Gülerce

Regrsyon Analizi için kullanılabilecek bir Excel Tablosuna buraya tıklayarak ulaşabilirsiniz. 

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

Paylaşın:

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

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

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

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

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

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

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

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

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

Geleneksel Proje Yönetimi Yaklaşımları

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Çevik Proje Yönetimi Yaklaşımları

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

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

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

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

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

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

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

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

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

Uyarlamalı Proje Yönetimi Yaklaşımı

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

Extreme Proje Yönetimi Yaklaşımı

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

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

Extreme Yaklaşımı

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

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

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

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

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

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

Paylaşın:

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: