Kategori arşivi: PMBOK7

PMP Hazırlık – Çevik Yaklaşımlar – Ekstrem Programlama(XP)

What Is Extreme Programming?. A complete overview of XP | by Pratyaksh Jain  | Inheaden | Medium

XP’nin temel değeri önce basitliktir. XP ekipleri ek ve gereksiz özelliklerden kurtulmak, israftan kaçınmak, işleri basit tutmak ve müşteri gereksinimlerini karşılamak için işe yarayabilecek en basit çözümü bulmaya odaklanırlar. Scrum gibi, XP de proje boyunca değişiklikler bekler ve XP ekibi değişikliği memnuniyetle karşılar.

XP’de son teslim tarihlerine sahip projeler, teslimatı oluşturmak için gereken süre konusunda gerçekçi değildir ve proje ekibine ek stres yaratır. Son teslim tarihi, XP ekibinin gereğinden fazla çalışmasına, baskı altında kalmasına ve yenilik yapmaktan korkmasına neden olabilir.

XP, zaman sınırlamalı yaklaşımında haftalık döngüler ve üç aylık sürüm döngüleri tercih edilir. Scrum’daki sprint gibi haftalık döngü yinelemeli gerçekleştirilir. Her haftanın ilk gününde ekip, neler başarıldığını tartışmak, hafta boyunca gerçekleştirilecek öncelikli kullanıcı hikayelerini seçmek ve seçilen kullanıcı hikayelerini nasıl oluşturacağına karar vermek için toplanır. Bu yaklaşım, sprint planlamasına benzer, ancak tipik sprint’ten daha kısadır. Üç aylık döngü sürümdür ve müşterinin gereksinimleri önceliklendirmesine göre haftalık döngülerde planlanır ve güncellenir. Temel olarak, her haftanın başarıları, her çeyrekte neyin piyasaya sürüleceğini belirlemeye yardımcı olur.

XP’de Slack kavramı, süre yetmezse haftalık döngüden çıkarılabilecek bazı düşük seviyeli gereksinimleri listeye ekleyerek oluşturulur. İşler sorunsuz gidiyorsa, proje ekibi için yük oluşturmayacak düşük seviyeli gereksinimler haftalık döngüye eklenebilirler.

XP’de On Dakikalık Yapı kavramı, yazılan kodun derleme ve test etmek için on dakikalık bir zaman diliminde tamamlanabileceği anlamına gelir. On dakikalık süre, ekibi otomatikleştirilmiş derleme yaklaşımı oluşturmaya, sık sık test etmeye ve sürekli entegrasyonu izlemeye teşvik eder. Sürekli entegrasyon, kod geliştirildiğinde veya değiştirildiğinde gerçekleşir. Ardından entegrasyon hatalarını bulmak ve düzeltmek için kod hemen test edilir.

XP, önce test planlama yaklaşımını izler. Önce test planlandığında, programcılar gerekli testi geçmek için kodun nasıl yazılması gerektiğini bilirler.

eXtreme Programming (XP) – An Agile Framework – StillGeek

XP, yaşam döngüsü boyunca planlama ve geri bildirim döngülerini içerir;

XP Projesini Planlamak

  • Kullanıcı hikayeleri yazılır.
  • Sürüm planı oluşturulur.
  • Sık, küçük sürümler için planlar geliştirilir.
  • Proje yinelemelere bölünür.
  • Her yineleme, bir yineleme planlama oturumu ile başlar.

XP Projesini Yönetme

  • Bir arada bulunan ekipler uygun çalışma ortamında çalışır.
  • Sürdürülebilir bir çalışma hızı oluşturulur.
  • Gün, 15 dakikalık ayaküstü toplantı ile başlar.
  • Proje ekibinin hızı düzenli ölçülür.
  • Ekip üyeleri diğer rollerde bilgi sahibi olacak şekilde eğitilir.
  • Retrospektifler, XP’deki sorunların çözülmesine yardımcı olur.

Tasarım

  • İşler basit tutulur.
  • Projenin hızlı ve kolay anlaşılması için sistem metaforu oluşturulur.
  • Yapılacak işler, sorumluluklar ve işbirliği kartları hazırlanarak, sistem tasarlanır.
  • Spike(mümkün olan en basit çözüm) yinelemeleri, riskleri ele almak için kullanılır.
  • İstenene kadar özellik ve işlev eklenmez.
  • Kodun temizlenmesi anlamına gelen refactor, proje boyunca gerçekleşir.

Kodlama

  • Müşteri rolüne ihtiyaç vardır.
  • Tüm kodlama için standartlar oluşturulur.
  • Önce birim testleri yazılır.
  • Programcılar eşli programlama (aynı işi bilen iki kişi) yapar.
  • Kod sık sık entegre edilir.
  • Tüm kodlar ekibe aittir, herhangi bir programcı kodu gözden geçirebilir veya düzenleyebilir.

Test yapmak

  • Tüm kodlar için birim testleri yapılır.
  • Tüm kodlar yayınlanmadan önce birim testini geçmelidirler.
  • Koddaki hatalar, yeni testlerin oluşturulmasını gerektirebilir.
  • Kabul testi gereklidir, sonuçlar izlenir ve paylaşılır.

XP’nin en önemli unsuru iletişimdir. XP, Scrum gibi, yüz yüze iletişime önem verir. Etkili iletişim erken ve sık geri bildirim almayı sağlar. Bu sayede erken ve hızlı başarısız olma avantajı yakalanır. Ekip hızlı ve erken başarısız olduğunda, neyin işe yarayıp yaramadığına dair geri bildirim alırlar, ayarlamalar yapabilir ve projede ilerleyebilirler. XP, çalışanların deneyip başarısız olmaları için güvenli bir ortam gerektirir. Olumsuz bir geri bildirim yoktur. Eğer yapılan işe yaramadıysa, ekip neyin işe yaramadığını bilir ve ceza korkusu olmadan devam edebilirler.

XP’de basit, kolay anlamına gelmez. Basit, aşırı mühendislik yapmamak, karmaşık kod oluşturmamak, doğrudan ve uygulaması kolay bir çözüm tasarlamak anlamına gelir. XP’de, müşteri gereksinimlerini karşılamak için işe yarayacak en basit şey hedeflenir.

Scrum’da, ekipler bir sonraki sprintte gelişme ve daha iyi çalışma fırsatı için sprint retrospektif yaparlar. XP, anında geri bildirim yoluyla benzer bir konsepte sahiptir. Geri bildirim yargılayıcı değil yapıcı olmalı ve ekibe daha iyi kararlar verme konusunda rehberlik etmelidir. Geri bildirim verirken ekip üyeleri saygılı, dürüst olmalı ve neyin işe yarayıp neyin yaramadığına odaklanmalıdır. Geri bildirimler, suçlamak için fırsat değil, projede ilerlemek için fırsattırlar.

