Ürün yöneticilerinin sahip olduğu Backlog’u nasıl önceliklendirmesi gerektiği konusuna “Değer Katan Ürün  Sahibi” yazımızda değinmiştik.

Bu çerçevede hikayelerinizin her biri için “iş değeri” – business value değerinin girilmesi gerekir.

Hikayelerinizi daha önceden girdiğinizi varsayalım. Business value’ları girmenin en kolay yolu olarak ben Agile | Planning Board menüsünde hikayelerin üzerinde değişiklik yapmayı tercih ediyorum.

Benim projemde Planning Board şu anda aşağıdaki gibi gözükmekte. Daha önce açılmış olan version 1’de 3 tane hikayemiz var. (Sprintlerin Tanımlanması için bir önceki yazımıza bakınız)

 Planning board’daki görünümümüz liste görünümü. Eğer özet veya kart görünümünde iseniz sağ üst köşedeki View’den Liste görünümüne geçebilirsiniz.

Böylece yukarıdaki görünüme ulaşabilirsiniz.

Sprint 1’in yanında yer alan “None” kısmında business value’lar gözüküyor. Buranın üzerine tıklayarak iş değerlerini yazabilirsiniz.  Hikaye 1 200 değerinde, hikaye 2 1000 değerinde ,hikaye 3 ‘de 500 değerinde olsun. En yüksek rakam bize en fazla değer katan hikaye olsun.

Aşağıdaki ekranda girişler sırasında bir görüntü görebilirsiniz. None’ın üzerine geldiğinizde çıkan kaleme tıklayarak değerleri girebilirsiniz.

Tüm hikayelerin business value’larını girdikten sonra planlama tahtasını iş değerlerine göre dizmek isterseniz yeni bir görünüm yaratmanız gerekmekte. Bunun için default’un yanındaki oka tıklayarak New diyerek

Yeni bir görünüm oluşturun.

 Context Name’e anlamlı bir isim vermek gerekli. Ben isimlendirme için “Story Sorted by Business Value” vermeyi tercih ediyorum. Sorting seçeneğinde Field Name olarak “Business Value” seçiyoruz. Sorting olarak descending verdiğimizde büyükten küçüğe sıralama yapabilirsiniz. Filter’da Issue Type olarak Story seçiyorum. Böylece sadece Story’leri takip etmek istiyorum. Save and apply diyerek yeni görünümüzü kaydediniz.

Artık planning board’da iş değerlerine göre sıralanmış hikayeleriniz bulunuyor.

Serinin Önceki Yazıları İçin

Jira ve Greenhopper ile Scrum – I

Jira ve Greenhopper ile Scrum – II

Internet’te makaleyi okuduktan sonra gerçekleştirdiğim arama sırasında Isaacson’un John Adams Enstitüsünde gerçekleştirmiş olduğu bir söyleşinin video’suna eriştim.

Bu yazıda hem liderlik derslerinin başlıklarına hem de video bağlantısına erişebilirsiniz.

14 liderlik Dersi Başlıkları

1. Odaklanın (focus)
2. Sadeleştirin (simplify)
3. Baştan sona sorumluluk üstlenin ( take responsibility end to end)
4. Geride kaldığınızda sıçrayın (when behind, leapfrog)
5. Ürünler kardan önce gelsin (put products before profits)
6. Hedef grupların kölesi olmayın (don’t be a slave to focus groups)
7. Gerçekliği bükün (bend reality)
8. Atfedin (impute)
9. Mükemmeli isteyin (push for perfection)
10. Sadece A Sınıfı Oyunculara hoşgörü gösterin ( tolerate only “A” players)
11. Hem büyük resme hem ayrıntılara bakın (know both the big picture and the details)
12. Yüz yüze ilgilenin (engage face-to-face)
13. İnsancıllığı bilimle birleştirin (combine the humanities with the sciences)
14. Aç kalın, budala kalın (stay hungry, stay foolish)

Makalenin orjinaline ulaşıp satın almak isterseniz tıklayınız.

