MS Project’te kritik yol neden bazen sürekli değişir?

Kritik yol; bağımlılıklar, takvimler, kısıtlar ve kaynak kaymaları değiştikçe yeniden hesaplanır. Sert kısıtlar, yanlış bağ türleri veya farklı çalışma takvimleri yalancı kritik yaratabilir. Ayrıca leveling sonrası kaynak kaymaları kritik zinciri başka bir akışa taşıyabilir. Önce kısıtları sadeleştirip bağları gerçek akışa göre düzeltmek, sonra takvim ve kaynak etkisini kontrol etmek gerekir.

Total slack kaç gün olunca görev riskli sayılmalıdır?

Tek bir evrensel sayı yoktur; eşik, sprint uzunluğu ve onay/tedarik sürelerine göre belirlenir. Pratikte 0 gün kritik, 1–3 gün yüksek risk, 4–7 gün orta risk gibi bir bant yaklaşımı kullanılabilir. Önemli olan, bu eşikleri ekipçe sabitlemek ve raporlamada aynı risk dilini kullanmaktır. Böylece kritik olmayan ama kritikleşmeye yakın işler erken yönetilir.

Kritik yol analizinde Must Start On kısıtı neyi bozar?

Must Start On gibi sert kısıtlar, float değerlerini yapay biçimde sıfırlayabilir ve planı kırılganlaştırır. Bu durumda MS Project kritikliği “kısıt nedeniyle” gösterebilir; gerçek bağımlılık zinciri geri planda kalır. Eğer sözleşmesel zorunluluk yoksa, daha esnek kısıt türleriyle çalışmak ve bağımlılıkları doğru kurmak daha sağlıklı bir süre yönetimi sağlar.

Baseline olmadan kritik yol yönetimi yapılabilir mi?

Kritik yol, mevcut planın fotoğrafını verir; ancak baseline olmadan planlanan ile gerçekleşen arasındaki sapmayı güvenle ölçemezsiniz. Baseline, değişiklik yönetimi ve performans değerlendirmesi için referanstır. Baseline set edilmediğinde, plan güncellemeleri geçmişi siler ve gecikmenin nedeni tartışmalı hale gelir. Bu nedenle proje başlangıcında baseline almak ve onaylı değişikliklerde güncellemek önerilir.

Resource leveling kritik yolu uzatırsa nasıl karar vermeliyim?

Leveling, kapasiteyi korur ama süreyi uzatabilir; karar, teslim hedefi ve kaynak maliyeti dengesine bağlıdır. Önce kritik ve yüksek risk bandındaki görevleri koruyup, düşük risk görevlerden kaydırma yapmayı deneyin. Gerekirse görev bölünebilirliğini ve task type ayarlarını gözden geçirin. Alternatif olarak ek kaynak, dış hizmet veya kapsam fazlama gibi senaryoları kritik yol etkisiyle kıyaslayarak karar verin.

MS PROJECT’TE KRİTİK YOL ANALİZİYLE SÜRE YÖNETMEK

Proje planı “takvimde güzel durduğu” için doğru olmaz; doğru plan, kritik yolun nereden geçtiğini ve en küçük sapmanın hangi işi devireceğini gösterdiği için doğru olur. MS Project’te kritik yol analizi, süre yönetimini sezgiden çıkarıp ölçülebilir bir kontrol mekanizmasına dönüştürür.

Kurumsal projelerde teslim tarihi baskısı arttıkça, ekipler en hızlı görünen kısayola gider: daha fazla işi aynı anda başlatmak. Oysa bağımlılıklar, takvimler ve kaynak kısıtları hesaba katılmadan yapılan paralelleştirme, kritik zinciri uzatır. Kritik yol analizi; bu “hızlı gibi görünen” kararların gerçek etkisini sayısal olarak ortaya koyar.

Bu yazıda, MS Project kritik yol analizi üzerinden süreyi yönetmek için pratik bir yaklaşım kuracağız: doğru mantık bağları kurmak, float (total slack) okumak, kısıtları temizlemek, baseline ile kıyaslamak ve senaryolarla karar vermek. Hedef, planı sadece raporlamak değil; planı yönetmek ve gecikmeyi önlemek.

Gantt görünümünde kırmızı vurgulu görev zinciri ve yan tarafta total slack sütunu olan plan ekranı

Kritik yol kavramını proje hedefiyle eşlemek

Kritik yol (critical path), projenin bitiş tarihini belirleyen en uzun bağımlılık zinciridir. Burada “en uzun” ifadesi yalnızca süre toplamını değil; takvim farklılıklarını, gecikmeleri ve bazı kısıt türlerini de kapsar. Bu nedenle kritik yolu okumadan önce, proje hedefinizin hangi tarihe bağlandığını netleştirmek gerekir: teslim kilometre taşı mı, sözleşme bitişi mi, iç onay mı?