Erken, hızlı ve sık sık başarısız olmak için cesarete ihtiyaç vardır. Geliştiriciler deneme yaptıklarında ekipteki herkes tarafından görülebilir. Ekip, kodu açıkça paylaşır, birbirlerinin kodunu düzeltme yetkisine sahiptirler. Eşli Programlamada bir kişi geliştirici olarak çalışır ve yanında kodu geliştirmesini izleyen bir kişi vardır. İkinci programcı hataları yakalamaya yardımcı olur, iyileştirmeler sunar ve programcıya ihtiyaç duyduğunda yardımcı olur. Programlayan kişiye sürücü, yardım eden kişiye yönlendirici denir. Sürücü ve yönlendirici her 1,5 ila 3 saatte bir rol değiştirir.

Etkili iletişim kurmak, eşli programlamayla birlikte çalışmak ve yeni yaklaşımlar denemek için ekip üyeleri birbirlerine saygı duymalıdırlar. XP, projenin başarısı veya başarısızlığından herhangi bir kişinin değil herkesin sorumlu olduğu kavramını benimser. Herkes farklı çalışır, ancak ekiple birlikte çalışmak gerekir.

What Is Extreme Programming (XP)? - Values, Principles, And Practices

XP Rolleri ve Sorumlulukları

XP projesinde PMP sınavı için bilmeniz gereken sekiz rol vardır. Bunları derinlemesine bilmeniz gerekmez, ancak sorumluluklarını bilmeli ve projede her rolün ne yaptığını anlayabilmelisiniz;

  • Müşteri veya ürün sahibi – Bu rol, scrum’daki ürün sahibi gibi, iş değerlerini temsil etmekten, kullanıcı hikayeleri yazmaktan, gereksinimleri önceliklendirmekten ve programcıların kullanıcı hikayelerinin değerini anlamalarına yardımcı olmaktan sorumludur. Bu rol müşteri gibi hareket eder. Müşterinin neye değer verdiğine ve projeden ne beklendiğine dair iyi bir içgörüye ihtiyaçları vardır.
  • Koç – XP koçu, ekip üyelerine XP yaklaşımı konusunda koçluk yapar, işlerin ilerlemesini sağlar, projenin çalışmasını denetler ve ekip geri bildirimlerine dayalı olarak süreç iyileştirmelerinin uygulanmasına yardımcı olur. Koç, proje yöneticisi ile aynı şey değildir, ancak proje faaliyetlerinin koordine edilmesine yardımcı olur, herkesin kurallara uymasını ve katkıda bulunmasını sağlar.
  • Programcı – Kodu müşterinin gereksinimlerini karşılayacak şekilde yazandır. Kullanıcı hikayelerini tamamlamak için gereken görevleri belirlerler ve birim testleri yaparlar.
  • Testçi – Programcıların oluşturduğu kod üzerinde işlevsel testler gerçekleştirirler. Fonksiyonel testler, entegrasyon testleri olarak da adlandırılır ve programcıların yaptığı birim testlerinden farklıdır. Testçi, test sonuçlarını belgeler.
  • İzleyici – Bu rolün bazı proje yönetimi görevleri vardır, çünkü kişi projede işlerin “yolda” olduğunu doğrulamak için iş atamalarını izleyecektir. İşler beklendiği gibi gitmezse, kişi belirli görevleri yapmak için plan yapacaktır. İzleyici ayrıca proje ilerlemesini raporlamak için programcılar, koç ve müşteri ile bir araya gelir.
  • Risk İzleyici – Projelerdeki, riskleri, kötü sonuçları ve projeyle ilgili sorunları izler. Projenin başarısını tehdit edebilecek durumlar hakkında sık sık iletişim kurar. Rolün amacı, projenin sağlığı konusunda dürüstlüğü ve şeffaflığı sağlamaktır.
  • Yönetici – Projeyi söz verildiği gibi teslim etmekten sorumludur. Yönetici, proje müşterisine durumu iletmekten, sürüm planlaması için toplantıları planlamaktan ve genellikle kontrol etmekten sorumludur.
  • Sponsor – Projeye kaynak sağlayandır.

XP ekipleri yüz yüze iletişim ve ozmotik iletişim (konuşulanlara kulak kabartmak) kurarlar. XP rollerine bazen genelleme uzmanları denebilir. Bir rolün yalnızca bir şey yapmaktan ziyade birden fazla şey yapabileceği anlamına gelir.

PMP sınavında dikkat edilmesi gereken sürdürülebilir tempodur. Ekip, ürün iş biriktirme listesini incelerken, en üstteki en önemli öğelerle başlayacak ve ekip, tamamlama sürecinde(döngüde) kaç hikaye noktası tamamlayabileceklerini belirleyecektir. Yeni döngülerde, daha fazla iş yapmaya teşvik edilmezler. Bu fazla mesaiye ve uzun çalışma saatlerine yol açar ve sürdürülebilir değildir. Hız bir ekibin yinelemede ne kadar iş yapabileceğidir, bu yüzden tek tip ve sürdürülebilir olmalıdır.

PMP Sınavında, senaryo bazlı sorular proje çalışmasını tanımlayabilir, projenin tamamladığı işin türüne göre çevik veya öngörücü olduğuna dair bilgiler verecektir.

PMP sınavında dikkat etmeniz gereken tüm çevik proje yönetimi kavramlarının benzerlikleri vardır:

  • İletişim şeffaf ve dürüst olmalıdır.
  • Değişim memnuniyetle karşılanır ve beklenir.
  • Proje gereksinimlerine değerine göre öncelik verilir.
  • Ekip ve paydaşlar işbirliği yapar.
  • Asgari düzeyde yeterli belge olmalıdır.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Takvimler

Resource Calendars in Exchange Online | Office 365

Proje Yönetiminde Zaman Çizelgesinin doğru hazırlanabilmesi için öncelikle çalışılan ve çalışılmayan zamanların belirlenmesi gerekir. Üç adet takvimi dikkate almamız gerekir;

  • Şirket Takvimi
  • Proje Takvimi
  • Kaynak Takvimi

Şirket Takvimi

Şirketin çalışılan ve çalışılmayan zamanlarını gösterir. Mesai saatleri, resmi tatiller, planlı duruşlar vb. takvimde çalışılmayan zaman olarak işaretlenmelidir.

Proje Takvimi

Proje ekibinin çalışmasının planlandığı günleri, tarihleri ve saatleri gösterir. Çoğunlukla şirket takvimi ile aynıdır. Ancak bazı projeler özelinde farklı çalışma zamanları seçilebilir. Örneğin projenin kritikliği sebebiyle haftanın 7 günü çalışma veya başka bir durumda projeye haftada bir gün ayırma vb.

