KAMU İHALELERİNDE SÜRE UZATIMI GEREKÇELENDİRME DOSYASI KURGULAMAK

Kamu ihalelerinde süre uzatımı talebi, çoğu zaman “gecikme oldu” demekten çok daha fazlasını ister. İdare, kontrol teşkilatı, iç denetim ve gerektiğinde yargısal denetim karşısında; gerekçelerin ölçülebilir, izlenebilir ve kanıta dayalı biçimde sunulması beklenir. Bu yüzden süre uzatımı gerekçelendirme dosyası, bir dilekçe ekinden ziyade, karar verdiren bir teknik-hukuki paket olarak düşünülmelidir.

Doğru kurgulanmış bir dosya; gecikme nedenlerini sınıflandırır, mevzuat ve sözleşme hükümleriyle ilişkilendirir, zaman etkisini hesaplar ve talebin kapsamını netleştirir. Ayrıca idarenin “neye göre onay verdim?” sorusunu, geri dönüp bakıldığında dahi cevaplayacak şekilde kayıt üretir. Kurumsal ölçekte bu yaklaşım, süre uzatımı yönetimini sürdürülebilir hale getirir ve proje portföyü yönetimine ölçüm verisi sağlar.

Bu makalede; süre uzatımı gerekçelendirme dosyası kurgulamak için pratik bir çerçeve kuracağız: amaç-kapsam belirlemekten ekleri tasarlamaya, kritik yol analizinden dijital arşiv düzenine kadar uçtan uca bir yöntem izleyeceğiz. Kurumsal yazılım geliştirme ekipleri için de, talep/olay kayıtlarının nasıl yapılandırılacağına dair örnekler göreceksiniz. Daha kapsamlı mevzuat ve uygulama senaryoları için kamu ihale eğitimi içeriğini de inceleyebilirsiniz.

Süre uzatımı gerekçelendirme dosyasının amacı ve kapsamını netleştirmek

Dosyanın ilk başarısı, “tam olarak neyi talep ediyorum?” sorusuna net cevap vermekle başlar. Süre uzatımı talebi; gün sayısı, başlangıç-bitiş tarihleri, hangi iş kalemlerini etkilediği ve hangi olaylara dayandığı açısından açık biçimde tanımlanmalıdır. Aksi durumda idare, talebi belirsiz bulabilir veya eksik inceleme riski doğar.

Bu bölümde hedef; talebi parçalara ayırmak, kapsam dışı yorum ihtimalini azaltmak ve inceleme yükünü düşürmektir. Kurgu şu üç soruya yanıt vermelidir: (1) Süre uzatımı kaç gün ve hangi tarih aralığı için isteniyor? (2) Gecikme hangi olay(lar)a dayanıyor? (3) Bu olaylar yüklenicinin kusuru dışında mı ve sözleşmesel/mevzuatsal bir karşılığı var mı?

Talep tanımını ölçülebilir hale getirmekle

Talep metninde “makul süre”, “uzun gecikme” gibi yoruma açık ifadeler yerine; tarihler, olay numaraları, yazışma referansları, revize iş programı sürümleri ve etkilenen faaliyet kodları gibi nesnel tanımlayıcılar kullanılmalıdır. Böylece dosyanın geri kalanındaki kanıtların hangi talebi desteklediği doğrudan görülebilir.

Kapsam dışı riskleri erken elemekle

Gecikme nedenleri bazen birden fazla olayı içerir: yer teslimi gecikmesi, projede revizyon, idareden onay beklenmesi, üçüncü taraf kurumlardan izin süreçleri gibi. Her olayı ayrı bir “vaka” olarak tanımlamak, idarenin her birini kendi içinde değerlendirmesini kolaylaştırır. Bu yaklaşım, “tümü reddedildi” yerine “bir kısmı kabul edildi” gibi daha yönetilebilir sonuçlar üretir.

Mevzuat dayanaklarını izlenebilir şekilde eşlemek ve referanslamak

Süre uzatımı gerekçelendirme dosyası; dayanakların yalnızca listelendiği değil, olaylarla eşleştirildiği bir yapı ister. İdarenin karar mekanizması genellikle “olay + hüküm + kanıt + etki” şeklinde çalışır. Bu nedenle, her gecikme olayı için hangi sözleşme maddesi, hangi şartname hükmü ve hangi mevzuat düzenlemesinin dayanak olduğu netleştirilmelidir.