Kilometre taşı mantığını netleştirmek ve bağlamak

Kurumsal planlarda kritik yol çoğu zaman bir milestone üzerinden okunur. Milestone’lar doğru bağlanmadığında MS Project, bitişi farklı bir görevden türetebilir ve kritik yolunuz “başka bir hedefe” göre hesaplanır. Önce teslimi temsil eden milestone’ı belirleyin, sonra tüm ana akışın bu noktaya bağlandığından emin olun.

Takvim farklılıklarını görünür kılmak ve standartlamak

Farklı ekiplerin farklı çalışma takvimleri (hafta sonu, vardiya, resmi tatil) kritik yolu dramatik biçimde değiştirebilir. Bir görev zinciri aynı süreye sahip olsa bile, takvim farkı nedeniyle bitiş kayabilir. Bu yüzden, “iş paketine göre takvim” yaklaşımını tanımlayın ve kritik akışta mümkün olduğunca standardize edin.

Mantık bağlarını doğru kurmak ve kısıtları temizlemek

Kritik yol analizi, bağlar doğru değilse yanıltıcıdır. En sık hata; her şeyi Finish-to-Start (FS) bağlamak ya da “işi başlatmak için” rastgele kısıt eklemektir. Oysa gerçek hayatta Start-to-Start (SS), Finish-to-Finish (FF) ve lag/lead değerleri kritik akışı daha doğru temsil eder.

FS SS FF ilişkilerini seçmek ve lag ayarlamak

Örneğin saha imalatı ile kalite kontrol eş zamanlı ilerleyebilir; bu durumda SS + lag kullanmak gerçekçi olur. Tasarım teslimi ile satınalma kapanışı FF ile bağlanabilir. Bağ tipini doğru seçmek, kritik yolun “gerçek bağımlılık” üzerinden akmasını sağlar ve yalancı kritikliği azaltır.

Must Start On kısıtını azaltmak ve esneklik yaratmak

“Must Start On” ve “Must Finish On” gibi sert kısıtlar, float değerini yapay biçimde sıfırlar ve planı kırılganlaştırır. Eğer kısıt bir sözleşme zorunluluğu değilse, daha esnek türlere (Start No Earlier Than gibi) geçmek süre yönetimini iyileştirir. Amaç, yönetilebilir bir float üretmek ve riski doğru yere yığmaktır.

// Örnek: Plan sağlığı kontrol listesi (temsili)
checks = [
  "Kritik milestone tanımlı mı ve tüm ana iş akışı ona bağlı mı?",
  "Sert kısıt sayısı (>0) kritik görevlerde gereksiz mi?",
  "Bağ türleri (FS/SS/FF) işin gerçek akışını temsil ediyor mu?",
  "Takvim farklılıkları kritik zincirde bilinçli mi seçildi?",
  "Özet görevlerde manuel tarih atanmış mı (kaçınılmalı)?"
]

Float total slack okumak ve risk bandı belirlemek

Kritik yol çoğu zaman “kırmızı görevler” olarak görülür; ancak asıl süre yönetimi, kırmızıya yaklaşan görevleri erken yakalamakla yapılır. Bunun ana göstergesi total slack (toplam kayma) değeridir. Total slack düşük olan görev, henüz kritik olmasa bile projenin bitişini tehdit etmeye adaydır.

Total slack eşiklerini tanımlamak ve uyarı üretmek

Uygulamada, bir risk bandı tanımı işinizi kolaylaştırır: örneğin 0 gün kritik, 1–3 gün yüksek risk, 4–7 gün orta risk, 8+ gün düşük risk. Bu eşikler; sprint uzunluğu, tedarik süresi ve onay döngülerine göre değişir. Önemli olan, ekiplerin aynı dili konuşmasıdır.

Free slack ile total slack ayrımını yapmak ve yorumlamak

Free slack, bir görevin ardılını etkilemeden kayabileceği süreyi gösterir; total slack ise proje bitişini etkilemeden kayabileceği toplam süreyi. Kurumsal kararlar çoğu zaman total slack üzerinden alınır; çünkü hedef teslim tarihidir. Yine de entegrasyon yoğun projelerde free slack düşükse, ardıl ekipleri etkileyen mikro gecikmeler birikir.

// Örnek: Slack bandı etiketleme (temsili)
function riskBand(totalSlackDays) {
  if (totalSlackDays <= 0) return "kritik";
  if (totalSlackDays <= 3) return "yüksek_risk";
  if (totalSlackDays <= 7) return "orta_risk";
  return "düşük_risk";
}

Baseline ile sapmayı izlemek ve süre kontrolü yapmak