Proje ekibinin günün hangi saatinde çalışacağını ve projenin hangi gün/saatte çalışmayacağını (örneğin tatiller vb.) gösterir.

Proje takvimi, proje ortamı ve kısıtlamalarından etkilenir. Örneğin, gün boyunca gürültülü çalışma varsa çalışma zamanı değiştirilir, asfalt atma projeleri yalnızca trafiğin az olduğu hafta sonları gerçekleştirilebilir vb.

Kaynak Takvimi

Kaynak Takvimi, belirli bir kaynağın (personel, makineler vb.) çalışacağı günleri, tarihleri ve saatleri gösterir.

Kaynakların birden fazla proje için aynı anda çalışması gerekebilir, belirli bir proje için kullanılabilirlik payları sınırlı olabilir veya personelin planlanmış tatili vb. olabilir.

Kaynak Takvimi, Kaynakların Sağlanması süreci sonrasında netleşir. Kaynaklar netleştikten sonra çalışma durumları doğrultusunda proje takviminde gerekli güncellemeler yapılır.

Proje Takvimi ve Kaynak Takvimleri, proje ortamındaki değişiklikleri ve proje ekibinin kullanılabilirliğini yansıtmak için planlama ve yürütme süreçleri sırasında sürekli olarak güncellenirler. Her iki takvim Proje Yöneticisinin Proje Zaman çizelgesini geliştirmesine yardımcı olur.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Ürün Kırılım Yapısı(ÜKY)

The Four Phases of Project Management

Ürün geliştirme projelerinde ürün ve süreç bazlı planlama birlikte ele alınır. Bu yaklaşım, önce ürünün tanımlandığı ve ardından proje aktivitelerinin, teslimatların ve ürünü oluşturup teslim etmek için gereken kaynakların planlandığı bir yaklaşımdır.

ÜKY, nihai ürünü bileşenlerine ayırmaktır.

İş Kırılım Yapısı (İKY) gibi, ÜKY ürün ve bileşenleri arasındaki ilişkiyi temsil eden görsel bir sunumdur. İKY ve ÜKY farklı amaçlar için kullanılır. İkisi arasındaki temel fark, ÜKY’nin ürüne, İKY’nin ise ürünü yaratmak için gereken işlere odaklanmasıdır.

ÜKY, ürünü tasarlayacak ve geliştirecek ürün uzmanları ve çapraz fonksiyonel ekip üyeleri ile oluşturulur.

ÜKY, projenin en sonunda oluşturulacak ve geliştirilecek olan ürünün diyagramı çizerek başlatılır. Müşterinin beklentilerini karşılayan çözüm belirlenir. Çözüm yalnızca temel ürünü değil, aynı zamanda müşterinin beklentisini karşılamak için ihtiyaç duyulan, ürünün bir dizi etkinleştirici unsurunu da içerebilir. Örneğin telefon tasarlanıyorsa şarj aleti, kutusu vb.

Çözümün tamamının iki bölümden oluştuğu söylenebilir;

  1. Ürünün temel bileşenleri
  2. Ürünün etkinleştirici bileşenleri

Temel bileşenler, entegre edildiğinde fiziksel ürünü oluşturan somut öğelerdir. Sistem dilinde, entegre ürünün alt sistemleridir. Etkinleştirici bileşenler, ürünün müşterilerin beklentilerini karşılamasını sağlamak için ihtiyaç duyulan ek unsurlardır. Ürünün hem temel hem de etkinleştiren bileşenlerinin projenin planlamasına dahil edilmesi gerekir.

Ürün ile ilgili çözüm ayrıca bir yazılım platformu, kablosuz iletişim altyapısına arayüz, üretim, kalite güvencesi, müşteri desteği vb. ihtiyaç duyulan diğer önemli unsurları da içermelidir. Bunlar, ürün teslim edildiğinde müşteri ve kullanıcı memnuniyetini sağlamak için ihtiyaç duyulan, ürünün etkinleştirici bileşenleridir.

Hazırlama

  1. İKY’de olduğu gibi, ÜKY içinde birden fazla yapı(hiyerarşik, tablo, zihin haritası vb.) seçeneği mevcuttur. Hiyerarşik ve tablo yapısı İKY ile benzerdir.
  2. Karar verilen ÜKY yapısı ile ürün, bileşenlerine ve alt bileşenlerine ayırılır. En üst düzeyde (veya zihin haritasında ortada), ortaya çıkacak entegre ürün bulunur.
  3. Entegre ürü birincil bileşenlerine ayırılır. Mantıksal bir ayrıştırma noktasına (proje çıktısı) ulaşılana kadar her bileşen alt bileşenlerine ayrıştırılır.
  4. Süreç ilerledikçe, ÜKY’nin en alt seviyesinden yukarıya doğru ilerleyerek, her seviyedeki alt bileşenlerin, alt bileşen veya bileşeni oluşturmak için entegre olup olmadığı doğrulanmalıdır.
  5. Üst düzey ürün doğrulanana kadar bu işleme devam edilir. Doğrulama işlemi sırasında eksiklikler keşfedilirse, gidermek için ayrıştırma adımına geri dönülür.

ÜKY, projenin neyi yaratması gerektiğini açıklamak için kullanılır. Tam ölçekli proje planlaması başlamadan önce oluşturulmalıdır. Açıkçası, “nasıldan” önce “ne” gelmelidir.

Faydalar

  • Ürün geliştirme projelerinde ürün ve süreçlerin aynı anda ele alınmaması, bu iki çabanın birbirinden kopması ve hatta birbiriyle çelişmesine yol açabilir. Planlama hem neyin geliştirileceğine hem de nasıl geliştirileceğine odaklamalıdır.
  • ÜKY, proje yöneticisinin ürün ve projenin çeşitli bileşenlerini görselleştirmesine yardımcı olur.
  • Görsel temsil, çok karmaşık projeler için yapı ve düzen oluşturmaya yardımcı olur.
  • ÜKY kullanımında elde edilen ancak somut olmayan önemli bir fayda, ekip uyumunu artırmasıdır. ÜKY, planlama sürecinin başlarında, proje ekibinin oluşmaya başladığı zamanda oluşturulur. ÜKY’nin geliştirilmesi, ürün uzmanları arasında işbirliğine dayalı çalışmayı teşvik eder, öğrenme artar.

Hiyerarşik

Product breakdown structure - Wikipedia

Tablo

Work Breakdown Structure (WBS) 2022 | Project-Management

Zihin Haritası

Product Feature Mind Map | Creately

 

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Güç

The Power of the Project Manager - PM Tips

Güç algısı, proje ekibinden yönetime ve tüm paydaşlara kadar diğer kişilerin sadece projeyi değil, aynı zamanda proje yöneticisini nasıl gördüğünü ve yaklaştığını ifade eder.

