3) Kritik konularda POC (proof of concept) yaptırın. Birçok projede ilk defa çalışılan bazı alanlar olur ve problem çıkma olasılığı en yüksek konuların buralardan çıktığını görürsünüz. Bu alanlara ne kadar çaba sarfetmeniz gerektiğini belirleyebilmenin birtakım yolları vardır. Bunlardan birisi hızlı bir POC yaptırarak teknik ve fonksiyonel bakış açılarıyla kurulacak iş zekası sistemini değerlendirmektir.Genellikle, projenin başlarında iseniz ve yazılım ve donanım kararını henüz vermediyseniz satıcılarınız değerlendirme sürecinize yardımcı olmak için can atacak ve isterseniz sizin için POC çalışması yapacaklardır. Bu aşamada önemli şeyler öğrenebilirsiniz. Örneğin yeni bir raporlama sistemi kurmak istiyorsanız ve bu sistemde yaklaşık 300 rapor tasarlanacağını düşünüyorsanız 3-4 adet raporun POC olarak hazırlanmasını istediğiniz taktirde harcanan emeğe bakarak satınalacağınız sistemle ilgili gerçekci tahminlerde bulunabilirsiniz. Ancak tecrübelerime dayanarak POC’lerde harcanan emek ve sürelerin gerçek projede ikiye katlanacağını söyleyebilirim.
4) Proje takımını projenizin bütçeleme sürecine dahil edin. Proje yöneticisi olarak bütçenin sosumluluğu tamamen sizin üzerinizdedir.Ancak farklı alanlardaki uzamnlardan yorum ve geribildirimler alarak bütçenin gerçekçiliğini büyük oranda arttırabilirsiniz.Örneğin sunucunun kurulması ve konfigurasyonunun ne kadar süreceğini tahmin etmek yerine sistem altyapı birimine giderek benzer çalışmayı son üç kurulumda ne kadar sürdüğünü öğrenebilirsiniz. Farklılıklara dikkat edin ancak konusundan uzmanlardan alacağınız bilgilerle zaman/maliyet tehminlerinizi optimum seviyeye çıkarabilirsiniz.,
5) Bütçenizde beklenmedik durumlar için bir pay olsun. Bütçeler yapılırken beklenmedik bir ihtiyaç olasalığına binaen genellikle bir pay bırakılır. Ancak bu payla ilgili yapılan iki büyük hata vardır. Birincisi böyle bir pay bırakmamak ikincisi ise bu payı projenin başlarında harcayıp bitirivermek. Projelerde makul bir artı pay koymak genellikle yapılmaz. Bunun nedenlerinden birisi, böyle bir ilave pay ile projeyi üst yönetime onaylatmak güçleşecektir. İkincisi ise bazı insanların bu tür bir fazlalığı abartı veya projeyi yapmaya karşı bir isteksizlik şeklinde algılamalarıdır. Dolayısıyla büteçenize ilave olarak koyacağınız bu pay mümkün olduğunca gerçekci olmalıdır. Küçük projelerde bu pay %5 civarında iken büyük, karmaşık, birçok departmanın ve yüzlerce kullanıcının veya birden fazla yazılım ve donanım ihtiyacının olduğu projelerde bu oran daha yüksek olabilmektedir. Proje boyunca yanlış giedebilecek veya istenmeyen durumların ortaya çıkabileceği birçok konuyla karşılaşılır. Bu nedenle kağı üzerinden yapılan proje maliyet analizinin tam olarak gerçeği yansıtması pek olası değildir. Ancak bütçede ayırdığınız ilave payı daha ilk kapsam değişikliğinde kullanmaya kalkarsanız ki bu sıklıkla karşılaşılan bir durumdur, hata edersiniz. Bütçedeki ilave pay (bu pay parasal ve zamansal olarak iki farklı alanda da olmalı) öngörülmemiş durumların ortaya çıkması durumunda kullanılmalıdır. Örneğin öngörülmemiş yeni bir donanım ihtiyacı çıkması gibi.
Özet olarak projenin başında harcayacağınız emek, gerçekci ve katılımcı yaklaşım ile proje boyunca size kolaylık sağlayacak ve başarı getirecektir.



Zaman zaman veri ambarı projelerinde bütçeyi aşmak genel geçer bir kuralmış gibi kabul edilebiliyor. Ancak bütçe aşımı gibi kaçınılmaz bir sonu engelleyebileceğimiz basit bazı yollar olduğunu söylemek isterim. Proje yöneticisi doğru bir bütçe ile başlayarak ve masrafları yöneterek, beklenen faydaları belirlenen sürede ve belirlenen bütçe ile elde edebilir. Tecrübelerimle elde ettiğim bazı ipuçlarını sizinle paylaşmak istiyorum :
Business Intelligence-BI uygulaması gerçekleştireceğiniz şirketiniz BI için gerçekten hazır mı? BI projesine ve kullanımına destek verecek anahtar kullanıcılar ve sponsorlarınız var mı ? Dünyada olduğu gibi Türkiye’de yapılan BI projelerindeki en büyük hata, projenin sadece IT bakış açısıyla yapılmaya çalışılması ve yeterince sponsor (yönetici, çalışan, departman, vs.) bulunamamasıdır. Bu şekildeki bir projeye son kullanıcıların bakış açısı şudur : “İşte yeni bir IT projesi daha…!”. Halbuki yapılması gereken şey projenin sadece bir IT projesi değil şirketin ve çalışanların iş ve süreçleriyle doğrudan içiçe olduğunu hissettirmektir.
Kurumsal yazılım kullanıcılarını temel olarak iki farklı kısımda değerlendirmek mümkün. Bir tarafta tekrarlı, tanımlı işleri yerine getiren (task users) görev kullanıcıları vardır. İK yöneticileri, satınalma sorumluları, müşteri temsilcilerini görev kullanıcıları ve anahtar kullanıcılar olarak isimlendirebiliriz. Örneğin, bu tür kullanıcılar işletme yazılımlarındaki arayüzleri kullanarak yeni çalışan bilgileri girebilir, bordro verilerini değiştirebilir veya müşteri bilgilerini güncelleyebilirler. Bu amaçla kullanılan kurumsal yazılımlar, görev kullanıcılarının en iyi şekilde kullanabilecekleri şekilde hazırlanmış olup, son derece esnek, çok karmaşık işlemleri kolaylaştırıcı ve sadeleştirici bir şekilde hazırlanmışlardır.

Başarılı bir proje yönetiminin sırları nelerdir? Bu sorunun kesin bir cevabı olmamakla birlikte yıllardır değişik disiplinlerde çalışan birçok yönetici ve akademisyen tarafından derin analizleri yapılmaya çalışılmıştır. Bu soruya aldığım en yaygın cevap “iletişim yani proje ile ilgili herkesin ne olup bittiğini bilmesi” şeklinde olur. Bu cevap elbette yanlış değil ancak bu hazır cevabı bir kenara koyduktan sonra konunun derinliklerine inmemiz gerekir diye düşünüyorum. Bu arada bu soruya benim cevabımı merak edenler varsa daha fazla bekletmeden vereyim : “Duygusal zeka”. Evet, bu kelimelerin altını kalın bir kalemle çizmenizde yarar var. Proje yöneticisinde duygusal zeka olmaz ise başarılı olunamayacağını ben de birçok PMP gibi açıkca iddia ediyorum.
Sosyal ağlarım