5 yıllık proje ofisi ve yaklaşık 150 BT projesi deneyiminden sonra, pek çok başarılı uygulama ile beraber muhakkak bazı kusur ve hatalarımızın da olduğunu belirtmem gerekir. Bunlar içerisinden önemli olarak nitelendirebileceğim birkaç tanesini bu tür bir yapılanmaya yeni başlayan veya nasıl başlamalıyım diye düşünen meslektaşlarımız için açıklamaya çalışacağım.
Deneyim paylaşımına geçmeden önce İngilizce’deki “Lessons Learned” sözünün Türkçe’de, ”Öğrenilen Dersler” yerine “Alınan Dersler” olarak kullanılmasını önereceğim. Takdir edeceğiniz gibi, -eğer İngilizce’den bir çeviri yapmıyorsanız- Türkçe’de ders öğrenmek diye bir tabir kullanılmaz, onun yerine gerçekleşen ya da başımıza gelen bir olaydan “ders almak” deyimini kullanırız. Proje yönetimi açısından konunun esası da ders almaktır. Bir projede yaşanan sorunlardan ders alırız (çoğunlukla almayız ki bu ayrı konu ve sorundur :-)), bu sorunlara bulunan çözümlerden de gelecekteki projelerde yararlanmayı umarız. Dolayısıyla “Lessons Learned” için doğru Türkçe karşlık “Öğrenilen Dersler” değil, “Alınan Dersler” olmalıdır.
Proje yönetimi ofisi deneyiminden aldığımız derslere gelince özellikle iki noktayı vurgulamak istiyorum.
1. Projelerden ders alabilmek için bütün sorunları ve çözümlerini kaydedin.
Başlangıçta bu konu çok önemli görünmeyebilir. Öncelikler, daha çok proje yönetim ofisinin organizasyonu, proje organizasyonu, projelerin başarılı bir şekilde sonuçlandırılması üzerine yoğunlaşacaktır ki aslında normaldir. Mevcut proje yönetimi uygulamaları içerisinde alınan dersler ya hiç yer almaz ya da proje sonuna bırakılır. Biz de çoğunlukla proje sonunda değerlendirme ve alınan dersleri, raporla paylaşma yöntemini seçtik. Bu da hiç yoktan iyidir ancak potansiyelden tam olarak yararlanılabildiği söylenemez. Proje sonunda genellikle sorunları ve kötü anıları unutma eğilimi vardır. Hele bir de proje başarılı bir şekilde sonuçlandı ise, “her projede sorun çıkar canım, üstesinden geldik nasıl olsa” psikolojisi içerisinde tamamen göz ardı edilir. Projede işler istenildiği gibi gitmese dahi, yaşanan sorunların bir bölümü raporda yer alırken bir bölümü muhakkak kaybolur.
Proje-portföy yönetimi yazılımları sorun kaydetme, takip etme (issue management) çözümleri sunuyorlar. Ancak her zaman kullanışlı olmayabiliyor. Sadece sorun yönetimi ya da proje-portföy yönetimi yazılımları için söylemiyorum, bazen ufak bir bilgi girmek için bir ekran dolusu alan getiriyorlar. Bu alanların çoğu ilk girişte gerekli değil, süreç ilerledikçe içleri doldurulması gereken alanlar. Fakat insan karşısında bir dolu alan görüp, hangilerinin zorunlu hangilerinin seçeneğe bağlı olduğunu da bir bakışta algılayamayınca doğal olarak bir soğukluk oluşuyor ve insanlar kullanmak istemiyorlar. Sorunlar ve bunlar üzerindeki tartışmalar genellikle bilgisayar üzerinden e-posta, MSN gibi araçlarla yapıldığı içni ayrıca başka bir yazılıma kaydetmekte bir külfet gibi görünüyor. Umarım proje-portföy yönetimi yazılımı üreten firmalar bu sürece uygun entegre yazılımlar üretirler.
Her türlü zorluğa rağmen, projede karşılaşılan sorunlar ve bunlar için üretilen çözümler çok değerli bilgilerdir. Bu bilgiler oluştuğu anda kaydedilmezse bir çoğunun kaybolması kuvvetle muhtemeldir. Sanılanın aksine, belirli bir sektörde yapılan projelerde yaşanan sorunlar aşağı yukarı belli. Yani her projede çok çok farklı sorunlar oluşmuyor. (Örneğin, bilgi teknolojileri projelerinde yaşanan sorunların listesine bir göz atmak için “BT Projeleri Riskleri ve Sorunları” adlı yazıya göz atın : http://www.ileriprojeyonetimi.com/proje_yonetimi/bt-projeleri-riskleri-ve-sorunlari.html).
Sorunların ve alınan önlemlerin kaydedilmesi kadar proje bağımsız olarak listelenebilmesi, aranabilmesi de önemli özellikler. Dolayısıyla kayıt işlemini bir projeye özel olarak değil, tüm projelerde yaşanan tüm sorunları elde edebilecek, sınıflandırabilecek ve izleyebilecek şekilde yapmak önemli. Bunu, özel bir veritabanı olarak da düşünebilir veya benzer veritabanları ile birleştirebilirsiniz (Bilgi teknolojileri sektöründe ITIL CMDB gibi). Bu şekilde projelerde yaşanan sorunların kaynağını bulmak ve bunlara göre çözüm, süreç ya da yöntem geliştirmek de mümkün olacaktır. Sözgelimi, sizin projelerinizde en çok görevlerin tahmin edilmesinde mi sorun yaşanıyor, yoksa teknik ya da teknolojik sorunlar mı, idari problemler mi, kültürel sorunlar mı?
2. Az veri ile iyi bir tahmin oluşturabilmek için kritik faaliyetleri ölçün.
Proje başında, ya da henüz bir fikir aşamasında iken en zor konulardan bir tanesi, proje için bütçe ya da zaman tahmininde bulunmaktır. Genellikle de proje için kararı verecek olanlar bu aşamada kaça malolur diye sorarlar. Bunlara örnek olarak, herhangi bir araştırma ya da ön-analiz yapmadan, “Bi ERP paketi alsak kaça çıkar? (sadece yazılımı satın alarak herşeyin düzeleceği, süreçlerde ya da iş yapış şeklinde herhangi bir değişiklik gerekmeyeceği gibi iyimser bir yaklaşım yaygındır :-)), bi çağrı merkezi kursak ne kadara malolur?, bi yazılım entegrasyonu lazım, kaça çıkar?” gibi sorular gösterilebilir. Proje yaptığınız faaliyet alanına göre bu soruları çeşitlendirebilirsiniz. Ne kadar bu sorulara muhatap oluyorsunuz bilmem ama, ortaya yapılmaya değer gibi görünen bir fikir çıktığında doğal olarak arkasından gelecek ilk soru, ne kadar malolacağı sorusudur. Malzemeler için hızlıca adet tahmini ve fiyat bilgilerine ulaşmak mümkün olabilir. Hizmet tarafında ise biraz zordur. En iyi tahmin en detaylı analizden sonra çıkar, ancak muhatapların beklemeye zamanı yoktur ve bu kadar iyi tahmin yapmak için harcanacak efora değer mi değmez mi tartışma konusudur. Dolayısıyla, ne çok kısa ne de çok uzun olmayan bir zaman içerisinde (optimum sürede) iyi bir tahmin oluşturabilmek önemli ve değerli bir beceridir. Özellikle de ihaleye giriyor ve taahhüt ile iş yapıyorsanız.
Doğal olarak hangi tür faaliyetleri ölçmeliyim sorusu hemen aklınıza geliyor, ancak bunu benim söylemem mümkün değil. Doğrudan iş yaptığınız sektöre bağlı. Önemli olan bu tür faaliyetlerin (ve çıktılarının), birim faaliyetler olması ve bunlar sayesinde projenin tamamına ait bir projeksiyon yapılabilmesi. Çok anladığımızdan değil ama klasik olduğundan ve konunun anlaşılmasına yardımcı olacağı düşüncesiyle inşaat sektöründen tamamen uydurarak örnek vermeye çalışalım. Bir usta günde x m2 kadar duvar örebilir ya da 10 m2 duvar x saatte örülür, (insan gücüyle yapılıyorsa) 1işçi günde x m3 harç karar, 120m2 bir daire için ortalama şu kadar demir, çimento vs. gerekir gibi. (İngiltere’den bir örnek vereyim, inşaat ve altyapı işleri ile ilgili olarak birim maliyetler o kadar belli ki, kitap haline getirip satıyorlar, ilgilenenler için; http://www.routledge.com/books/Spons-Architects-and-Builders-Price-Book-2009-isbn9780415465557)
Bizimkinde (bilgi teknolojileri) eforlar ve süreler çok değişken. Örnek olarak vereyim, yazılım geliştirme işinde verimlilik 1-10 arasında değişebiliyor. Yani, bazı durumlarda 1 tane çok iyi yazılım geliştirme uzmanı aynı işi yapan 10 kişinin toplamından daha iyi iş çıkarabiliyor. Bu durumda tahminler ve gerçekleşen eforlar arasında da kişiye bağımlılık oldukça yüksek durumda. Doğrudan yazılım işiyle uğraştığım zamanlarda tahmin vermeden önce projeyi kimlerle yapacağımızı muhakkak sorar ve tahminleri ona göre revize ederdim.
Hangi sektör, hangi iş alanı olursa olsun, birim oluşturabilecek çıktılar ve faaliyetler muhakkak vardır, bunların tespit edilmesi ve ölçülmesi, birim maliyetlerin ortaya çıkartılması zor olabilir, ancak kesinlikle çok işinize yarayacaktır.
Loading ...