İş Programında Doğru Takvim Kullanımın Önemi

Bu yazımızda iş programı yapımızda pek dikkat edilmeyen bir konudan bahsetmek istiyorum, inşaat aktivitelerinde işin karakteristiğine göre mevsimsel olarak verim düşmeleri yaşanmak. Mesela kil serilmesi gibi yağmur yağmayan bir ortamda yapılması gereken bir aktivitenin verimi yaz ve sonbahar aylarında çok değişkenlik gösterebilmektedir, aynı şekilde Ramazan ayı boyunca tüm şantiyenin veriminin yüzde 25 düşeceğini tahmin etmek zor değildir. Bu tip durumlarda yapılan yanlış uygulamalardan en önemlisi bu periyottaki aktivitelerin sürelerini manuel olarak arttırmak, yani iş programında yazın 10 günde biten bir kil serimi aktivitesini sonbaharda 20 gün olarak göstermektir. Bu yapılan yanlış uygulamanın sonucu olarak, iş programını dinamik bir belde olduğundan, ileride oluşacak gecikmeler ve hızlanmalar ile bu aktivitelerin yekleri sabit kalamayacaktır. Bu şekilde hazırlanmış bir iş programı hem projenin bitiş tarihini yanlış gösterirken hem de süre uzatma analizlerinde hatalı sonuçlar vermektedir.  Burada yapılması gereken doğru hamle ise düzgün bir takvim ile aktivitelerin yüzde yüz performans sürelerinin yazılmasıdır.

Bu yazımızda örnek olarak öneki yazılarımızda kullandığımız bir programı baz alacağız,

İlgili yazıya

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

Linkinden ulaşabilirsiniz,

Bu iş programa 3 adet yeni aktivite koyuyoruz, 14, 15 16 isimli aktivitelerin kil serme aktivitesi olduğunu farz ediyoruz. Aldığımız verilere göre kil sermesi için eylül ve ekim ayında yüzde 25, kasım ayında yüzde 50; aralık ayında yüzde 75 verim azalması varken, ocak şubat ve mart aylarında çalışmak mümkün değil, nisan ayında ise ilk 15 gün yüzde 50 performans ile çalışabiliyorken geri kalan tüm zamanlarda tam performans çalışılabiliyor, bu aşamada 2 adet iş programı hazırlayacağız, ilk örnek bu durumu düzgün takvim kullanarak aşarken ikinci örnek süreleri manipüle ederek aşmaya çalışacak.

Takvim yaratma

İlk iş programımız için yeni bir takvim yaratıyoruz, primavera saat bazlı çalışan bir programdır bu yüzden aslında 10 günlük bir aktivite tanımladığımızda iş programı bu aktivitenin bağlı olduğu takvimin ön tanımlı günlük çalışma saatine bakarak aktivitenin toplam kaç saatlik bir aktivite olduğunu hesaplar ve bundan sonra tüm hesaplamalarını buna göre yapar. Mesela 10 günlük günde 8 saat çalışma saati olan bir takvime bağlı aktivite aslında primavera tarafından 80 saatlik bir aktivite olarak tanımlanır, bu aktivitenin takvimini günde 10 saat çalışılan bir takvimle değiştirirseniz toplam 80 saati sabit tutacağı için aktivitenin toplam süresi 8 güne düşecektir, aynı şekilde toplam 8 saat çalışma tanımlı bir takvimde bazı günlerin çalışma saatini 4 saate düşürürseniz normal iş gününde 1 günde biten aktivite 2 günde bitecektir.  Yukarıda belirttiğimiz takvime uygun olarak gerekli zaman dilimindeki çalışma saatlerini yeni takvimimizde düşürüyoruz.

 

Mesela yukarıdaki fotoğrafta da görebileceğiniz üzere kasım ayındaki çalışılan günlerdeki çalışma saatini 4 saate indirdik ve bunu proje süresindeki tüm kasım aylarına uyguladık. Kil aktivitelerinin takvimini yeni yarattığımız aktivitelere atadık ve hepsini zamanını 45 gün olarak belirledik,

Böylece yukarıda gördüğümüz baseline ı oluşturmuş olduk,

İkinci senaryomuzda ise böyle bir takvim tanımlamadan Primavera’nın standart takvimini kullanarak iş programını oluşturduk,

 

İki projeyi de düzgün ve hatalı adlandırmalarıyla alt alta koyuyorum, gördüğünüz gibi 2 projede aynı tarihlere sahip,

1 Şubat 2019 tarihi itibariyle 2 projeyi de güncellediğimizde,

 

Gördüğünüz gibi aynı verilere sahip 2 güncelleme için proje bitiş tarihlerinde 16 günlük bir sapma meydana geldi, tabii ki aralık ayında verim düşeceği için ilk proje bitiş tarihi daha doğru,

Hikayemizi devam ettirdiğimizde 1 Şubat itibari ile şantiyeni 2 ay durdurulduğunu farz edelim ve her iki iş programı içinde bunu bir impact olarak kabul edelim ve bir gecikme analizi yapalım.

Gördüğünüz gibi her iki iş programına da 60 günlük 2 adet impact koyuyoruz ilk programda kil aktivitesi kışın yapılamayacağı için iş programı gelecek senenin baharına ertelenirken diğer projede kış ortasında bitmesi gerektiği gözüküyor, ilk program için yapılan analiz 185 gün süre uzatımı gösterirken ikinci programda tahmin edebileceğiniz gibi 60 günde kalıyor.

Peki böyle bir hatalı iş programınız varsa ne yapmalısınız; eğer işveren kabul ederse, ki etmeyebilir, bu aşamada yapmanız gereken analiz disruption(bozulma) denen analiz yani bir şekilde verim düştüğü için 41 günde yapacağınız işi çok daha uzun sürede yapacağınızı ispatlayıp bunu başka bir gecikme olarak gösterip 2. Bir gecikme analizi yapmanız gerekiyor, disruption analizi ile ilgili detaylı bir yazıyı ileriki zamanlarda yazmayı planlıyorum.

 

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.