P6 Program Sağlığı Kontrolü DCMA 14 Maddede Bitmemeli

DCMA Tuzağı

DCMA 14-Point Assessment, program sağlığında altın standart haline geldi. Olması da gerekiyordu — gerçek sorunları yakalıyor. Eksik logic, negatif float, hard constraint’ler, süresi aşırı uzun activity’ler, açıkta kalan start ve finish’ler. Metrikleri çalıştır, eşikleri kontrol et, raporu üret.

Ama 14 maddenin hepsini geçtiği halde temelden bozuk programlar inceledim.

Geçen yıl 3,4 milyar dolarlık bir ulaştırma programında yüklenicinin programı her DCMA metriğinde yeşildi. Negatif float yok. Predecessor ya da successor’ı olmayan tamamlanmamış activity oranı yüzde 5’in altında. Constraint oranı eşiğin altında. Program kâğıt üzerinde sağlıklı görünüyordu. Pratikte proje ekibinde ona güvenen kimse yoktu. İlerleme güncellemeleri üç hafta gerideydi. Resource yüklemesinin sahadaki fiili iş gücüyle hiçbir bağlantısı yoktu. WBS yapısı, maliyetleri program activity’lerine eşlemeyi imkânsız kılıyordu.

Temiz bir DCMA skoru programın teknik olarak uyumlu olduğunu söyler. İşe yaradığını söylemez.

14 Maddenin Kaçırdıkları

1. Takvim Tutarlılığı

Bu madde, zamanla birikerek büyüyen sinsi sorunlar üretir.

47 farklı takvimi olan P6 veritabanları açtım. 5 günlük çalışma haftasındaki activity’ler, 7 günlük takvimdeki successor’ları sürüklüyor. 2022’den beri güncellenmemiş tatil takvimleri. Birinin bir duruş için oluşturduğu “shutdown takvimi”, şimdi kazara 200 inşaat activity’sine atanmış durumda.

DCMA değerlendirmesi takvimlerinizin birlikte anlamlı olup olmadığına bakmaz. Logic’e ve float’a bakar — 5 günlük bir predecessor’ın 7 günlük bir successor’ı beslerken gerçek bir planlama çatışmasını maskeleyen hayali float üretip üretmediğine bakmaz.

Ne kontrol etmeli: P6’dan bir takvim raporu çekin. Kullanımdaki her takvimi, her birine atanmış activity sayısını ve haftalık çalışma saatlerini listeleyin. Son 12 ayda gözden geçirilmemiş her takvimi işaretleyin. Tatil tarihlerinin güncel olduğunu doğrulayın. Takvim atamalarının, işi yapan ekiplerin fiili çalışma düzeniyle örtüştüğünü teyit edin.

2. WBS Yapısının Kalitesi

WBS, programın iskeletidir. Çarpıksa üzerine kurulan her şey — raporlama, kazanılmış değer (EV), resource toplulaştırması — sakatlanır.

Mekanik dalında 12 seviye, elektrik dalında 2 seviye derinliğinde bir WBS gördüm. Maliyet hesaplarıyla örtüşmediği için EV hesaplarını anlamsızlaştıran iş paketleri. “Eski program böyle kurulmuştu” diye oluşturulmuş, hiçbir gerçek amacı olmayan özet seviyeleri.

Ne kontrol etmeli: WBS’i projenin iş kırılım yapısı sözlüğüyle (varsa) eşleyin. WBS seviyelerinin disiplinler arasında tutarlı olduğunu doğrulayın. En alt WBS seviyesinin kontrol edilebilir iş paketlerine karşılık geldiğini teyit edin. Her WBS düğümünde en az bir activity olduğunu kontrol edin — boş WBS dalları gereksiz kalabalıktır.

3. Resource Oranlarının Doğrulanması

