28 Mayıs'ta MCM Group tarafından düzenlenen 1. Ulusal Proje Meslek Konferansı konuşmamın konusu "Projelerde Proaktif Davranmak için Kazanılmış Değer Analizi" idi. Öncelikle konferans hakkında kısa bir bilgi vermek isterim;
http://www.upmk.org/ adresinden de detaylı bilgiye ve detaysız fotoğraflara :) erişebileceğiniz gibi, konferans ülkemizde Proje Yönetiminin bir meslek olarak benimsenmesini hedeflemekte. Devlet ve özel sektördeki Proje Yönetimi uygulamaları konusunda faydalı paylaşımlar yapılan konferansın geleneksel bir yapıya dönüşmesini ümid etmekteyim.
http://www.mcm.web.tr/images/stories/6MehmetGUZELISBANKASI.pdf bağlantısından erişebileceğiniz sunumumda Kazanılmış Değer Analizinin standart tanımının yanı sıra pratik hayattaki kullanımı, nasıl ve ne zaman kullanılması gerektiği, analiz sonuçlarının yorumlanması konusunda bilgi paylaşımında bulundum. Kazanılmış Değer Analizi ile ilgili detaylı yazımı http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kazanlms-deger-analizi.html adresinde bulabilirsiniz.
Bunun yanısıra vurgulamak istediğim nokta; kazanılmış değer analizi konusunda projenin ilk gününden itibaren sonuçların takibinin önemidir. Proje ilerledikçe; SPI ve CPI değerlerini yakalamanın maliyetini ne kadar dramatik boyutlara eriştiğini sunumun 15. slide'ındaki grafikten de görebilirsiniz.
Sunumumun ve yazımın önemli noktası şudur;
Sonuç olarak, Kazanılmış Değer Analizi sadece bir analizdir size mesaj verir bu mesajı doğru algılamak, kendinize itiraf etmek ve aksiyon almak Proje Yöneticilerinin yönetmesi gereken bir süreçtir. 1 senelik bir projeye ilk 10 gün için “gecikti” diyebilir miyiz? Evet diyebiliriz ve hatta durum bu ise demeliyiz de. Kazanılmış Değer Analizi verilerinin sponsor, müşteri ve diğer paydaşlar tarafından ciddiye alınması bu değerlerin öneminin farkındalığına vardırılması biz Proje Yöneticilerinin görevidir.
Proje Yönetimi etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Proje Yönetimi etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
14 Haziran 2010 Pazartesi
6 Ekim 2009 Salı
Critical Path Method CPM - Kritik Yol
Critical Path Method, birden çok adımdan oluşan bir projenin, süresini belirleyen adımlar serisidir. Eminim daha önce bu konuda herhangi bir çalışma yapmamış kişiler bu açıklamadan pek birşey anlamamıştır. CPM hakkında bilgi sahibi olanlar da bu açıklama ile bildiklerini unutmadan hemen güncel hayattan bir örnekle açıklamayı "açıklayayım".
Öncelikle Projemizin adı "Yeni Kiralanan Evinize Taşınma". Projemizin bazı varsayımları var; Öncelikle evde şu anda başka bir kiracı oturmakta ve yeni evinize yeni eşyalarla yerleşmek istiyorsunuz. Bu doğrultuda projemizin adımları şu şekilde;
Bu projede hangi adımlar gecikirse eve taşınma işlemi ertelenir. 5 Task'i olan bir proje için gözle bu tespit yapılabilir,
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Yeni eşyaların teslimi
Bu 3 adımdan herhangi birinin gecikmesi taşınmayı direkt geciktirecektir. Peki ya diğer adımlar gecikirse taşınma etkilenmez mi? Bu sorunun cevabını vermek için bir veriye daha ihtiyacımız var. Diğer adımlar "ne kadar" gecikirse taşınmamız ertelenir?
İşte Critical Path üzerinde olmayan adımların projeyi etkilemeyen gecikme süresine "slack" zamanı denir. Minimum (genelde 0) slack süresine ait adımlar Critical Path'i oluşturur.
"Elektrik / Su / Doğalgaz Devir İşlemleri" için slack 2 gündür. İlgili adım 1 ya da 2 gün gecikir ise taşınma işlemi ertelenmeyecektir. Bürokratik belediye işlemlerinin 16'sında tamamlanması bizim proje süremizi etkilemez. Fakat ilgili adım 3 gün geç başlar ya da planlanandan daha uzun sürer ise (mesela 8 gün) bu sefer projenin critical path'i değişir ve tamamlanma süresi etkilenir. Yeni plan şu şekilde olacaktır;
Yeni Critical Path ise;
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Elektrik / Su / Doğalgaz Devir İşlemleri
Burada Critical Path'in nasıl hesaplandığı bilgisi verilmeyecektir. Her modern proje yönetim aracı bu yöntemi uygulayabilir. Burada dikkat edilmesi gereken hususlar vardır. Adımların sadece mantıksal bir şekilde birbirlerini izlemediği (örneğin Eşyaların teslim edilmesi için evin boyanmış olması gerekir) aynı zamanda ortak kaynak kullanan adımların da birbirlerinin önkoşulu olabileceği gözden kaçırılmamalıdır. Eğer Evi kendiniz boyasaydınız, "Elektrik / Su / Doğalgaz Devir İşlemleri" ancak 15'inde başlayabilecekti.
Bir diğer önemli konu da plandaki her değişimden sonra Critical Path'in tekrar hesaplanması gerekliliğidir.
Öncelikle Projemizin adı "Yeni Kiralanan Evinize Taşınma". Projemizin bazı varsayımları var; Öncelikle evde şu anda başka bir kiracı oturmakta ve yeni evinize yeni eşyalarla yerleşmek istiyorsunuz. Bu doğrultuda projemizin adımları şu şekilde;
Bu projede hangi adımlar gecikirse eve taşınma işlemi ertelenir. 5 Task'i olan bir proje için gözle bu tespit yapılabilir,
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Yeni eşyaların teslimi
Bu 3 adımdan herhangi birinin gecikmesi taşınmayı direkt geciktirecektir. Peki ya diğer adımlar gecikirse taşınma etkilenmez mi? Bu sorunun cevabını vermek için bir veriye daha ihtiyacımız var. Diğer adımlar "ne kadar" gecikirse taşınmamız ertelenir?
İşte Critical Path üzerinde olmayan adımların projeyi etkilemeyen gecikme süresine "slack" zamanı denir. Minimum (genelde 0) slack süresine ait adımlar Critical Path'i oluşturur.
"Elektrik / Su / Doğalgaz Devir İşlemleri" için slack 2 gündür. İlgili adım 1 ya da 2 gün gecikir ise taşınma işlemi ertelenmeyecektir. Bürokratik belediye işlemlerinin 16'sında tamamlanması bizim proje süremizi etkilemez. Fakat ilgili adım 3 gün geç başlar ya da planlanandan daha uzun sürer ise (mesela 8 gün) bu sefer projenin critical path'i değişir ve tamamlanma süresi etkilenir. Yeni plan şu şekilde olacaktır;
Yeni Critical Path ise;
1-Mevcut kiracının evi geç boşaltması
3-Evin Boyanması
4-Elektrik / Su / Doğalgaz Devir İşlemleri
Burada Critical Path'in nasıl hesaplandığı bilgisi verilmeyecektir. Her modern proje yönetim aracı bu yöntemi uygulayabilir. Burada dikkat edilmesi gereken hususlar vardır. Adımların sadece mantıksal bir şekilde birbirlerini izlemediği (örneğin Eşyaların teslim edilmesi için evin boyanmış olması gerekir) aynı zamanda ortak kaynak kullanan adımların da birbirlerinin önkoşulu olabileceği gözden kaçırılmamalıdır. Eğer Evi kendiniz boyasaydınız, "Elektrik / Su / Doğalgaz Devir İşlemleri" ancak 15'inde başlayabilecekti.
Bir diğer önemli konu da plandaki her değişimden sonra Critical Path'in tekrar hesaplanması gerekliliğidir.
11 Eylül 2009 Cuma
Proje Ekibinin Performansın Ar++ırmak için Motivasyon
Motivasyon, proje ekibinin büyük hedeflere ulaşması için gerekli, ilhamı, cesareti ve teşviki sağlar.
Motivasyon için iki zıt Teorinin çok yaratıcı isimleri yoktur; "X Teorisi" ve "Y Teorisi"
X Teorisi; Proje ekip elemanlarının, tembel, fazla sorumluluk almaktan kaçınan, cezalandırma ile çalışan kişiler olduğunu varsayar. Bu tip çalışanlardan oluşmuş bir projenin yöneticisi, otoriter, sert bir yöneticilik tavrı sergilemekle beraber projenin zaman ve maliyet açısından kontrollerini çok daha sık yapmalıdır.
Çalışanlarının kendilerini geliştirmeye hevesli olduğu, işini seven, çalışkan kişilerden oluştuğu varsayımı ile ortaya çıkan "Y Teorisidir". Bu tip çalışanlardan oluşan ekibin yönetimi için kontrollerin daha az aralıklarla ya da çalışanlara daha az hissettirilerek yapılması. gerekmektedir. Ayrıca çalışanları pozitif değerlendirerek ve onlara sahip çıkarak işlerini sahiplenmelerinin sağlanması da ekip motivasyonu için önemlidir.
Bu iki teori hakkında yapılabilecek en büyük hata X ve Y tipi çalışanların beraber bulundukları bir ekip oluşturmaktır. X tipi bir çalışana Y yönetim yöntemlerini uygulanması,ya da tam tersi bir davranış kesinlikle demotive edicidir. Aynı ekipteki elemanlara bu kadar zıt yaklaşılması tamamen bir kaos ortamının habercisidir.
KITA (Kick in the pants) Teorisi hem pozitif hem de negatif motive edici faktörlerin olduğunu varsayar. Yöneticilerin havuçlara(Ödüller) ve sopalara(Cezalar) ihtiyacı vardır. Bir Proje Yönetimi Seminerinde Proje Yöneticisi için "Şirkette sorumluluğu olan ama gücü olmayan kişiler" olarak tanımlandığına şahit olmuştum. Buradaki güçten kazıt havuç ve sopalar. Özellikle Proje Bazlı organizasyon şemasını uygulamayan şirketlerde proje Yöneticilerine güç olarak havuç yerine "havuç suyu" sopa yerine de "kürdan" verilir. KITA teorisi Proje Yöneticisi ve proje takım elemanını anne/baba - çocuk ilişkisine benzer bir ilişkide görür. Bu tip bir ilişki, Proje Yöneticisinin kendini kompetan olarak görmesini sağlayabilir ve proje ekibinin kendine güvenini zedeleyebilir.
Başarı (Achievement) motivasyon teorisinde ekip elemanlarına çok net ve zorlayıcı hedeflere ulaşması beklenir. Bu şekilde motive olmuş kişiler için büyük dezavantaj, durulması gereken yerin bilinmemesi ve başarıya ulaşılmayan durumların kabullenilmemesidir.
Bağlılık (Affiliation) motivasyon teorisi, ekip içi ilişkilerle motive olunduğunu savunur. Bu şekilde motive olan kişiler takım içinde iyi çalışmakla beraber tek başlarına çok da başarılı olamazlar. Bu nedenle Proje Yöneticisi görev tanımlarını ve dağılımlarını yaparken birden çok ekip elemanının beraber çalışmasını sağlamalı.
Güçle motive etmek. Bu şekilde motive olabilen proje elemanlarına daha fazla sorumluluk ve güç verilir. Böylece proje yöneticisine daha fazla yardımcı olur, ekibe liderlik eebilir. Bu şekilde motive edilen kişiler üzerinde Proje Yöneticisi kontrolü kaybetmemelidir.
Motivasyonla ilgili en sık yapılan hatalar;
- Beni motive eden şey başkalarını da motive eder.
- İnsanlar parayla motive olur.
- Profesyonel insanların motivasyona ihtiyacı yoktur.
- Bir sorun çıktığında motive ederim
Proje Yöneticisi her insan için farklı motivasyon faktörünü tespit etmeli ve uygulamalı ama unutmamalı ki bazı yöntemlerin beraber uygulanması çok daha kötü sonuçlar elde edilmesine neden olabilir. Bir takım kültürü oluşturulduğu takdirde Proje Yöneticisinin işi çok daha kolay olur. Takım Kültürü oluşturmak için;
- Herkesin rolünü çok net belirleyin
- Takımın uygulaması gereken süreçleri iyi tanımlayın.
- Motive edici bir ortam hazırlayın.
- Takımı ve elemanlarını ödüllendirin.
- Güvenilir olun, takım çalışmasını teşvik edin ve iletişime açık olun.
- Takım elemanlarının güçlü ve zayıf yanlarını iyi analiz edin.
- Olgun bir takım oluşturun.
- Projenin başarısını ödüllendirin.
2 Haziran 2009 Salı
Proje Yönetimi - Kazanılmış Değer Analizi (Earned Value Management)
Kazanılmış Değer Analizi (EVM ya da EVA) projelerin maliyet ve bütçe ölçeğinde plana ne kadar uygun gittiğini ölçen bir analiz yöntemidir. Projelerin gidişatı hakkında üst yönetim ya da sponsor tarafından gelen takip sorularına; "Çok iyi gidiyor", "Plana uygun gidiyoruz", "Mükemmel" gibi yalan ve optimist cevaplar vermek de bir yöntem. Fakat bu yöntem özellikle projenin son aşamalarına doğru ciddi zararlara sebebiyet verebilir. Herşeyden önce projenin gidişatını kendimize objektif olarak itiraf etmeliyiz ki projenin kötü gidişatını önceden görüp, ilgili önleyici faaliyetleri alabilelim.
Kazanılmış değer analizi için elimizde proje hakkında 3 veri olması gerekir. Planlanan değer, Gerçekleşen değer ve Kazanılmış değer. Bu değerlerin açıklaması için örneğimi çok basit tutacağım. Farzedelim ki kare şeklinde bir arsanız var. Projeniz bu arsanın etrafını çitle çevirmek. Bir usta ile anlaşıyorsunuz; Usta ile, çit maliyeti dahil günlüğü 100TL'ye 4 günde arsayı çevirmek üzere anlaşıyorsunuz. İşe başlanıyor. Siz ustaya ödemeyi her gün sonunda yapıyorsunuz. Usta işe başladıktan 3 gün sonra arsaya gidip durumu kontrol ediyorsunuz. Bir de bakıyorsunuz ki usta 3 gün sonunda sadece 1 kenarı çitle çevirebilmiş. Siz de adama kızıp, son günlüğü vermiyorsunuz ve 3 gün için toplam 200TL ödeme yapıyorsunuz.
Buradaki Planlanan değer(Planned Value); 300 TL'dir yani 3 gün sonunda ustadan 3 kenarın çitle çevrilmesini planlamıştınız ve bunun maliyeti 100(kenar başına planlanan maliyet) X 3 = 300TL'dir
Gerçek Değer(Actual Cost); Herşey yalan cebinizden çıkan para gerçek. Ustaya kızdığınız için 200 TL cebinizden maliyet çıktı.
Kazanılmış Değer(Earned Value); Ustanın çıkardığı iş yani 3 günde projeye katkısı; Sadece 1 kenar yani 100 TL
Kazanılmış değer analizinde 2 önemli Indeks vardır; CPI(Cost Performance Index) ve SPI(Schedule Performance Index).
CPI bütçe açısından projenin durumunu gösterir; Değerin 1 çıkması tam olarak planlanan bütçede projenin ilerlediğini gösterir. 1'in altındaki değerler, planlanan bütçeden daha maliyetli bir şekilde projenin ilerlediğini, 1'in üzerindeki değerler, planlanan bütçeden daha ucuz bir şekilde projenin ilerlediğini ifade eder. CPI formulü; "Kazanılmış Değer" / "Gerçek Değer" dir. Bizim örneğimizde; 100 / 200 = 0,5'tir. proje planladığımızdan daha pahalı bir şekilde ilerlemektedir. Projenin tahmini bitiş maliyeti; "Planlanan Maliyet / CPI" 'dır.
Yani bizim örneğimizde; 400 / 0,5 = 800TL'ye bu cit işlemi tamamlanır. Bu ustayla devam edilirse planladığınızın 2 katı maliyetle biter bu iş hem de ustaya kızıp daha az ödeme yapmış olmanıza rağmen.
SPI süre açısından projeyi yorumlar. Yorumlanması CPI ile aynıdır.
SPI'in formülü "Kazanılmış Değer" / "Planlanan Değer" yani bizim örneğimizde; 100 / 300 = 0,33'tür ki bir proje için çok dramatik bir değerdir. Bu SPI değerine göre Planlanan Süre / SPI formülü uygulandığında projenin tahmini bitiş süresini elde edebilirsiniz. 4 günde bitmesi planlanan çit çevirme işlemi; 4 / 0,33 = 12 günde tamamlanır. Bu usta ya hesap yapmayı bilmiyor ya da hiç dayak yememiş.
Kazanılmış Değer Analizi, bu basit örnekten yola çıkarak daha büyük projelere da aynı mantık ile uygulanabilir. Şirket bünyesinde yürütülen projelerde kazanılmış değerler, projenin o aşamasına kadar insan kaynaklarına ödenen maaş ya da prim ve proje hakkındaki ekstra maliyetler(ulaşım ücretleri, ofis kiraları vs.) olabilir.
Kazanılmış Değer Analizi hakkında bir diğer önemli konu ise; CPI ve SPI değerlerinin projenin başlangıç aşamalarında şekillendiğinin ve belirli bir noktadan sonra bu değerler üzerinde ciddi düzenlemeler yapmanın çok zor olacağıdır. Örneklemek gerekirse; 1 senelik bir projenin ilk 2 ayında CPI ve SPI değerlerimiz 0,8 civarında ise plan üzerinde değişiklik yapılmadığı sürece bu değerin 1'e taşınmasının çok zor olduğudur. Bu nedenle sapmalar tespit edildiği anda önleyici aksiyonların alınmasında fayda vardır. Bizim örneğimize gerçeklersek; 3. gün değil de 1. gün kontrole gelinse ustanın yan gelip yattığının tespiti daha kolay olur ve usta değiştirmek(önleyici aksiyon), 3. günde usta değiştirmektense işi daha az zamanda ve maliyette tamamlanmasını sağlayacaktır.
Kazanılmış değer analizi için elimizde proje hakkında 3 veri olması gerekir. Planlanan değer, Gerçekleşen değer ve Kazanılmış değer. Bu değerlerin açıklaması için örneğimi çok basit tutacağım. Farzedelim ki kare şeklinde bir arsanız var. Projeniz bu arsanın etrafını çitle çevirmek. Bir usta ile anlaşıyorsunuz; Usta ile, çit maliyeti dahil günlüğü 100TL'ye 4 günde arsayı çevirmek üzere anlaşıyorsunuz. İşe başlanıyor. Siz ustaya ödemeyi her gün sonunda yapıyorsunuz. Usta işe başladıktan 3 gün sonra arsaya gidip durumu kontrol ediyorsunuz. Bir de bakıyorsunuz ki usta 3 gün sonunda sadece 1 kenarı çitle çevirebilmiş. Siz de adama kızıp, son günlüğü vermiyorsunuz ve 3 gün için toplam 200TL ödeme yapıyorsunuz.
Buradaki Planlanan değer(Planned Value); 300 TL'dir yani 3 gün sonunda ustadan 3 kenarın çitle çevrilmesini planlamıştınız ve bunun maliyeti 100(kenar başına planlanan maliyet) X 3 = 300TL'dir
Gerçek Değer(Actual Cost); Herşey yalan cebinizden çıkan para gerçek. Ustaya kızdığınız için 200 TL cebinizden maliyet çıktı.
Kazanılmış Değer(Earned Value); Ustanın çıkardığı iş yani 3 günde projeye katkısı; Sadece 1 kenar yani 100 TL
Kazanılmış değer analizinde 2 önemli Indeks vardır; CPI(Cost Performance Index) ve SPI(Schedule Performance Index).
CPI bütçe açısından projenin durumunu gösterir; Değerin 1 çıkması tam olarak planlanan bütçede projenin ilerlediğini gösterir. 1'in altındaki değerler, planlanan bütçeden daha maliyetli bir şekilde projenin ilerlediğini, 1'in üzerindeki değerler, planlanan bütçeden daha ucuz bir şekilde projenin ilerlediğini ifade eder. CPI formulü; "Kazanılmış Değer" / "Gerçek Değer" dir. Bizim örneğimizde; 100 / 200 = 0,5'tir. proje planladığımızdan daha pahalı bir şekilde ilerlemektedir. Projenin tahmini bitiş maliyeti; "Planlanan Maliyet / CPI" 'dır.
Yani bizim örneğimizde; 400 / 0,5 = 800TL'ye bu cit işlemi tamamlanır. Bu ustayla devam edilirse planladığınızın 2 katı maliyetle biter bu iş hem de ustaya kızıp daha az ödeme yapmış olmanıza rağmen.
SPI süre açısından projeyi yorumlar. Yorumlanması CPI ile aynıdır.
SPI'in formülü "Kazanılmış Değer" / "Planlanan Değer" yani bizim örneğimizde; 100 / 300 = 0,33'tür ki bir proje için çok dramatik bir değerdir. Bu SPI değerine göre Planlanan Süre / SPI formülü uygulandığında projenin tahmini bitiş süresini elde edebilirsiniz. 4 günde bitmesi planlanan çit çevirme işlemi; 4 / 0,33 = 12 günde tamamlanır. Bu usta ya hesap yapmayı bilmiyor ya da hiç dayak yememiş.
Kazanılmış Değer Analizi, bu basit örnekten yola çıkarak daha büyük projelere da aynı mantık ile uygulanabilir. Şirket bünyesinde yürütülen projelerde kazanılmış değerler, projenin o aşamasına kadar insan kaynaklarına ödenen maaş ya da prim ve proje hakkındaki ekstra maliyetler(ulaşım ücretleri, ofis kiraları vs.) olabilir.
Kazanılmış Değer Analizi hakkında bir diğer önemli konu ise; CPI ve SPI değerlerinin projenin başlangıç aşamalarında şekillendiğinin ve belirli bir noktadan sonra bu değerler üzerinde ciddi düzenlemeler yapmanın çok zor olacağıdır. Örneklemek gerekirse; 1 senelik bir projenin ilk 2 ayında CPI ve SPI değerlerimiz 0,8 civarında ise plan üzerinde değişiklik yapılmadığı sürece bu değerin 1'e taşınmasının çok zor olduğudur. Bu nedenle sapmalar tespit edildiği anda önleyici aksiyonların alınmasında fayda vardır. Bizim örneğimize gerçeklersek; 3. gün değil de 1. gün kontrole gelinse ustanın yan gelip yattığının tespiti daha kolay olur ve usta değiştirmek(önleyici aksiyon), 3. günde usta değiştirmektense işi daha az zamanda ve maliyette tamamlanmasını sağlayacaktır.
28 Mayıs 2009 Perşembe
Proje Yönetimi Kestirim Yöntemleri
Kestirim, aslında hayatımızın her aşamasında her zaman yapıyoruz. Akşam işten çıkıldığında eve varış saatimizi kestiriyoruz, arabanın frenine ne zaman basarsak kırmızıda durabileceğimizi (ya da gaza ne kadar basarsak yakışıklı fotoğramız çekilmeden trafik ışıklarından geçebileceğimizi) hep kestiriyoruz. Bu kestirimler daha çok geçmiş benzer tecrübelere dayanarak bilinçli ya da bilinçaltımızdan yapıyoruz.
Profesyonel hayatta yapılan kestirimlerin kalitesi ve doğruluğu şirkete itibar ve para kazandırabilir/kaybettirebilir. Proje Yönetiminde kestirimler daha çok zaman/bütçe skalasında yapılır. Tabii ki bunlar teoride olan yaklaşımlar özellikle IT projelerinde yöneticileriniz kestirimleri sizler adına yapmış olur. "sene sonuna kadar bitsin" cümlesi ile "detaylı" bir kestirim yaparak sizi bu yorucu ve sıkıcı süreçten kurtarmış olabilir.
Tabii ki daha bilimsel kestirim yöntemleri vardır. Kestirimler projelerin her aşamasında yapılabilir ve aşağıdaki grafikte göründüğü gibi, projenin ilerleyen aşamalarında kestirimler daha net sonuç verebilir. Projenin kapanış kokteylinde, projenin son içki içildikten sonra kapanacağını kestirebilirsiniz.
Yapılan kestirimlere göre projenin gidişatının takibi, EVA(Earned Value Analysis) Kazanılmış Değer Analizi ile yapılır. EVA, projenin gidişatının bütçe ve zaman çerçevesinde analiz eder. Daha detaylı bilgiye http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kazanlms-deger-analizi.html yazısından ulaşabilirsiniz.
Kestirim yöntemlerinde sıklıkla başvurulan kaynaklar, geçmiş projelerden üretilen veriler ve uzman görüşleridir. Özellikle IT projelerinde kullanılan kestirim yöntemleri; Kestiri yöntemi üzerindeki bağlantıdan yöntemle ilgili detaylı bilgiye erişebilirsiniz.
1- Butom up Kestirim
2- Top Down Kestirim
3- Parametrik Kestirim / COCOMO
4- Delphi Kestirim
5- Function Point Kestirim
6- Uzman Görüşü
7- PERT
Profesyonel hayatta yapılan kestirimlerin kalitesi ve doğruluğu şirkete itibar ve para kazandırabilir/kaybettirebilir. Proje Yönetiminde kestirimler daha çok zaman/bütçe skalasında yapılır. Tabii ki bunlar teoride olan yaklaşımlar özellikle IT projelerinde yöneticileriniz kestirimleri sizler adına yapmış olur. "sene sonuna kadar bitsin" cümlesi ile "detaylı" bir kestirim yaparak sizi bu yorucu ve sıkıcı süreçten kurtarmış olabilir.
Tabii ki daha bilimsel kestirim yöntemleri vardır. Kestirimler projelerin her aşamasında yapılabilir ve aşağıdaki grafikte göründüğü gibi, projenin ilerleyen aşamalarında kestirimler daha net sonuç verebilir. Projenin kapanış kokteylinde, projenin son içki içildikten sonra kapanacağını kestirebilirsiniz.
Yapılan kestirimlere göre projenin gidişatının takibi, EVA(Earned Value Analysis) Kazanılmış Değer Analizi ile yapılır. EVA, projenin gidişatının bütçe ve zaman çerçevesinde analiz eder. Daha detaylı bilgiye http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kazanlms-deger-analizi.html yazısından ulaşabilirsiniz.
Kestirim yöntemlerinde sıklıkla başvurulan kaynaklar, geçmiş projelerden üretilen veriler ve uzman görüşleridir. Özellikle IT projelerinde kullanılan kestirim yöntemleri; Kestiri yöntemi üzerindeki bağlantıdan yöntemle ilgili detaylı bilgiye erişebilirsiniz.
1- Butom up Kestirim
2- Top Down Kestirim
3- Parametrik Kestirim / COCOMO
4- Delphi Kestirim
5- Function Point Kestirim
6- Uzman Görüşü
7- PERT
Proje Yönetimi Kestirim Yöntemleri - Top Down Kestirim
Top Down Kestirim Yöntemi aslında projenin tamamının değil parçalarının kestirimi için kullanılır. Farklı kestirim yöntemleri ila yapılan proje tahminlemelerinden projenin aşamalarının kestirimleri yapılır.
Yazılım Geliştirme Projesi için, proje süresinin %50'si geliştirme faaliyetinde geçer, %25'i test faaliyeti için ayrılır gibi şirket özelinde ya da dünya standartlarında kullanılan oranlarla proje adımlarının kestirimleri yapılabilir.
Yazılım Geliştirme Projesi için, proje süresinin %50'si geliştirme faaliyetinde geçer, %25'i test faaliyeti için ayrılır gibi şirket özelinde ya da dünya standartlarında kullanılan oranlarla proje adımlarının kestirimleri yapılabilir.
Proje Yönetimi Kestirim Yöntemleri - Buttom Up Kestirim
Buttom - Up Kestirim, yöntemi adından da anlaşılacağı gibi, projeyi oluşturan daha küçük parçalar bazında kestirim yapılması esasına dayanır. Nedir bu parçalar? İş Kırılım Yapısını oluşturan elemanlar, kestirim için atomik bir ölçüdür.
Buttom-up Kestirim yöntemi için de uygulanması gereken bir süreç vardır; (Süreçsiz olmaz.)
1 - İş Kırılım Yapısını Oluştur
2 - Her görev için kaynak kestirimi yap
3 - Projenin kilometretaşlarını (Milestone) her perspektiften çıkart(Müşteri Odaklı, Yönetim Odakli, Süreçlerin Gerektirdiği)
4 - Her kilometretaşı için bitiş günü belirle
5 - İş(Proje) Planını oluştur. Görevlerin ilişkilerini belirle
6 - Kaynakları görevlere ata
7 - Görev sürelerini tahminle
8 - Critical Path'ı hesapla
9 - Daha önce belirlenen günlerle İş Planında kestirilmiş görevlerin günlerini karşılaştır.
10 - İş Planını düzenle (2,6,7,8 numaralı adımlar tekrarlanabilir ya da süreler için müşteri ile tekrar pazarlık yapılabilir)
11 - Riskleri belirle ve değerlendir
12 - Proje gelişimi sırasında risklerin oluşması ya da öngörülmeyen bir gelişmenin olması durumlarında planı düzenle.
Her kestirim yönteminin olduğu gibi Buttom Up yönteminin de dezavantajları vardır. Bunlardan ilki bu kestirim yönteminin ciddi zaman almasıdır. Her kestirim yönteminde olduğu gibi elde olan veri ne kadar sağlıklı ise o oranda doğru bir kestirim yapılabilir. İş Kırılım yapısının eksiksiz yapılması çok önemlidir.
En küçük görevleri de dahil ettiği için buttom up kestirim yöntemi diğer yöntemlere göre daha gerçekçi sonuçlar verebilir. Ayrıca bu yöntemle görevler arasındaki ilişki de belirlenerek daha doğru süre taahütlerinin verilmesi sağlanmaktadır.
Buttom-up Kestirim yöntemi için de uygulanması gereken bir süreç vardır; (Süreçsiz olmaz.)
1 - İş Kırılım Yapısını Oluştur
2 - Her görev için kaynak kestirimi yap
3 - Projenin kilometretaşlarını (Milestone) her perspektiften çıkart(Müşteri Odaklı, Yönetim Odakli, Süreçlerin Gerektirdiği)
4 - Her kilometretaşı için bitiş günü belirle
5 - İş(Proje) Planını oluştur. Görevlerin ilişkilerini belirle
6 - Kaynakları görevlere ata
7 - Görev sürelerini tahminle
8 - Critical Path'ı hesapla
9 - Daha önce belirlenen günlerle İş Planında kestirilmiş görevlerin günlerini karşılaştır.
10 - İş Planını düzenle (2,6,7,8 numaralı adımlar tekrarlanabilir ya da süreler için müşteri ile tekrar pazarlık yapılabilir)
11 - Riskleri belirle ve değerlendir
12 - Proje gelişimi sırasında risklerin oluşması ya da öngörülmeyen bir gelişmenin olması durumlarında planı düzenle.
Her kestirim yönteminin olduğu gibi Buttom Up yönteminin de dezavantajları vardır. Bunlardan ilki bu kestirim yönteminin ciddi zaman almasıdır. Her kestirim yönteminde olduğu gibi elde olan veri ne kadar sağlıklı ise o oranda doğru bir kestirim yapılabilir. İş Kırılım yapısının eksiksiz yapılması çok önemlidir.
En küçük görevleri de dahil ettiği için buttom up kestirim yöntemi diğer yöntemlere göre daha gerçekçi sonuçlar verebilir. Ayrıca bu yöntemle görevler arasındaki ilişki de belirlenerek daha doğru süre taahütlerinin verilmesi sağlanmaktadır.
27 Mayıs 2009 Çarşamba
Proje Yönetimi Kestirim Yöntemleri - Parametrik Kestirim
Parametrik Kestirim yöntemi ciddi bir tarihsel veriye ihtiyaç duyar. Şirkette her yapılan aktivite ile ilgili verinin(ne kadar kaynakla yapıldığı, % kaç eforla tamamlandığı, ne kadar süre içerisinde bittiği vs.) muntazam saklanması gerekmektedir.
2 tür parametrik kestirim vardır. "Regression Analysis" ve "Learning Curve". Learning Curve kaynakların kendini geliştirdiği varsayımına dayanır. 100. kere bir duvar boyamak, ilk tecrübeden daha kısa sürer. Regression Analiz ise kişilere biraz daha temkinli yaklaşır ve çok düz istatistiksel bir yöntem kullanır.
Parametrik kestirim için belirlenecek parametreler tamamen kuruma özgü olabilir. Parametrelerin belirlenmesi için geçmiş veriler üzerinden excel'de LINEST komutu ile bir regresyon parametresi sağlanabilir. (Bakınız. http://support.microsoft.com/kb/828533, http://www.bionicturtle.com/learn/article/how_to_use_excels_linest_function_to_return_multivariate_regression_10_min_ )
Regresyon analizi yapılacak iki veri seti arasındaki korelasyonun da iki veri arasında mantıksal bir ilişki olduğunu kanıtlamak gerekir. (Bknz. http://office.microsoft.com/en-us/excel/HP052090231033.aspx) İki veri seti arasındaki korelasyon, -1 ve 1 arasında bir değerdir. -1 ya da 1 'e yakın değerler mantıksal bir ilişkiyi ifade eder. 1'e yakın değerler iki veri seti arasında doğru orantılı bir ilişki olduğunu ifade eder. Örneğin; Projede üzerinde çalışılan aylık saatin artması ile maliyetleri yükselmesi. -1'e yakın değerler ters orantıyı ifade eder. Proje geliştirme sürelerinin azaldıkça, müşteri memnuniyetinin artması gibi.
Kestirime başlanması için elimizde bir başlangıç verisi olması gerekmekte. Bu veri de LOC(Lines of Code) yani yazılım için gereken satır sayısını ifade eder. LOC da aslında kestirilmesi gereken bir büyüklük ölçütüdür. LOC kestirimi için Function Point Analysis yöntemi kullanılabilir. (Bknz. http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kestirim-yontemleri_1298.html) KLOC, 1000 satırlık kod anlamında kullanılmaktadır.
Efor : A * KLOCˆB
Efor burda adam/ay birimindedir.
Zaman : C * EforˆD
Zaman ölçüsü "Ay"dır.
FTE(Full Time Equivalent People) : Tam zamanlı çalışan.
FTE = Efor / Zaman
Elde edilen verilerle, üretkenlik de ölçülebilir. Burada Efor için adam/ay 'lık birimi ortalam 152 ile çarpılarak adam/saat birimine çevrilebilir.
Verimlilik : LOC / Efor * 152
Somut Örneklerden gitmek gerekirse 250,000 satırlık bir uygulamanın tespiti ve genel olarak kullanılan parametreler ile Formüllerimiz uygulanır ise;
Efor = 2.94*Boyutˆ1.1 = 2.94*250ˆ1.1 = 101.4(Adam/Ay) * 152 = 15,400 (Adam/Saat)
Time = 3.67*(101.4)ˆ0.32 = 16.1 Ay sürecek bir proje olarak öngörülüyor.
Peki bu proje için dedike kaç adama ihtiyaç vardır?
FTE = Efor / Zaman = 101,4 / 16,1 = 6,3 tam zamanlı adama ihtiyaç vardır.
Verimlilik : 25 KSLOC/15,400 (Adam/Saat) = 1.62 Satır kod bir kişi tarafından bir saatte yazılabilir.
2 tür parametrik kestirim vardır. "Regression Analysis" ve "Learning Curve". Learning Curve kaynakların kendini geliştirdiği varsayımına dayanır. 100. kere bir duvar boyamak, ilk tecrübeden daha kısa sürer. Regression Analiz ise kişilere biraz daha temkinli yaklaşır ve çok düz istatistiksel bir yöntem kullanır.
Parametrik kestirim için belirlenecek parametreler tamamen kuruma özgü olabilir. Parametrelerin belirlenmesi için geçmiş veriler üzerinden excel'de LINEST komutu ile bir regresyon parametresi sağlanabilir. (Bakınız. http://support.microsoft.com/kb/828533, http://www.bionicturtle.com/learn/article/how_to_use_excels_linest_function_to_return_multivariate_regression_10_min_ )
Regresyon analizi yapılacak iki veri seti arasındaki korelasyonun da iki veri arasında mantıksal bir ilişki olduğunu kanıtlamak gerekir. (Bknz. http://office.microsoft.com/en-us/excel/HP052090231033.aspx) İki veri seti arasındaki korelasyon, -1 ve 1 arasında bir değerdir. -1 ya da 1 'e yakın değerler mantıksal bir ilişkiyi ifade eder. 1'e yakın değerler iki veri seti arasında doğru orantılı bir ilişki olduğunu ifade eder. Örneğin; Projede üzerinde çalışılan aylık saatin artması ile maliyetleri yükselmesi. -1'e yakın değerler ters orantıyı ifade eder. Proje geliştirme sürelerinin azaldıkça, müşteri memnuniyetinin artması gibi.
Kestirime başlanması için elimizde bir başlangıç verisi olması gerekmekte. Bu veri de LOC(Lines of Code) yani yazılım için gereken satır sayısını ifade eder. LOC da aslında kestirilmesi gereken bir büyüklük ölçütüdür. LOC kestirimi için Function Point Analysis yöntemi kullanılabilir. (Bknz. http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kestirim-yontemleri_1298.html) KLOC, 1000 satırlık kod anlamında kullanılmaktadır.
Efor : A * KLOCˆB
Efor burda adam/ay birimindedir.
Zaman : C * EforˆD
Zaman ölçüsü "Ay"dır.
FTE(Full Time Equivalent People) : Tam zamanlı çalışan.
FTE = Efor / Zaman
Elde edilen verilerle, üretkenlik de ölçülebilir. Burada Efor için adam/ay 'lık birimi ortalam 152 ile çarpılarak adam/saat birimine çevrilebilir.
Verimlilik : LOC / Efor * 152
Somut Örneklerden gitmek gerekirse 250,000 satırlık bir uygulamanın tespiti ve genel olarak kullanılan parametreler ile Formüllerimiz uygulanır ise;
Efor = 2.94*Boyutˆ1.1 = 2.94*250ˆ1.1 = 101.4(Adam/Ay) * 152 = 15,400 (Adam/Saat)
Time = 3.67*(101.4)ˆ0.32 = 16.1 Ay sürecek bir proje olarak öngörülüyor.
Peki bu proje için dedike kaç adama ihtiyaç vardır?
FTE = Efor / Zaman = 101,4 / 16,1 = 6,3 tam zamanlı adama ihtiyaç vardır.
Verimlilik : 25 KSLOC/15,400 (Adam/Saat) = 1.62 Satır kod bir kişi tarafından bir saatte yazılabilir.
Proje Yönetimi Kestirim Yöntemleri - Function Point
Function Point nedir? Birçok sektörde ölçüm için dünya çapında kullanılan standart ölçü birimleri kullanılmaktadır. İnşaat Mühdendisleri, uzunluk birimlerini kullanır, makina mühendisleri beygir gücü, tork gibi terimlerle standartlaşmıştırlar(hayatımda ilk defa yazdım bu kelimeyi), elektrik - elektronik mühendisleri watt, amper gibi ölçü birimleri kullanmaktadırlar. Yazılım projelerinde, geliştirilecek olan uygulama için ne tür bir ölçü birimi kullanmalılar? Yapılan fazla mesai? Çalışma saati? Proje ekibinde 1 haftada çıkan tartışma sayısı? Tabii ki değil. Hatta diğer kestirim yöntemlerinde kullanılan LOC(kaynak kod satır sayısı) bile yazılım projeleri için zayıf bir ölçü birimidir çünkü LOC daha çok projenin geliştirme aşamasını ölçen bir birimdir fakat bir yazılım projesinin, analiz, tasarım, birim test, sistem test, kullanıcı kabul testi gibi farklı aşamaları da vardır ve bunları LOC ile ölçmek çok gerçekçi değildir. Function Point(Kimi yerlerde use case olarak da karşınıza çıkabilir) Yazılım projeleri için doğru fakat genede ölçeklendirilmesi zor bir ölçü birimidir.
Function Point Analizinde, Function Point'ler 5 kategoride gruplanır.
1 - External interfaces (Dış arayüzler) : Projenin geliştirme kapsamı dışında yeralan bir sistemle veri alışverişi ihtiyacı duyulan fonksiyonaliteler. Örneğin, devlet servislerinden Mernis sorgusu ile kişi bilgilerini almak.
2 - User inquires (Acil Kullanıcı Müdahaleleri) : Yazılımın yönettiği sistemde beklenmedik bir durum olduğunda, kullanıcılara uyarı gönderilmesi(yazılım üzerinden, e-posta ya da SMS ile bilgilendirme) ve kullanıcının müdahalesini kapsayan fonksiyonaliteler. Örneğin sunucuda veritabanı uygulamasının CPU kullanım yüzdesi belirli bir limite yaklaşmış ise sistem yöneticisinin bilgilendirilmesi.
3 - User outputs (Kullanıcı ile paylaşılan veriler) : Sistemin herhangi bir işlemi tamamladığına(ya da tamamlayamadığına) dair kullanıcıya veri ya da rapor iletmesi.
4 - User inputs (Kullanıcının giriş yaptığı veriler) : Sistemin herhangi bir işlemi gerçekleştirmesi için kullanıcılardan veri alınması.
5 - Internal interfaces (İç arayüzler) : Uygulamanın içerisinde yeralan farklı modüllerin veri alışverişini kapsamaktadır. Bir veritabanından farklı bir veritabanına arşivleme ya da yedekleme işlemi bu grupta değerlendirilir.
Function pointlerin LOC'da çevirmek için çeşitli yöntemler kullanılabilir. LOC birçok kestirim yöntemi için girdi teşkil etmektedir.
Function Point'leri LOC'a çevirmek için öncelikler Function Point'lerin karmaşıklıklarını belirlemek gerekir. FP karmaşıklıklarının ağırlıkları aşağıdaki tabloda belirtilmiştir;
FP'ler programlama dillerine göre farklı kodlama standartlarına göre kodlanabilir ve aynı FP, farklı programlama dillerinde değişik satır sayıları ile geliştirilebilir. Bunun için genel olarak kullanılan değişkenlere örnek aşağıdaki tablodadır. Daha detaylı bilgi için http://www.qsm.com/FPGearing.html adresi ziyaret edilebilir.
FP'ler ağırlıklarına ve programlama dillerine denk gelen değişkenlerle çarpıldığında. FP'nin geliştirilmesi için gerekli kod satır sayısı elde edilebilir. Şirket bünyesinde tutulan tarihsel bilgilere, ve çevresel faktörlere dayanarak (performans gereksinimleri, reusability, değişiklik isteği gelme ihtimali vs.) dayanarak FP'ler bir düzenleme katsayısı ile (0,95 ; 1,1 gibi) çarpılabilir.
FP analizi için teknik bir uzman görüşüne ihtiyaç bulunmamaktadır. Doğru çıkartılmış FP'ler ile(ki burada İş Analistlerine çok büyük görev düşmekte) gerçeğe yakın kestirimler yapılabilir. Bakım ve iyileştirme çalışmaları için kullanılabilir bir yöntem değildir. Ayrıca karmaşıklık ağırlığı gibi sonucu ciddi oranda etkileyebilecek kararların tamamen subjektif olarak verilmesi zorunluluğu FP yönteminin dezavantajları arasındadır.
Function Point Analizinde, Function Point'ler 5 kategoride gruplanır.
1 - External interfaces (Dış arayüzler) : Projenin geliştirme kapsamı dışında yeralan bir sistemle veri alışverişi ihtiyacı duyulan fonksiyonaliteler. Örneğin, devlet servislerinden Mernis sorgusu ile kişi bilgilerini almak.
2 - User inquires (Acil Kullanıcı Müdahaleleri) : Yazılımın yönettiği sistemde beklenmedik bir durum olduğunda, kullanıcılara uyarı gönderilmesi(yazılım üzerinden, e-posta ya da SMS ile bilgilendirme) ve kullanıcının müdahalesini kapsayan fonksiyonaliteler. Örneğin sunucuda veritabanı uygulamasının CPU kullanım yüzdesi belirli bir limite yaklaşmış ise sistem yöneticisinin bilgilendirilmesi.
3 - User outputs (Kullanıcı ile paylaşılan veriler) : Sistemin herhangi bir işlemi tamamladığına(ya da tamamlayamadığına) dair kullanıcıya veri ya da rapor iletmesi.
4 - User inputs (Kullanıcının giriş yaptığı veriler) : Sistemin herhangi bir işlemi gerçekleştirmesi için kullanıcılardan veri alınması.
5 - Internal interfaces (İç arayüzler) : Uygulamanın içerisinde yeralan farklı modüllerin veri alışverişini kapsamaktadır. Bir veritabanından farklı bir veritabanına arşivleme ya da yedekleme işlemi bu grupta değerlendirilir.
Function pointlerin LOC'da çevirmek için çeşitli yöntemler kullanılabilir. LOC birçok kestirim yöntemi için girdi teşkil etmektedir.
Function Point'leri LOC'a çevirmek için öncelikler Function Point'lerin karmaşıklıklarını belirlemek gerekir. FP karmaşıklıklarının ağırlıkları aşağıdaki tabloda belirtilmiştir;
FP'ler programlama dillerine göre farklı kodlama standartlarına göre kodlanabilir ve aynı FP, farklı programlama dillerinde değişik satır sayıları ile geliştirilebilir. Bunun için genel olarak kullanılan değişkenlere örnek aşağıdaki tablodadır. Daha detaylı bilgi için http://www.qsm.com/FPGearing.html adresi ziyaret edilebilir.
FP'ler ağırlıklarına ve programlama dillerine denk gelen değişkenlerle çarpıldığında. FP'nin geliştirilmesi için gerekli kod satır sayısı elde edilebilir. Şirket bünyesinde tutulan tarihsel bilgilere, ve çevresel faktörlere dayanarak (performans gereksinimleri, reusability, değişiklik isteği gelme ihtimali vs.) dayanarak FP'ler bir düzenleme katsayısı ile (0,95 ; 1,1 gibi) çarpılabilir.
FP analizi için teknik bir uzman görüşüne ihtiyaç bulunmamaktadır. Doğru çıkartılmış FP'ler ile(ki burada İş Analistlerine çok büyük görev düşmekte) gerçeğe yakın kestirimler yapılabilir. Bakım ve iyileştirme çalışmaları için kullanılabilir bir yöntem değildir. Ayrıca karmaşıklık ağırlığı gibi sonucu ciddi oranda etkileyebilecek kararların tamamen subjektif olarak verilmesi zorunluluğu FP yönteminin dezavantajları arasındadır.
Proje Yönetimi Kestirim Yöntemleri - Delphi
Delphi Yöntemi, bir grup uzmanın konsensüs sağlayarak uygulanan bir kestirim yöntemidir. Bir kaç görüşmeden(round) sonra bir sonuç alınması beklenmektedir.
Her roundda uzmanlar birbirlerinden bağımsız şekilde tahminleme yaparlar. Kestirimlerin hangi uzman tarafından yapıldığı belirtilmez. Kestirimler üzerinde her görüşmede yorumlar yapılır. Çok uç kestirimler bu görüşmeler sonucunda genellikle elenir ve tekrar tahminleme toplanır.
Delphi yöntemi "Narrow Band Delphi" ve "Wide Band Delphi" olmak üzere iki şekilde uygulanabilir. Narrow Band yöntemde round görüşmeleri yüzyüze yapılmaz. Sahipliği belirtilmeden bütün kestirimler e-posta aracılığı ile paylaşılır ve yeni kestirimler toplanır. Wide Band Delphi yönteminde kestirimler üzerindeki fikir alış verişleri yüzyüze yapılır ve bir konsensüs sağlanması beklenir.
Tur sayısı; katılımcı sayısı, proje büyüklüğüne göre düzenlenebilir. Turlar tamamlandıktan sonra. Veriler, istatistiksel bilgilere dönüştürülür. Modüller için ortalama, standart sapma, medya, minimum ve maksimum değerler listelenir. Bazı durumlarda ortalamadan ziyade medyan kullanılması daha doğru olacaktır. (Medyan, küçükten büyüğe dizilmiş verilerin sıralamada ortadaki değerinin aynen alınması Örn: 5 veri toplanmış ise 3. büyük veri, 7 veri toplanmış ise 4. büyük veri. 10 veri toplandığı durumlarda 5. ve 6. verilerin ortalaması kullanılabilir.) Medyan kullanımı çok uçlarda bulunan minimum ve maksimum verileri kestirim için eleyecektir ve daha doğru bir sonuç çıkartacaktır.
Delphi yönteminin temel avantajı, daha önce yapılan çalışmalardan tarihsel bilgiye ihtiyaç duymaması ve ucuz olmasıdır. En büyük dezavantaj, kestirim yöntemleri içersinde daha yavaş uygulanan bir yöntem olmasıdır.
Her roundda uzmanlar birbirlerinden bağımsız şekilde tahminleme yaparlar. Kestirimlerin hangi uzman tarafından yapıldığı belirtilmez. Kestirimler üzerinde her görüşmede yorumlar yapılır. Çok uç kestirimler bu görüşmeler sonucunda genellikle elenir ve tekrar tahminleme toplanır.
Delphi yöntemi "Narrow Band Delphi" ve "Wide Band Delphi" olmak üzere iki şekilde uygulanabilir. Narrow Band yöntemde round görüşmeleri yüzyüze yapılmaz. Sahipliği belirtilmeden bütün kestirimler e-posta aracılığı ile paylaşılır ve yeni kestirimler toplanır. Wide Band Delphi yönteminde kestirimler üzerindeki fikir alış verişleri yüzyüze yapılır ve bir konsensüs sağlanması beklenir.
Tur sayısı; katılımcı sayısı, proje büyüklüğüne göre düzenlenebilir. Turlar tamamlandıktan sonra. Veriler, istatistiksel bilgilere dönüştürülür. Modüller için ortalama, standart sapma, medya, minimum ve maksimum değerler listelenir. Bazı durumlarda ortalamadan ziyade medyan kullanılması daha doğru olacaktır. (Medyan, küçükten büyüğe dizilmiş verilerin sıralamada ortadaki değerinin aynen alınması Örn: 5 veri toplanmış ise 3. büyük veri, 7 veri toplanmış ise 4. büyük veri. 10 veri toplandığı durumlarda 5. ve 6. verilerin ortalaması kullanılabilir.) Medyan kullanımı çok uçlarda bulunan minimum ve maksimum verileri kestirim için eleyecektir ve daha doğru bir sonuç çıkartacaktır.
Delphi yönteminin temel avantajı, daha önce yapılan çalışmalardan tarihsel bilgiye ihtiyaç duymaması ve ucuz olmasıdır. En büyük dezavantaj, kestirim yöntemleri içersinde daha yavaş uygulanan bir yöntem olmasıdır.
26 Mayıs 2009 Salı
Proje Yönetimi Kestirim Yöntemleri - PERT
PERT, "Program Evaluation and Review Technique" ifadesinin kısaltılmasıdır. PERT diğer kestirim yöntemlerinden farklı olarak nokta atışı yapmaz. Eldeki verilere göre projenin belirli bir sürede bitme olasılığını da verir. Bu projenin 6 Ayda bitme olasılığı %50'dir gibi bir cümle PERT Tekniğinin bir sonucu olabilir.
PERT uygulanıren, uzmanlardan görev başına 3 tahminleme alınır. Optimist tahmin(minimum süre "L"), pesimist tahmin(maksimum süre "H") ve gerçekçi tahmin("M") olmak üzere.
Bu sürelerin; E = (L + 4 * M + H)/6 şekilinde "M"ye biraz torpil yapılarak alınan ağırlıklı ortalaması alınır.
Standart Sapma da; σ = (H – L)/6 formülü ile hesaplanır.
Peki bu yeni ortalama ve standart sapma nasıl kullanılır? Ortalama ve standart sapmalar projenin bütününe aşağıdaki şekilde yayılır.
Proje için hesaplanan ortalama(μ) ve standart sapmaya(σ) göre analiz yapabilmek için öncelikle proje verilerinin bir dağılıma sahip olduğunun varsayılması gerekir. Genelde "normal dağılım" varsayımı geçerlidir.
Dolayısı ile ortalama sürenin kaç standart sapma uzağındaki süre için bir tamamlanma ihtimali belirlenebilir. Bazı örnek standart sapmalar sayıları ve yüzdeler aşağıda belirtilmiştir.
μ = 50%
μ + 0.5σ = 59%
μ + 0.8σ = 79%
μ + 1.0σ = 84%
μ + 1.3σ = 90%
Örneklemek gerekirse Ortalaması 12 Ay çıkan projenin standart sapması 1 Ay çıkar ise;
Projenin 12 Ayda bitme olasılığı %50 (bana göre çok optimist bir yaklaşım)
13 Ayda bitme olasılığı %84'tür.
Bu yöntemde en büyük soru işareti dağılım varsayımıdır. Bazı durumlarda normal dağılım yerine Triangular Distribution kullanmak daha iyi sonuçlar verebilir. Ayrıca alınan kestirimlerin de niteliksel ve subjektif olma olasılıkları bu yöntemin dezavantajlarıdır.
PERT uygulanıren, uzmanlardan görev başına 3 tahminleme alınır. Optimist tahmin(minimum süre "L"), pesimist tahmin(maksimum süre "H") ve gerçekçi tahmin("M") olmak üzere.
Bu sürelerin; E = (L + 4 * M + H)/6 şekilinde "M"ye biraz torpil yapılarak alınan ağırlıklı ortalaması alınır.
Standart Sapma da; σ = (H – L)/6 formülü ile hesaplanır.
Peki bu yeni ortalama ve standart sapma nasıl kullanılır? Ortalama ve standart sapmalar projenin bütününe aşağıdaki şekilde yayılır.
Proje için hesaplanan ortalama(μ) ve standart sapmaya(σ) göre analiz yapabilmek için öncelikle proje verilerinin bir dağılıma sahip olduğunun varsayılması gerekir. Genelde "normal dağılım" varsayımı geçerlidir.
Dolayısı ile ortalama sürenin kaç standart sapma uzağındaki süre için bir tamamlanma ihtimali belirlenebilir. Bazı örnek standart sapmalar sayıları ve yüzdeler aşağıda belirtilmiştir.
μ = 50%
μ + 0.5σ = 59%
μ + 0.8σ = 79%
μ + 1.0σ = 84%
μ + 1.3σ = 90%
Örneklemek gerekirse Ortalaması 12 Ay çıkan projenin standart sapması 1 Ay çıkar ise;
Projenin 12 Ayda bitme olasılığı %50 (bana göre çok optimist bir yaklaşım)
13 Ayda bitme olasılığı %84'tür.
Bu yöntemde en büyük soru işareti dağılım varsayımıdır. Bazı durumlarda normal dağılım yerine Triangular Distribution kullanmak daha iyi sonuçlar verebilir. Ayrıca alınan kestirimlerin de niteliksel ve subjektif olma olasılıkları bu yöntemin dezavantajlarıdır.
25 Mayıs 2009 Pazartesi
Proje Yönetimi Kestirim Yöntemleri - Uzman Görüşü
Uzman görüşü kestirim yönteminin nasıl uygulanacağını anlatmak aslında bu cümleden daha kısa sürer. "Uzmanın görüşü alınır." Bu kadar. Peki neden algoritmik yöntemler yerine uzman görüşü alınır? Herşeyden önce çok daha ucuz ve kolay bir yöntemdir. Tabii ki farklı nedenler de var;
Algoritmik kestirim yöntemlerinin 4 adet temel sorunu vardır.
1 - Algoritmik yöntemlerde kullanılan girdi verileri LOC(Lines Of Code) ve FP(Function Point) lerin tespiti ciddi uzmanlık ve tecrübe gerektirir. (Bknz. http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kestirim-yontemleri_1298.html
2 - Algoritmik yöntemlerin uygulanması için çok ciddi tarihsel veriye ihtiyaç vardır. Dünya standartlarında tarihsel veriler sunulmakla beraber bu verilerin şirket özelinde düzenlenmesi gerekebilir.
3 - Veri Analizinin zorluğu. Verilerin yorumlanması için istatistiksel regresyon analizi kullanılabilir. Genel anlamda soğru sonuçlar vermekle beraber bazı dış faktörler bu analizlerle gözardı edilebilir. Örneğin zam oranlarının düşük olduğu ya da performansa göre verilmediği bir sene verimlilik daha önceki senelerden düşük olabilir.
4- Süreç Karmaşıklığı. Algoritmik yöntemleri uygulanırken takip edilen süreçlerin yönetimi zaman zaman zor olabilir. Özellikle IT gibi artık günümüz teknolojilerinde farklı fiziksel lokasyonlardan sürdürebilen projeler için süreçleri yönetmek çok daha zor olabilir.
Uzman görüşü yönteminden çıkacak olan kestirimin kalitesi, uzmanın kestirim konusundaki kabiliyetinden öteye geçemez. Niteliksel ve gayri resmi verilerle yapılan bir çalışma olması da bu yöntemin dezavantajlarıdır.
Algoritmik kestirim yöntemlerinin 4 adet temel sorunu vardır.
1 - Algoritmik yöntemlerde kullanılan girdi verileri LOC(Lines Of Code) ve FP(Function Point) lerin tespiti ciddi uzmanlık ve tecrübe gerektirir. (Bknz. http://www.profesyonelpaylasimlar.com/2009/05/proje-yonetimi-kestirim-yontemleri_1298.html
2 - Algoritmik yöntemlerin uygulanması için çok ciddi tarihsel veriye ihtiyaç vardır. Dünya standartlarında tarihsel veriler sunulmakla beraber bu verilerin şirket özelinde düzenlenmesi gerekebilir.
3 - Veri Analizinin zorluğu. Verilerin yorumlanması için istatistiksel regresyon analizi kullanılabilir. Genel anlamda soğru sonuçlar vermekle beraber bazı dış faktörler bu analizlerle gözardı edilebilir. Örneğin zam oranlarının düşük olduğu ya da performansa göre verilmediği bir sene verimlilik daha önceki senelerden düşük olabilir.
4- Süreç Karmaşıklığı. Algoritmik yöntemleri uygulanırken takip edilen süreçlerin yönetimi zaman zaman zor olabilir. Özellikle IT gibi artık günümüz teknolojilerinde farklı fiziksel lokasyonlardan sürdürebilen projeler için süreçleri yönetmek çok daha zor olabilir.
Uzman görüşü yönteminden çıkacak olan kestirimin kalitesi, uzmanın kestirim konusundaki kabiliyetinden öteye geçemez. Niteliksel ve gayri resmi verilerle yapılan bir çalışma olması da bu yöntemin dezavantajlarıdır.
Kaydol:
Kayıtlar (Atom)