Aşağıda yer alan güç tanımları proje yöneticisinin bakış açısından çerçevelendirilmesine rağmen müşteriden proje sponsoruna kadar herhangi bir paydaş bu gücü elinde tutabilir. Bunların hepsi organizasyonların politik ortamının parçasıdır. Uygulanmakta olan gücü anlayabilmek, proje yöneticisi olarak projeyi ve sonuçlarını daha iyi yönetmeye yardımcı olur.

  • Konumsal güç – Proje yöneticisinin veya paydaşın gücü, sahip olduğu konumun bir sonucudur. Bu aynı zamanda resmi, yetkilendirilmiş ve meşru güç olarak da bilinir.
  • Bilgilendirme gücü – Proje yöneticisi veya paydaş, verinin toplanması ve bilginin dağıtımı üzerinde kontrole sahiptir.
  • Referans gücü – Proje yöneticisi veya paydaş, proje ekibinin onunla geçmiş deneyimleri nedeniyle saygı görür veya takdir edilir. Proje yöneticisinin veya paydaşın organizasyondaki güvenilirliği ile ilgilidir.
  • Durumsal güç – Proje yöneticisi veya paydaş, organizasyondaki belirli durumlardan dolayı güce sahiptir.
  • Kişisel veya karizmatik güç – Proje yöneticisi veya paydaş, başkalarının sevdiği sıcak bir kişiliğe sahiptir.
  • Güçten kaçınma – Proje yöneticisi veya paydaş harekete geçmeyi, dahil olmayı veya karar vermeyi reddebilmektedir.
  • Uzman gücü – Proje yöneticisi veya paydaş bir disiplinde derin becerilere ve deneyime sahiptir.
  • Ödüllendirme gücü – Proje yöneticisi veya paydaş proje ekibini ödüllendirebilir.
  • Cezalandırıcı veya zorlayıcı güç – Proje yöneticisi veya paydaş proje ekibini cezalandırabilir.
  • Etkileyici güç – Proje yöneticisi veya paydaş, etkileme yoluyla proje ekibi ve diğer paydaşların beğenisini kazanabilmektedir.
  • Baskıya dayalı güç – Proje yöneticisi veya paydaş, proje ekibinin proje çalışmasını gerçekleştirmesini sağlamak için seçeneklerini kısıtlayabilmektedir.
  • Suçluluğa dayalı güç – Proje yöneticisi veya paydaş, projeye uyum sağlamak için proje ekibini ve diğer paydaşları suçlu hissettirebilmektedir.

Proje yöneticisi paydaşa ve duruma göre gücünü ayarlayabilmeli, birlikte çalıştığı paydaşların güçlerinin ve olası etkilerinin farkında olmalıdır.

Türkçe eğitimler

İngilizce eğitimler

Proje Yönetiminde Sorumluluk Atama Matrisi

FinOps team: roles and responsibilities | Hystax

Proje boyutu ne olursa olsun, rol ve sorumlulukların net bir şekilde tanımlanması gerekir. Projede yer alan herkesin kendi rollerini, görevlerini ve sorumluluklarını anlaması gerekir. Sorumluluk Atama Matrisi, her ekip üyesinin rol ve sorumluluğunu tanımlamak için kullanılır.

Sorumluluk Atama Matrisi (Responsibility Assignment Matrix), RACI (Responsible, Accountable, Consulted, Informed) kısaltması ile kullanılabilir. Bu kelimeleri “Sorumlu, Yaptıran, Danışılan ve Bilgilendirilen” olarak çevirebiliriz.

RACI, beklentilerdeki karışıklığın azaltılmasına, proje verimliliğinin artırılmasına ve çıktıların iyileştirilmesine yardımcı olur. Kararlar daha hızlı alınır, hesap verme sorumluluğu netleşir ve iş yükü eşit olarak dağıtılabilir.

  • R – Responsible – Sorumlu: Görevi tamamlayacak kişidir.
  • A – Accountable – Yaptıran (Hesap Verebilir Olan): Görev(ler)le ilgili kararlar alan, işi yaptıran kişidir.
  • C – Consulted – Danışılan: Karar verme süreci ve belirli görevler hakkında iletişim kurulacak kişidir
  • I – Informed – Bilgilendirilen: Proje süresince alınan kararlar ve eylemlerden haberdar edilecek kişi(ler)dir.

RACI, her bir kişiye hangi işlevsel rol(ler)in atandığını gösterdiğinden, çalışanların iş yükü hakkında bilgi verir. Örneğin kuruluş, birine ne kadar çok sorumluluk verildiği görülebilir.

RACI, yanlış iletişimi azaltır ve üretkenliği artırır. Görev ile ilgili problemlerde, kimin yaptığını ve nihayetinde sorumlu olduğunu gösterir. Doğru kişilerle doğru konuları ele almanızı sağlayarak, zaman kazandırır.

RACI, bazı belirsiz durumlarda tam çözüm getirmeyebilir. Bu tip durumlarda tabloya ek açıklama girilmelidir.

Danışılan rolü bazen belirsizdir. Sadece danışmak mı yoksa onay almak mı olduğu belirtilmelidir.

RACI, işlerin doğru yapılmasını garantilemez. Uzman ve motive bir ekip üzerinde uzlaşmaya vardıkları RACI ile verimli ve üretken iş çıkarabilirler.

İşi yapan (Sorumlu) ve yaptıran her zaman kişini yöneticisi olmayabilir. Kurum kültürü ve organizasyon yapısı dikkate alınmalıdır.

RACI, geleneksel veya çevik yöntemlerde kullanılabilir. Çevik yöntemlerde beklenen rollere göre uyarlama yapomak gerekir. Örneğin Yaptıran yerine Kolaylaştıran vb.

RACI, ekip üyelerini projenin amacına göre organize etmek için uygun bir araçtır. RACI’nin ezbere değil aksine projeye, ekibe ve kuruma göre uyarlanması gerekir.

RACI’de denge önemlidir. Her rolde çok fazla veya yetersiz kişi olduğunda projeye zarar verir.

Başarı Koşulları

  • Görev başına Bir Sorumlu – Birden fazla sorumlu(yapan) varsa, birden fazla kişinin araba kullanması gibi bir durum ortaya çıkar. Sürücü yoksa, yine araba gitmeyecektir.
  • Doğru Miktarda Sorumlu – Aynı göreve atanan çok fazla insan var ise zaman kaybı olasılığı yükselir.
  • Çok Fazla Danışılan Olmamalı – Görevin tamamlanmasını yavaşlatabilir. Görev tamamlamadan önce birkaç paydaşa veya konu uzmanına danışılması gerekiyorsa, zaman kaybı olabilir.
  • Çalışanları Bilgilendirme – Danışılmasına gerek olmayan, sadece güncellemeniz gerekenler olabilir. İletişim eksikliğinden kaynaklanan sorunlar yaşamamaya çalışın.