Saati 0 dolardan yüklenmiş resource’lar. Üç yıl önce orijinal baseline kurulduğundan beri güncellenmemiş oranlar. İşçilik oranı taşıyan ekipman resource’ları. 400 activity’ye atanmış bir “TBD” resource’u.

DCMA resource bütünlüğünü değerlendirmez. Resource yüklenip yüklenmediğine bakar (ona da gevşek biçimde). Yüklemenin anlamlı olup olmadığına bakmaz.

Bir petrol ve gaz projesinde programın 120.000 saat kalan işçilik gösterdiğini gördüm. Proje kontrol ekibi kendi bağımsız tahminine dayanarak tamamlanmaya 85.000 saat raporluyordu. Fark, 18 aylık program güncellemeleri boyunca birikmiş oran tablosu hatalarından ve mükerrer resource atamalarından geliyordu. Bir yıldan uzun süredir kimse programın resource verisini maliyet sistemiyle mutabakata sokmamıştı.

Ne kontrol etmeli: Resource atamalarını ve oranları dışarı aktarın. Disiplin bazında toplam bütçelenmiş saatleri maliyet tahminiyle karşılaştırın. Oranı 0 dolar olan resource’ları, aynı activity üzerindeki mükerrer atamaları ve oranı baseline’dan beri hiç değişmemiş her resource’u işaretleyin.

4. Baseline Bütünlüğü

Program adli incelemesinin program sağlığıyla buluştuğu yer.

Sözleşmenin notice to proceed tarihinden önceki tarihlerle baseline’lanmış activity’ler. Açıkça iş gerektiren activity’lerde sıfır baseline süresi. Yürütmenin altıncı ayında mevcut program kopyalanarak kurulmuş — yani tüm sapmayı fiilen silmiş — bir “current baseline”.

Yüklenicinin iki yılda dört kez re-baseline yaptığı bir program inceledim. Gerekçe her seferinde “onaylı kapsam değişikliği”ydi. Her seferinde, aylarca birikmiş negatif sapma da ne tesadüfse ortadan kalkıyordu. Son baseline’a göre DCMA metrikleri gayet iyi görünüyordu. Oysa projenin orijinal bitiş tarihi 14 ay kaymıştı ve baseline geçmişini kazımadan bunu göremiyordunuz.

Ne kontrol etmeli: Mevcut baseline’ı orijinal baseline (BL-0) ile karşılaştırın. Her re-baseline olayını gerekçesiyle belgeleyin. Baseline tarihlerinin sözleşmesel performans dönemi içinde kaldığını doğrulayın. Baseline finish’i mevcut data date’ten sonra olduğu halde yüzde sıfır tamamlanmış görünen activity’lere bakın — gerçekten mi başlamadılar, yoksa ilerlemeleri mi girilmemiş?

5. Kodlama Yapısı

Activity kodları, bir P6 programının filtreleme ve raporlama omurgasıdır. Tutarsız olduklarında onlara dayanan her rapor güvenilmezleşir.

Örüntü hep aynı: activity kodlarını proje mobilizasyonu sırasında biri kurar. O kişi ayrılır. Sonraki planlamacı kendi kodlarını ekler. Üçüncü planlamacı kodları tamamen yok sayar. İki yıl sonra elinizde 15 activity code türü vardır; bunların 6’sı fiilen kullanılıyordur ve hiçbiri tutarlı biçimde atanmamıştır.

Ne kontrol etmeli: Tüm activity code türlerini ve değerlerini listeleyin. Her kod türü için değer atanmış activity yüzdesini ölçün. Yüzde 90’ın altındaki her atama oranı şüphelidir. 5’ten az activity’si olan kod değerlerine bakın — bunlar çoğunlukla yazım hatası ya da terk edilmiş kategorilerdir. Kod atamalarının WBS yapısıyla uyumlu olduğunu ve çelişki üretmediğini doğrulayın.

6. Constraint Mantığı