Kurumsal pratikte en sık hata; mevzuat referanslarını tek bir paragrafta toplayıp geçmektir. Bunun yerine, her vaka başlığının altında “Dayanaklar” alt bölümü açarak, ilgili hükümleri vaka bazında ilişkilendirmek daha güçlüdür. Böylece denetimde, “bu hüküm neden burada?” sorusu doğmadan, iz sürme zahmeti azalır.

Vaka-hüküm matrisi kurmakla

İzlenebilirlik için basit ama etkili bir teknik; vaka-hüküm matrisi oluşturmaktır. Bu matriste satırlarda olaylar, sütunlarda hüküm başlıkları yer alır; her hücreye “uygulanır/uygulanmaz” ve kısa not düşülür. Daha sonra eklerde, ilgili yazışma ve tutanaklar bu matristeki vaka kodlarıyla etiketlenir.

Referans disiplinini standartlaştırmakla

Her yazışmaya bir “Belge Kodu” vermek, eklerde karışıklığı engeller. Örneğin “YAZ-2026-014” gibi bir kod; evrak numarası, tarih ve konu ile birlikte kullanıldığında; dosya hacmi büyüse bile aranan parçaya hızlı erişim sağlar. Özellikle elektronik doküman yönetim sistemlerinde, bu kodlar indeksleme açısından kritik avantaj sağlar.

Gecikme nedenlerini kanıtlarla sınıflandırmak ve kök neden analizi yapmak

Süre uzatımı taleplerinin reddedilmesindeki yaygın gerekçe; “gecikmenin nedeni ispatlanamamıştır” veya “yüklenicinin kusuru kapsamındadır” değerlendirmesidir. Bu riski azaltmak için, gecikme nedenlerini sistematik biçimde sınıflandırmak gerekir: idare kaynaklı, üçüncü taraf kaynaklı, mücbir sebep benzeri durumlar, tasarım değişikliği, saha koşulları, onay süreçleri gibi.

Burada amaç; “kanıt seti” oluşturmaktır. Her vaka için asgari kanıt paketi düşünün: yazışma zinciri, toplantı tutanağı, saha tespiti, talimat/olur, ilgili çizim revizyonu, fotoğraf yerine mümkünse ölçüm raporu veya metraj karşılaştırması, tarih damgalı sistem kayıtları. Kurumsal yazılım ekipleri için bu; iş emri, değişiklik talebi, onay akışı ve yorum kayıtlarının denetlenebilir tutulması anlamına gelir.

Kanıt setini minimum standartla tanımlamakla

Her kurumun dosya standardı farklı olsa da, pratikte bir “minimum kanıt” listesi belirlemek işleri kolaylaştırır. Aşağıdaki liste, çoğu ihalede temel bir iskelet sunar:

• Vaka özeti: olay tanımı, tarih aralığı, etkilenen faaliyetler
• Yazışmalar: talep, cevap, hatırlatma, talimat
• Tutanaklar: toplantı kararları, yerinde tespitler
• Teknik ek: revize çizimler, hesaplar, metraj/keşif etkisi
• Zaman analizi: iş programı sürümleri, kritik yol etkisi
• Sistem kayıtları: onay akışı, değişiklik kaydı, log ve tarih damgaları

Kök neden analizi ile kusur tartışmasını yönetmekle

Kök neden analizi, “sonuç” ile “sebep” ayrımını netleştirir. Örneğin “faaliyet X gecikti” bir sonuçtur; sebep ise “proje revizyonu onayı 17 gün sürdü” gibi somut bir olaya dayanmalıdır. Kök neden analizi, idarenin kusur değerlendirmesini daha rasyonel zemine taşır. Burada neden-sonuç zinciri kurmak; hem teknik hem idari dilde ikna edicidir.

Zaman etkisini hesaplamak: kritik yol, iş programı ve revizyon mantığı

Süre uzatımı gerekçelendirme dosyasının omurgası, zaman etkisinin nasıl hesaplandığıdır. “Gecikme oldu” demek yerine, “hangi faaliyetler etkilendi ve bu etki proje bitiş tarihini neden kaydırdı?” sorusuna yanıt verilmelidir. Bu noktada kritik yol (critical path) yaklaşımı ve iş programı sürüm yönetimi büyük önem taşır.

