Gecikme Analizi Tipleri ve Tanımları

Öncelikle şunu belirtmeliyim ki gecikme analizleri konusunda diğer mühendislik uygulamalarında olduğu gibi bir uzlaşma mevcut değil , İngiltere’de mahkemede ki bir bilirkişinin kabul ettiği analizi Danimarka’da ki başka bir bilirkişi kabul etmeyebiliyor , ayrıca isimlendirme de bile ayrışmalar söz konusu , bir kurumun TIA olarak adlandırdığı analizi başka bir kurum modelled multi based window analysis olarak yada bir kurumun window analysis olarak adlandırdığı analizi diğer bir kurum snapshot analysis olarak değerlendirebiliyor. Benim görebildiğim kadarıyla bu konuda insanların referans olarak kullandıkları 2 adet protokol var bunlardan birincisi

AACE International Recommended Practice No. 29R-03 -Forensic Schedule Analysis

AACE (American Association of Cost Engineers) tarafından hazırlanan ve çok Teknik bir dile sahip olan bu şartname dünyada kabul gören bir referanslardan biri, , bu şartnamenin avantajı özellikle Amerika ile ilgili bir iş yapıyorsanız bu şartnameye referans yaparak sunduğunuz süre uzatımı iddiasının kabul edilmesi daha olası, dezavantajı ise içerisinde çok fazla analiz seçeneği var ve bu da kafa karıştırıcı olabiliyor, halka açık bir yayın olmadığı için burada paylaşamıyorum ama internette biraz araştırırsanız bulabileceğiniz bir doküman.

İkincisi ise

Society of Construction Law- Delay and Disruption Protocol

SCL (Society of Construction Law) tarafından hazırlanan bu protokol ise bir önceki belgeden daha basit bir dile sahip ve dünyada kabul gören bir başka referans, halka açık olarak kendi sitesinde yayınlanan bu protokole

https://www.scl.org.uk/sites/default/files/SCL_Delay_Protocol_2nd_Edition.pdf

adresini kullanarak ulaşabilirsiniz

Bu protokolün avantajı daha az analiz seçeneği sunması, basit bir dili olması, sadece analizin nasıl yapılacağını açıklamaktansa gecikme ile ilgili tüm detaylara odaklanması ve herkes tarafından ulaşılabilir olması, dezavantajı ise analizlerin AACE de olduğu gibi güzel gruplanmaması. Benim bu protokolü tercih etmemdeki en önemli sebep ise Analiz olarak TAI’yi önermesi.

Yazının bu kısmından sonra vereceğimiz bilgiler SCL protokolü temel alınarak hazırlanmış bilgiler olacaktır, bu protokole göre 6 adet temel analiz var;

Impacted As Planned

Bu teknik gerçekleşen gecikmelerin baseline iş programına işlenerek yeni oluşan programındaki bitiş tarihindeki ötelenmenin süre uzatımına eşit olması mantığıyla yapılan bir analiz , öncelikle bu analizi kullanabilmeniz için iş programının çok iyi hazırlanmış olması ve gecikme anına kadar birebir uygulanmış olması lazım böylece kritik hat değişmemiş ve uyguladığımız impact gerçekten projeyi olması gerektiği gibi ötelemiş olmalı , fakat gerçek hayatta böyle bir proje mümkün değil impact ortaya çıktığında kritik hattın değişmiş olma ihtimali çok yüksek bu yüzden bu Teknik bence kullanılabilir bir teknik değil.

Time Impact Analysis

Bu teknik impactin olduğu zaman aralığındaki en son güncellenmiş iş programına bu impacti uygulayıp proje süresinin ne kadar ötelendiğini hesapladığımız bir yöntem, diğer yöntemlerden farklı olarak eşzamanlı gecikmeleri daha önceki yazımızda anlattığımız gibi kolayca hesaplayabileceğimiz bir yöntem, eşzamanlı gecikmeleri TIA yönteminde nasıl hesaplayabileceğinizi anlattığımız yazı için

http://planlamadanismanlik.com/impacted-as-planned-iap-analizi-neden-ise-yaramiyor/

Linkini kullanabilirsiniz,

Bu tekniğin avantajı diğer bazı tekniklerden farklı olarak sadece impact'in olduğu zaman aralığını analiz edebilirsiniz, eğer proje ortasında bir baseline revizyonu olduysa bile bu sizin hesaplamanızı etkilemez, her ne kadar SCL dokümanında prospective bir yöntem olduğunu söylese de elinizde as-built bir iş programı varsa bir nokta için güncelleme tahmin edip geçmişe yönelik bir çalışmada yapabilirsiniz,

