Ülkemizde maalesef planlamanın proje yönetimindeki rolü yavaş yavaş gelişmektedir. Global dünyada her hangi bir proje yönetimi esnasında kalan işler için her zaman bir tahminleme beklenir. Bu tahminlemenin en büyük aracı kaynakları yüklenmiş bir planlamadır. Sonuç olarak planlama denildiğinde akıllara gelen sadece çubuk diagramlar olmamalıdır. Bu diagramlar sadece, “arka planında işin kapsamı ve gereken iş gücünün stratejik olarak düşünülmüş bir iş akışının yansıması” olmalıdır.
Aslında oluşturulan iş programlarının parametreleri düşünüldüğü kadar karışık değildir. Fakat program içinde bu parametrelerin bilinçsiz kullanımı ortaya çıkan ürünün inandırıcılığını kaybetmemesine yol açmaktadır. Buradaki bilinç ancak ve ancak bu parametrelerin yerli yerinde kullanılmasıyla oluşur. Örneğin ms projectte iş programı oluştururken gantt chart üzerindeki bir aktiviteyi sürükleyip bıraktığımızda otomatik olarak başlangıcını bir tarihe sabitlemiş (constraint olmuş) oluruz. Primavera’da is bunu emin misiniz mesaj kutusuyla teyidini sorar. İki programda da bu tip aktiviteleri sabitleme işlemi olur. Burada sıkıntı yürütülen işlemin farkındalığıdır. Sonuç itibariyle hesaplanacak toplam bolluklar ve kritik yollar bu tür hareketlerden etkilenmektedir. Bunun için sadece zamanı bile yönetsek de bilgisayarların bunu nasıl hesapladığını bilmemiz gerekir. Hatta bu konuda planlamacaının yetkinliği kadar, proje yöneticileri de yetkin olmalıdır. Aksi halde iş akışındaki sıkışıklığın tespiti zorlaşır.
Genel olarak aktiviteleri, milestonelar ve süreç gerektiren işler olarak düşünebiliriz. Milestone kavramı, iş programımıza sözleşmede geçen önemli tarihleri belirtmemizde işimize yarar. Her iki programda da milestonelar “0” gün olarak nitelendirilir. Bunlar; iş yer teslimi, avans ödemeleri, iş bitimleri ...vs. gibi proje yönetimi sırasında önemli hak taleplerini (claim) yaparken kullanacağımız önemli tarihler olabilir. Tarafların sorumluluklarının önemli noktaları iş programında olmazsa, sorunun kaynağına inerek hak talebinde bulunulması zorlaşır. Bu projenin tüm tarafları için geçerlidir. İşveren iş bitiminin gecikmesini sorgularken, işi yapan yer teslimindeki gecikmeyi süre uzatımı ve maddi zarar olarak işverenden talep edebilir. Hepsinin takip edileceği nokta iş programı olmalıdır.
Milestonelar kullanırken, bağlı olan iş kalemleri ile arasındaki ilişkilendirmeler de normal aktiviteler gibi yapılmalıdır. Çünkü bu milestonelerının diğer işlere bağlı olarak sürüklenmesi de olasıdır. Yani kontratsal tarihleri, hem bir sabit tarih olarak girebiliriz (constraint), hem de kendisi ile ilgili aktivitelere bağlı olarak gösterebiliriz. Kendisine bağlı olan işler yapılmazsa bu milstone’umuz ilerleyecektir. “start on or after” ya da “start no earlier than” constraintleri kullanılmış olsa bile. Bu bize ileride ilgili işler ile alakalı hak talebi yaparken yardımcı olacaktır. Çünkü bu tarz hak taleplerinde anlaşılır olmak şarttır. Talebe hakkını teslim edecek makam kendisinin kandırılmadığına ikna olmalıdır. Buradaki psikolojiyi iyi anlamak gerekir.
Aktivitelerin iş programındaki rolü sadece iş kaleminin süreci ile alakalı değildir. Her bir aktivite kendi çapında bir proje gibi algılanmalıdır. Başlangıcı belirli şartlara dayanan, süreci kapsamındaki iş miktarına ve eldeki iş gücüne bağlı ve de maliyeti olan bir proje gibidir. O nedenle süreçler irdelenirken bu şekilde düşünüldüğünde yapılacak bağlantı tipleri ve ötelemeleri (lag) bir kez daha düşünülmelidir. Aksi halde gelişi güzel bağlanmış aktivitelerde, sahadaki gerçekleşmeler bağlantı tiplerine göre olmadığında, bol bol sıra dışı gerçekleşmeler (out of sequence tip aktiviteler) ile karşılaşmaktayız. Buradan çıkan sonuç “hiç birşey planlandığı gibi gitmemektedir”. Bu da planlama raporlarının etkisini önce azaltacaktır. Ardından proje yönetimince yok sayılacaktır. Bu tip durumlarda planlama şirketin sadece ve sadece kalite yönetim sertifikasını almak için denetçi firmaya gösterdiği, yalandan ibaret olan bir belgeye dönüşecektir.
Burada eksik olan nokta ekip olarak iş programının hazırlanmasında çalışmaların yapılmamasıdır. Çünkü yöneticilerin teknik planlama bilgilerine (burada kastedilen program operatörlüğü değildir) haiz olmaması, bu çalışmayı alt kademelerine nasıl yaptıracağını bilememesine yol açmaktadır. Peki, bu çalışmalar nasıl olmalıdır?
Bu çalışmaları süreçlerin belirlenmesi ve aktivitelerin ilişkilendirilmesi olarak ikiye ayırmak mümkündür.
- Süreçlerin belirlenmesi için ;
- İş kalemlerinin belirlenmesi,
- İş kalemlerinin kapsamının belirlenmesi,
- O kalemi gerçekleştirecek iş gücüne karar verilmesi,
yapılacak aktivitenin sadece sürecinin tahmin edilmesini sağlayacaktır. Burada planlamacının takip edeceği konu ilgili süreçte gereken kaynağın bu iş için ayrılıp ayrılmadığı olacaktır. Gereken kaynak ayrılmıyorsa, zaten süreç baştan aksamaya başlamış demektir.
- Aktivitelerin ilişkilendirilmesi için;
- İş kaleminin başlamasına etki edebeilecek tüm kalemlerin belirlenmesi,
- Bağlantı tiplerinin, kalemlerin türleriyle ilişkilendirilmesi,
- Bağlantı tiplerine eşlik eden ötelemelerin (lag) belirlenmesi,
- Sabitlenecek tarihlerin (constraint) türlerinin ve ilişkilerinin belirlenmesi
Burada sıklıkla yapılan hatalardan biri, birden çok aktiviteye bağlı olarak başlıyacak aktivitenin kendisinden önce başlaması ya da bitmesi gereken primer aktiviteye bağlanıp, diğer aktivitelere bağlanmamasıdır. Süreç içinde bu bağlantıların önem seviyesinin değişebileceğini de unutmamak lazım. Aksi halde veri giriş tarihi çizgisiyle (data date=schedule date) sebepsi şekilde ötelenen bir sürü aktivite görmek mümkün olacaktır.
Bağlantı tipleri ise, bir iş zincirinin bir birleriyle ilişkisini göstermekten çok, bize o işin hikayesini verir. Bu iş programını hangi gözle irdelediğinize bağlıdır. Yani eğitimler sırasında kullandığım bir örneği paylaşacak olursak;
Şekil 1.1’de aynı süreleri içeren (10’ar gün) A ve B olarak isimlendirdiğimiz iki grup iş görünmektedir. A grubundakiler bir birine FS (Finish to Start) olarak bağlıyken, B grubundakiler birbirine SS+10 (Start to Start + 10 gün) olarak bağlanmıştır. Şekilde de görüldüğü üzere her iki grupta toplamda 20 gün sürecek şekilde planlanmış.
Şekil 1.1
Şekil 1.2’de ise birinci işler aynı tarihlerde gerçekleşmeye başlamış, ancak gerçekleşen başlangıç tarihinden itibaren her iki iş kaleminde de ilerleme kaydedilememiştir. Dokuz gün sonra mevcut program güncellendiğinde her iki iş içinde ilerleme kaydedilemediği için, kalemlerimiz 10. Gün’e kadar ötelenmiştir. Birinci grupta aktiviteler birbirine FS tipinde bağlı olduğu için birinci aktivite bitmeden ikinci aktiviteye başlanamamaktadır. Bu nedenle 20 günlük süreç olduğu gibi ötelenmiştir. Sonuç olarak süreç 29 gün'e çıkmıştır.
Ancak ikinci grupta ikinci iş birinci işe SS +10 gün olarak bağlandığı için sadece birinci kalem dokuz gün ötelenmiştir. Çünkü ikinci kalemin başlaması için gerekli olan neden gerçekleşmiştir. Toplam süreçte herhangi bir değişiklik olmamıştır. Buradan bağlantı tipinin önemini bir kere daha görmekteyiz. Son olarak ötelemelerimizin aktivite süreçlerinin belirlenmesindeki değerlendirmeler gibi hesaplanması gerekmektedir. Aksi takdirde yazılmış lagler sonradan başlayacak işlerin tarihlerini etkilemektedir.
Şekil 1.2
Sonuç itibariyle süreçlerimizi gerçekleştirecek kalemler hakkında doğru yorumlarda bulunabilmek için temel olarak bu parametreleri ve rollerini bilmemizin yanında zaman içinde nasıl davranış göstereceğini de düşünmemiz gerekir. Bu sadece ilk andaki görünütüde oluşan tarihlerin uygunluğu ile ilgili bir durum olarak algılanmamalıdır. Aksi halde her zaman programın başkaları tarafından bilinçsiz bir şekilde planlandığını ya da bilgisayarın bu işi yanlış hesapladığını düşünmeye devam ederiz. Yeterki sorunun odağında kendimiz olmayalım, suçu atacak bir yer bulunur deriz.
Saygılarımla
Mesud Baydar
2