Kurgu, en az iki iş programı sürümünü karşılaştırır: baz program (onaylı) ve revize program (güncel). Her vaka için; etkilenen faaliyet kodları, gecikme günleri, bağımlılıklar ve kritik yol üzerinde olup olmadığı belirlenir. Eğer kritik yol dışı bir faaliyet gecikiyorsa, toplam süreye etkisi sınırlı olabilir; bu ayrım dosyada açıkça gösterilmelidir.

İş programı sürüm yönetimini şeffaflaştırmakla

İş programı dosyalarının “son hali” gibi muğlak ifadelerle sunulması, incelemede güvensizlik yaratır. Bunun yerine; sürüm numarası, oluşturulma tarihi, kim tarafından üretildiği ve hangi veriyle güncellendiği belirtilmelidir. İdareye verilen her program çıktısı, aynı sürüm numarasıyla eklerde yer almalıdır.

Kritik yol etkisini örnekle göstermekle

Aşağıdaki örnek, vaka bazlı zaman etkisi kaydını yapılandırmak için kullanılabilir. Bu yapı; kurumsal yazılımlarda “gecikme olayı” kaydı oluştururken de doğrudan işe yarar:

{
  "vakaKodu": "VKA-2026-03",
  "olayTuru": "projeRevizyonuOnayi",
  "tarihAraligi": { "baslangic": "2026-01-08", "bitis": "2026-01-25" },
  "etkilenenFaaliyetler": [
    { "kod": "A-120", "ad": "Uygulama Projesi Onay", "kritikYol": true, "gecikmeGun": 17 }
  ],
  "dayanaklar": [
    { "tip": "yazisma", "belgeKodu": "YAZ-2026-014" },
    { "tip": "tutanak", "belgeKodu": "TTN-2026-006" }
  ],
  "zamanEtkisiOzeti": "Kritik yol üzerindeki A-120 faaliyeti 17 gün sarktığı için bitiş tarihi aynı ölçüde ötelenmiştir."
}

Maliyet, risk ve sözleşme yönetimi boyutlarını birlikte değerlendirmek

Süre uzatımı talebi her zaman doğrudan bedel artışı anlamına gelmese de, süre uzadığında dolaylı maliyetler, kaynak planı, teminat süreleri, sigorta ve iş programına bağlı cezai şart riskleri gündeme gelebilir. Bu yüzden gerekçelendirme dosyası, en azından riskleri görünür kılan bir çerçeve sunmalıdır: “Süre uzatımı verilmezse ne olur?” sorusu, idarenin kararını etkileyebilir.

Bu bölümde amaç; maliyet talebine girmeden dahi, süre uzatımının sözleşme yönetimi açısından zorunlu olduğuna dair rasyonel bir zemin kurmaktır. Örneğin; gecikme idare kaynaklıysa, gecikme cezası tartışması doğabilir. İdare, ileride ihtilaf yaşamamak için süre uzatımını doğru gerekçeyle karara bağlamayı tercih edebilir.

Risk kayıtlarını talep dosyasına entegre etmekle

Kurumsal düzeyde “risk kaydı” yaklaşımı, süre uzatımı dosyasına güç katar. Vaka bazında risk tanımı yapılabilir: olasılık, etki, önlem, sorumlu ve izleme periyodu. Böylece talep, sadece geçmişe dönük savunma değil, ileriye dönük kontrol planı da sunar.

Sözleşmesel sonuçları sade dille anlatmakla

Teknik ekiplerin ürettiği analizlerin idari karar diline çevrilmesi gerekir. Bu nedenle; “kritik yol 17 gün kaydı” ifadesinin yanında, “bitiş tarihi değişmediği takdirde işin sözleşme süresinde tamamlanması teknik olarak mümkün değildir” gibi kısa, net cümleler kullanılmalıdır. Bu yaklaşım, değerlendirme komisyonu veya üst yönetim için anlaşılabilirlik sağlar.

İdareye sunum paketi: ekler, onay akışı ve dijital arşiv kurgusu

Gerekçelendirme dosyası, içerik kadar paketleme ile de kazanır. Eklerin sıralaması, isimlendirme standardı, çapraz referansları ve sayfa/ek numaralandırması; inceleme süresini ciddi biçimde kısaltır. Kurumsal yazılım geliştirme açısından bu; iş akışı tasarımı, doküman yönetimi ve denetim izi üretimi anlamına gelir.