Sizde aşağıdaki linkle video’yu izleyebilirsiniz. (Yaklaşık 1,5 saatlik bir söyleşi, ancak hem makaledeki birçok konuyu, hem de fazlasını içeriyor.)

Bu arada capital dergisi eski sayılarda yayınladığı hbr yazılarını web sitesinde de yayınlıyor. Buraya tıklayarak ulaşabilirsiniz.

Bu yazı dahilinde vizyon ve misyon konusunda biraz açıklama gerçekleştirip, örnek ifadeler içeren sitelere bağlantılar verip, bir örnek olarak erdemseherler.com için vizyon ve misyon tanımlamaya çalışacağım.

Vizyon için çeşitli tanımlar

• Kurmak istediğiniz geleceğiniz
• Ulaşmayı amaçladığınız nokta
• İşletme yönetiminde, işletmenin uzun dönemde gerçekleştirmeyi hedeflediği sonuç
• Ne olmak istediğimizi, nasıl çalışmak istediğimizi, nasıl algılanmak istediğimizi gösteren amaç

Misyon için tanımlar

• Bir kişi veya topluluğun üstlendiği özel görev
• Değerlerimizi, niçin var olduğumuzu, ne yapmak istediğimizi belirleyen sebepler
• Müşterilerimiz için ürettiğimiz değerler

Sözlük anlamı ile  oynadığımızda misyonumuzu bir kişi veya gruba atanmış olan özel görev olarak tanımlayabiliriz.

Bu çerçevede vizyonumuz ulaşmayı hedeflediğimiz yegane hedef, misyonumuz ise bu hedefe ulaşmak için atmamız gereken görevler olarak görülebilir.

Dünya’dan vizyon,misyon örnekleri:

Örnek Vizyon ifadeleri: http://www.skills2lead.com/sample-vision-statements.html

Örnek Misyon ifadeleri: http://www.skills2lead.com/sample-mission-statements.html

Türkiye’den vizyon, misyon örnekleri:

Türk Telekom vizyon, misyon ve değerleri:  http://www.turktelekom.com.tr/tt/portal/TTHakkinda/KurumsalTanitim/VizyonMisyon/

Netaş vizyon ve misyonu:

http://www.netas.com.tr/kurumsal/detay.aspx?SectionID=v84jiEYC3k7YeEPi79F5VQ%3D%3D&ContentID=PMO1LxuU1hr6IoJQtL511g%3D%3D

Erdem Seherler.com için Vizyon ve Misyon

Böyle bir yazı yazdıktan sonra erdemseherler.com için de vizyon ve misyon değerlerini yazmayı denemek gerekli diye düşünüyorum. İşte ilk denemem:

Vizyon:  

İçerdiği konular ile ilgili sektörde takip edilen bir yönetim danışmanı olmak.

Misyon: 

• Erdem Seherler’in tanıtımını gerçekleştirmek
• Farklı yönetim konularındaki bilgi paylaşımını sağlamak
• Paylaşılan bilgiler vasıtasıyla, yeni kişi ve kurumlara ulaşarak işbirliği fırsatları yaratmak

Lütfen beğendiniz misyon ve vizyon ifadelerini ve geribeslemelerinizi bu sayfaya yorum olarak ekleyiniz.

Blog’un bulunduğu sunucunun değişmesi ile  birlikte wordpress üzerinde  tutulan ayarlardan bazıları değişti.

Birkaç sene öncesinde hazırlamış olduğum blog’un üzerinde yaptığım değişiklikleri tekrar gerçekleştirmem gerekti

Bu yazıda neleri nasıl değiştirdiğimi not olarak tutup, sizlerle de paylaşacağım.

Yüklememi önereceğiniz başka word press plug-inleri varsa iletişim sayfası vasıtasıyla önerebilirsiniz.

Çok yakında yeni yazılarla buluşmak üzere;

Bağlantı adreslerinin düzenlenmesi:

Site üzerindeki bağlantıların p=100 şeklinde çıkması yerine kategori adı / doküman adı olarak değiştirmek için Admin panelde Settings|Permalinks altında Custom Structure seçip /%category%/%postname%/ yazabilirsiniz.