DCMA hard constraint’lere bakar ve constraint oranını ölçer. Bu gerekli. Ama asıl soru “kaç constraint var?” değil — “her bir constraint neden orada?”

Planlamacı logic’i çözemediği için konmuş Mandatory constraint’ler. Teklif aşamasında girilmiş, sözleşme imzalandıktan sonra hiç güncellenmemiş “Start On” constraint’leri. Proje müdürü “tarihleri tutmak” istediği için her milestone’a konmuş “Finish No Later Than” constraint’leri.

Gerekçesiz constraint’ler kaldırılınca o güne dek görünmez kalmış 60 günü aşkın negatif float’ın ortaya çıktığı programlar temizledim. Program yeşil raporluyordu. Proje aslında iki ay gerideydi.

Ne kontrol etmeli: Her constraint’i dışarı aktarın. Her birini sınıflandırın: sözleşmesel milestone, dış bağımlılık, mevzuat gereği ya da “bilinmiyor”. “Bilinmiyor” kategorisindeki her constraint araştırılmayı bekliyor demektir. Constraint’lerinizin yüzde 20’sinden fazlası gerekçelendirilemiyorsa, bir logic bütünlüğü sorununuz var.

7. İlerleme Metodolojisi

Percent complete nasıl hesaplanıyor? Tek başına bu soru, herhangi bir DCMA metriğinden daha fazla program sorunu ortaya çıkardı.

Duration percent complete — P6’nın task’ler için varsayılanı — ilerlemeyi actual start ile remaining duration arasında geçen zamana göre hesaplar. Physical percent complete elle giriş ister. Bazı planlamacılar otomatik diye her şeyde duration percent kullanır. Sonuç: 6 ay önce başlamış 12 ay süreli bir activity, fiili ilerlemeden bağımsız olarak yüzde 50 tamamlanmış görünür.

Bir enerji santrali projesinde, physical percent’in uygun olacağı yerlerde duration percent complete kullanan 300’den fazla activity buldum. Program yüzde 67 tamamlanmış gösteriyordu. Saha ekibinin fiziksel ilerleme değerlendirmesi yüzde 54’tü. O 13 puanlık fark, kabaca 40 milyon dolarlık bir kazanılmış değer (EV) yanlış beyanına karşılık geliyordu.

Ne kontrol etmeli: Activity bazında percent complete türü raporu alın. Süresi 20 günü aşan ve duration percent kullanan her activity’yi işaretleyin — bunların neredeyse tamamı physical percent ya da units percent istiyor. Actual start tarihi olduğu halde yüzde 0 görünen ya da actual finish tarihi olmadan yüzde 100 görünen activity’lere bakın. İkisi de veri bütünlüğü hatasına işaret eder.

Organizasyon Katmanı

Yukarıdaki teknik kontroller program verisindeki sorunları bulur. Ama bir program boşlukta yaşamaz — o sorunların düzelmesini ya da büyümesini belirleyen bir organizasyon bağlamının içinde yaşar.

Yönetişim Olgunluğu

Programın sahibi kim? Teoride değil — pratikte. Bir logic değişikliğini onaylama, activity ekleme ya da constraint değiştirme yetkisi kimde? Sağlıklı projelerde cevap nettir. Sağlıksızlarda hem herkes hem hiç kimse.

Prosedüre Uyum

Bir planlama prosedürü var mı? Uygulayan var mı? 80 sayfalık, onaylandıktan sonra bir daha hiç açılmamış planlama prosedürleri inceledim. Prosedür ancak planlamacıların gerçekten uygulayabileceği kadar pratikse işe yarar.

Kullanıcı Yetkinliği

Planlamacılar kendi logic’lerini açıklayabiliyor mu? Bu soruyu her sağlık kontrolünde sorarım. Rastgele bir activity seçin, planlamacıya predecessor ve successor’larının neden öyle olduğunu sorun. Programı açmadan açıklayamıyorsa, logic muhtemelen düşünülerek değil mekanik olarak kurulmuştur.

