İş programının sağlığı: DCMA 14 nokta kontrolünü uygulamak

DCMA 14 nokta kontrolü nedir, ne işe yarar

DCMA 14 nokta değerlendirmesi, ABD savunma sözleşmelerini izleyen kurum DCMA ile anılan, bir iş programının teknik yapısını ve planın uygulanabilirliğini ölçen 14 kontrolden oluşur. Amaç, programda gizli kalmış zayıflıkları yürütme başlamadan görmektir: bağlanmamış görevler, tarihi sabitleyen kısıtlar, aşırı uzun işler, gerçek dışı tarihler.

Bu kontroller savunma sektörüne özgü olmaktan çıkıp inşaat, enerji ve altyapı gibi büyük programlarda sözleşme şartnamelerine ve program denetim raporlarına girmiştir. Primavera P6 ya da MS Project gibi bir araçta hazırlanan programın üzerinde, aracın kendi hesabından bağımsız bir sağlık kontrolü sunar.

Kontrol sonucunun geçmek ya da kalmak olarak okunması yanıltıcıdır. Uygulamada kontroller, programı inceleyecek kişiye nereye bakması gerektiğini söyleyen bir tarama listesi işlevi görür. Programı sunan ekip için asıl değer, bulguların bir plana düşüp düzeltilmesidir.

Kontrolleri yönlerine göre okumak

14 kontrolü sırayla ezberlemek yerine hangi soruyu sorduklarına göre gruplamak daha kolaydır. • Mantık ve ilişkiler: Bağlantısız görev var mı, lead ve lag ne kadar kullanılmış, ilişkiler çoğunlukla bitiş-başlangıç türünde mi? • Kısıt ve süreler: Sert kısıtlar tarihleri sabitliyor mu, bolluk uç değerlerde mi, çok uzun görevler var mı, tarihler tutarlı mı? • Kaynaklar: Kaynak ya da maliyet atanmayan görevler var mı? • Yürütme göstergeleri: Taban plana göre kaçırılan görevler var mı, kritik yol sınanıyor mu, hedefe yetişme verimliliği ve taban plana uyum nasıl?

Gruplar birbirine dayanır. Mantık eksikse bolluk değerleri anlamsızdır; kısıtlar sertse kritik yol gerçeği göstermez. Bu yüzden kontroller yapıdan yürütmeye doğru sırayla okunur.

14 kontrol ve her birinin anlamı

• Mantık: Öncülü ya da ardılı olmayan açık görevler. Bağlantısız iş, takvimden etkilenmez ve gecikmeyi göstermez.
• Lead: Ardılın öncül bitmeden başlaması. Gerçekçi olmayan bindirmeleri gizleyebilir.
• Lag: Öncül bitince ardılın başlamadan önce beklemesi. Bekleme çoğunlukla ayrı bir görev olarak görünür kılınmalıdır.
• İlişki türleri: Programın büyük bölümü bitiş-başlangıç ilişkisiyle kurulmalıdır; başlangıç-bitiş türü ise istisnadır.
• Sert kısıtlar: Görevi sabit bir tarihe bağlayan kısıtlar, bağımlılık mantığının üstüne çıkar.
• Yüksek bolluk: Çok fazla toplam bolluğu olan açık görevler genellikle eksik bağ işaretidir.
• Negatif bolluk: Bir görev ya da kısıt yüzünden tarihe yetişilemiyor demektir; çözüm gerektirir.
• Yüksek süre: Çok uzun açık görevler, ilerlemeyi izlenebilir kılmak için alt görevlere bölünmelidir.
• Geçersiz tarihler: Geçmişte kalan tahmini tarihler ya da gelecekte görünen gerçekleşmeler.
• Kaynaklar: Kaynak ya da maliyet bağlanmamış görevler, iş yükü ve maliyet çözümlemesini eksik bırakır.
• Kaçırılan görevler: Taban plana göre bitmesi gerekirken bitmeyen işler.
• Kritik yol testi: Kritik bir görevin süresini uzatınca proje bitişi aynı oranda kaymıyorsa mantık kopuktur.
• Kritik yol uzunluk endeksi (CPLI): Hedef tarihe yetişmek için gereken verimliliği, kalan kritik yol ve bolluk ilişkisi üzerinden gösterir.
• Taban plana uyum endeksi (BEI): Taban plana göre bitmesi gereken işlerle gerçekten biten işleri karşılaştırır.

Her kontrolün sayısal bir eşiği olabilir; eşikler kaynaktan kaynağa ve sözleşmeden sözleşmeye değiştiği için burada rakam verilmemiştir. Hangi sınırın geçerli olduğunu şartnameniz ya da müşterinizin program denetim kuralları belirler.

Eşik değerleri nasıl okumalı