RACI, işbirlikçi bir çabayı modellemeye yöneliktir. Herkes, kendisinin ve meslektaşlarının sahip olduğu her rol konusunda rahat olmalıdır. RACI ile iletişim ve süreç verimliliği iyileştirilmeye çalışılır.

Örnek RACI tabloları;

RACI Chart: Definitions, Uses And Examples For Project Managers – Forbes Advisor

Beeye on Twitter: "The RACI chart (also known as RACI matrix or diagram) should be there to make your life easier as a Project Manager. Here's how can you make your RACI

Sample RACI Matrix Worksheet - 3 Quick Steps

Türkçe eğitimler

İngilizce eğitimler

Portföy Yönetiminde Proje Önceliklendirme – İkili Karşılaştırma

Borneo Breezes: Pair-Wise Ranking

İkili karşılaştırma tekniği projelerin öncelik sırasını belirlemede kullanılır. Projeleri karşılaştırmadan önce karar yönteminin (ör. fikir birliği, otokratik, oylama vb) belirlenmesi gerekir. Ek olarak, bir projeyi diğeriyle karşılaştırmak için sayısal veya sezgisel yaklaşımın ne olacağı belirlenmelidir.

İkili karşılaştırma, iki ana adımdan oluşan çok basit bir süreçtir. İlk olarak, karşılaştırılacak projelerin sayısını temsil eden bir karşılaştırma matrisi oluşturulur. 6 proje işçin aşağıdaki matris oluşturulabilir;

Numaralandırmanın doğru bir şekilde yapıldığından emin olunmalıdır. Altı projenin her birini temsil eden sayılar , hem dikey hem de çapraz eksende yukarıdan aşağıya artan düzende yerleştirilmelidir.

Karşılaştırmada tutarlılığı sağlamak için her bir proje çiftinin karşılaştırılacağı bir dizi kriter tanımlanmalıdır. Bu kriterler, projelerin her birinin birbiriyle karşılaştırılması için temel teşkil edecektir. Kriterleri, en fazla beş olacak şekilde düşünün. Beş kriterden fazlası karşılaştırmayı olması gerekenden daha karmaşık hale getirir. Kriter örnekleri aşağıdaki gibidir;

  • Net bugünkü değer
  • Yatırım getirisi
  • Geri ödeme süresi
  • Stratejik uyum düzeyi
  • Tasarruf etkisi
  • Pazar payı artışı etkisi

Oluşturulan karşılaştırma matrisi, belirlenen kriterler, üzerinde anlaşmaya varılan karar yöntemi ve bir araya getirilen doğru paydaş grubu ile aşağıdaki adımlar gerçekleştirilir;

Adım 1: Her projeyi diğeri ile karşılaştırın. Her bir proje için, paydaşlar belirlenen kriterlere göre iki projeden hangisinin tercih edildiğini belirlemelidirler. Tercih edilen projenin numarası karşılaştırma matrisine eklenir. Bu karşılaştırma, karşılaştırma matrisi tamamen dolana kadar tekrarlanır.

Adım 2: Sayım tablosunda karşılaştırma sonuçlarının toplanması. Basit bir tablo kullanarak, her bir projenin kaç kez tercih edildiği belirlenir. Projeler, tercih edilme sayılarına göre sıralanır.

Faydaları

İkili karşılaştırma, aynı anda yalnızca iki projenin değerlendirilmesi sayesinde bir proje listesini basit bir şekilde önceliklendirmeye yardımcı olur.

Yapılandırılmış bir süreçtir ve karşılaştırma sonuçlarını paydaşlar ve karar vericiler için anında görünür kılar. Tablo kullanmak görsel olarak etkilidir.

Türkçe eğitimler

İngilizce eğitimler

 

Proje Yönetiminde Kaynak Dengeleme

A guide to the fundamentals of resource leveling - Work Life by Atlassian

Projeler, aktivitelerin gerçekleştirilmesi için kaynaklara ihtiyaç duyarlar. Kaynaklar, işin yapılması için gereken işgücü, ekipman ve malzemeleri içerir. İşgücü, mühendisler, programcılar, sistem analistleri vb. kişilerdir. Ekipman, vinçler, test teçhizatları, süreç simülatörleri vb. içerir. Malzemeler, yazılım lisansı, döşenecek tel vb. içerir.

Projelerde kaynaklar sınırsız değildir ve proje ekibinin kaynakların kullanımını ve tüketimini “dengelemesi” gerekir.

Proje yöneticileri, hedefleri mevcut kaynaklarla gerçekleştirilebilecek plan geliştirmek zorundadırlar. Aynı kaynakları kullanmak isteyen farklı operasyonlar ve projeler olduğu için doğru yaklaşım önemlidir.

PMP) resource leveling vs resource smoothing - YouTube

Projenin mevcut kaynaklarla tamamlanabilmesi için zaman çizelgelerini yeniden ayarlamaya Kaynak Dengeleme denir.

Kaynak dengelemenin amacı, projeyi zaman, maliyet ve kapsam kısıtları dahilinde mevcut kaynaklarla en iyi şekilde tamamlamaktır.

Bazen aktivitelerin başlangıç ve bitiş tarihleri ile oynayarak, bitiş tarihini geçmeden dengeleme mümkün olabilir. Bu noktada kaynakların müsaitliğine göre aktivitelerin başlangıç ve bitiş tarihleri değiştirilebilir.

Kaynakların sınırlı olduğu varsayımıyla öncelikli olarak kritik aktivitelerin yapılması tercih edilebilir, daha az kritik aktiviteler ötelenir.

Zaman çizelgesi geliştirilirken öncelikle kaynak sınırı gözetilmez. İdeal plan yapılır daha sonra olası darboğazlar ve sıkıntılar giderilmeye çalışılır. Aktivitelerin süresi çoğu zaman atanan kaynağa göre değişiklik gösterebilir. Bu sebeple dengeleme yapılırken kaynak miktarı ve/veya tüketimi dikkate alınmalıdır.

Proje ekibinin ihtiyaçlarına bağlı olarak, kaynak dengelemenin olası sonuçlar aşağıdaki gibidir;

  • Amaç, mevcut proje son tarihini korumaksa, daha fazla kaynağın kullanılması
  • Hedef, mevcut kaynaklarla projeyi yürütmek ise, projenin son teslim tarihi uzay

