Impacted as planned (IAP) analizi neden işe yaramıyor

Bu yazıyı yazmadan önce gecikme analizlerini tanıtan bir yazı yazmak istiyordum fakat, potansiyel bir müşterime kendisine süre uzatımı için sunulan Impacted as planned analizinin neden hatalı olduğunu anlatmam gerekiyordu, kendisine yapacağım sunumu aynı zamanda burada da yayınlamayı uygun gördüm.
Elimizde 1 adet proje öncesinde sunulmuş baseline’mız var, baseline’mız 13 adet aktiviteden oluşan bir iş programı.

Aynı gecikmelere fakat farklı gerçekleşmelere sahip birbirine çok benzer 2 adet senaryomuzun olduğumuzu farz ediyoruz

Her iki senaryomuzda da yüklenici altta gri ile belirlediğim impact’lerin kendisini geciktirdiğini iddia ediyor ve işveren bunu kabul ediyor

Gördüğünüz gibi 3 impact ’de 2 senaryoda birbirinin aynı bu yüzden IAP analizimiz iki projede de aynı oluyor.

 

Ve bu analize göre yüklenicinin hakkettiği uzatma 33 gün oluyor, peki bu 2 senaryodaki süre uzatımını ayrı ayrı time impact analizi (TIA) ile hesaplasaydık ne olurdu
TIA da analiz impact ’in olduğu zaman aralığına bakılarak yapılıyor eğer elimizde düzgün güncellemeler olsaydı impact ’ten önceki ve sonraki güncellemelere bakacaktık , şu an elimizden güncellemeler olmadığı için as-built iş programından güncellemeler yaratacağız , fakat burada dikkat etmemiz gereken nokta buradaki gibi uzun aktivitelere sahipsek aktivitenin gerçekleşmesi lineer olmayabilir , mesela 1 haftada işin yüzde 70 i bitmişken sonra 1 ayda yüzde 30 u tamamlanmış olabilir ve buda tam impact ‘in gerçekleştiği zamana denk gelmiş olabilir , elimizde bu tür bilgide varsa bunu da göz önünde bulundurmalıyız , elimizde güncellemeler olmadığı için ilk senaryoda ilk impact ‘in başlangıç tarihi için bir güncelleme oluşturuyoruz

Daha sonra bu güncelleme üzerine oluşan impact’ı koyup 3 numaralı aktiviteyi öteliyoruz

İmpact kritik hatta olduğu için kendi süresi kadar projeyi öteliyor, 3. Bir aşama olarak da bu impact oluştuğu sırada bir concurrent gecikme olup olmadığına bakmamız gerekiyor ,concurrent gecikmeleri aynı işverenin gecikmeleri gibi birer impact olarak gösterebiliriz , bu aralıkta gerçekleşen tek aktivite 5 numaralı aktivite ve onunda 2 gün uzadığı görülüyor, bunu bir impact olarak yansıttığımızda 5 numaralı aktivitenin 15 gün bolluğu olduğu için bu gecikme projeyi uzatmayacağı için concurrent gecikme olamadığını söyleyebiliriz , peki böyle 13 aktiviteli değil de 1500 aktiviteli bir iş programız olsaydı ve bu aralıkta 20 tane yüklenici aktivitesi olsaydı? Bu durumda kullanılan bir teknik var oda impact ‘ten etkilenen aktivitelerin incelediğimiz periyodun sonuna kadar bir önceki güncellenen iş programındaki gibi ilerlediğini varsayıp, diğer aktiviteleri yüklenicinin gerçekleştirdiği gerçekleşmeler ile güncelliyoruz

Daha önceden de belirttiğimiz gibi burada bir concurrent gecikme olamadığı için iş programımız ilk güncellememiz ile aynı çıkıyor 2. Ve 3. İmpact’ler içinde uyguluyoruz ve karşımıza sırasıyla

Analizleri ortaya çıkıyor, tüm projelere baktığımızda

Basit bir hesapla

Project ID Project Name Finish     extension
      01.base-1 A baseline 19-Sep-19    
      04.update1-1 A update1 18-Sep-19    
      05.impact1-1 A impact 1 04-Oct-19 delay 16 16
      06.concur1-1 A concurrent1 18-Sep-19 concurent delay 0  
      07.update2-1 A update2 18-Sep-19    
      08.impact2-1 A impact 2 08-Oct-19 delay 20 20
      09.concur2-1 A concur2 18-Sep-19 concurent delay 0  
      10.update3-1 A update3 09-Oct-19    
      11.impact3-1 A impact3 05-Nov-19 delay 27 27
      12.concur3-1 A concur3 09-Oct-19 concurent delay 0  
        total 63

 

Toplam 63 gün süre uzatımını buluyoruz, peki 2. senaryoda ne oldu, detaylara girmeden sadece 3 impactin projeye etkilerini teker teker veriyorum

İlk impact kritik hatta olmadığından projeyi uzatmıyor ortada bir gecikme olmadığı için concurrent gecikmeye bakmamıza gerek yok, diğer 2 impact'e de baktığımızda

Tüm projelere baktığımızda

 

Aynı hesabı yaparak

Project ID Project Name Finish     extension
      01.base-2 B baseline        
      07.update2-2 B update2 18-Sep-19    
      08.impact2-2 B impact 2 08-Oct-19 delay 20 18
      09.concur2-2 B concur2 20-Sep-19 concurent delay 2  
      10.update3-2 B update3 09-Oct-19    
      11.impact3-2 B impact3 05-Nov-19 delay 27 20
      12.concur3-2 B concur3 16-Oct-19 concurent delay 7  
        total 38

 

toplam gecikme 38 gün olarak bulunuyor , bu 2 örnekte birbirine çok benzeyen gerçekleşmeler kullanmak istedim , gerçekleşmeler üzerinde biraz daha oynayarak 0 gecikmede bulabilirdim.
Görüldüğü birbirinden çok farklı 2 TIA’daki verilerle IAP analizi aynı oluyor, bunun sebebi impact ortaya çıktığındaki projenin kritik hattı baseline dan farklı olabiliyor bu yüzden IAP analizleri değişen kritik hatları hesaplamanın işçine katamıyor ayrıca concurrent gecikmeleri de IAP analizi ile hesaplamak imkânsız, bu yüzden birçok kurum IAP analizlerini süre uzatımı çalışmalarında kabul etmiyor.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir