Ayrıştırma

 

PMBOK’ta iki süreç içinde kullanılan bir araç ve teknik olarak geçer.

Birinci kullanım yeri; İş Kırılım Yapısı Oluşturma, ikinci kullanım yeri; Aktivite Tanımlama’dır.

Bir projede işleri bölerken “Daha fazla iş mi yaratıyorum?” diye sorun. Eğer, detaylandırılan işin gerektirdiği efor, bu işi tanımlamak, kaynak atamak ve takip etmek gibi faaliyetlerin getirdiği eforlardan daha az ise, detaylandırmak bize bir kazanç sağlamayacak hatta işimizi zorlaştıracaktır.

Burada önemli olan şey şudur; Detaylandırdığınız da o işe atadığınız kişi veya kişiler size yaptıkları işle ilgili gerçekleşme verilerini verecekler ve siz de bu faaliyetleri kontrol edebilecek misin? Kontrol edemeyecekseniz, hiç detaylandırmayın. Attığınız taş, ürküttüğünüz kurbağa değsin.

Ayrıca, işe atadığınız kişiler, işin nasıl yapıldığını zaten biliyorsa, bu kişilere işin kırılımını çıkarmak da gereksiz olacaktır. Hatta, bu insanlardan tepki de alabilirsiniz. Dikkat!

Altın Kaplama Yasak

PMP sınavına hazırlananlar bilirler. PMI sınavda bu konuyla ilgili en az bir soru sorar. Bence bu konuyu sınava hazırlanmayanların da bilmesi gerekir.

Nedir bu Altın Kaplama (Gold Plating) ?

Öncelikle Altın Kaplama, Proje Kapsam ve Kalite Yönetimi ile ilgili bir konudur. Özetle şu; Eğer müşterinize Kapsam veya Kalite açısından anlaşmanızın haricinde “jest amacıyla” bir ekstra sunarsanız, bu Altın Kaplama olarak anılır.

Ve Altın Kaplama, PMI’a göre kesinlikle yapılmamalıdır çünkü projenin kapsamının kaymasına veya gereksiz ekstraların ortaya çıkmasına sebep olur.

Peki ya gerçekten proje ortasında baştan müşteriyle konuşmadığımız bir konuda müşterinin ihtiyacını farkedersek ne yapmalıyız?

Yapılacak işlem basit; Bu ihtiyacı “jest yapmış” gibi göstermek yerine, müşterimizi çağıracağız, kapsama yeni bir içeriğin daha eklenmesi gerektiğini söyleyeceğiz, (gerekirse ek süre veya maliyetin olduğunu söyleyeceğiz) kabul ederse, Proje Gereksinim Dokümanı, Proje Kapsam Bildirimi, İş Kırılım Yapısı, güncellenecek, ek süre ve maliyet ihtiyacı doğarsa, bu planlar da güncellenecek ve proje yeni kapsamıyla kaldığı yerden devam edecek.

Tutkulu PY’den Mektup – 2

Sevgili Proje Koçu,

Bundan 3 ay önce üst yönetim tarafından şirketim için önemli bir projeye, proje yöneticisi olarak atandım. Gerekli hazırlıkları yaptıktan sonra atandığım projenin 1 sene süreceği ve 10 kişi ile çalışmam gerektiğini hesapladım ve üst yönetime bu konuda bilgi verdim.

Üst yönetimimden tam destek aldım. 10 kişilik bir ekip oluşturuldu ve projemiz için 1 sene süre kabul edildi. Ekip üyeleri başta çok heyecanlı ve istekliydi. Yönetimin de tam desteğini almış görünüyorduk.

Bir ay sonra ekip üyelerimden bir tanesini yeni başlayan bir başka projeye atandığını söyleyen bir e-mail aldım. Artık 9 kişi kalmıştık. Çok fazla problem etmedim, eksilen 1 kişinin işlerini üstlenebilirdik.

Aradan bir ay daha geçti, geçmedi bir takım arkadaşım işten ayrıldı. İkinci ayın sonunda 8 kişi kalmıştık.

Aradan bir ay daha geçti ki takım üyelerimizden bir tanesinden 3 aydır hiç verim alamadığımı farkettim. Bu da 7 kişi kaldığımız anlamına geliyordu. Şimdi ben, proje yöneticisi olarak koordinasyon görevinden çok, proje işlerini yapmakla uğraşıyorum.

Size sorum şu; planları değiştirmeli miyim? Yani 1 senelik süre hedefini 10 kişinin sürekli çalışacağını varsayarak, belirlemiştim. Şimdi 7 kişiyiz ve yavaş yavaş zaman programının gerisine düşme riskimiz ortaya çıkmaya başladı. Bu durumda olan birisine ne önerirsiniz?

Rumuz: Tutkulu PY

————————————-

 Sevgili Tutkulu PY,

Proje planını sadece Zaman Diyagramı olarak düşünme. Bu pek çok kişinin yaptığı bir hatadır. Proje planı, zaman, maliyet, kapsam, insan kaynakları, iletişim vb. ile bir bütün olarak düşünülmelidir.

Yani, bu faktörlerden bir tanesi değişse, bir diğer faktörün değişeceği açıktır. Özellikle İnsan Kaynakları sayısı, doğal olarak, zamanı, maliyeti ve hatta kaliteyi etkileyebilir. Bu gözle değerlendir, lütfen. Eksilen 3 kişiden boşalan aktivitelerin neler olduğunu ortaya çıkar. Kalan 7 kişi ile bu aktivitelerin kimler tarafından yapılacağını belirle ve sürelerini yeniden tahminle. Eğer kaynak darboğaz sorunu ile karşılaşırsan, kaynak dengeleme işlemini yapmayı unutma. Kritik yola da dikkat et, diyeceğim ama boşver kafanı çok karıştırma…

İşte, bu işlemlerin sonunda proje süresini yeniden ortaya çıkar ve son halini üst yönetime götür ve uzama söz konusu ise sebeplerini açık ve net olarak, ortaya koy. Onay aldıktan sonra yeni planı proje ekip üyeleriyle paylaş ve yoluna devam et.

Yolun açık olsun.

Proje Koçu

Kapsam ile Kalitenin İlişkisi

Bir projenin kapsamının daralması, kalitesinin düşmesi anlamına gelir mi? Bu soruyu duyan pek çok kişi bir tereddüt yaşıyor. Bu soruya evet veya hayır demek kolay değil. Ben konuya “algı meselesi” olarak bakıyorum.

PMBOK’ta çok beğendiğim bir örnek vardır. Bir yazılım satın aldığınızı düşünün; Satan kuruluş, bu yazılımın çok fazla fonksiyonu olduğunu söylemiş olsun. Yani bir yazılım alarak, şirketinizdeki pek çok meseleyi tek bir merkezden halledeceksiniz. Bir taşla bir sürü kuş vuracaksınız. Firmaya inandınız ve yazılım satın aldınız, diyelim. Yazılıma baktığınızda gerçekten bir çok fonksiyonu var fakat çalıştırdığınızda yanlış sonuçlar veriyor, hatalı işlemler yapıyor veya çok geç yapıyor, kimi zaman hiç yapmıyor.

Böyle bir ürünü mü tercih edersiniz, yoksa daha dar fonksiyonlu ama en azından istediğiniz gibi hatasız çalışan bir ürünü mü?

Bence kapsam ile kalite arasındaki farkı en iyi anlatan örnek budur.

Çıkan sonuç: kapsamı geniş tutup, zamanında yetiştirmek adına kalitesiz, bir şey yapmaktansa, daha dar kapsamlı fakat kalite kriterlerinden ödün verilmemiş bir proje çok daha başarılı görülecektir.

Bazen Proje Yöneticisi zamanı baskısı yüzünden kaliteden feragat etmeyi tercih ediyor. Halbuki, müşteri ile açıkça konuşmalı, beklentilerin bir bölümünü bir sonraki faza aktarmanın daha doğru olacağına, kalitenin vazgeçilmez bir başarı göstergesi olduğuna ikna etmelidir.

Burada iletişim çok büyük önem taşıyor çünkü eğer Proje Yöneticisi, müşteriye haber vermeden kapsamı daraltırsa, müşteri gözündeki algı, ürünün kalitesinden feragat edildiği yönünde olacaktır. Müşteri gözündeki kapsam ve kalite algısını oluşturmak ve yönlendirmek, Proje Yöneticisinin görevleri arasındadır.

MS Project’te Kilometretaşları

PMBOK’a göre bir “Kilometretaşı Raporu”, üst yönetime özet bilgi vermek için sunulur. Böylece üst yönetime, projenin ara hedefleri de sunulmuş olur.

MS Project’te proje planı hazırlarken, projenizin ikinci satırına (1. satırda projenin adı yazıyor) “Proje Başlangıcı” diye bir aktivite yazmanızı ve bunun da süresini “0” (sıfır) yapmanızı tavsiye ediyorum. Benzer şekilde planın en son aktivitesi de “Proje Teslimi”, “Proje Kapanışı” gibi ifadelerden birini yazarak, bunu da kilometretaşı olarak, gösterin.

Bunun yanısıra, proje içindeki ana aşamalrın da özellikle son aktivitelerini kilometretaşı olarak, göstermenizde fayda var. Böylece, projenin hangi aşaması hangi tarihte bitecek, bir diğer ifadeyle, projenin ara hedeflerine hangi tarihlerde ulaşılabilecek, bilgisini görmek koalylaşacaktır.

Projenin gerçekleşme verilerini toplarken de eğer aktivite sürelerinde herhangi bir sapma var ise, gelen değişikliklerin hangi ara hedefleri, ne kadar etkilediğini de kolaylıkla görebilirsiniz.

Bunun için MS Project’in filtreler bölümünde “Milestone” veya raporlar bölümündeki “Milestone Report” araçlarını kullanmanızı işinizi kolaylaştıracaktır.