Dezavantajı ise hesaplamanın doğruluğunun tamamen gerçekleşmemiş aktivitelerin tahminlerinin doğru olmasına bağlı olması, mesela gerçekleşmemiş 3 ardıl aktivite aslında aynı anda yapılabiliyorsa ve sizin gecikmeniz bu hat üzerindeyse aslında kritik hatta olmayan bir gecikme kritik hattaymış gibi hesaplanıp hesabınızı etkiliyor , burada yapılabilecek tek şey baseline’ı doğruymuş gibi kabul edip eğer yüklenici bu 3 aktiviteyi aynı anda yaptıysa bunu projeyi hızlandıran bir efor olarak kabul etmek.

Time Slice Window Analysis

Bu teknik her güncellemeyi bir önceki ile karşılaştırıp eğer projenin bitiş zamanında bir değişim varsa bu periyoddaki her iki taraf içinde olan gecikmeleri ayrı ayrı analiz etme üzerine kurulmuş bir sistem , avantajları TIA’da bahsettiğimiz güncellenmemiş aktivitelerin önemi yok çünkü baştan sona tüm güncellemeleri gözden geçirmeniz gerekiyor, eğer bir periyodda proje bitiş tarihinde değişiklik yoksa bu periyod için analiz yapmanıza gerek kalmıyor , ki bu avantaj pek uygulanabilir değil çünkü her güncellemede değişiklikler olması çok muhtemel.

Dezavantajları TIA’da sadece impact öncesi güncellemenin düzgün yapılması yeterli iken bu teknikte tüm güncellemelerinizin düzgün yapılmış olması gerekiyor, hatalı tek güncelleme tüm hesaplamayı bozabiliyor , eğer proje ortasında baseline revizyonu yapıldıysa ,bu gerçekleşmemiş 2 aktivitenin ilişkilerinin düzeltilmesi bile olsa bu tekniği  kullanamıyorsunuz, en önemlisi incelenen peridodaki tüm gecikmeleri teker teker bulmanız ve bunu tüm periyodlar için tekrarlamanız gerekiyor , hata yapmaya çok elverişli,çok uzun ve bence uygulanma ihtimali çok düşük bir prosedür bu.

 As Planned Versus As-Built Window Analysis

Bu tekniği time slice window tekniğinin güncelleme periyodunun tüm proje olduğu bir Teknik olarak düşünebiliriz, yani eğer elimizde düzenli güncellemeler yoksa bu tekniği kullanıyoruz,

Bu tekniğin avantajları ve dezavantajları time slice window analysis ile aynı fakat bu analizde incelenecek periyod çok daha uzun olduğu için hata yapma olasılığı çok daha yüksek.

Retrospective longest path analysis

Bu Teknik as built projede son aktiviteden itibaren geriye doğru gidip en uzun hattı bulup sadece bu hat üzenindeki gecikmeleri hesaba katarak yapılan bir hesaplama,

Avantajı baselinedaki hatalı ilişkilerin önemi kalmıyor,

Dezavantajı ise yapması çok zor ve gecikme yaşandığı zaman en uzun hatta olmayan fakat kritik hatta olup gerçekte projeyi uzatmış aktiviteleri hesaplamaya katamıyorsunuz.

Collapsed As-Built

Bu teknikte ise baseline’ı hiç dikkate almadan as built üzerinden yeni bir iş programı oluşturuyoruz. Daha sonra da bu programdan impact’leri çıkartarak ortaya çıkan yeni programın bitiş tarihi ne kadar öne geldiyse gecikmenin bu süre kadar olduğu kabul ediyoruz.

Avantajı baselinedaki hatalı ilişkilerin önemi kalmıyor,

Dezavantajı yeni oluşturulan programda ilişkiler bir mantık üzerinden değil gerçekleşmeler üzerinden yapıldığı için sıkıntılar yaşanıyor, mesela birbirinden 5 sün soran başlayan ve 10 gün sonra biten 2 aktiviteyi SS 5 gün  veya FF 10gün olarak bağlayabiliyoruz fakat bu iki bağlantı sonucu hesaplama farklı çıkabiliyor , hatta belki 2. Aktiviteyi öteleyen aktivite bambaşka bir aktiviteydi ve analiz sırasında bunun kontrolü pek mümkün olmuyor, aynı gerçekleşmeleri gösteren farklı programlarda çok farklı hesaplamalar ortaya çıkabiliyor.

Sonuç olarak tüm analizleri gözden geçirdiğimizde TIA’nın hem makul bir şekilde uygulanabildiğini hem de nispeten daha doğru sonuçlar verdiğini görüyoruz. Proje sonunda analiz tekniği tartışmalarından kaçınmak için bence kullanılacak yöntem proje basında belirlenmeli, şartname ya da sözleşmede belirtilmeli. Benim bu konuda ki önerim kullanılacak  yöntem TIA olmalı ve impact oluştuktan sonra ilk güncelleme ile birlikte analiz olarak sunulmalı.

 

 

 

 

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.