MS PROJECT: KRİTİK YOL (CRİTİCAL PATH), BAĞIMLILIKLAR VE TAKVİM YÖNETİMİ

Bir projenin “en kritik” kısmı çoğu zaman en çok görünen işler değil, zamanı kilitleyen bağımlılıklar ve takvim kurallarıdır. MS Project’te kritik yol doğru kurgulanmadığında, plan aynı görünür ama gerçekte teslim tarihi sessizce kayar.

Bu yazıda kritik yol (critical path) mantığını pratik bir bakışla ele alacağız: bağımlılık türleri (FS/SS/FF/SF), gecikme-önleme ayarları, proje ve kaynak takvimleri ile çizelgeleme davranışının nasıl değiştiğini adım adım göreceksiniz.

Hedef, yalnızca “kırmızı çubukları” izlemek değil; kritikliği üreten nedenleri (bolluk, kısıtlar, takvim farkları, manuel planlama) yakalayıp planı güvenilir hale getirmek.

Kritik Yol Nedir ve Neyi Ölçer?

Kritik yol, projenin bitiş tarihini belirleyen en uzun bağımlı görev zinciridir. Bu zincirdeki görevlerde oluşan her gecikme, proje bitişini de aynı ölçüde geciktirir. MS Project, kritikliği genellikle “Toplam Bolluk (Total Slack)” değerine göre hesaplar: toplam bolluk sıfırsa görev kritik kabul edilir.

Ancak kritik yol tek bir “kırmızı çizgi” değildir; takvim farklılıkları, kısıtlar ve bölünmüş çalışma gibi etkenlerle kritik yol birden fazla kola ayrılabilir. Bu nedenle kritik yol analizi, yalnızca renk okumak değil, çizelgeleme kurallarını anlamaktır.

CPM Mantığı: Süre, Ağ Mantığı ve Tarihler

Critical Path Method (CPM), görevleri bir ağ (network) gibi ele alır. Her görevin bir başlangıç ve bitiş tarihi vardır; bu tarihler bağımlılıklar ile birbirine bağlanır. MS Project varsayılan olarak “olabildiğince erken” planlama (ASAP) yaklaşımıyla, bağımlılıklar ve takvim uygunluğu doğrultusunda görevleri en erken tarihe yerleştirir.

Bolluk (Slack) Kavramı: Serbest ve Toplam

Serbest bolluk, bir görevin ardıl görevleri etkilemeden gecikebileceği süreyi ifade eder. Toplam bolluk ise proje bitişini etkilemeden gecikebileceği süreyi gösterir. Kritik yol analizinde temel gösterge toplam bolluktur; fakat serbest bolluk düşükse “gizli risk” oluşur: görev proje bitişini etkilemese bile ardıl zinciri sıkıştırabilir.

Bağımlılıklar: Doğru Türü Seçmek Neden Hayati?

Görev bağımlılıkları, planın omurgasıdır. Yanlış bağımlılık türü seçildiğinde MS Project tarihler üretir ama mantık hatalıdır. Bu durum en sık, “her şeyi Finish-to-Start yapalım” refleksiyle ortaya çıkar. Oysa gerçek hayatta paralel ilerleyen işler ve kontrol noktaları vardır.

FS, SS, FF, SF: Ne Zaman Hangisi?

• Finish-to-Start (FS): Ardıl görev, öncül görev bitince başlar. Klasik ardışık akış.
• Start-to-Start (SS): Ardıl görev, öncül görev başlayınca başlar. Paralel başlatma.
• Finish-to-Finish (FF): Ardıl görev, öncül görev bitince biter. Bitişleri senkronlamak için.
• Start-to-Finish (SF): Ardıl görev, öncül görev başlayınca biter. Nadir kullanılır (ör. vardiya devri).

Örneğin “Geliştirme” ile “Test Hazırlığı” çoğu zaman SS bağımlıdır; test ekibi geliştirme başlar başlamaz hazırlık yapabilir. “Dokümantasyon” ise FF ile, geliştirme biterken aynı anda tamamlanacak şekilde kurgulanabilir.

Gecikme (Lag) ve Önleme (Lead) Ayarlarını Mantıklı Kullanmak