Yorumlarda ki maydanozlar için:

Akismet‘e ait ID’si yeni sunucuya geçtiğimde taşınmamıştı. Akismet.com’dan yeni bir ID alıp, tanımlamasını yaptım. Bu id’nin size gönderildiği e-postayı bir yerlere arşivleyebilirsiniz.

Feedburner

Feedburner bilgilerimde sunucu taşıması sırasında kaybettim.  Özellikle  yeni kayıtlar girildiğin de feedburner vasıtasıyla okuyuculara ulaşması için feedburner’ı kullanıyorum. Feedburner.google.com adresine giderek doğru feedburner title’ını tıkladım (bir den fazla varmış ) İlgili başlık altında publicize sekmesinden “email subscriptions” ve feedcount bağlantıları altındaki linkleri bir  text widget’ı altına koyarak menüye ekledim.

Contact  / İletişim Form

Contact ve İletişim Formlarımda ne yazık ki taşıma sırasında yok olmuştu. Bu formları yönetim ekranında contact menüsü altında (plug-in tarafından eklenmiştir) formları güncelleyip, ilgili form bilgilerini ilgili sayfalara ekleyerek tekrar çalışır hale getirdim.

İlgili Diğer Yazılar

Her bir yazının altına ilgili diğer yazıları gösteren bileşenim (YARPP) başlangıçta çalışmadı, ayarları değiştirmek için menüsüne girdiğimde  bir sorun olduğunu ama daha sonra düzeldiğini yazan bir not vardı. Sadece before / after related entries kısmını Türkçeleştirdim.

Tema’nın Eklediği Zorunlu Menüler

Kullanıdığım temanın içerisinde kodda yer alan menüleri koda müdahale ederek kaldırdım.  Bunun için yönetici panelindeki Appearence | Editör kısmını kullandım.

Tecrübelerimden gördüğüm, ürün sahibinin değeri arttırması için elinde bulunan en önemli araç önceliklendirilmiş ürün ve sprint backlog’u.

Ürün sahibi, gerçekleştirilecek her bir sprint içerisinde en fazla değeri alabilmek için, takımı öncelikle en fazla fayda üretecek olan hikayeler üzerinde çalışmasını sağlaması gerekmekte. Bu noktada takıma hedef olarak göstereceği hikayelerin üreteceği değerleri tahmin etmesi ve takım ile çalışma yapmadan önce bu değerleri belirlemesi gerekmekte.

Sprint planlama toplantıları öncesinde product backlog’u üzerinden sprint backlog’unu belirlerken son hali ile üretilecek bu değerleri göz önüne alması gerekmektedir.

–

Değer üretilmesi çeşitli zamanlarda finansal verilere indirgenebilir.

–

Örneğin “online kayıt formunun hazırlanması “ başlığında bir iş maddemiz olsun. Eğer online kayıt formu yaratıp web sitemize koyabilirsek, her bir kayıt için 100 TL kazanalım ve buradan aylık beklentimiz bir defalığına 100 kişinin kayıt olması olsun. Bu çalışmanın parasal değeri 10.000 TL olacaktır.

Bir diğer örneğimiz ise “ Yasal Zorunluluktan dolayı önceki kayıtların duyurulması “ başlığındaki iş maddemiz olsun. Bu madde daha önceden gerçekleştirilen bir etkinlik için başvuran kişilere web sitesi üzerinden bilgi verilmesi ile ilgili yasal bir sayfa açılmasını gerektirsin. Bu duyuru ile ilgili bulunduğunuz organizasyondan gelen bildiride şu şekilde bir not yazsın “Şirketiniz içerisinde bulunduğu organizasyonu kurallarından dolayı ilgili listenin 3 ay içerisinde yayınlanmamanız durumunda 50.000 TL ceza ödeyeceksiniz”.

Ürün sahibi olsanız elinizde bu iki madde ile birlikte irili ufaklı size her yapacağınız madde için 100 – 5000 TL arasında para kazandıracak veya yapmazsanız kaybetmenize neden olacak 10larca madde olsa hangi maddeleri yaparsınız.

