Proje Yönetimi – MS Project – PMP – PMBOK

PMBOK 2008′e yeni eklenen başlıklardan bir tanesi de “Proje Taraflarının (Paydaşlarının) Belirlenmesi – Identify Stakeholder- olmuştur. PMI, bu başlığı İletişim Yönetimi Bilgi Alanında ve Proje Başlatma süreci içinde ele almıştır.

Projeden etkilenecek bütün kişiler ve organizasyonları belirlenmesi işlemi olarak bu başlığı basitçe ifade edebiliriz. Projenin başarısı için proje taraflarının  ilgi veya alakaları yazılı hale getirilmesi gerekir. Örneğin, bazı departmanlar müşteri durumunda iken, bazıları proje neticesinden etkilenecek, üst yönetim projenin sonunda verimlilik artışı isteyecek ve tedarikçi firmalar da alt projeleri üstleneceklerdir.

Proje Tarafları Belirlemek için en önemli gereksinim (Input) Proje Duyurusu ‘dur. Böylece Proje Yöneticisi, talep edilen projenin özelliğine bakarak, proje için hangi kişi veya organizasyonların projeye dahil olması gerektiğini belirler.

Proje Taraflarını belirlemek için (Tools) iki adımdan oluşan “Proje Tarafları Analizi” yapılması gerekir. Bu analiz ile projeye taraf durumunda olan kişi veya organizasyonların İlgi ve Etki Güçleri değerlendirmeye tabi tutulur.

Değerlendirme neticesinde (Output) elinizde Proje Taraflarının açıkça isimleri, rolleri, organizasyondaki pozisyonları, iletişim bilgileri ve Proje Taraflarını yönetmek için “Proje Taraf Analizi” göz önüne alınarak, Proje Yöneticisi’nin stratejisi yazılı hale getirilir.

Project Server’da projenin kaydedilmesi (SAVE) ile projenin yayınlanması (PUBLISH) arasında fark vardır. Bir proje planı üzerinde çaışılırken yapılan değişikliklerin kaybolmaması için tekrar tekrar kaydedilir. Proje nihai hale gelmediği için proje yayınlanmadan önce gözden geçirmek veya değişen talepler çerçevesinde projeyi değiştirmek amacıyla kayıt fonksiyonu önemlidir. Bu yüzden, proje nihai plana ulaştığı anda önce temel plan (BASELINE) olarak kaydedilir ve daha sonra proje taraflarına görevlerini bildirmek amacıyla proje yayınlanır.

Pek çok kişi MS Project’in print fonksiyonundan şikayet eder. Üst Yönetimden gelen rapor biçimini veya proje planlarını Proje Yöneticimiz bir türlü istendiği gibi kağıda basmayı beceremez. Aslında bir iki kurala dikkat ederek, kağıtlara alacağınız çıktıları daha etkin hale getriebilirsiniz.

1- Kolonlarla, takvimi ayıran orta çizgiye dikkat. O çizgi eğer aşağıdaki gibi “Finish” kolonunun ortasında ise Print işlemi neticesinde “Finish” kolonunun kağıda basılmadığını göreceksiniz. Bu yüzden  kesinlikle hangi kolonları görmek istiyorsanız, o çizgi kolonların en sağında kalmalıdır.

