"Başarı bir hedeftir. Proje ise o hedefe giderken kullanılan yoldur."
O yol bildiğiniz gibi PMI tarafından 8 kola ayrılmıştır:
Risk, Kapsam, Zaman, Maliyet, Kalite, İletişim, İnsan Kaynakları, Tedarik.
"Proje yöneticisinin, o hedefe doğru atılan adımlarda, yolun seyrini değiştirmeye ne kadar yetkisi varsa, projenin başarısına etkisi de o kadar fazladır."
Dincer Ozturan, 02.2006
Soru1: Kötü ve başarısız bir proje yöneticisine rağmen bir proje başarı ile sonuçlanabilir mi? Ekipler, başlarinda proje yöneticisi olmadan, söz konusu 8 kolu kendi içlerinde sistemli ve sorunsuz olarak ve üst denetimsiz yürütebilir mi?
Soru2: kotu veya yetersiz ekiplere ramen sirf proje yoneticisinin basarisi ve azmi ile projeler basariya kosabilir mi? bazen ekip parcalansa da, proje yoneticisi o projeyi alternatif cozumler ile sonuclandiramaz mi?
Proje yöneticisinin tam yetkili olduğunu varsayarsak:
1. Durum: Proje Yöneticisi kötü ama Proje Takımı sağlam olursa:
Bence bu durumda projenin başarı ile sonuçlanma şansı kesinlikle var; ancak tabi bunun için Proje Takımının, informal bir süreç içerisinde doğal bir lider çıkarması gerektiğini düşünüyorum. Ayrıca bu resmi olmayan gizli liderin gizli yetkileri olması veya organizasyon tarafından kabullenişi yine de gereklidir. Proje takımı kendi kendisine disiplinli, motive ve güvene dayalı otonom bir habitat oluşturabilirse proje elbette başarı ile sonuçlanabilir.
2. Durum: Proje yöneticisi iyi ama Proje Takımı çürük olursa:
Bence bu durumda projenin başarı ile sonuçlanması ilk duruma nazaran daha zor; ancak bunu bir "bilişim profesyoneli" kimliğimle söylüyorum. Zira bir yazılım sistemi geliştirme projesinin başarısı, sistemi geliştiren proje takımına göbekten bağlıdır. Proje, zaman, maliyet ve kapsam üçgeninde, görünüşte de kalite kriterlerine uygun bitirilebilir. Ancak projenin başarısı aylar ve hatta yıllar sonra ancak anlaşılabilir, çünkü bir yıl boyunca tıkır tıkır çalışan bir sistem, ilgili projedeki kötü geliştirme süreci nedeni ile bir yıl sonra veri hacmindeki büyüme, tarihlerdeki değişim, otomatize edilen iş sürecinin doğası gereği bir yıl sonra oluşacak yeni sistem koşulları nedeni ile hata üretmeye başayabilir, yavaşlayabilir ve hatta tümden çökebilir. Bir yıl önce Z K M K üçgeninde başarı ile yapılmış görünen projenin, ROI çerçevesinde başarılı olduğunu böyle bir durumda söyleyemeyiz. Yazılımda kalitenin ölçümü çok zorlu ve günümüzde yerli bilişim şirketleri için de çok maliyetli olduğundan, bu konuya müdehale de çok mümkün olmuyor; proje üyelerinin insafına, disiplinlerine ve insiyatiflerine ister istemez güvenmek durumunda kalıyorsunuz.