Değişiklik Yönetimi

Kapsam değişiklikleri programa nasıl yansıyor? Activity eklemek için resmi bir süreç mi var, yoksa proje müdürü toplantıda söyleyince planlamacı ekleyiveriyor mu? Silinen activity’ler gerçekten kaldırılıyor mu, yoksa yüzde 0 tamamlanmış, “Not Started” statüsünde öylece duruyorlar mı?

Bir Sağlık Kontrolü Programı Kurmak

Tek seferlik bir program sağlığı kontrolü sorunları bulur. Bir sağlık kontrolü programı sorunları önler.

Aylık: Otomatik Metrikler

DCMA 14 maddesini ve birkaç ek otomatik kontrolü çalıştırın — takvim tutarlılığı, kod kapsaması, constraint sınıflandırması. Bunlar betiklenebilir ya da P6’nın yerleşik Check Schedule özelliğinden çekilebilir. Bir pano üretin. Trendleri izleyin. Ay be ay kötüleşen bir program, krize dönüşmeden müdahale ister.

Üç Aylık: Derin İnceleme

Yukarıdaki maddelerin elle incelenmesi — WBS yapısı, resource bütünlüğü, baseline sadakati, ilerleme metodolojisi. Bu, rapor çalıştırmakla değil, nitelikli bir planlamacının program verisiyle 2-3 gün geçirmesiyle olur. Planlama ekibiyle görüşün. Son logic değişikliklerinin üzerinden geçin. Programın anlattığı hikâyeyi projenin fiili durumuyla karşılaştırın.

Yıllık: Organizasyon Değerlendirmesi

Yönetişim, süreç ve yetkinlik boyutlarını değerlendirin. Planlama prosedürleri güncel mi? Uygulanıyor mu? Planlamacıların eğitime ihtiyacı var mı? Kurumun elinde doğru araçlar ve şablonlar var mı?

Sağlık Kontrolü Raporu

İşe yarar bir sağlık kontrolü raporunun dört bölümü vardır:

1. Yönetici Özeti — Genel sağlık notu (Kırmızı/Sarı/Yeşil), en önemli 3 bulgu, önerilen acil aksiyonlar.
2. Metrik Panosu — DCMA 14 maddesi artı genişletilmiş metrikler, gidişatı gösteren trend verisiyle.
3. Ayrıntılı Bulgular — Her sorun; önem derecesi, kanıtı (belirli activity’ler ya da veriler), kök nedeni ve önerisiyle belgelenmiş.
4. İyileştirme Yol Haritası — Efor tahminleri ve sorumlularıyla önceliklendirilmiş aksiyonlar.

Rapor doğrudan olmalı. “Programda activity code ataması olmayan 847 activity var; bu, disiplin bazlı raporlamayı güvenilmez kılıyor” demek, “activity kodlaması iyileştirilebilir” demekten daha yararlıdır. Somutluk hesap verebilirlik yaratır.

Hedeflemeye Değer Standart

14 maddeyi geçen bir program, asgari standartları karşılayan bir programdır. Sağlıklı bir programsa insanların gerçekten güvendiği ve karar almak için kullandığı programdır.

Haftalık planlama toplantısının haftanın en verimli saati olduğu projelerde çalıştım — çünkü program gerçeği yansıtıyordu, ekip onu anlıyordu ve kararlar güvenle alınabiliyordu. Programın duvara yansıtılıp sistematik biçimde yok sayıldığı toplantılarda da oturdum; salondaki herkes onun kurgudan ibaret olduğunu biliyordu.

Farkı yaratan DCMA skoru değildi. Geri kalan her şeydi.

Geçer not ile insanların güvendiği program arasındaki o boşluk, tam olarak bir sistem ve program denetiminin konusu — on dört kontrolün kendisi ise yalnızca başlangıç noktası.