Maddeler

• Online Kayıt Formu Hazırlanması
• Önceki Kayıtların Duyurulması
• 100- 5000 TL arasında para kazandıracak
• 100-5000 TL arasında para kaybettirecek maddeler.

Hangisini önce yaparsınız?

İşte bu noktada Ürün Sahibinin marifetleri ve yaklaşımı önemli. Elindeki iş listesini kendisine en fazla para kazandıracak ve en az para kaybettirecek şekilde düzenleyip şekilde sıralaması ve buna göre Scrum Takımının önüne iş listesini koyması gerekmekte.

Scrum Ekibinin yukarıdaki işleri 20 iş günlük (yaklaşık bir ay) sprintler içerisinde yaptığını düşünelim.

Kayıt formu’nu mu önce hazırlardınız, yoksa kayıtların duyurulması ile ilgili işleri mi?

Ürün sahibinin sorumluluğunu biraz daha arttıralım. Ürün sahibi kendi maaşı da dahil olmak üzere scrum ekibinin maaşını dağıtan kişi olsun. Elinde sadece ekibin maliyeti olan 10.000 TL’yi ödeyecek kadar para ile başlasın. (Nakit akışı problemi)

Şimdi önce hangisini yaparsınız?

Halen bana daha fazla veri lazım dediğinizi duyar gibiyim. Bildiride duyuru için 3 ay ne zaman mı bitecek diyorsunuz. Tamam batırmayalım ürün sahibinin iş modelini bildiri eline yeni geçti ve 3 ayı var şu anda.

Sıralama için karar vermeniz için yeterli mi? Değil mi? İşlerin ne kadar süreceğini bilip ona göre mi planlama yapmak istiyorsunuz?

Tamam sizde değer hesaplama ve buna göre ürün backlog’unu hazırlama kabiliyeti var.

Kayıt Formu 1 adam ay; duyuru ise 3 adam ay sürüyor. Geliştirme ekibiniz de 2 adam’dan oluşuyor. (örnek bu ya ideal Scrum takımı büyüklüğü altında kaldık)

Şimdi nasıl davranırsınız. Ürün sahibi olarak bir adamın kayıt formu, diğer adamın ise duyuru ile ilgilenmesini mi istersiniz. Olmadı şimdi. Scrum takımlarını kendi kendilerine organize olabilirler, onlara iş ataması yapmayalım. Kendileri kim nasıl iş paylaşacağına karar versin.

Bu örnekte kar etmek sizin için değer ise, elinizdeki backlog’un karınıza etkilerine, ne kadar zaman sonra bu karı elde edeceğinize ve kaynaklarınıza göre sprint ve product backloglarınızı optimize etmeniz gerekecektir.

• Ürün sahibi kar’ına göre ve işlerin ne zaman bitirilebileceğini (işin maliyeti) söyleyen takıma göre planlarını yapar.
• Takımına işleri zamanında değere dönüştüreceği konusunda güvenir.
• Ancak risk yönetimini de yapar.
• Ürün sahibi parayı veren ve değer üretiminden sorumlu olan kişi olarak ürettiği ve üretemediği değer çerçevesinde ekip içerisinde omuzlarında sorumluluk vardır.
• Ürün sahibi sprint içerisinde önceliklerle ve iş listesinde oynayamayacağından (tamam sprintin zamansız kapanmasını isteyebilir.), öngörü ile işleri iyi planlamalıdır.

“Bu işlerin hepsini yapmamız zorunlu, bu işlerin hepsi bu sprintte bitmeli, tamam backlog’ta yoktu ama bu işte yeni geldi çok acil diyerek” ürün sahipliği yapılmamalıdır.

Değer yaratabildiğiniz ve sprint hedeflerine ulaşabildiğiniz nice sprintler dileğiyle.

19 Nisan tarihinde katıldığım bir webinar’da Mike Cohn’un sunumunu izleme fırsatı buldum.

Sunumun pdf dosyasına buradan adresinden ulaşabilirsiniz.

Kısa özeti ile yedi günah şu şekilde açıklanıyor:

1. Pis boğazlık  /Aç gözlülük (Gluttony) : Projenin tüm boyutlarını (kapsam, zaman, kaynaklar ve kalite) sabitlemek

2. İhtiras / Tutku / Şehvet Düşkünlüğü (Lust): Özellikler için yoğun ve kontrolsüz tutku

3. Tembellik (Sloth): Her zaman yüksek kalitede iş çıkaramama

4. Şeffaf Olmama / Bulanıklık (Opaqueness): Projenin ilerlemesini, kalitesini veya diğer özelliklerinin belirsiz olması

5. Gurur/ Kibir (Pride): Ürünü geliştirmek için herşeyi bildiğine inanmak

6. İsraf (Wastefulness): Kritik kaynakların yanlış kullanımı

7. Miyopluk / Uzağı görememezlik (Myopia): Kendi işinizden ötesini görememe

Bu ve benzer webinarlara http://agile.vc.pmi.org/ adresini takip ederek ulaşabilirsiniz.

Jira ve Greenhopper ile Scrum yazımızın ikinci bölümüne hoş geldiniz. İlk bölüme buradan ulaşabilirsiniz.

Sprintlerin Tanımlanması

Scrum çerçevesinde her bir iterasyon Sprint olarak isimlendirilmektedir. Sprintleri paketlenmiş zaman aralıkları olarak düşünebilirsiniz. Bakınız: Scrum Guide: Time-boxes

Sprintlerimiz başlangıç ve bitiş tarihleri bulunmaktadır, ve ekibin hızını ayarlamak için her bir sprint’in aynı sürede tutulması önerilmektedir.

Jira içerisinde projeler için sürüm tanımlamaları yapılabilmektedir. Jira 4.1.1’de Project menüsüne tıkladığınızda erişebileceğiniz projeleri görecekseniz. Burada herhangibir projenin üzerine tıkladığınızda proje sayfası açılacaktır. Sol menüden version’a tıkladığınızda projeniz içerisinde tanımlanmış versionları görebilirsiniz. Sayfanın sağ üst kısmında “Manage Versions” linkini tıklayın. (Bu linki göremiyorsanız yeterli yetkiniz olmayabilir Jira yöneticiniz ile iletişime geçiniz.)

Açılan sayfa içerisinde yeni sürümünüzü tanımlayabilirsiniz.

Version Name: Sürümünüze bir isim verin. Örneğin: Sprint 1

Description: Bir açıklama girin

Release date: Sprintinizin bitiş tarihini girin.

Schedule:Sprintinizin zaman sırasına göre hangi sürümden sonra geleceğini seçin.

“Add” tuşuna basarak yeni sürümünüzü ekleyebilirsiniz. Jira’ya eklediğiniz sürüm, scrum’da Sprint’e denk gelmektedir.

Şu ana kadar Sprint’imizin ancak bitiş tarihini ve ismini verebildik. Şimdi de başlangıç tarihini verelim.

Sprint’in başlangıç Tarihinin Tanımlanması

Bunun için üst Menüden Agile | Planning Board’a geçiş yapmalıyız.

Dikkat edecek olursanız sol tarafta Unscheduled ve Sprint 1 isimli iki kutumuz bulunuyor. Eğer göremiyorsanız bu sütun saklanmış durumdadır. Board search’ün yanındaki “toggle columns visibility” ikonuna tıklayarak ilgili sütunların görülmesini sağlayını. Eğer kutularımız kapalı (collapsed) ise expand all ikonuna tıklayarak Unscheduled ve Sprint 1 kutularının genişlemesini sağlayın. Sprint-1 için dikkat ederseniz “End Date” Jira içerisinde tanımladığımız release date tarihini almış. Start date’i ise üzerine tıklayarak değiştirebilirsiniz.

Tatil Günleri

Bazı dönemlerde sprintlerinizin içerisine tatiller denk gelebilir. Scrum’da hızımızı ayarlamak için sprint sürelerini sabit tutmak istememizden dolayı bu tatil günlerini sprintimizin dışında tutmak isteriz.