MS Project’te bağımlılığa pozitif gecikme (lag) veya negatif gecikme (lead) ekleyebilirsiniz. Örneğin teslimat sonrası 2 gün kurulum beklemek için FS+2g gibi bir gecikme uygundur. Negatif gecikme ise çoğu ekipte izlenebilirliği zorlaştırır; bunun yerine işi iki göreve ayırmak (ör. “Hazırlık” ve “Uygulama”) daha şeffaf olur. Yine de zorunlu durumlarda, lead/lag değerlerini net gerekçe ile kullanın ve raporlayın.

Takvim Yönetimi: Proje, Kaynak ve Görev Takvimleri Nasıl Çakışır?

MS Project’te tarihler yalnızca “süre” ile oluşmaz; takvimler tarihin gerçek belirleyicisidir. Proje takvimi, kaynak takvimi ve görev takvimi aynı anda devrede olabilir ve en kısıtlayıcı olan kazanır. Bu yüzden “3 gün sürer” dediğiniz iş, aslında 5 iş gününe yayılabilir.

Proje Takvimi: Varsayılan Çalışma Zamanı

Proje takvimi, çalışma günleri, resmi tatiller ve varsayılan mesai saatlerini belirler. Örneğin şirketiniz Cuma yarım gün çalışıyorsa, takvim bunu yansıtmalı; aksi halde süre hesapları tutarlı görünür ama saha gerçekliğiyle çelişir. Proje takvimini erken aşamada netleştirmek, kritik yol hesaplarını da stabilize eder.

Kaynak Takvimleri: İzinler, Vardiyalar ve Gerçek Kısıtlar

Kaynak takvimleri, kişinin izinleri, vardiya düzeni veya bölüm bazlı çalışma saatlerini temsil eder. Aynı görev, farklı kaynak atanınca tarih değiştiriyorsa bunun nedeni çoğu zaman kaynak takvimidir. Bu etkiyi “kötü sürpriz” olmaktan çıkarıp yönetilebilir hale getirmek için kaynakların izinlerini ve kapasite kısıtlarını planın başında işleyin.

MS Projectte Kritik Yol Analizi: Görünümler, Filtreler ve Sahaya Yakın Kontrol

Kritik yol analizi için ilk adım, kritik görevleri görünür kılmaktır. Gantt Chart üzerinde kritik çubuklar öne çıkar; ancak tek başına yeterli değildir. Ölçülebilir kontrol için bolluk alanlarını tabloya eklemek, kritikliği “neden-sonuç” ilişkisiyle okumayı sağlar.

Kritik Görevleri ve Bolluk Alanlarını Görünür Hale Getirme

Gantt görünümünde “Total Slack”, “Free Slack”, “Constraint Type” ve “Constraint Date” alanlarını ekleyin. Ardından “Kritik” filtreleri veya grup görünümüyle kritik zinciri ayrıştırın. Böylece bir görevin kritik olmasına neden olan etkeni (kısıt mı, takvim mi, ağ mantığı mı) hızlıca teşhis edebilirsiniz.

Ayrıntılı Gantt ile Gecikmeleri ve Kritikliği Aynı Anda Okumak

Detail Gantt benzeri görünümler, bolluk ve gecikmeleri çubuk üzerinde görselleştirerek “nerede tampon var” sorusuna hızlı yanıt verir. Özellikle çok bağımlı projelerde, “kritik olmayan ama tamponu az” görevler risk yaratır. Bu görevler için erken uyarı kurmak, son dakika paniklerini azaltır.

Örnek: Özel Alan Formülü ile Kritikliği Daha Net Etiketlemek

Varsayılan kritik tanımı (Total Slack=0) bazı senaryolarda yeterli olsa da, sizin ekibiniz “1 gün ve altı bolluk” durumunu da kritik saymak isteyebilir. Bunun için bir özel alan (Custom Field) oluşturup, bolluğu eşik değerle etiketleyebilirsiniz.

Özel Alan (Text1) Formülü (mantık örneği):
Eğer TotalSlack <= 1g ise "Kritik/Riskli"
Değilse "Normal"

Uygulama adımları:
1) Project > Custom Fields
2) Text1 alanını seçin
3) Formula veya Lookup ile eşik tanımlayın
4) Gantt tablosunda Text1 alanını gösterin

Bu yaklaşım, kritik yol dışındaki “kırılgan” alanları görünür kılar. Özellikle çok sayıda paralel işin olduğu programlarda, gerçek riskler çoğu zaman kritik yol dışına taşar.

