P6 Check Schedule: Her Test Aslında Ne İçin Var?

Primavera P6 Professional, projenize karşı DCMA 14-Point Assessment çalıştıran ve sonuçları ayarlanabilir eşiklerle raporlayan bir program kontrolüyle birlikte gelir. Planlamacıların çoğu bunu keşfeder, bir kez çalıştırır, bir yüzde duvarıyla karşılaşır ve bir daha hiç açmaz.

Yazık — çünkü bu kontroller keyfî bürokrasi değil. Her biri, belirli bir program hatası insanlara tekrar tekrar paraya mal olduğu için var. Bu yazı, her testin aslında neyi aradığı — ve belirli bir projede hangilerinin ilginizi hak ettiği — hakkında.

Nerede duruyor

P6 Professional’da bu kontrol Tools menüsünün altında; projeyi seçer, eşikleri ayarlarsınız ve size geçen/kalan testlerin raporunu üretir. EPPM web istemcisi burada tarihsel olarak geride kaldı — birçok ekibin sırf bu amaçla aynı veritabanına bağlı bir Professional istemcisi tutmasının sebebi de bu.

Eşikler düzenlenebilir. Bu önemli: varsayılanlar ABD savunma tedariki bağlamından geliyor ve onları iki aylık bir duruşa ya da on yıllık bir altyapı programına körü körüne uygulamak, içgörü değil gürültü üretir.

On dört kontrol, cevapladıkları soruya göre gruplanmış

Listeyi on dört madde olarak değil, dört soru olarak ele alırsanız hem akılda tutması hem de yönetime anlatması çok daha kolay olur.

1 — Ağ tamam mı?

Logic, öncülü veya ardılı eksik aktiviteleri sayar. Hedef: %5 veya altı. Bu temel kontroldür, çünkü ardılı olmayan bir aktivite gecikme analizi için görünmezdir — sonsuza kadar kayabilir ve bitiş tarihi kımıldamaz. (Proje başlangıç ve bitiş milestone’ları meşru istisnadır.)

Relationship types, en az %90 Finish-to-Start bekler. FS, bir insanın akıl yürütebildiği ilişkidir. Yoğun SS/FF kullanımı yasak değildir — örtüşen lineer işler buna gerçekten ihtiyaç duyar — ama FS olmayan her bağlantı, programın insanların yanlış okuyacağı biçimde davrandığı bir noktadır.

Leads — negatif lag — sıfır olmalı. Negatif lag “bunu, öncülü bitmeden başlat” der; bu aslında kötü yazılmış bir Start-to-Start ilişkisidir ve kimsenin beklemediği tarihler üretebilir.

Lags %5’in altında olmalı. Lag; sahibi, kaynağı ve ilerlemesi olmayan bir süredir: 7 günlük lag olarak modellenmiş kür süresi, 7 günlük bir hatadan ayırt edilemez. Bekleme gerçek iş ya da gerçek zamansa, dürüst model bir aktivitedir.

2 — Dürüst mü?

Hard constraints sıfır, soft olanlar %5’in altında olmalı — sebepleri constraint yazısında. Bir hard constraint gecikmelerin yayılmasını durdurur; bu da rapordaki diğer her sayıyı güvenilmez hâle getirir.

Negative float sıfır olmalı. Negative float bir modelleme hatası değildir; programın, mevcut planın kendisine verilen bir tarihi tutturamayacağını haykırmasıdır. Hata, var olması değil — “zaten herkes biliyor” diye altı ay çözümsüz bırakılmasıdır.

Invalid dates, geçmişte kalmış tahmin tarihlerini ve gelecekteki actual tarihleri bulur. İkisi de data date ile ilerlemenin uyuşmadığı anlamına gelir ve ikisi de aşağı yöndeki her hesaplanmış tarihi saçmalığa çevirir. Beş dakikalık bir düzeltmedir ve aylık güncellenen bir program için listedeki en yüksek değerli kontroldür.

High float, 44 iş gününden fazla total float taşıyan aktiviteleri işaretler. Bu genellikle bir float sorunu bile değildir — başka bir yerde kendini gösteren bir eksik mantık sorunudur. High float’lı aktivitelerin peşine düşün; Logic kontrolünün kaçırdığı açık uçları bulursunuz.

3 — Gerçekçi mi?