Eğer Jira/Greenhopper yöneticimiz tatil günlerini girmedi ve sizde projenin yöneticisi iseniz; yetkimiz dahilinde Agile altındayken ekranın sağ üst tarafında gördüğümüz Tools menüsünü kullanabilirsiniz.

Tools| Configuration’a tıklayın.

Sprint zamanlarını tanımlayarak Burndown chart’ın başlangıç bitiş zamanlarını da tanımlamış olduk. Şimdi sıra backlogumuzu oluşturup business değerlerini vermeye geldi.

Bir sonraki yazımızda Business Value tanımlayarak devam edeceğiz.

Bu yazımızda elinizde Jira ve Greenhopper bulunduğunda Scrum adımlarını işletmek için neler yapmanız gerektiği konusunda bilgi vermeye çalışacağım.

Yapılması gerekenleri aşağıdaki gibi sıralayalım.

·Test statülerinin Jira’ya eklenmesi “To Test”, “In Test Progress”

·“Task Board”’ da “To Verify” sütununun eklenmesi

·Sprintlerin tanımlanması

·Business Value’ların verilmesi

·Business Value’lara göre Task Board’un Sıralanması

Task Board’s “To Verify” sütunun eklenmesi

Scrum içerisinde hikayelere göre yapılacak işler, üzerinde çalışılacak işler, doğrulanacak işler ve biten işler bulunmaktadır. Bütün bu işlerin bulunduğu bir Scrum İş Tahtası (Task Board) oluşturmak isteyeceğiz. Greenhopper ile gelen İş Tahtası içerisinde “To Verify“ kolonu bulunmamaktadır.

Bu kolonu eklemek için aşağıdaki adımları gerçekleştirin.

·Agile’a tıklayın

·Ekranın sağ üst köşesindeki Tools menüsünü tıklayın

·Bu menüdeki Configuration menüsüne tıklayın

·( General | Card Styles | Task Board Mapping) içerisinden Task Board Mapping sekmesini seçin.

·Add a column diyerek yeni bir sütun ekleyin.

·Yeni sutun’un adını “To Verify” olarak değiştirin.

Yukarıdaki işlemleri gerçekleştirerek Task Board’umuza “To Verify “ kolonumuzu eklemiş olduk.

Test Statülerinin Jira’ya eklenmesi

“To Verify” sütununu ekledik eklemesine ancak, bu sütuna hangi statüdeki işlerin gözükmesini gerektiğini henüz seçmedik. Bunun temel nedeni henüz bu statüleri yaratmamış olmamız.

Jira içerisinde yeni statü yaramamız için Jira ya yönetici (admin) olarak giriş yapmamız gerekmektedir. Eğer yönetici yetkisine sahip değilseniz, Jira’yı kuran kişilerden yardım talep etmeniz gerekecektir.

Yeni statü olarak “To Test”ve “In Test Progress” adımlarını ekleyeceğiz. Bunun için aşağıdaki adımları takip edin.

·Yönetici olarak Jira’ya giriş yapın.

·Sol menüde “Issue Settings” altında Statusus’u seçin.

·Add New Status bölümünde

oName kısmına “To Test”

oAçıklamasına “Teste gönder.”Yazın.

oIcon URL’e beyendiğiniz bir icon tanımlayın

·Aynı işlemi “In Test Progress”için de tanımlayalım.

Workflow steps içerisinden workflow içerisine yeni statüleri tanımlayın. Detayları için http://confluence.atlassian.com/display/JIRA/Configuring+Workflow adresine bakınız.

Task Board konfügrasyonuna şimdi geri dönüp yeni statüleri “To Verify” sütununda seçin. Seçimi gerçekleştirmek için “with one of the selected statuses” seçin, sonrasında “To Test” ve “In Test Progress” adımlarını seçin.

Artık task board’umuzda “To Verify” sütunumuz var ve gerekli adımlardaki hikayelerimiz ve işlermiz bu sütunda gözükecek.

Bir sonraki yazımızda Sprint’lerimizi tanımlayarak devam edeceğiz.