Bağımlılık ve Takvim Kaynaklı Yaygın Hatalar

MS Project’te kritik yolun “garipleşmesine” en sık neden olan şeyler; aşırı kısıt kullanımı, manuel planlama ve takvim çakışmalarıdır. Planı düzeltmeden önce, hatanın kaynağını bulmak gerekir.

Sabit Tarihler ve Kısıtlar: Tarihleri Kilitlemenin Bedeli

“Must Start On / Must Finish On” gibi sert kısıtlar, ağ mantığını devre dışı bırakıp kritik yolu yapay hale getirebilir. Kısıt gerekiyorsa bile, mümkün olduğunca “Start No Earlier Than” gibi esnek kısıtları tercih edin ve kısıtın gerekçesini açıklama alanında not edin. Aksi halde kritik yol, gerçek akışın değil, kilitlenmiş tarihlerinizin ürünü olur.

Manuel Planlama ve Bölünmüş Çalışma: Görünmeyen Kaymalar

Manually Scheduled görevler, otomatik çizelgelemenin kurallarını by-pass edebilir. Bu görevler özellikle bağımlılıklar ile bağlandığında beklenmedik sonuçlar üretir. Eğer proje yönetim standardınız otomatik çizelgeleme ise, manuel görevleri tespit edip ya otomatiğe çevirin ya da izolasyon amaçlı ayrı bir kontrol listesine alın.

İleri Seviye Pratikler: Baz Çizgi, İzleme ve Senaryo Analizi

Planı kurmak kadar, planı izlemek de kritiktir. Kritik yol, ilerleme verisi geldikçe değişebilir. Bu yüzden baz çizgi (baseline) ve düzenli durum güncellemesi olmadan kritik yol analizi “tek seferlik” bir ekran görüntüsü gibi kalır.

Baz Çizgi (Baseline) ile Sapmaları Anlamlandırmak

Baseline, planın “taahhüt edilmiş” versiyonudur. Başlangıç ve bitiş sapmaları, kritik görevlerdeki gecikmelerle birleştiğinde yönetilebilir bir risk tablosu üretir. İyi bir pratik: faz bazında baseline almak, değişiklik yönetimini de kolaylaştırır.

What-if Senaryoları: Takvim ve Bağımlılık Değişikliklerini Güvenle Denemek

Tek bir kaynağın izin planı değiştiğinde veya bir bağımlılık türünü SS yapmak istediğinizde, canlı planı bozmak yerine senaryo kopyasıyla çalışın. Alternatif takvim (ör. fazla mesai) ya da ek kaynak atamasıyla kritik yolun nasıl kısaldığını karşılaştırın. Bu, karar almayı “hissiyat”tan çıkarıp veriye dayandırır.

Örnek: VBA ile Kritik Görevleri Otomatik Vurgulama

Düzenli raporlama yapan ekipler için küçük otomasyonlar ciddi zaman kazandırır. Aşağıdaki VBA örneği, aktif projede kritik görevleri kontrol edip adında bir etiket taşımayanları “CRIT” etiketiyle işaretlemek için bir başlangıç fikridir (kurum standardınıza göre uyarlayın).

VBA (mantık örneği):
Sub TagCriticalTasks()
  Dim t As Task
  For Each t In ActiveProject.Tasks
    If Not t Is Nothing Then
      If t.Critical = True Then
        If InStr(1, t.Name, "CRIT", vbTextCompare) = 0 Then
          t.Name = "CRIT - " & t.Name
        End If
      End If
    End If
  Next t
End Sub

Bu tip bir etiketleme, özellikle dış paydaş raporlarında kritik işleri hızlıca ayırmanıza yardımcı olur. Yine de, otomasyonların planı “kirletmemesi” için standardınızı belirleyin; örneğin etiketleri ayrı bir özel alanda tutmak daha temiz olabilir.

Özetle; kritik yol, yalnızca bir çıktı değil, bağımlılıkların ve takvim kurallarının birlikte ürettiği bir sonuçtur. Bağımlılık türlerini gerçek iş akışına göre seçip takvimleri doğru tanımladığınızda, MS Project çizelgesi güvenilir bir karar destek aracına dönüşür. Konuyu uygulamalı örneklerle pekiştirmek isterseniz MS Project eğitimi sayfasına göz atabilirsiniz.