High duration, 44 iş gününü aşan kalan süreleri işaretler. Uzun çubuklar ilkesel olarak yanlış değildir, ama ölçülemezler: iki ay süren bir aktivite, sahada ne olursa olsun haftalarca aynı “%50”yi raporlar. İşin doğal aşamaları neredeyse, orada bölün.

Resources, süresi olan aktivitelerin kaynak veya maliyet taşıyıp taşımadığına bakar. Yalnızca program gerçekten kaynak yüklüyse anlamlıdır — değilse bu test gürültüdür ve her ay mazeret üretmek yerine kapatılması gerekir.

Critical path test en zekice olanı — ve en az kullanılanı. Kritik bir aktiviteye büyük bir gecikme enjekte edip yeniden hesaplatırsınız: proje bitişi aşağı yukarı aynı miktarda kaymalıdır. Kaymıyorsa critical path bir yerde kopuktur — genellikle bir constraint ya da eksik bir bağlantı yüzünden. Ağınızın gerçek bir model olup olmadığına dair tek başına en iyi sağlama budur ve projenin bir kopyasında iki dakika sürer.

4 — Yolunda mıyız?

Missed tasks, data date’e kadar bitmesi gerekip bitmemiş aktiviteleri sayar — beklenti %5’in altıdır.

CPLI (Critical Path Length Index), kalan critical path uzunluğunu eldeki süreyle karşılaştırır. 1.0 tam zamanında bitiş demektir; 0.95’in altı, yolun artık sığmadığı anlamına gelir.

BEI (Baseline Execution Index), fiilen tamamlanan işleri baseline’ın “şimdiye kadar tamamlanmış olmalı” dediği işlerle karşılaştırır. 0.95’in altı, tahmin tarihleri ne iddia ederse etsin planın gerisine düştüğünüz anlamına gelir.

Yönetimin önüne konmaya değer iki sayı CPLI ve BEI’dir; çünkü “program iyi görünüyor” cümlesini, trendi izlenebilen iki orana çevirirler.

On dört madde, tek tek — eşikler ve çareler

Yukarıdaki anlatı neden kısmıydı. Aşağıdaki ise çalışma referansı: eşik, P6’da nereden bakılacağı ve sorunu gerçekte neyin çözdüğü. Numaralama standart DCMA sırasını izliyor.

1 · Logic — öncülü veya ardılı eksik olanlar %5’in altında. Kontrol: Predecessors = 0 OR Successors = 0 koşullu bir Activities filtresi; gerçek başlangıç ve bitiş milestone’ları hariç. Çare: gerçekte var olan ilişkiyi ekleyin. Sayıyı temizlemek için toptan SS/FF bağlantısı dağıtmayın — bir aktiviteye hiçbir şey bağlı değilse ve o da hiçbir şeye bağlı değilse, önce programda yeri var mı diye sorun.

2 · Leads — sıfır. Kontrol: Relationships sekmesi, lag sıfırın altında olacak şekilde filtreli. Çare: her lead’in meşru bir mantık alternatifi vardır. Öncülü bölün ya da pozitif lag’li Start-to-Start kullanın.

3 · Lags — ilişkilerin %5’inden az. Kontrol: aynı görünüm, lag sıfırın üstünde. Çare: bekleme gerçekse — kür, kuruma, izin onayı — onu kimsenin sahiplenmediği bir lag olarak değil, takip edebileceğiniz süreli bir aktivite olarak modelleyin.

4 · Relationship types — en az %90 Finish-to-Start. Kontrol: Relationships görünümünü tipe göre gruplayıp sayın. Çare: gerçek örtüşmeyi modelleyen SS/FF çiftlerini koruyun; alışkanlıktan konulanları sökün.

5 · Hard constraints — sıfır hard, %5’in altında soft. Kontrol: Primary Constraint kolonunu ekleyip sıralayın. Çare: hard’ı soft ile, daha iyisi mantıkla değiştirin. Microsoft Project’ten dönüştürülmüş programlar bu konuda en kötüsüdür — MSP’nin otomatik constraint’leri temiz çevrilmez; her aktivitesinde baseline tarihine çakılmış bir Start No Earlier Than taşıyan dosyalar devraldım.

6 · High float — 44 iş günü üzeri total float %5’in altında. Kontrol: Total Float değeri 44’ün üzerindekileri filtreleyin, tamamlanmış aktiviteler hariç. Çare: her high-float aktiviteyi ileri doğru izleyin; onunla bitiş milestone’u arasında bir yerde eksik bir bağlantı vardır. Milestone’a bağlanmış ama beslediği montaja bağlanmamış satın alma, klasik örnektir.