Proje yönetimi konusunda ise Amazon’dan gelen bir e-posta ile “Value-Based Metrics for Improving Results: An Enterprise Project Management Toolkit” Mel, Ph.D. Schnapper, Steven C. Rollins kitabı dikkatimi çekti.

PMI üyeliğim sayesinde books24x7.com  üzerinden bu kitabı okuma fırsatı buldum.

Kitap herhangi bir organizasyonda baz plan, izleme, yönetme, iyileştirme, iş fonkisyonlarının aynı hizaya getirilmesi ve ödüllendirilmenin geliştirilmesi için ölçütlerin kullanıldığı bir araç olan değer bazlı bir metodoloji için yol haritası belirtiyor.

Yazarlar bu kapsamada Performansın 3M’si olarak adlandırdıkları bir süreç geliştirmişler. 3M’den kasıt ise Measure (Ölç), Manage (Yönet), ve Magnify (Büyüt) şeklinde tanımlanmış.

Bu metodoloji, kurumların amaçlarına ulaşmak için stratejik olarak belirledikleri ölçütlerin organizasyon içerisinde hiyerarşik olarak yaygınlaştırılmasını destekliyor. Hiyerarşi ise organizasyon için ölçütlerin oluşturulması, bu ölçütlerin departmanlara indirgenmesi, ve bu ölçütlerin daha sonra bireylere indirgenmesi şeklinde.

Bu ölçütlerin tanımlanmasında, herhangi bir işe başlamadan önce işin tamamlanması sonrasında başarı ölçülerinin nasıl tanımlanacağını belirlenmesi gerekliliği belirtiliyor. ( Bu cümleyi yazdıktan sonra covey’in sonunu düşünerek işe başla, uygulama geliştirmede test driven developement, çevik iş analiz süreçlerinde hikayelerin  yazılması sırasında kabul kriterlerinin yazılması, iş yönetiminde amaçlarla yönetim gibi konular aklıma geliyor. J )

Yazarlar, projelerin maliyetlerinde ve proje sürelerinde bitirilememesini, ölçütlerin işe başlanmadan belirtilmesi yerine iş yapılırken tespit edilmesine bağlıyorlar.

Ölçütlerle yönetmek için gerekli adımlar ise şu şekilde sıralandırılıyor.

1.       Başlangıç için baz alınacak tüm verileri toplayın

2.       Kurumsal amaçlar için atanmış kurumsal hedeflere ait tüm maliyetleri hesaplayın.

3.       Her bir kurumsal amaç için planlanmış başlangıç ve bitiş zamanlarını belirleyin.

4.       Kurumsal amaçların, kurum için stratejik önemine göre (katacağı değere göre) sıralayın.

5.       Bu bilgiler ışığıdan kurumun 3M profilini çıkarın.

Örneğin kurumun amaçlarından birinin kurum içerisinde PMO sürelerinin oturtulması olduğunu düşünelim. Bu durumda yazarlar öncelikle ölçecekleri anahtar sonuç alanlarını (key value areas) ve ağırlıklarını şu şekilde belirlemişler.

a.       PMO’nun kurulumu (%40)

b.      PMO’nun yönetimi (%40)

c.       Çalışanların geliştirilmesi (%20)

Performans amaçlarını da her bir anahtar sonuç alanı için belirlemişler.

PMO’nun kurulumu (%40):

Kurulumun başlangıcı (%20):  1 ay içerisinde gerçekleşirse ( 4: Mükemmel), 2 ay içerisinde gerçekleşirse (3: İyi),  3 ay içerinde gerçekleşirse (2: Tatmin edici), 3 aydan daha fazla sürede gerçekleşirse (1: tatmin edici değil)

PMO için gerekli kaynakların temini(%20): Gerekli  kaynakların %90’ının temini (4: Mükemmel), Gerekli  kaynakların %50’sinin temini (3: İyi), Rol ve sorumluluklarının belirlenmiş olması (2: Tatmin edici), Tanımsız (1: tatmin edici değil)

Bu şekilde hedefleri belirlenmiş amaçların daha iyi yönetilebileceği belirtiliyor.