Kaynak dengeleme aşağıdaki konularda faydalıdır;

  • Eldeki kaynaklardan en iyi şekilde yararlanmanızı sağlar. Hangi projelerin ek kaynak gerektirdiğini ve hangilerinin son teslim tarihleri açısından esnek olduğunu değerlendirmenize yardımcı olur.
  • Önemli proje gecikmelerini önleyerek maliyet ve işçilik kayıplarını en aza indirir. Kuruluşun mevcut kapasitesini ve finansal kaynaklarını aşmadan kaynak talebini yönetmenizi sağlar.
  • Fazla kaynak yükleme sorunlarını son tarihleri ayarlayarak önler.
  • Proje çıktıları için aynı kalite seviyesini koruyarak hem kaynakları hem de müşteri beklentilerini yönetmeyi sağlar.

Türkçe eğitimler

İngilizce eğitimler

 

Proje Yönetiminde FAST (HIZLI) Hedefler

Isn't it time to switch from SMART goals to FAST goals? - Workanize

Projelerde hedeflerin doğru belirlenmesi başarı için kritik öneme sahiptir. Yanlış hedefler değerli kaynakları boşa harcamaya, hedefleri düşük tutmak düşük kaliteli sonuçlara yol açar. Hedeflerin tüm paydaşlara iletilmemesi ve doğru anlaşılmaması projede yönün kaybedilmesine yol açar.

HIZLI hedefler, ingilizce FAST kelimesinin baş harflerini sağlayan kelimelerle oluşturulmuş bir çerçevedir;

F – Frequently Talked About – Sıkça konuşulan

A – Ambitious – Azimli

S – Spesific – Belirli

T – Transparent – Şeffaf

HIZLI hedefler, SMART hedefler gibi geleneksel hedef belirleme yönteminden farklıdır. HIZLI hedefler, hedeflere bir bütün olarak nasıl yaklaşılması ve kullanılması gerektiğini özetlemeye çalışır. Çevik uygulamalarda çevreye odaklanarak hedef belirlemeyi modernleştirir.

PMBOK kılavuzu projelerin amacını, “Projeler, çıktılar üreterek hedefleri gerçekleştirmek” şeklinde tanımlar.

Projenin hedef(ler)i, proje planında birçok küçük hedefe bölünür. Projenin karmaşıklığına bağlı olarak, bu hedefler yönetilebilir bir boyuta ulaşana kadar tekrar tekrar bölünebilir. Proje yönetiminde hedeflerin önemi bu nedenle kritiktir. Proje yönetiminde sadece hedeflerin olması yetmez, aynı zamanda hedeflerin doğru kullanılması daha yüksek motivasyon, performans ve iş tatmini vb. faydalar sağlayabilir . Hedeflerin kötü kullanımı planlamayı olumsuz etkiler, kaynakların israfına, kalitenin düşmesine ve hayal kırıklığına yol açabilir.

SMART (Spesifik, Ölçülebilir, Ulaşılabilir, İlgili ve Zamana Bağlı) ve sonrasında geliştirilen SMARTER (Spesifik, Ölçülebilir, Ulaşılabilir, İlgili, Zamana Bağlı, Etkili ve Ödüllendirici) hedefler projelerde tercih edilmiştir. OKR (Hedefler – Temel Sonuçlar) yaklaşımında hedefler bir dizi kilit sonuç eklenerek belirlenir. OKR metodolojisinde hedef belirleme, SMART kullanılarak hedeflerin belirlenmesidir ancak vurgu, OKR’lerin erken oluşturulması, geri bildirim alma ve güncelleme, stratejik uyum ve şeffaflık üzerinedir. OKR metodolojisi, yalnızca hedef belirlemeye odaklanmaz, aynı zamanda hedeflerin proje boyunca alakalı kalmasını ve doğru bir şekilde önceliklendirilmesini sağlamak için uyarlanabilirliği benimser. Bu yaklaşım, SMART’ta olmayan OKR metodolojisinde olan bir durumdur. OKR metodolojisi yalnızca yüksek kaliteli hedef nedir sorusuna cevap aramaz. Hem yüksek kaliteli hedefler belirlemenin hem de bu hedefleri gerçekleştirirken yüksek performans göstermenin bir yolu olarak hizmet eden bir metodoloji sunmaya çalışır.

OKR ile ilgili detaylı bilgi için aşağıdaki yazılarımı okuyabilirsiniz.

2018’de, Stratejik Çeviklik Projesi adlı bir dizi makalenin parçası olarak Hedeflerle, HIZLI SMART’ı Yener adlı bir makale yayınlandı. Stratejik Çeviklik Projesi makaleleri dizisi, uygulayıcıların kuruluşlar içindeki strateji ve hedefler arasında daha iyi bir uyum bulmalarına yardımcı olmayı amaçlamaktaydı. Stratejiyle uyumlu hedefler oluşturmak için OKR metodolojisinin duyarlılığı dikkate alınmış, yüksek kaliteli hedefler belirlemenin yeterli olmadığı belirtilmekteydi. Donald Sull ve Charles Sull, insanların hedef belirleme eylemine çok fazla odaklandıklarını ve hedeflerin nasıl kullanıldığına yeterince dikkat edilmediğini anlatıyorlardı. Bu makalede önerilen “HIZLI”(Sıkça konuşulan, Azimli, Belirli ve Şeffaf) hedefler, hedeflerin nasıl algılandığını ve üzerinde çalışıldığını yeniden yönlendirmek amacıyla yeni bir hedef metodolojisi olarak ortaya çıktı. HIZLI hedefler çerçevesi, hedeflerin kullanılma şeklinin, motivasyonu artıran, daha yüksek kaliteli sonuçlar üreten ve genel strateji ile daha iyi uyum sağlayan hedeflere ulaşmak için yeniden şekillendirilebileceğini öne sürer.

HIZLI hedefler

Sıkça konuşulan

Hedefler, ilerlemeyi gözden geçirmek, kaynakları tahsis etmek, yapılan işlere öncelik vermek ve geri bildirim sağlamak için devam eden görüşmelerde yer almalıdır. HIZLI hedefler belirlemek için hedeflerin sık sık gözden geçirilmesi bir zorunluluktur. Sıklık yoruma bağlıdır, ancak HIZLI hedefler tartışmayı, görüşleri yansıtmayı ve hedeflerin gözden geçirilmesini normalleştirmeyi gerektirir. Sıklıkla tartışılması gereken sadece ilerleme değil geri bildirim, kaynak tahsisi ve önceliklendirme ele alınmalıdır. HIZLI hedef, hep aynı kalmaz, uyum sağlamalı ve değişebilmelidir.

Azimli

Hedefler zor olmalı ama ulaşılması imkansız olmamalıdır. İddialı hedefleri motivasyonla ilişkilendiren çalışmalar, yüksek performansla da ilişkilendirirler. Ancak, iddialı hedefler hedeflere ulaşamama riskiyle birlikte gelirler. Yüksek ve iddialı hedefler koymak bunlara ulaşılamamasını kabul etmeyi gerektirir. İddialı hedeflerin, imkansız hedefler olmaması gerekir.