Pratik bir kural: Ana metin “özet ve karar verdiren” olmalı; ayrıntı eklerde yaşamalıdır. Ana metinde her iddia, bir ek referansına bağlanmalıdır. Eklerde de her belge, ilgili vaka kodu ile etiketlenmelidir. Böylece “kanıt nerede?” sorusu tek hamlede cevaplanır.

Ek dizinini ve isimlendirmeyi standartlaştırmakla

Ek dizini, değerlendirmeyi hızlandıran bir harita gibidir. Örneğin:

1. EK-1 Vaka Listesi ve Talep Özeti
2. EK-2 Vaka-Hüküm Matrisi
3. EK-3 Yazışmalar (YAZ-xxxx-xxx)
4. EK-4 Tutanaklar (TTN-xxxx-xxx)
5. EK-5 İş Programı Sürümleri ve Zaman Etkisi Analizi
6. EK-6 Teknik Dokümanlar (Revizyon çizimleri, hesaplar)

Bu dizin; hem basılı hem dijital kullanımda tutarlı olmalıdır. Doküman yönetim sisteminde aynı kodlarla klasör yapısı kurulması, tekrar kullanım sağlar.

Dijital denetim izi üretimini tasarlamakla

Kurumsal yazılım ekipleri için kritik nokta; talep sürecinin denetim izini doğrudan sistemden üretmektir. Aşağıdaki örnek, bir süre uzatımı talebinin onay akışını ve kanıt bağlantılarını kayıt altına almak için basit bir SQL sorgusu fikri verir:

-- Süre uzatımı talebine bağlı vaka ve belge bağlantılarını izlemek için örnek
SELECT
  t.TalepNo,
  v.VakaKodu,
  v.OlayTuru,
  v.BaslangicTarihi,
  v.BitisTarihi,
  b.BelgeKodu,
  b.BelgeTipi,
  a.AdimAdi,
  a.Durum,
  a.GuncellemeTarihi
FROM Talepler t
JOIN Vakalar v ON v.TalepId = t.Id
LEFT JOIN Belgeler b ON b.VakaId = v.Id
LEFT JOIN OnayAdimlari a ON a.TalepId = t.Id
WHERE t.TalepNo = 'SUZ-2026-001'
ORDER BY v.VakaKodu, b.BelgeKodu, a.GuncellemeTarihi;

Bu tür bir çıktı, dosyaya “sistem kayıtları” eki olarak konduğunda; tarih damgaları, kimlik doğrulama ve işlem izleriyle güvenilirliği artırır. Ayrıca idare ile yazışma ve ek paylaşımında sürüm karışıklığını azaltır.

Süre uzatımı gerekçelendirme dosyasını kontrol etmek için kısa kontrol listesi oluşturmak

Dosya tamamlandığında, son bir kontrol listesi ile tutarlılığı ölçmek çok değerlidir. Çünkü en güçlü kanıt bile, yanlış ek numarası veya kopuk bir referans yüzünden zayıflayabilir. Aşağıdaki kontrol başlıkları, son okumada işinizi kolaylaştırır.

Kontrol listesini operasyonel hale getirmekle

• Talep gün sayısı ve tarih aralığı ana metin ve eklerde tutarlı mı?
• Her vaka için dayanak hüküm ve en az bir kanıt referansı var mı?
• Kritik yol etkisi gerekçesi açıkça gösterildi mi?
• İş programı sürümleri sürüm numarası ve tarih ile sunuldu mu?
• Ek dizini ile klasör/etiket yapısı birebir uyuşuyor mu?
• Yazışmaların tarih sırası ve cevap zinciri eksiksiz mi?

Karar verdiren özet bölümünü güçlendirmekle

Yöneticiler çoğu zaman önce “özet”i okur. Bu yüzden özet; talep edilen gün sayısı, temel vakalar, kritik yol etkisi ve eklerdeki ana kanıtlar açısından kısa ama yoğun olmalıdır. Özetin dili; teknik doğruluğu korurken, idari karar diline uygun olmalıdır. Son olarak, dosyanın tümünde aynı kavramların aynı şekilde adlandırıldığından emin olun: “vaka”, “olay”, “gecikme” gibi terimler tutarlı kullanılmalıdır.