Geçen sene Türkiye’deki CAPM sertifikasına sahip kişiler ile ilgili bir yazı yazmıştım. PMI’nın online registry sayfasından sorgulama yapmış ama doğru rakamlara ulaşamamıştım. Bir arkadaşım yazıya eklediği yorumla esasında Türkiye’de 2009 başı itibarı ile 5 tane CAPM olduğunu belirtmiş ve ben de tekrar sorgulama yaparak bunu görmüştüm.
Sanırım PMI veri tabanını sorgulama biçimim artık doğru. Dün tekrar bir sorgulama yapıp Türkiye’de bugün itibarı ile kaç tane PMP, CAPM, PMI-RMP, PgMP ve PMI-SP olduğunu öğrenebildim. Veri tabanından yapmış olduğum sorgulamada, sertifika sahibinin adı-soyadı, hangi il’den PMI’ya kayıt olduğu ve sertifikayı hangi yıl aldığı bilgisi de var.
22 Ağustos 2010 tarihi itibarı ile rakamlar şöyle…
PMP sertifikasına sahip toplam 714 kişi var listede. Listede 2 kişi var, ülke olarak Türkiye görünmekle birlikte bu kişilerin belirttikleri şehir yurtdışı… Bu 2 kişiyi listeden çıkartırsak Türkiye’deki PMP sayısı toplam 712 kişi. PMP’lerin illere göre dağılımı: Istanbul 516, Ankara 144, Kocaeli 25, İzmir 16, Bursa 1, Mersin 1, Rize 1, Konya 1, Kütahya 1, Zonguldak 1, Kayseri 1, Antalya 1, Tekirdağ 1, Sakarya 1, Adana 1
PgMP sertifikasına sahip şu anda 1 kişi var, listede Ankara olarak görünüyor, kendisi aynı zamanda PMP ve 17 Temmuz 2010 tarihinde sertifikayı almaya hak kazanmış.
CAPM sertifikasına sahip toplam 8 kişi var. İçlerinden birisi daha sonra PMP sertifikası da almış. İllere göre dağılımı: İstanbul 6, Ankara 1 ve Konya 1
PMI-RMP sertifikasına sahip 1 kişi var, listede Istanbul olarak görünüyor ve aynı zamanda PMP sertifikasına da sahip.
PMI-SP henüz yok. Bakalım zaman içerisinde bu sertifikayı da alacak kişiler olabilir.
70 milyon nüfusu olan bir ülke olarak sertfikalı sayısının bu rakamların çok üzerinde olması lazım, kafamdaki rakam en az 5000 kişi olmasının gerektiği… PMP sınavı inşallah bu sene sonunda Türkçe alınabilecek. PMBOK Türkçe de bu sene piyasaya çıktı. Bu rakamların önümüzdeki birkaç yıl içerisinde hızlı bir şekilde artacağına inanıyorum.
Daha önce de birkaç yazımda vurgulamıştım blog’uma olabildiğince iş ağırlıklı yazılar yazıyorum. Arada sırada hobilerim ve kendi yaşamım ile ilgili yazılar da yazıyorum. Bugün yaşadığım yoğun duygular ve düşündüklerimin kayıt altına alınması için bu yazıyı yazmak istiyorum.
Kızım, Zeynep, bugün 12:15′de Delta Airlines ile Amerika’ya uçtu. Öğrenci Değişim programı kapsamında geçen sene sınava girdi ve başarıyla geçti. Yaklaşık 2 yıldır bunu kendisi istiyor. Lise 3′ü orada okuyacak. Bu kendi kararıydı. Eşim ve ben onu yönlendirmedik. Kendi vermiş olduğu karardan dolayı onu destekledik. Son3-4 aydır hazırlıkları sürüyordu. Eşim inanılmaz koşturdu, hazırlıkları için en ince detayına kadar uğraştı onu hazırladı. Bu hazırlık sürecinde içimde oluşan duyguları anlatamam. 17 yıldır kızımla beraberiz. 2 sene önce 1 aylığına İngiltere’ye gitmişti. En uzun ayrı kaldığımız süre oydu ama o zaman bu kadar etkilenmemiştim. Bu sefer çok daha uzun bir süre…
Zeynep, Amerika’da Virginia Beach şehrinde kalacak. Okyanus kıyısında 500.000 nüfusu olan sevimli bir yer. Kalacağı ailenin biri 17 yaşında diğeri de 12 yaşında iki kızı var. Anne öğretmen, baba bankacı. Gideceği yer belli olduktan sonra Zeynep aileyle iletişim kurdu. Aile heyecanla Zeynep’i bekliyor. Oradaki ailesi bizlere ve kendisine çok sıcak mesajlar gönderdiler. Eşimle benim ilk başlardaki tedirginliğimiz gitti. Zeynep’in yaşında olan Victoria diplomat olmak istiyormuş. Türkiye ve Türkçe ile ilgileniyor. Geçen sene Ankara’ya gelmiş bir süre kalmış. Bu yıl da Istanbul’a Türkçe öğrenmeye geldi Temmuz başında ve 6 hafta burda kaldı. Zeynep gitmeden Victoria ile tanışma fırsatı oldu. Bu onun için çok iyi oldu. Onun da içinde bazı tedirginlikler vardı. Amerika’da beraber olacağı, aynı evde yaşayacağı kardeşi ile tanışmış olduğu için kendini iyi hissetti.
Oldukça uzun bir süre bizim için. Bugün yolcu ederken içimiz iyice parçalandı, duygulandık, göz yaşlarımıza hakim olamadık. Onu çok ama çok özleyeceğiz. Programın bize aktardığı diğer bir konu da anne ve baba, çocukla 6 ay yüz yüze görüşemiyor. Anne, Baba olarak baktığınızda bu durumu kabul edemeseniz de bunun haklı nedenleri var. Bakalım biz gidebilirsek Şubat ayında onu görmeye gidebileceğiz.
Evet bu, Zeynep’in kararıydı ve bu kararına sıkıca tutundu. Kafa olarak kendini hazırladı ve gitti. Zeynebime güveniyorum, başarılı olacağına eminim. Yolun açık olsun bitanem, seni çok seviyorum.
Değişiklik istekleri (change request) bir projede farklı kanallardan gelebiliyor. Bir proje nasıl ortaya çıkıyor? Çalıştığınız şirketin yapısına bağlı değişiklikler gösterebilir. Örneğin benim çalıştığım şirkette projeler şu şekilde ortaya çıkıyor. Ben bir GSM operatöründe program yöneticisi olarak çalışıyorum. Yukarıdan baktığınız zaman şirketimiz, kabaca, Teknoloji, Satış, Pazarlama ve Müşteri Hizmetleri bölümlerinden oluşuyor. Teknoloji dışındaki bölümler ihtiyaçlarını karşılamak için Teknoloji bölümüne ihtiyaçlarını bildiriyor. Teknoloji bölümü bu süreçte müşteriden iş gerekçesini istiyor. Tamam bu projeyi yapalım ama bunun sonucunda şirket ne kazanacak? Müşteri sayısı artacak mı, gelirimiz artacak mı? Bu akış tanımlanmış bir süreç çerçevesinde ilerliyor. İş’i isteyen, proje sonunda ortaya çıkan hizmeti, ürünü veya uygulamayı kullanacak olan bölümler Teknoloji bölümüne göre “müşteri”. İş’in sahibi bu bölümler. Daha fazla detaya girmeyeyim. Projenin yapılabilirliği iş analistleri tarafından çalışılıyor, analiz ediliyor. Eğer yapılabilir ise ne kadar sürede yapılacağı ve kabaca bütçesi müşteri ile paylaşılıyor. Projenin başlamasına karar veriliyor ve proje yöneticisi atanıyor. Artık elimizde bazı biligiler var, tahmini süre, bütçe ve eğer başka bir firma (tedarikçi) ile çalışılacaksa onların bilgileri vs… Proje kickoff toplantısı ile başlatılıyor. Planlama aşamasında proje paydaşları olarak hem müşteri hem de teknik proje ekibi ile yoğun mesai yapılıyor. Bütün bunların koordinasyonunu proje yöneticisi yapıyor. Bu çalışmaların içerisindeki en önemli doküman “kapsam dokümanı”. Kapsam çıkartılıyor ve müşterinin onayına sunuluyor. Kapsam dokümanı projede ne yapılacak, müşteri tarafından ne isteniyor gibi bilgilerin detaylı olarak yer aldığı doküman. Bu doküman müşteri tarafından onaylanınca artık taraflar arasında mutabakat sağlanmış oluyor. Sonrasında tasarım aşamasına geliniyor, tasarım çalışmaları yapılıyor. Bu çalışmalar sırasında da müşteri ile iletişim devam ediyor. Tasarım dokümanı da onaylanıyor. Eğer proje bir yazılım geliştirme sürecini içeriyorsa tasarım onayından sonra geliştirmeler başlıyor. Vurguladığım gibi bu geliştirmeleri şirket içi kaynaklarla ve/veya tedarikçi bir firma ile yapabilirsiniz. Geliştirmeler bittikten sonra geliştirilen uygulamanın mevcut alt yapınıza entegrasyonu için testler yapılıyor. Bu teknik testler başarı ile tamamlanınca artık geliştirilen uygulama, yani müşterinin istediği uygulama son kullanıcı testi (UAT: user acceptance test) için hazır hale geliyor. Müşteri son kullanıcı testlerini de başarı ile bitirirse artık proje hayata geçiyor ve tamamlanıyor. Bu aşamadan sonra operasyon başlıyor ve projeyi şirketin operasyon bölümü devir alıyor.
Proje başladıktan sonra analiz yapılırken, tasarım çalışmaları sürerken müşteriden değişiklik istekleri gelebiliyor. Şuna da ihtiyacımız var, yeni bir düzenleme geldi şunları da eklememiz gerekiyor, tasarımı böyle yaptık ama kullanıcı ekranında şu buton şurada olsun, ben bu butona basığımda bir bilgilendirme mesajı önümüze çıksın, almak istediğim raporlar için şu tip raporları da ekleyelim gibi birçok değişiklik isteği geliyor. Değişiklik istekleri bir projenin doğasında vardır ve normaldir. Fakat proje sağlığı açısından değişiklik isteklerinin proje akışında bir noktaya kadar gelmesine izin vermek gerekiyor. Örneğin artık test aşamasına gelmişsiniz, tasarım onaylanmış, geliştirmeler tamamlanmış, artık projenin sonuna yaklaşmışsınız. Müşteri önünüze değişiklik isteği ile geliyor. Bu durum projeyi maliyet ve zaman açısından etkiliyor. Baştan planladığınız sürede bitiremeyeceksiniz ve üzerine fazla para harcamanız gerekiyor. Ben program yönetici olarak proje yöneticisi arkadaşlarıma tasarım sürecinin sonuna kadar müşteriden değişiklik isteklerini alabileceklerini ve değerlendirebileceklerini söylüyor ve onların da müşteriye bu bilgiyi aktarmasını istiyorum. Tamam müşterinin ihtiyacı varsa bu yapılacak, ihtiyacını karşılamak lazım. Ama bu ilave ihtiyaçların projenin 2.fazı olarak ele alınacağını müşteri ile paylaşmalarını, proje yöneticilerinden istiyorum.
Bu arada değişiklik istekleri sadece iç müşterinizden gelmiyor. Proje için birlikte çalıştığınız tedarikçi firma da karşınıza, farklı bir şekilde, değişiklik talebi ile çıkabiliyor. Örneğin tasarım aşamasında birlikte çalışmış, sonrasında çıkan dokümanı da şirket olarak onaylamışsınız. Geliştirmeler yapılıyor, teste geliyorsunuz ve geliştirilen uygulamayı fonksiyonel olarak ele alıyorsunuz, bakıyorsunuz ki eksikler var. Bunu tedarikçi firmaya iletiyorsunuz, bakın tasarım dokümanında yazdık bunu bekliyorduk ama şu anda yok bunu da eklemelisiniz diyorsunuz. Tedarikçi firma orada yazanı biz şu şekilde algılıyoruz, bu istek bir değişiklik isteğidir, daha önce konuşulan, yazılan şeylerin dışındadır diyebiliyor. Sonra ne oluyor, başlıyorsunuz kavga etmeye bu değişiklik isteğidir, değildir yapmalısınız vs.
Geçen yıl Değişiklik Yönetimi konusunda bir yazı yazmıştım. O yazıda kaleme aldığıım durum farklı bir değişiklik isteğiydi. O zaman üstünde çalıştığımız büyük bir projede çalıştığımız tedarikçi firma ile aramızdaki onların hatasından kaynaklanan bir durum için karşımıza değişiklik isteği ile gelmişler ve biz de bunu kabul etmemiştik. Biz onların hatası olduğunu ortaya koyuyorduk onlar da hayır siz bizi beklettiniz biz şu kadar adamı burada tuttuk, bize şu kadar para vermelisiniz diyorlardı. Oldukça sıkıntılı bir durumdu ve yönetmekte zorlanmıştık. O yazımda da bu tür değişiklik isteklerinin önüne geçmek için neler yapılması gerektiğini vurgulamıştım.
Bir projede değişiklik isteklerinin (change request) hangi süreçte ele alınacağının ve işleyişin, sürecin nasıl olması gerektiğinin başlangıçta belirlenmesi önemli. Değişiklik isteği proje ekibine nasıl ve hangi yolla iletilecek? Değişiklik istekleri nasıl analiz edilecek? İletilen değişiklik istekleri nasıl takip edilecek? Değişiklik isteğinin onaylanması ya da reddedilmesi için neler yapılacak? Büyük projelerde, örnek olarak 1 yıldan fazla süren, değişiklik yönetimi sürecinin proje başlangıcında çok net belirlenmesinde fayda var.
Değişiklik isteklerini ilk karşılayan kişi Proje Yöneticisidir. Gelen istekleri proje ekibi ile değerlendirip analiz eder. Projeye olan etkisi (zaman, maliyet…) çıkartılır. Analiz tamamlanıp dokümante edilince değişiklik kontrol kuruluna (change control board – CCB) proje yöneticisi tarafından aktarılır. CCB değişiklik isteği üstünde bir değerlendirme yapar ve sözkonusu isteğin yerine getirilip getirilmeyeceği konusunda bir karar verir.
Geçen seneki yazım Vikipedi Özgür Ansiklopedi’de ele alınan Değişiklik Yönetimi makalesinde kaynak olarak gösterilmiş. Sonradan fark ettim, ben bunun için bir şey yapmadım. Ama tanımadığım birisi yazımı kaynak olarak göstermiş, çok memnun oldum. Blog’umda yazdığım bu yazılar okuyanlara bir şeyler verebiliyorsa ne mutlu bana.
