P6 Activity Type'ları: Herkesin Karıştırdığı Dört Tip

Activity Type, General sekmesindeki tek bir açılır menü. Ayarlamak bir saniye sürüyor ve neredeyse kimse üzerine düşünmüyor. Sonra biri çıkıp soruyor: proje yönetimi aktivitesi neden 400 gün, kimse hiçbir şeye dokunmadığı hâlde bir ekibin süresi neden uzadı, programın yarısında total float neden bu kadar saçma görünüyor? Cevap, çoğu zaman, o açılır menüde.

Primavera P6’da beş tip var: Task Dependent, Resource Dependent, Level of Effort, WBS Summary ve Start/Finish Milestone. İçlerinden iki çift sürekli birbirine karıştırılıyor. Bu yazı o çiftler hakkında.

Task Dependent ile Resource Dependent

İki tip de gerçek işi tarif eder. Fark tek bir soruda: işin ne zaman yapılacağına kimin takvimi karar veriyor?

• Task Dependent — aktivitenin takvimi geçerlidir. Atanmış kaynaklar, kendi takvimleri ne derse desin, aktivite takvimi “çalışılıyor” dediğinde çalışır.
• Resource Dependent — her kaynağın kendi takvimi geçerlidir. Atanmış her kaynak kendi takvimine göre çalışır ve aktivitenin süresi, en az müsait olan kaynağa yetişecek şekilde uzar.

Varsayılan olarak Task Dependent kullanın. İnşaatta ekip, şantiye çalıştığında çalışır. Aktivite takvimi dürüst modeldir; süreler öngörülebilirdir ve programı okuyan bir planlamacı her tarihi açıklayabilir.

Resource Dependent’ı bilinçli kullanın — müsaitliği gerçekten kaynağın belirlediği durumlarda: yalnızca salı günleri gelen bir kontrolör, farklı vardiya düzeninde çalışan uzman bir alt yüklenici, projeler arasında paylaşılan ve rezervasyonla çalışan bir test düzeneği. Bu durumlarda sürenin uzaması bir hata değildir — tam da görmek istediğiniz bilgidir.

Kötü örnek

Denetimlerde en sık rastladığım hasar: birinin programa kaynak yükleyip “artık kaynaklarımız var” mantığıyla her şeyi Resource Dependent yapması. Süreler kendi kendine oynamaya başlar, geçen ayın tarihlerini kimse yeniden üretemez ve planlamacı, yönetimin sorduğu tek soruyu cevaplama yeteneğini kaybeder: bu tarih neden bu?

Kaynak takvimleriniz aktivite takvimiyle birebir aynıysa iki tip aynı davranır — ta ki biri bir kaynak takvimini düzenleyene kadar. O an programın yarısı, kimsenin belgelemediği sebeplerle kayar.

Level of Effort ile WBS Summary

İki tip de kendine ait süresi olmayan işi tarif eder — süreyi başka bir şeyden türetirler. Fark, neyden türettiklerinde.

• Level of Effort (LOE) süresini ilişkilerinden türetir. Onu gerçek aktivitelere bağlarsınız, o da aralarında uzar.
• WBS Summary süresini WBS konumundan türetir. Bulunduğu WBS dalındaki aktivitelerin en erken başlangıcı ile en geç bitişini kapsar — herhangi bir bağlantı olsun ya da olmasın.

LOE ne zaman kullanılır

Başka işler var olduğu için var olan, zamana bağlı işler: şantiye gözetimi, proje yönetimi, geçici tesisler, susuzlaştırma, kalite kontrol mevcudiyeti. İş birimi başına değil, gün başına işleyen maliyetler.

Asıl önemli kural: bir LOE ancak bağlantıları kadar iyidir. Tipik kullanım, ilk gerçek aktiviteden Start-to-Start, son gerçek aktiviteye Finish-to-Finish bağlamaktır. Bunu yanlış yaparsanız, iki yıllık bir işin üçüncü ayında biten ve genel giderlerinizi her dönem sessizce eksik raporlayan bir LOE elde edersiniz.

WBS Summary ne zaman kullanılır

Her zaman bir WBS dalıyla örtüşen bir çubuk istediğinizde ve bunun için bağlantı bakımı yapmak istemediğinizde. Pratiktir — ve tuzak da tam o pratikliktedir: hiçbir şey ona bağlı olmadığı için, süresi değiştiğinde sizi hiçbir şey uyarmaz. Biri bir aktiviteyi başka bir WBS’e taşır, özet çubuk sessizce dört ay büyür ve hiçbir scheduling log’u şikâyet etmez.

Kötü örnekler

• Gerçek aktivite yerine LOE. İşin kendi süresi varsa ve ardıllarını sürükleyebiliyorsa, o bir Task Dependent aktivitedir. LOE aktiviteleri programı sürüklemez; devreye alma fazınızı LOE yapmak onu critical path’ten çıkarır ve tam da göstermeye çalıştığınız riski gizler.
• İlişkisiz LOE. Arasında uzanacağı bir şey yoktur; P6’nın sonrasında raporladığı her şey anlamsızdır.
• WBS Summary’yi ilerleme satırı olarak kullanmak. Tarihleri türetilmiş olduğu için, ona fiziksel ilerleme girmek alttaki işler hakkında hiçbir şey söylemez.
• İkisinden birini DCMA sayımında bırakmak. İkisi de düzgün mantık kontrollerinin dışında tutulur — bir sebebi var. Onları “missing predecessor” sayılarınızda bırakmak bulguları şişirir ve gerçek sorunların görülmesini zorlaştırır.

Milestone’lar, kısaca

Start ve Finish Milestone’ların süresi sıfırdır ve zamanda tek bir noktayı işaretler: sözleşme tarihleri, teslimler, izin onayları, işe başlama talimatları. Korumaya değer iki alışkanlık:

1. Anlamlı olan her yerde, her milestone’a iki taraflı mantık verin. Öncülü olmayan bir sözleşmesel tamamlanma milestone’u süsten ibarettir.
2. Milestone’ları tarih sabitleme aracı olarak kullanmayın. O iş constraint’lerin işidir — ve constraint’lerin kendine ait dertleri var; o da ayrı bir yazının konusu.

Kendi programınızda beş dakikalık bir kontrol

Aktivite listenizi Activity Type’a göre gruplayın ve sayılara bakın. Sağlıklı bir inşaat programında görmeniz gereken tablo şudur: büyük çoğunluk Task Dependent, bir avuç milestone, az sayıda ve bilinçli yerleştirilmiş LOE, çok az ya da hiç WBS Summary — ve Resource Dependent, yalnızca sebebini yüksek sesle söyleyebildiğiniz yerlerde.

Dağılım bundan farklı görünüyorsa çoğunlukla felaket değildir — ama neden öyle göründüğünü bilmek her zaman değerlidir. Ekipte kimse cevap veremiyorsa, bağımsız bir program denetiminin daha ilk öğleden sonra ortaya çıkardığı şey tam olarak budur.