Belirli

Hedefler, her bir hedefe nasıl ulaşılacağına ve ilerlemenin nasıl ölçüleceğine dair netliği zorlayan somut ölçütlere ve kilometre taşlarına dönüştürülür. Tüm proje yönetimi metodolojileri planlamada ve genel olarak proje yönetimi boyunca belirlilik ihtiyacına atıfta bulunurlar. Hedef belirlemede belirlilik ve ölçülebilirlik gerekir. Hedeflerin net olması artan motivasyon ve performans anlamına gelir.

Şeffaflık

Hedefler ve mevcut performans, tüm çalışanların görmesi için şeffaf hale getirilmelidir. Proje yöneticisi, projedeki herkesin hedeflerini ve ilerlemesini görmesini sağlamalıdır. Şeffaflık odaklanmayı artırır. Uygunsuz odaklanma, kaynakların tekrar eden işlerde israf edilmesi ve ekipler arası zayıf iletişim sonucu çatışmalara yol açar. Şeffaflık, daha iyi stratejik uyum, artan motivasyon ve yüksek performanslı çalışanlar için projenin daha çekici hale gelmesini sağlar.  

Türkçe eğitimler

İngilizce eğitimler

 

Proje Yönetiminde Performans Ölçümü Temel Çizgisi(PÖTÇ)

An Introductory Guide To Project Management Metrics | Wrike

Proje yönetiminde, projenin ilerlemesinin ve performansının izlenmesi gerekir. Proje performansını ölçmek için kriterler açıkça tanımlanmalı ve proje paydaşları tarafından kabul edilmelidir.

Performans Ölçümü Temel Çizgisi Nedir?

Performans Ölçümü Temel Çizgisi (PTÇ), proje yönetimi planının bir bileşenidir. Projenin ilerleyişi esnasında, proje yöneticisinin ve paydaşların projenin kapsam, zaman çizelgesi ve maliyet açısından ne durumda olduğunu belirlemesine yarara.

Performans Ölçümü Temel Çizgisi tüm proje, aşamalar veya belirlenmiş kontrol hesapları için oluşturulabilir.

Performans Ölçümü Temel Çizgisi, 3 temel çizgiden oluşur;

  • Kapsam temel çizgisi,
  • Zaman çizelgesi temel çizgisi ve
  • Maliyeti temel çizgisi.

Kapsam temel çizgisi, kapsam bildirimi, iş kırılım yapısı ve iş kırılım yapısı sözlüğünden oluşur.

Zaman çizelgesi temel çizgisi, proje aktivitelerinin zamanlamasını içeren Gantt Grafiği veya tablo formatında süreleri ve tarihleri içerir.

Maliyet temel çizgisi, proje aktivitelerine yönelik maliyet tahminlerine dayanan tahsis edilen bütçedir. Zaman çizelgesi ve maliyet temel çizgisi, beklenmedik durum yedeklerini içerir ancak yönetim yedeklerini içermezler.

Performans ölçümü amacıyla kullanılmak üzere, bu temel çizgilerin proje yönetişimi tarafından onaylanması gerekir.

Performans Ölçümü Temel Çizgisi, bu temel çizgilerin içeriğini birleştiren konsolide bir ölçüt olup PMBOK®, 6. baskı, Bölüm 4.2.3.1)’de “ek belge” olarak yer almaktadır.

PÖTÇ, hangi göstergelerin performansının ölçüldüğünü göstererek, proje kaynaklarının yanı sıra paydaşlar için proje kontrolü ve şeffaflık konusunda rehberlik sağlar.

Resmi onay sürecinden geçmiş değişiklikler normal olarak performans ölçümü temel çizgisini de etkiler.

PÖTÇ proje boyunca kapsam, zaman çizelgesi ve maliyet kontrolünde kullanılır. Önceden tanımlanmış göstergeler aracılığıyla ölçülen gerçek ilerleme, temel çizgilerile karşılaştırılır.

Performans ölçümü ve yönetimi aşağıdakilere atıfta bulunabilir;

  • Kümülatif veya belirli bir zamanda performans,
  • Geçmiş veya mevcut performans,
  • Öngörülen gelecekteki performans.

Performans ölçümünün sonuçları, proje yöneticisinin yanı sıra paydaşları bir bütün olarak projenin ve/veya bileşenlerinin ilerleyişi hakkında bilgilendirir.

Proje performansının analiz edilmesi, proje yürütme/teslimatındaki sorunların ve engellerin belirlenmesine yardımcı olur. Düşük performans, sapmaları düzeltmek veya önlemek için gerekli eylemleri gösterebilir.

Proje performans ölçümünde en yaygın teknik Kazanılmış Değer Analizidir(KDA).

Planlanan Değer (PD), performans ölçümü temel çizgisinin önemli ve hatta tek göstergesidir.

PD ve Planlanan Bütçe (PB), gözlemlenen değerlerin, yani Gerçekleşen Maliyet (GM) ve Kazanılmış Değerin (KD) karşılaştırıldığı temeldir.

KDA göstergelerinin proje performansının tek ölçüsü olduğu projelerde, performans ölçümü temel çizgisi, maliyet temel çizgisi ile aynı olabilir. Bunun nedeni, maliyet temel çizgisinin, kapsam temel çizgisinde oluşturulmuş olan zaman çizelgesi temel çizgisini yansıtmasıdır.

Performans Ölçümü Temel Çizgisi Nasıl Oluşturulur?

PÖTÇ, projenin planlama aşamasında oluşturulur. Kapsam, zaman çizelgesi ve maliyet temel çizgisinden oluşur. Bu nedenle PÖTÇ’nin oluşturulması, bu üç proje temel çizgisinin belirlenmesi anlamına gelir.

Adım 1 – Kapsam Temel Çizgisinin Geliştirilmesi

İlk adım, projenin hedef(ler)ini ve çıktılarını belirlemektir. Kapsam temel çizgisi aşağıdakikerl içerir;

  • Proje Kapsam Bildirimi
  • İş Kırılım Yapısı (İKY),
  • İKY sözlüğü.

Bu belgeler ilgili kurul(lar) ve/veya paydaşlar tarafından onaylandığında kapsam temel çizgisini oluştururlar.

Adım 2 – Zaman Çizelgesi Temel Çizgisinin Geliştirilmesi

Kapsam temel çizgisine dayalı olarak, aktivitelerin bağımlılıkları ele alınır, süre tahminleri yapılır, kaynak ihtiyaçları belirlenir, varsayımlar ve kısıtlar dikkate alınarak Zaman Çizelgesi Temel Çizgisi geliştirilir.

Adım 3 – Maliyet Temelini Geliştirin