Eşikler çoğu kaynakta danışma niteliğinde yönergeler olarak sunulur. Belirli bir oranın üstüne çıkmak programın reddedilmesi anlamına gelmez, ama incelenmesi gerektiği anlamına gelir. Aynı biçimde bir sınırın altında kalmak da programın doğru olduğunu garanti etmez.

Kontroller farklı biçimlerde okunur. Bazılarında oran incelenir: programın ne kadarının bağlantısız, ne kadarının kısıtlı olduğu gibi. Diğerlerinde sıfır beklenir: negatif bolluk ve geçersiz tarih gibi, tek bir örneği bile açıklama gerektiren bulgular. Oran kontrollerinde bulgunun nedeni de önemlidir: tarih sabitleyen bir kısıt, sözleşmeden gelen gerçek bir dış tarih için kullanılıyorsa gerekçesiyle kabul edilir.

Bir bulguyu kabul etmek geçerli bir karardır, ama gerekçesi yazılı olmalıdır. Program denetiminde sorulan şey genellikle rakam değil, o rakamın arkasındaki mantıktır.

Değerlendirmeyi uygulamak

Kontrolü bir seferlik rapor olarak değil, programın her önemli sürümünde tekrarlanan bir rutin olarak kurun. Uygulama akışı şu şekilde ilerler: programın bir kopyasını alıp üzerinde çalışırsınız ki canlı programı bozmayın. Önce mantık taraması yapılır; öncülü ya da ardılı olmayan görevler filtre ve sorgu özellikleriyle bulunur. Sonra kısıtlar, bolluk ve uzun görevler listelenir. Kaynak ve ilerleme kontrolleri ardından gelir. Her bulgu için ya düzeltme ya da gerekçeli kabul kararı yazılır, program yeniden hesaplanır ve kontroller tekrarlanır.

Filtre ve sorgu adları araca göre değişir, bu yüzden yazılımınızın güncel belgesine bakın. Önemli olan, kontrolün programı hesaplayan aracın içinde değil, sonuçları kayıt altına alan ayrı bir tabloda tutulmasıdır; böylece sürümler arasında bulguların azalıp azalmadığı izlenebilir.

Örnek: bir bina projesinin ilk taslak programı

Bir konut projesinin yüklenicisi, ilk taslak programı müşteriye sunmadan önce kontrolden geçiriyor. Tarama, bazı kaba inşaat görevlerinin ardılsız kaldığını, ruhsat ve teslim tarihlerinin dışında da birçok görevin belirli bir tarihe sabitlendiğini ve cephe işinin tek bir uzun kalem olarak girildiğini gösteriyor.

Bağlantısız görevler gerçek ardıllarına bağlandığında bitiş tarihi kaymıyor, ama bolluk dağılımı değişiyor: önceden bolluklu görünen cephe işi artık kritik yola yaklaşıyor. Gereksiz sabitlemeler kaldırılınca mantığın kendisinin tarih ürettiği görülüyor. Cephe işi alt görevlere bölününce ilerleme haftalık izlenebilir hale geliyor. Kritik yol testi, bir kritik görevin süresi uzatıldığında bitişin gerçekten ilerlediğini doğruluyor.

Bu örnekte kontrol, programı süslemedi; hesaplanan tarihe güvenin hangi varsayımlara dayandığını gösterdi. Sunumdan önce yapılan bu temizlik, uygulama sırasındaki yeniden planlama maliyetini düşürür.

Sık yapılan hatalar

• Rakamı düzeltip programı düzeltmemek: Bağlantısız görevi rastgele bir göreve bağlamak, eşiği geçirir ama mantığı bozar.
• Sorunu kısıtla gizlemek: Negatif bolluğu bir tarih kısıtıyla sıfırlamak sorunu çözmez, gerçek gecikmeyi saklar.
• Kritik yol testini atlamak: Bu test, diğer kontrollerin yakalayamadığı kopuk mantığı gösterir.
• Yalnız oran takip etmek: Tek bir negatif bolluk, oranlara bakınca küçük görünür ama çözüm gerektirir.
• Kaynak atamasını boş bırakmak: İş yükü ve maliyet analizi eksik görev üzerinden yapılır.
• Kontrolü yalnız teslimden önce yapmak: Hatalar, düzeltmenin en pahalı olduğu anda ortaya çıkar. Her sürümde tekrarlayın.
• Bulguyu gerekçesiz kabul etmek: Sonradan programı inceleyen kişi neden bırakıldığını anlayamaz.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Mindset'in Primavera P6 ile İş Programı Hazırlama eğitiminde Mantıksal Bağlar ve Kritik Yol Analizi, Baz Plan Yönetimi ve İlerleme Güncelleme ile Sözleşmesel Kullanım ve Program Denetimi modülleri, programın kurulumundan denetlenmesine uzanan hattı ele alır. Planlama uzmanları, proje kontrol ekipleri ve sözleşme tarafında program sunan yükleniciler için konu bu çerçevede çalışılır.