Kritik yol analizi tek başına “bugünün” fotoğrafıdır; baseline ise “planlanan ile gerçekleşen” arasındaki farkı görünür kılar. Baseline olmadan, kritik görevlerin kayması ile planın doğal evrimi karışır. Bu yüzden proje başlangıcında (ve onaylı değişikliklerde) baseline disiplinini işletmek gerekir.

Baseline set etmek ve değişiklik yönetimi bağlamak

Baseline, yalnızca raporlama için değil; değişiklik yönetimi için de bir referanstır. Örneğin bir kapsam değişikliği geldiyse, önce etki analizi yapıp sonra “yeni baz plan” mantığıyla onay almak gerekir. Aksi halde her güncellemeyle geçmiş silinir ve süre yönetimi tartışmalı hale gelir.

Variance sütunlarını okumak ve trend takip etmek

Start Variance, Finish Variance ve Duration Variance; gecikmenin hangi boyutta olduğunu gösterir. Kritik yol üzerinde küçük gibi görünen 1–2 günlük sapmalar, ardıl zincirde büyüyebilir. Bu yüzden tek seferlik bir rapor yerine trend izlemek (haftalık sapma grafiği gibi) daha doğru karar üretir.

Baseline olmadan sapmayı ölçememek
Takvim farkını ihmal edip yanlış karşılaştırmak
Kısıt şişmesiyle yalancı kritik üretmek
Bağımlılık hatasıyla riskin yerini kaçırmak

Kaynak kısıtlarını dengelemek ve süreyi korumak

Plan mantıksal olarak doğru olsa bile, kaynak kapasitesi kritik yolu değiştirebilir. Aynı uzman üzerinde üst üste binen işler, görevlerin otomatik kaymasına neden olur; bu kayma bazen kritik zinciri uzatır. Bu noktada “kritik yol” ile “kritik kaynak” birlikte ele alınmalıdır.

Resource overallocation görmek ve leveling stratejisi seçmek

Overallocation, aynı kaynağın aynı anda birden çok işe atanmasıdır. MS Project’te leveling uygulanırken, hangi görevlerin kaydırılabileceğini total slack üzerinden seçmek gerekir. Körlemesine leveling, kritik görevleri de kaydırıp teslimi tehlikeye sokabilir. Bu yüzden önce risk bandı düşük görevlerden başlayın.

Task type ve effort driven mantığını ayarlamak

Fixed Units, Fixed Work ve Fixed Duration seçenekleri, kaynak ekleyince sürenin nasıl davranacağını belirler. Örneğin “Fixed Work” ile iki kişi eklemek süreyi düşürebilir; ancak iş doğası bölünebilir değilse bu gerçekçi olmaz. Süre yönetiminde, işin bölünebilirliği ve ekip verim katsayısı açıkça tanımlanmalıdır.

Senaryo analizi kurmak ve kararları kanıtlamak

Kritik yol analizi, tek bir doğru üretmek zorunda değildir; çoğu zaman karar vericiler “en iyi olasılık” ve “en kötü olasılık” aralığını görmek ister. Bu nedenle senaryo planlama, kurumsal yönetimde güçlü bir iletişim aracıdır. Amaç; riskleri sayıya dökerek, yönetilebilir alternatifler sunmaktır.

What-if senaryosu üretmek ve alternatif akış denemek

Örneğin bir tedarik gecikmesi varsa, paralel bir hazırlık iş paketi açarak SS bağıyla öne çekmek mümkün olabilir. Ya da onay döngüsünü kısaltmak için ara kontrol noktaları eklenebilir. Bu değişikliklerin kritik yola etkisini total slack ve Finish Variance ile ölçüp, senaryoları kıyaslayabilirsiniz.

Rapor görünümünü standartlamak ve paydaşları hizalamak

Paydaşlar genellikle aynı detayı görmek istemez: yönetim özet ister, ekip lideri risk bandını ister, PMO baseline sapmasını ister. Bu yüzden kritik yol analizi raporunu standardize etmek gerekir: kritik görev listesi, yüksek risk bandı, başlıca kısıtlar ve önerilen aksiyonlar. Konuyu daha sistemli uygulamak için ms project eğitimi kapsamında kritik yol, kısıt yönetimi ve senaryo çalışmaları birlikte kurgulanabilir.

Filtrelenmiş kritik görevler listesi ve yanında finish variance ile risk bandı etiketlerinin yer aldığı tablo görünümü

Sonuç olarak; MS Project’te kritik yol analiziyle süre yönetmek, kırmızı görevleri izlemekten ibaret değildir. Doğru bağımlılık kurmak, gereksiz kısıtları temizlemek, total slack bandıyla riski erken görmek, baseline sapmasını trend olarak izlemek ve kaynak dengelemesini kontrollü yapmak gerekir. Bu disiplin oturduğunda, teslim tarihi bir “tahmin” olmaktan çıkar; ölçülen, izlenen ve yönetilen bir hedefe dönüşür.