Kaynak gereksinimlerine bağlı olarak aktivitelerin beklenen maliyeti tahmin edilerek bütçe hesaplanır. Dönemlere göre ayrılmış (zaman aşamalı), kontrol hesaplarına veya iş paketlerine tahsis edilen bütçe, projenin maliyet temel çizgisini oluşturur.

Adım 4 – Performans Ölçütlerini/Göstergelerini Belirlemek

Kullanılan ölçüt ve gösterge seti, kazanılmış değer analizinin göstergelerine atıfta bulunabilir Ayrıca, projenin mantıklı olan diğer göstergeleri de içerebilir.

Adım 5 – Üç Temel Çizgiyi Performans Ölçümü Temel Çizgisinde Konsolide Etmek

Performans ölçümü temel çizgisini içeren belgede, performans izleme için kullanılan tüm göstergeler birleştirilir. Projenin performans ölçümünün, teslim edilen proje çalışmasını ve kukllanılan kaynakları bu 3 temel çizgiye göre değerlendirmesi gerekir.

Adım 6 – PÖTÇ’yi Paylaşmak, Uygulamak ve İzlemek

PÖYÇ geliştirildikten sonra proje ekibi ve projenin ilgili paydaşları ile paylaşılır. Proje yöneticisi çıktı(lar), kilometre taşları ve bütçenin farkında olmalı, tanımlanan göstergeleri izlemeli ve performans ölçüm temel çizgisiyle karşılaştırmalıdır. Yapılacak izleme ve karşılaştırma farklı ayrıntı düzeylerinde ve zaman bazında veya kümülatif olarak ileriye dönük bir eğilim analizi olarak yapılabilir.

Türkçe eğitimler

İngilizce eğitimler

 

Proje Yönetiminde Kabul Kriterleri

Acceptance | Fern Lim - Actress and Filmmaker

Projelerde, çatışmaları önlemek ve projelerin zamanında teslim edilmesini sağlamak için proje ekibi veya müşteri tarafından belirlenen şartlara proje kabul kriterleri veya proje yönetimi kabul kriterleri denir.

Proje ekibinin belirli bir zamanda başarması gereken hedefler ve müşterinin projeyi hangi koşullar altında kabul edeceği hakkında tüm ayrıntıları içerirler.

Projede yer alan paydaşlar fazlaysa bir paydaşın yaptığı işin diğerinin gereksinimlerine uymaması durumunda çatışmalar ortaya çıkabilir. Proje ekibi, projeyi hangi yönde yürütmeleri gerektiği konusunda hemfikir fikri olmadığında, sonuca ulaşmak zorlaşır. Bu nedenle proje yönetiminde aynı proje üzerinde çalışan her proje ekibinin referans olarak takip etmesi gereken önceden belirlenmiş kabul kriterleri olması gerekir. Bu yaklaşım işleri daha kolay ve pürüzsüz hale getirecek ve zamanında teslimat şansını artıracaktır.

Kabul Kriterleri Türleri

Proje yönetiminde üç tür kabul kriteri örneği vardır.

  • Senaryo Odaklı
  • Kural Odaklı
  • Özel Biçim

Projeye aktif veya dolaylı olarak dahil olan tüm paydaşlar, bu türlerden herhangi birinde kabul kriterlerini sağlamakla yükümlü olacaktır.

Kabul kriterlerinin nihai kullanımı, projelerin istenilen şekilde, zamanında teslim edilmesini sağlamaktır. Kabul kriterleri aşağıdakileri sağlarlar;

  1. Detaylı Bilgi – Ekipte çalışan herkese ne yapılması gerektiği ve bunu yapmanın doğru yolu hakkında ayrıntılı bilgi sağlar.
  1. Görevleri Kolaylaştırma – Proje tamamlanana kadar her adımdan sonra ne yapılacağını belirlemeye ve görevlerin atanmasına yardımcı olur.
  1. Daha İyi İletişim – Gereksiz çatışmalardan kaçınarak ekipler için iletişimi sorunsuz ve sorunsuz hale getirir.
  1. Değerlendirme – Projenin tesliminden önce projenin tamamlanmasının ve kalitenin doğrulanmasına yardımcı olur.

Proje Yönetimi Kabul Kriterlerinin Önemi

İyi tasarlanır ve uygulanırsa, proje kabul kriterleri herhangi bir projenin bel kemiği haline gelirler. Proje ekibine çalışmalarında yön verir. Proje kabul kriterleri belirlendikten sonra, roller ve teslimat standartları daha net olacağından proje ekip üyeleri arasında çatışma olasılığı azalacaktır.

Proje Kabul Kriterlerinin Faydaları

Aynı proje üzerinde birlikte çalışanların çatışma olasılıkları azalır. Çatışmalar genellikle rol ve sorumluluk kaynaklı olduğundan kriterler belirledikten sonra kimin neyi nasıl yaptığı belşi olacaktır.

Proje ekibinin karşılamaları gereken kriterler veya standartlar hakkında bilgilendirme sağlarlar.

Projede meydana gelen herhangi bir değişiklik, kabul kriterleri aracılığıyla değerlendirilebilir.

Gereksinimlerle ilgili belirsizlikleri ortadan kaldırmaya yardımcı olur, projede sorun yaşanma veya yanlış yönetim olasılığını önemli ölçüde azaltır.

Nasıl Olmalı?

  • Kabul kriteri işi yapacak olana hitaben yazılmalıdır.
  • Sorumlu kişi veya paydaş net olarak belirtilmelidir.
  • Net ve kısa tutularak anlaşılması kolay olmalı, proje ekibinin anlamak için ekstra çaba sarf etmesi gerekmemelidir.
  • İlgili tarafların onayı alınmalıdır.

İpuçları

  • Her gereksinimin kabul kriterlerine sahip olduğundan emin olmak ve proje ekibe ayrıntılı olarak açıklamak gerekir. Birden fazla kabul kriteri olabilir, ancak gereksiz olanlar çıkarılmalıdır.
  • Projeye başlamadan önce kabul kriterleri belirlenmeli ve proje ekibi ile paylaşılmalıdır.
  • Proje müşterisiyle sorun yaşamamak içi gereksinimleri belirlemeye önem verilmelidir.
  • Proje ekibi tarafından tamamlanan kabul kriterlerinin kabul veya reddedileceği senaryoları tanımlayın.
  • Kabul kriterleri proje ekibini her zaman projenin nihai sonucuna yönlendirecek şiekilde olmalıdır.
  • Kabul kriterleri kısa, net ve anlaşılır olmalıdır. Herkesin anlayacağı bir dil kullanılmalıdır.
  • Kabul kriterleri, proje ekibi ve müşteri tarafından onaylanmalıdır.

Türkçe eğitimler

İngilizce eğitimler