7 · Negative float — sıfır. Kontrol: Total Float değeri sıfırın altındakileri filtreleyin. Çare: buna yol açan constraint’i ya da dayatılmış tarihi bulun. Ya tarih oynar, ya mantık değişir, ya da ekip gecikmeyi kabul eder. Sayı kaybolsun diye constraint’i silmek, programın size vermeye çalıştığı tek bilgiyi yok eder.

8 · High duration — kalan süresi 44 iş gününü aşanlar %5’in altında. Kontrol: Original Duration değeri 44’ün üzerinde ve durumu tamamlanmamış olanları filtreleyin. Çare: ayrıştırın. “Ekipman imalatı”; çizim teslimi, faz 1 imalat, fabrika kabul testi olur — her biri bağımsız ölçülebilir.

9 · Invalid dates — sıfır. Kontrol: data date’ten önceki tahmin tarihleri, data date’ten sonraki actual tarihler. Çare: beş dakikalık statusing disiplini. Listedeki en ucuz kontroldür ve aşağı yönündeki her şeyi en sık geçersiz kılan da odur.

10 · Resources — süresi olan aktiviteler kaynak veya maliyet taşır. Kontrol: Budgeted Units veya Budgeted Cost sıfır olanları filtreleyin. Çare: hızlı bir iş değil — önce büyük kalemleri yükleyin (ana işçilik, kilit ekipman). Program bilinçli olarak kaynak yüklü değilse, her ay mazeret üretmek yerine kontrolü kapatın.

11 · Missed tasks — %5’in altında. Kontrol: Baseline Finish değeri data date’ten önce olup durumu tamamlanmamış olanlar. Çare: bu bir uygulama ya da statusing sorunudur, planlama sorunu değil. Sayıyı temizlemek için rebaseline yapmak, kapsam gerçekten değişmediyse dürüstlükten uzaktır.

12 · Critical path test — enjekte edilen gecikme yayılmalı. Kontrol: bir kopyada, kritik bir aktivitenin kalan süresine 20 iş günü ekleyip yeniden hesaplatın; bitiş yaklaşık 20 gün kaymalı. Çare: kaymıyorsa critical path boyunca constraint’leri, open end’leri ve takvim uyumsuzluklarını ayıklayın. Çalıştırması iki dakika — ve listedeki tek başına en iyi sağlama.

13 · CPLI — 0.95’in üzeri. Critical Path Length Index = (critical path uzunluğu + total float) / critical path uzunluğu. 0.95’in altında, tarihi tutmak için kalan critical path’i %5’ten fazla sıkıştırmanız gerekir. Kontrol: longest path ve tamamlanma milestone’undaki float üzerinden elle hesap.

14 · BEI — 0.95’in üzeri. Baseline Execution Index = fiilen tamamlanan işler / baseline’a göre şimdiye kadar tamamlanmış olması gereken işler. 0.95’in altı, tahmin tarihleri ne derse desin geride kaldığınız anlamına gelir.

Sonuçları boğulmadan kullanmak

Bunları yıllarca başkalarının projelerinde çalıştırmaktan kalan üç alışkanlık:

1. Önce invalid dates ve negative float’ı düzeltin. Onlar temizlenene kadar diğer her yüzde, gerçeği tarif etmeyen bir programı ölçüyordur.
2. Raporu not olarak değil, teşhis olarak okuyun. On dört kontrolden geçmek bir programı iyi yapmaz — kusursuz puan alıp işi sahanın asla inşa edemeyeceği bir sırayla modelleyen programlar denetledim. Kontroller mekanik arızaları bulur; sıralamanın mantıklı olup olmadığını söyleyemezler.
3. Eşikleri bir kez, bilinçli ayarlayın ve gerekçesini yazın. Herkesin görmezden gelmeyi öğrendiği bir program kontrolü, hiç kontrol olmamasından kötüdür.

O ikinci madde, her otomatik kontrolün dürüst sınırıdır — ve bağımsız bir sistem ve program denetiminin tam da on dört maddenin bittiği yerden başlamasının sebebi budur: ağ, işin gerçekte nasıl inşa edileceğini tarif ediyor mu?