2- Takvimin zaman skalasına dikkat. Yine yukarıda gördüğünüz gibi takvim eğer ayları gösterecek biçimde ayarlanmışsa, baskı aldığınızda da kağıdınızda aylık zaman skalası gözükecektir. Eğer daha farklı baskı almak isterseniz (yukarıdaki yaklaş(büyüteç)/uzaklaş(küçülteç) butonlarına basmanız gerekir. Yaklaştıkça daha detaylı bir plan alacağınız için görüntü daha fazla sayfaya yayılacaktır.

3- Baskı Önizleme yaparak, alacağınız baskının nasıl olacağını önizleyebilirsiniz.

Yukarıdaki önizleme sayfasının en altında bir klavuz (Legend) görülmektedir. Gantt üzerindeki çubukların ne anlama geldiğini göstermektedir. Eğer Page Setup butona basıp, Legend on: None işaretlerseniz, daha fazla bilgiyi tek bir sayfaya yerleştirebilrsiniz.

4- Page Setup penceresinden Page sekmesine tıklayarak, baskıyı belirli oranda küçültebileceğiniz gibi bütün projeyi tek bir sayfaya sığdırmayı da deneyebilrisiniz. Tabiki bu durumda yazılarınız okuyamayacak kadar küçülebilir. Buna dikkat edin.

Proje Yöneticileri, planlama esnasında genellikle iki önemli hatayı yapmaktan kurtulamazlar. Birincisi; Projede görev alacak diğer departmanlarının bireylerinin zaman planlarına dikkat etmeden kendi projelerine dahil etmeleridir. Projeye dahil edilecek kaynakların iş yükleri, tecrübeleri, eğitim düzeyleri gibi faktörler göz önüne alınmadan yapılan proje planlarının geçerliliği tartışmaya açıktır. Özellikle kaynakların aktivitelere atanması ve sürelerin tahminlenmesinde, proje yöneticileri ilgili kaynaklardan bilgi almadan plan hazırlamakta ve bu durum, planların sapmasına sebep vermektedir.

Projenin başında projeye destek vermesi gereken kaynakların, proje sürecinde yeterli desteği ver(e)memesi, proje yöneticilerini zor durumda bırakacağından, pek çok proje yöneticisi diğer kaynakların yapacağı işleri kendi kendilerine öğrenirler ve uygulamaya geçerler. En azından üst yönetime birşeyler raporlayabilme kaygısıyla projeyi yürütmeye çalışırlar.

Yukarıdaki uygulamaların saysısının artması proje yöneticisi diye adlandırılan kişilerin joker eleman olmasına sebep verecek ve zamanla proje yönetiminin bir takım ruhu gerektirdiği gerçeğinden uzaklaşılacak, bireysel yapılan her iş proje olarak adlandırılmaya başlanacaktır.

Planlamada yaşanan bir diğer sorun ise “Planlamama” olarak adlandırılabilir. Geçmişte yapılan planlara sadık kalınmaması, planlarda sapmaların yaşanması, proje yöneticilerinde plan yapmaya karşı bir isteksizlik uyandırır.Nasıl olsa planlar bir işe yaramamaktadır, bu durumda bir de plan yapmak için zaman harcamamak gerekir.

Halbuki; planlamadaki amaç; Geçmişte yaşanan sapmalardan, risklerden, problemlerden ders alarak her defasında daha iyi planlar yaratabilmektir.

Unutulmamalıdır ki; “Planlama Planlanmalıdır.”

Planlama ile aşağıdaki sorulara cevap aranmalıdır:

• Yapılması gereken işler nelerdir? Bu soru hedefler ve işin kapsamına yönelik cevaplar oluşturmayı sağlar.
• Nasıl yapılacak? Bu soru ile projenin uygulanmasına yönelik stratejiler belirlenecektir.
• Kimler yapacak? Rollerin ve sorumlulukların belirlenmesi gerekir.
• Ne kadar sürede yapılacak? Zaman programını oluşturmayı sağlar.
• Ne kadara mal olacak? Bütçe oluşturmayı sağlar.

Ürün/Hizmet ne kadar iyi olmalı? Kalite standartlarını da belirleyebilmek için bu soruya cevap aranmalıdır

Hepimizin bildiği gibi Proje Yöneticisi projenin çıktılarından sorumludur. Proje Yöneticiliği pozisyonu temelde bu amaç için oluşturulmuştur. Bu çerçevede özellikle projenin planlanması, uygulaması, kontrolü ve kapanışı süreçlerinden PY sorumludur. Fakat bu durum PY’nin proje içindeki işleri yapması anlamına gelmez.

Proje Yönetmek tam zamanlı bir iş olduğunda proje yöneticisinden teknik analiz yapmasını , tasarım, üretim, test gibi işleri beklemek ve istemek projenin yönetim fonskioynuun sekteye uğramasına sebep olur. Eğer PY, teknik detaylara fazlasıyla gömülürse yukarıda saydığımız planlama, uygulama, kontrol süreçlerine zaman bulamaz ve projeyi yönetmekten çok , projeyi yapmaya odaklaır. Proje Yöneticiliği özellikle farklı talepleri olan proje taraflarının ihtiyaçlarını, belirli bir zaman ve bütçe içinde, mutabık kalınan bir kapsam dahilinde ortaya çıkarmak amacıyla vardır. Bu çerçevede PY özellikle koordinasyona odaklanmalı ve planlardaki herhangi bir değişikliğin projenin bir başka tarafını nasıl etkilediğini entegre (bir bütün) olarak düşünüp, yansımalarını çok hızlı biçimde etkilenecek kişilere, üst yönetime, sponsora, vs. haber vermelidir. Bu yüzden PY, proje için ayırdığı zamanının ağırlıklı bir bölümünü İLETİŞİMe odaklanarak geçirmelidir.

Proje içinde yaşanan iletişim sorunları pek çok projenin başarısızlık sebebidir bu yüzden, iletişim yönetimine özel bir önem vermek gerekir; Yanlış anlama, yanlış anlatma, bilgi vermeme, eksik bilgi verme, yanlış yorumlama vb. gibi sebeplerden pek çok projede gecikme veya kalite düşmesi yaşanır.

Araştırmalar, projelerdeki başarısızlığın arkasındaki %60′lık payın, iletişimin etkin yönetilmemesinden kaynaklandığını göstermektedir.

MS Project 2007′de Project Menusunden Project Information seçeneğini işaretleyin.

Yukarıdaki pencerede Statistics butonuna tıklayın, karşınıza aşağıdaki gibi bir pencerede çıkacaktır.

Bu sayfada;

Current Start ve Finish: Projenizin mevcut sapmalardan etkilenerek, yeni bitiş tarihini göstermektedir.

Baseline Start ve Finish: Nihai(Temel) Planı onaylattığınız andaki (yani planlanan) proje başlangıç ve bitiş tarihidir.

Actual Start ve Finish: Projenin fiilen başladığı tarihi göstermektedir. Projenin tüm falliyetleri bitmeden Actual Finish alanında NA ifadesi görülür.

 Start Variance: Current Start ile Baseline Start arasındaki fark – Projeye plana göre ne kadar geç başladığınızı gösterir.

Finish  Variance: Current Finish ile Baseline Finish arasındaki fark – Projeye plana göre ne kadar geç bitireceğinizi gösterir.

Süre, Maliyet ve Efor gibi bilgiler de benzer şekilde yorumlanabilir.

Sol alt köşede %Comp. projenin % kaçını tamaladığınızı ve hemen yanında da %W.Comp. planlanan eforun % kaçının harcandığını gösterir.

Millet olarak herşeyimiz kendimize özgüdür. Problemlere yaklaşım ve çözüm biçimimiz; Dolayısıyla, proje yönetme yaklaşımımız da yabancılara göre daha farklıdır. Örneğin biz planlamayla zaman kaybetmeyi sevmeyen bir milletiz, bu yüzden projeleri planlamadan doğrudan uygulama sürecine geçerek, başlatırız. Plan olmadığı için kontrol edecek de bir referans yoktur, böylece su akar yatapını bulur ve proje de münasip bir zamanda, münasip bir sonuçla biter, diye düşünürüz.

Konuyu fazla dağıtmak istemiyorum, esas ilginizi çekeceğini umduğum başlığı biraz açalım. Malumunuz milletimizin hurafelere olan inancı dini açıdan önemli gecelerde TV’lerde boy gösteriyor. Çocuğuna kısmet bulmak isteyenler yatırlara, vücudundaki bir arızayı gidermek isteyenler üfürükçülere, evindeki uyumsuzluğu gidermek isteyenler büyücülere, cincilere başvuruyorar.

Bundan yola çıkarak ben de yeni bir sektöre açılmaya karar verdim. Malum benim konum Proje Yönetimi … Yapacağım yeni iş ise özellikle geciken, maliyetini aşan, müşterinin sürekli şikayet ettiği projelerde kara büyü olup, olmadığını bulmak ve her türlü büyüyü projenin içinden çekip, çıkarmak. Bu işi danışmanlık olarak düşünebilirsiniz. Ama ben şimdi projenizin içine büyü, in, cin vb. girmemesi için şimdi bir kaç öneride bulunacağım.

Kurban Kesme: Her projenin başında mutlaka kurbanınızı kesin. Bu uygulama inşaat projelerinde aslında uygulanır. Arazi sahibi inşaata başlamadan önce işçilerin faydalanması ve inşaatın hayırlara vesile olması için kurban kestirir. İşte benim önerim bu uygulamayı genişletme yönünde; özellikle IT projelerinde kick-off toplantısını müteakip kimse dağılmadan kurbanımızı kesiyoruz. Akan kanı bütün proje taraflarının (stakeholder) alnına sürüyoruz ki yarın öbür gün kimsenin başı ağrımasın, kimsenin motivasyonu düşmesin, stres bizden uzak olsun. Mutlu mesut projemiz tamamına ersin. (Kurbanın nasıl kesileceğine ayrı bir yazıda değineceğim)

Projeci Babayı Ziyaret: Eğer kurbanınızı kestiyseniz, şimdi ekip olarak toplanıyor ve İstanbul Kadıköy/Ataşehir meydanda yattığı bilinen Projeci Baba’yı ziyaret ediyorsunuz. Projeci Baba’ya yolunuz düşünce bana da uğrayın. Ben de özel WC kağıtları var. Onları Projeci Baba’nın bulunduğu mekana rulo halinde bırakıyorsunuz. Topluca projenizin yine hayırlara vesile olmasını temenni eden dualarınızı yaptıktan sonra artık projeye başlamaya hazır sayılırsınız.

Yukarıdakileri bütün işlemleri bitirdikten sonra proje uygulaması esnasında örneğin Risk Yönetimi toplantısındasınız. Ne PMI’ın ne de başka bir kurumun önerdiği yöntemleri asla uygulamıyoruz. Peki napıyoruz? Tabi ki yüzlerce yıldır bizleri idare eden Kahve Falına odaklanıyoruz. Proje Yöneticisi şekersiz bol telveli bir kahve içiyor ve arkasından kahve fincanını okumayı bilen en az üç arkadaşımız (çünkü bir kişi yanılabilir) projenin karşılaşabileceği riskleri açık ve net olarak ortaya koyuyor. Proje Yöneticisi elinde kalem ve kağıtla söylenenleri bir bir not ediyor. Bu arada ekip olarak önleme yöntemleri düşünülebilir ama lütfen fazla kafa yormayalım.

Bunun haricinde başta Proje Yöneticisi olmak üzere bütün takım üyeleri üzerlerinden nazarlıklarını eksik etmiyorlar, her nerde olursa olsun kara kedilere dikkat ediyorlar, yolu kısaltmak için bile olsa asla merdiven altından geçmiyorlar.

Bütün bunlara rağmen yine de projede başarısızlık sözkonusu oluyorsa üfürüğü güçlü bir hocaya, papaza, hahama (farketmez ama PMP olursa daha iyi olur) başvuruyorlar ve inanın bundan sonra projeler, ne kapsamından, ne zamanından, ne de maliyetinden taviz vermeden ilerlemeye başlıyor. Kalitesi hakkında birşey diyemeyeceğim, artık onu da Allah’a emanet edebilirsiniz.

Lütfen yukarıda önerdiklerimi çekinmeden uygulayın. Sonuçları da bu yazımın yorumlar bölümüne lütfen ekleyin ki başkaları da sizin yaptıklarınızdan feyz alsın ve millet olarak daha başarılı projelere imza atalım.

PMBOK 2008, bildiğniz gibi 31.12.2008 tarihinde yayınlandı. Bir önceki baskıyla olan farklılıklardan daha önceki yazılarımdan bir tanesinde kısaca bahsetmiştim.

Bir yazı dizisiyle özellikle İngilizce olan PMBOK 2008′in önemli başlıklarını kısmen Türkçe’ye çevirmek ve okuyucularımla paylaşmak istiyorum.

PMI, bir projenin başlangıcında sürecinde en önemli işlemin Proje Duyurusu’nun hazırlanması olduğunu ifade eder.

Proje Duyurusu neden önemlidir?

Proje taraflarının ihtiyaç ve beklenrilerini karşılayacak bir projenin tanıtımı yazılı olarak proje yöneticisine ve proje yöneticisini destekleyecek  olacak kişilere duyurulur. Böylece,

• proje resmiyet kazanır.
• proje yöneticisi üst yönetimden yetkiyi devralmış olur.

Proje henüz müşterinin dile getirdiği ihtiyaçlar çerçevesinde tanımlanmıştır. Üst Yönetim veya Proje Sponsoru bu dökümanı aşağıdaki başlıkları içerecek şekilde yayınlarlar.

• Projenin amacı
• Kabaca ihtiyaçlar
• Çok genel proje tanımı
• Karşılaşılabilecek riskler
• Kilometre taşlarının neler olabileceği
• Yaklaşık maliyet
• Üst Yönetim adına destek alınacak kişi veya birimler
• Atanan Proje Yöneticisi
• Atanan Proje Sponsoru

MS Project’te aktivite sürelerini farklı şekilde tanımlamak mümkündür.

Eğer kullandığınız MS Project İngilizce ise Duration kolonuna yazacağınız aşağıdaki kısaltmalar aktivite sürelerini belirlemenizi sağlar.

• m – dakika
• h- saat
• d- gün
• w- hafta
• mo- ay

Eğer aktivitelerin süre bilgilerini aynı değere çekmek istiyorsanız, aşağıdaki adımları gerçekleştiriniz.

 Bir macro çalıştırın.

Format_Duration macrosunu çalıştırın. Aşağıdaki herhangi bir formatı seçerek, bütün aktivitelerinizin aynı değere dönüşmesini sağlayabilirsiniz.

Evet, bir proje planı hazırladınız ve planın gelecekteki durumunu inceliyorsunuz. Bir kaynağınız iki ay sonraki 4-5 aktiviteyi aynı anda yapmak üzere görevlendirilmiş. İleride yaşanacak bu darboğazı farkettiğinizde ne yaparsınız?

Değişik çözüm yöntemlerini önermeden önce bu fazla yüklenme durumunun nasıl oluştuğunu inceleyelim. Belirli bir zaman diliminde herhangi bir kaynağımızın kapasitesinin üzerinde iş atamış olmamızla birlikte kaynakta fazla yükleme problemi oluşur. Örneğin haftada 40 saatlik iş yüklediğimiz bir kaynağımıza daha fazla iş yüklemeye devam edersek, kaynağımız fazla yüklenmiş olarak ifade edilir.

Ne yapılabilir?

1. Ek Kaynak Ekleyin: Fazla iş yüklenen kaynağın yanına bir kaynak daha ekleyin Böylece sorunlu kaynağın iş yükünü azaltıp, fazla yüklenme problemini çözün.
2. Aktivitenin Süresini Uzatın:  Fazla yüklenen iş yükünden dolayı kişiye atanan aktivitelerin bitiş tarihlerini uzatın.
3. İki Aktiviteyi Birbirine Bağlayın: Fazla yüklemeye sebep olan faaliyetleri ard arda başlayacak şekilde planlayın.
4. Günlük-Haftalık Çalışma Saatlerini Artırın: Kaynağın günde 8 saat, haftada 40 saatlik çalışma süresini artırın.
5. Teknolojiden Yararlanın: Eğer zamanınız varsa kaynağın aynı iş sonuçlarına hedeflediğiniz sürede ulaşması için teknolojik gelişmelere destek olun.
6. Dış Yaptırım: Aynı nda bitmesini istediğim işlerin bir bölümünü dışarıdan birsine devredebiliriz. Bu seçenek maliyetleri daha fazla artırma riski yaratır.
7. Kapsamı Daraltın: Son çare olarak düşünülebilecek bir seçenek.Eğer ekstra dahil edebileceğiniz kimse yoksa, dışarıdan destek konusunda  bütçe kısıtı varsa bu durumda projenin kapsamı daraltılabilir. Ortaya çıkacak ürünün veya hizmetin fonksiyonlarının azaltılması sonucuyla karşılaşılır.
8. Hibirşey Yapmayın: İş yükü açısından ileride darboğaz olacağını görmenize rağmen hiçbir şey yapmamak da bir seçenektir. Darboğaz yaşayacak olan kişi işleri kalitesiz yapıp, teslim eder sonra o kalitesiz işleri düzeltmesi proje yöneticisine düşer.