Ölçütlerle yönetim sırasında amaçların değişmesi durumunda , oranların değiştirilerek ilgili organizasyon veya kişilerin daha fazla değer katacak yere yönlendirilebileceği belirtiliyor.

Genel olarak bakacak olursak kitap 4 ana bölüme ayrılmış durumda:

a.       Metodolojinin tanımlanması

b.      Organizasyon için 3M Yönetim Programı

c.       Organizasyon için 3M Yönetim Araçları

d.      Organizasyonunuz için Uygulamaya Konulacak Ölçüt Programının  Değer Teklifinin Ortaya Çıkartılması

Eğer organizasyonunuz içerisinde proje yönetimini ve proje ofisinizi ölçütlerle yönetmeyi planlıyorsanız 3M metodolojisi size bir fikir verecektir. Aynı zamanda yazarın sunmuş olduğu örnek araçlar ve özellikle son bölümde yer alan PMBOK içerisinde yer alan süreçler için sunmuş olduğu “3Ms Maturity Model” bölümü ve bölümde PMO’lar için belirlemiş olduğu 7 seviye PMO olgunluğunuzu değerlendirmek için bir model oluşturuyor. Yazar aynı zamanda 3M olgunluk modelini oluşturmak için her ay neler yapılacağını belirttiği bir yol haritası belirtiyor.

Linkler:

Amazon’dan kitabı almak için

PMI’a üye olmak için (üye olduğunuzda kitaba ulaşabiliyorsunuz.)

Google Kitaplar’dan kitaba göz atmak için

Yeni yazılardan e-posta ile haberdar olmak için blog’a ana sayfadan abone olabilirsiniz.

Edward de Bonu’nun kitaplarını 2009 yılı içerisinde okumaya çalışıyorum. D&R’dan birkaç kitabını alma fırsatı buldum. deBono yanal düşünme (lateral) ve paralel düşünme terimlerinin yaratıcısı.

Güzel akıl nasıl edinilir? kitabında deBono iletişim konusunda aklımızı nasıl kullanabileceğimiz üzerinde durmuş. İletişim için önce ne söylenildiğini anlama, sonra akıl yürütme ve sonrasında da konuşma gerekiyor. Bu üç işlem için de aklımızı güzel bir şekilde kullanmamız gerekiyor.

Kitap’ın içindekiler bölümünde

· Aynı görüşte, karşı görüşte, farklı görüşlerde olma

· İlginç olmak

· Karşılık vermek

· Dinlemek

· Sorular

· Paralel düşünme

· Kavramlar

· Alternatifler

· Duygular ve Heyecanlar

· Değerler

· Yön Değiştirme ve Sapma

· Bilgi

· Görüş

· Karşıdakine müdahale etmek

· Tavırlar

· Konuşmaya Başlama ve Konular;

Bölümleri yer alıyor. Her bölüm örneklerle anlatılıyor ve sonunda özetleri bulunuyor.

deBono’nun düşünme ve akıl yürütme konularında geliştirdiği sistemsel yöntemlerin iletişim ve karar alma süreçlerinde riskleri azaltma konusunda faydalı olabileceğini düşünüyorum. Sorun şu ki akıcı ve basit bir şekilde ortaya konular sistemlerin uygulanmaya konulması için pratikler yapılması gerekiyor.

Kitap içerisinde işaretlediğim bir bölümü sizlerle paylaşmak istiyorum. Yazar alternatifleri aramanın güzel aklın çok önemli bir faaliyeti olduğunu belirtiyor. Alternatifleri aramak için ise üç aşamadan söz etmektedir.

1. Alternatifleri aramaya karşı istek,

2. Alternatif üretmek için çaba,

3. Alternatiflere değer biçme,

Deming’in plan-do-check –act yapısını akla getirmiyor mu? Alternatifleri bulma ihtiyacı iş süreçlerini iyileştirmek için geliştirilmiş bir problem çözme süreçlerine benziyor. Demek ki güzel aklımızı geliştirmek için alternatifleri sorgulamak bizim için faydalı bir faaliyet olacak.

Daha fazlası için: