Saadet TEKEL

Yazar hakkında: İstanbul Üniversitesi İşletme Fakültesi İngilizce bölümünden mezun oldu. Yüksek lisansını Marmara Üniversitesi Bankacılık ve Sigortacılık Enstitüsü-Sigortacılık Bölümünde yaptı. Yaklaşık 10 yıllık Pazarlama, Satış Destek ve Ar-Ge çalışmasından sonra bilgi teknolojileri alanına dikey geçiş yaptı. 2004 yılından itibaren çeşitli IT projelerinde iş analisti ve proje yöneticisi olarak görev aldı. 2009 yılında PMP sertifikasını alan yazarımız, PPM araçları konusunda da önemli deneyimlere sahiptir.

KIRIK CAMLAR TEORİSİ
Tem06

KIRIK CAMLAR TEORİSİ

Yıllar önce çalıştığım şirkette bir yönetim değişikliği yapılmış ve önceden tanıyıp çok saygı duyduğumuz bir yöneticimiz yeni genel müdürümüz olarak atanmıştı. Bir süredir kronikleşmiş bazı sorunlar yaşıyorduk ve bu sorunlar rakamsal sonuçlarda da etkisini göstermeye başlamıştı. Yeni genel müdürümüz bir süre durumu gözlemledikten sonra geniş katılımlı bir toplantıyla bize mevcut resmi çizdi ve sorunumuza teşhisi koyduğunu söyledi: “kırık cam sendromu”. Bu toplantıdan önce hiç duymadığım ve çok ilginç bulduğum “kırık camlar teorisi”ni (Broken Windows Theory) sizinle de paylaşmak istiyorum. Teoriye göre; İnsanların bir yerde düzen olmadığına veya düzenin zayıf olduğuna inanmaları, onların suç işlemek için bir sakınca görmemelerine ve sorumlu tutulmayacaklarını düşünmelerine sebep olur. Katılıyor musunuz? Bu teori ilk kez 1982 yılında sosyal bilimciler James Q. Wilson ve George L. Kelling tarafından makale olarak sunulmuş. Bu makalelerinde Wilson ve Kelling teorilerini özet olarak aşağıdaki gibi açıklamış: “Birkaç kırık penceresi olan bir bina düşünün. Camlar tamir edilmemişse vandallar birkaç cam daha kırmaya meyillidir. Hatta bina boş ise binaya daha büyük zararlar verebilirler, sonunda bina ve devamında o sokaktaki diğer binalar yaşanmaz hale gelebilir…” İlk kez 1982’de yayınlansa da, aslında ABD’li suç psikologu Philip Zimbardo’nun 1969 yılında yapmış olduğu bir deneyden esinlenerek elde edilmiş olan, kentsel düzensizlikler ve suç eğilimlerini ele alan kriminolojik bir teori. Bence konunun en ilginç yönü tam da bu deney. Zimbardo deneyinde, plakası olmayan iki arabayı Kaliforniya’nın Bronx ve Palo Alto semtlerinde terk ederek gözlemlemeye başlamış. Bronx suç oranının yüksek, sosyo ekonomik düzeyin düşük olduğu bir kenar mahalle semti, Palo Alto ise Etiler gibi son derece nezih bir muhit. Sanırım Bronx’ta arabanın başına neler geldiğini tahmin etmek zor değil. Birkaç dakika içinde 3 kişilik bir aile tarafından radyatör ve aküsü sökülmüş, 24 saat içinde ise arabada değer taşıyan tüm parçalar alınmış. Camları kırılan ve döşemeleri de yırtılan arabayı çocuklar oyun alanı olarak kullanmaya başlamış. Peki aynı anda Palo Alto’ya bırakılan arabaya ne olmuş dersiniz? Tahmin ettiğiniz gibi kimse dokunmamış. Taa ki bir hafta sonunda Zimbardo iki asistanıyla arabaya yaklaşıp kelebek camını kırana kadar. Bu hareketten sonra dakikalar içinde çevredekiler de ona katılmış ve araba hızla tahrip edilerek 24 saat içinde kullanılmaz hale gelmiş. Zimbardonun gözlemlerine göre bu eyleme katılanların büyük bölümü iyi giyimli ve beyaz yetişkinlermiş. Bunun sonucunda Zimbardo şunu belirtmiş: “İlk camın kırılmasına, ya da çevreyi kirleten ilk çöpe, ilk duvar yazısına izin vermemek gerek. Aksi halde kötü gidişatı engelleyemeyiz.” İşte bu kural, dünyada pek çok yerel yönetim tarafından kentsel düzenin sağlanması ve suç oranlarının azaltılması için kullanılmış. En başarılı örneğini Newyork kentinde 1994-2001 yıllarında belediye başkanı olarak görev yapan Rudy Guiliani göstermiş ve New York’ta suç oranlarını önemli ölçüde düşürerek Amerika’nın güvenli şehirlerinden biri haline getirmiş. “Metruk bir bina düşünün. Binanın camlarından biri bile kırılsa,...

Read More
UZUN SOLUKLU PROJELERDE BAŞARI
Nis20

UZUN SOLUKLU PROJELERDE BAŞARI

Uzun İnce Bir Yoldayız… Uzun Soluklu Projelerde Başarı için 11 İpucu Uzun bir aradan sonra tekrar FABE sayfalarında sizlerle buluştuğum için çok heyecanlıyım. “Değişmeyen tek şey değişimin kendisidir.” Herakleitos İş hayatındaki herkesin iyice benimsediği bu evrensel tespit, bana kalırsa içinde bulunduğumuz durumu anlatmak için artık yetersiz kalıyor. Teknoloji ve ihtiyaçlar büyük bir hızla değişiyor, kurumlar -ve kişiler- bu hıza ayak uydurmak için sürekli bir ‘dönüşüm’ halinde olmak zorunda. Aslında ben kendi adıma bu durumdan oldukça memnunum. Durmadan yeni, büyük, farklı projelerde çalışırken çok şey öğreniyorum. Üstelik kurumlar da öğreniyor ve proje yönetim metodolojisi -dolayısı ile proje yöneticilerinin- gerekliliği ile ilgili farkındalıkları artıyor. Bu ay, uzun süreli dönüşüm projelerinin başarısı için kritik gördüğüm noktaları sizlerle paylaşmak istiyorum. 1. Ne kadar uzun? Genellikle birden fazla alt projeyi içereceği için, bu tür dönüşüm projelerini program olarak da adlandırmak mümkün. Dönüşüm programı da olsa mümkünse bir buçuk yıldan uzun süreli bir proje yapılmamalı, benim görüşüm bu. Programların uzamasının getireceği çeşitli riskler var, sonraki maddelerde bunlara değiniyorum. Yolda çıkacak risk ve sürprizlere hazırlık olarak sadece finansal bütçede değil, zaman planında da bir emniyet payı bırakmalısınız. 2. Hedefleri netleştirin ve kapsam çerçevesini çizin Projenin hedefleri net olmalı; sağlam bir olurluk analizi (business case) hazırlandığından emin olun. En yüksek ve hızlı kazanımı sağlayacak işler belirlenip bir öncelik belirlenerek yol haritası oluşturulmalı. Herşeyi bir anda yapmaya kalkınca paralel yürüyen birçok alt proje ortaya çıkıyor ve aslı faydayı sağlayacak kilit projeler de riske giriyor. 3. Proje Yönetim Ekibi kurun Günümüzde bilgi teknolojilerinin dahil olmadığı bir dönüşüm programı düşünemiyorum. Bu tür programlarda dışarıdan danışmanlık almanın da yaygın bir uygulama olduğunu düşünürsek aslında projelerin 3 önemli ayağının olduğunu söyleyebiliriz: Teknoloji Departmanı (BT), İş Birimleri, dış partiler (danışmanlar ve diğer iş ortakları). Bunlardan birinin katılımı gereken dozda olmadığında projedeki dengeler de bozulacaktır. Her üçünün de rollerinin tanımlı ve net olduğu bir proje yönetim ekibi kurarak sahiplenmeyi sağlamalısınız. Bu ekibi projenin “Proje Yönetim Ofisi” olarak da adlandırabilirsiniz. 4. Kimin projesi? Proje sahibi iş birimi dışında Projeye dahil olması gereken tüm kişilerin resmi olarak ekibe atanması işin sahiplenilmesi için çok önemli. Ekip üyelerinin performansının proje yöneticisi tarafından değerlendirilmesi de sürece katkıda bulunacaktır. 5. Kritik paydaşlara dikkat! Gereksinimler belirlenirken tüm paydaşları sürece dahil ettiğinizden ve gerekli tüm onayların alındığından emin olun. Dikkate alınmayan paydaşlar patlama hazır bir bomba gibi her an kendilerini gösterebilir. Özellikle gereksinimler belirlenirken tüm iş kurallarının belirlenmiş ve ilgili her bölüm tarafından onaylanmış olması gerekli. Kullanıcılar –özellikle sıfırdan oluşturulan yeni yazılım uygulamaları ve modüller için- tasarım ve yazılım aşamalarında da sürece dahil edilmeli. Aksi halde son testler sırasında bile çok sayıda ek kapsam talebi ortaya çıkabilir. 6. Değişimi yönetin, sürprizlere hazırlıklı olun Kapsamın belirlenmesiyle tamamlanması arasında geçen süre uzadıkça, değişiklik ihtiyaçlarının...

Read More

PDU REHBERİ

Bugün Proje Yönetimi İçin Ne Yaptınız? PMP sertifikası almaya karar verdiğimde gözümü en çok korkutan şey sertifikayı yenilemek için PDU toplamanın zorunlu olmasıydı. İlk PDU’larımı raporlamak istediğimde oldukça zorlandım.  Hangi kategoriyi seçeceğim, kaç puan talep edebilirim soruları kafamı karıştırıyordu. Geçen üç yılda gördüm ki puan almak o kadar da zor değil ve kendini geliştirmek açısından çok güzel bir sistem. Sertifika Devamlılık Kriterleri (CCR –Continuing Certification Requirements ) Sistemi CCRS, PMI sertifikaları sahiplerinin bilgilerini ve yetkinliklerini geliştirmelerini sağlamak amacıyla oluşturulmuş. Yani sürekli mesleki gelişimi teşvik edip destekleyen bir yapı düşünülmüş.  Sistem hepinizin bildiği gibi, sahip olunan sertifikanın gerektirdiği mesleki gelişim puanlarını (meşhur PDU’lar) tamamlamak esasına dayanıyor. Her bir sertifika için, sertifikanın geçerli olduğu süre boyunca tamamlanması gereken puan sayısı farklılık gösteriyor.  PDU kazandıran aktiviteler çeşitli kategorilere ayrılıyor. PMI’ın PDU sisteminde yaptığı son düzenlemeyle kategori sayısı azaldı ve yapı biraz daha sadeleşmiş oldu. Yeni yapıda iki ana kategori var: Eğitim ve Mesleğe Katkı (Giving Back to the Profession). Her bir kategori üç alt kategoriye ayrılıyor. Bu kategorilere giren mesleki aktivitelerde harcanan her bir saat için 1 PDU kazanma hakkımız var. Talep ettiğimiz PDU tam sayı olmak zorunda değil, 0,50 gibi küsürlü puanları da beyan edebiliriz.  Kategoriler: PDU Kazanmak için Öneriler PMI, sertifikanızı alır almaz PDU kotanızı tamamlamak için bir plan yapmanızı öneriyor. İşte puan kazanabileceğiniz bazı aktivite örnekleri: • REP sertifikası olan veya olmayan kurumlardan Proje yönetimi eğitimleri almak • Proje yönetimi seminer/kongrelerine katılmak • Proje yönetim derneklerinde gönüllü çalışmalar yürütmek • Ücretli ve ücretsiz on-line eğitimler almak • Proje yönetimi ile ilgili makaleler yayınlamak • Kongrelerde sunum yapmak • Gönüllü proje yönetimi eğitimleri vermek • Proje yönetimi ile ilgili kitap ve yayınları okumak • Proje yönetimi ile ilgili görsel yayınları izlemek • Daha tecrübeli bir proje yöneticisinden formal olarak koçluk/mentorluk almak • Fiili olarak proje/program yönetmek Hangi aktivitelerin hangi kategoriye gireceği ile ilgili detaylı bilgiye ve sistemle ilgili pratik bilgiler veren videolara aşağıdaki linkten erişebilirsiniz. http://www.pmi.org/~/media/PDF/Certifications/pdc_pmphandbook.ashx https://ccrs.pmi.org/ Hakedilen PDU’ların Raporlanması Büyük emeklerle hak ettiğiniz PDU’larınızı talep etmek için  https://my.pmi.org/  adresinden sisteme giriş yaparak CERTIFICATION STATUS bölümündeki REPORT PDU butonuna basarak ilgili sayfaya ulaşabilirsiniz. Bu sayfada yapmanız gereken tek şey doğru kategoriyi seçerek, yaptığınız çalışmayla ilgili detayları vermek. Aktivite ile ilgili tarih, sertifika, belge gibi bilgileri dosyalamanız faydalı olur. Çünkü denetime takılan talepler için sertifika sahiplerinden PDU aktivitesinin belgelenmesi istenebiliyor. Hepinize, sürekli gelişmenizi sağlayan bol PDU’lu günler diliyorum. SAADET TEKEL, PMP Mayıs...

Read More

NEREDEN ÇIKTI BU PROJE?

BT Projelerinde Kaynak Planlaması “Değişmeyen tek şey değişim.” Sanırım BT dünyasında çalışanların çalışma hayatını en iyi anlatan cümle bu olmalı. Aslında tüm uzmanlık alanları ve sektörler için bu gerçek geçerli. Ama yazılım işinde sürekli gelişen teknoloji ve iş birimlerinin aralıksız yeni ihtiyaçları pek çok projeyi eş zamanlı olarak yürütmeyi bir yaşam tarzı haline getiriyor. Ben içinde bulunduğun finansal hizmetler sektöründe bu gerçekle yaşıyorum. Aynı anda hem pek çok projeyi yönetip hem günlük hayatı sorunsuz bir şeklide sürdürmeye çalışırken,  bir yandan da iş tarafından gelen yeni taleplerin baskısı altında kalmak biz BT profesyonellerinin aşina olduğu bir durum. Hatta artık taleplerin iş fonksiyonlarından gelmesini beklemek yerine BT ekiplerinin sürekli innovasyon yapması, şirketin vizyonunu şekillendirerek takip eden değil lider rolünde olması bekleniyor. Hayatımıza devam edebilmek için bu gerçeği bir yaşam biçimi haline getirmeye çalışırken en çok zorlandığımız işlerden biri de kısıtlı ve değerli uzman kaynakların yönetilmesi. Her talebi kabul etmek işlerin söz verdiğimiz zamanda tamamlanmamasına neden olurken, her gelen talebi –süresiz-  bekletmek de iç müşterilerde dipsiz bir kuyuya taş atmışlık duygusu yaratıyor. Projeler Gelin! Korkmuyoruz Gelen yoğun proje talepleri karşısında ilk yapmaya ihtiyaç duyduğumuz şey elimizde yeterli kaynak bulunup bulunmadığını kontrol etmek. Böyle tek cümleyle ifade etmek kolay gibi…   Ama hepimiz bunun zorlu bir iş olduğunu biliyoruz. Benim proje yöneticisi olarak yaşadığım en büyük zorluklardan biri; kaynakların diğer proje ve günlük işlerden gelen iş yükleri nedeniyle proje planlarımızın sürekli sarkması. (Proje bazlı değil, matris bir organizasyondan söz ediyorum). Taahhüt verebilmek ve verdiği taahhütlere uymak için bir BT organizasyonunun yapması gereken en önemli iki iş : 1. Kaynaklarını doğru planlamak ve dengeli iş atamaları yapmak, 2. Kaynakların iş yüklerini görüp izleyebilmek, 3. En az sapmayla doğru efor tahminleri yapmaya çalışmak. Eğer orta ve büyük ölçekli bir BT ekibi ile çalışıyorsanız bu iki işi hakkıyla yapabilmek için bir araç kullanmak gerekli.  Projelerde çalışan kaynakların herbir projeden gelen iş yüklerini görmek, buna göre atamaları yapabilmek için ortak bir çalışma platformu sağlayan pek çok başarılı yazılım var. Özellikle bankalar ve telekomünikasyon şirketlerinde yaygın olarak kullanılıyor. Bu araçları kullanarak ileriye dönük kaynak planlamaları yapılabilirse, hemen başlaması mümkün olmayan projeler için muhtemel başlama tarihi, ya da hemen başlamak için ne kadar yeni kaynağa ihtiyaç duyulduğu iç müşteriye bildirilebilir. Önce Hangi Proje? Artık elimizdeki Bir BT Departmanı üzerine hızla gelen projeler sürüsünü nasıl karşılayacağına karar vermek için atması gereken ikinci adım ise (artık kaynaklarımızı doğru planladığımızı ve o an itibarı ile elimizde ne kadar uygun kaynak olduğunu bildiğimizi vrsayıyorum) projeleri seçmek ve öncelik vermek. Aslında bu süreç üst yönetimin de dahil olması gerken stratejik kararları içeriyor. Ocak Ayında yayınlanan “DOĞRU PROJE, DOĞRU YÖNETİM” başlıklı yazımda da bu konuya değinmiştim. BT projelerinde –ki çoğunlukla yazılım projeleridir- yazılım ve donanıma...

Read More

TOPLANTI SANATI

İş hayatında en sık duyduğumuz yakınma cümlelerinden biri  “toplantı yapmaktan çalışamıyoruz” cümlesidir herhalde. Yoğun toplantı trafiği bazen gerçekten de insanları gerçek işin yürütülmesinden alıkoyabiliyor. Uzadıkça uzayan ama bir sonuca ulaşmayan hatta konunun sonunda daha da karmaşık hale geldiği toplantılar, çay-kahve partisi ve arkadaş sohbetlerine dönüşen toplantılar, çok ilgisiz konulara ısrarla dalıp toplantının ilerlemesini engelleyen katılımcılar… Sonuçta verimsiz geçen zaman ve doğal olarak bitmeyen işler… Toplantıları planlayabilmek ve başarılı toplantılar yürütebilmek bana göre gerçekten bir sanat. Bugüne kadar edindiğim deneyimlere dayanarak toplantıları yürütmekle ilgili bazı önerilerim olacak. Bunlar yeni söylenen şeyler değil, evrensel kurallar ama yine de tekrarlamak istiyorum. •    Öncelikle toplantı planlanmalı: amacı ve gündemi mutlaka önceden belli olmalı. •    Gündeme göre kimlerin katılması gerektiği doğru belirlenmeli •    Süresi önceden belirlenmeli, mümkün olduğu kadar kısa tutulmalı •    Toplantılar zamanında başlamalı •    İyi yönetilmeli,  konunun dağılmasına izin verilmemeli •    Katılımcılar hazırlıklı gelmeli •    Toplantının amacı ne ise, onun gerçekleştirildiğinden emin olunmalı •    Toplantı sonunda görüşülenler özetlenmeli ve bir sonraki adımda alınacak aksiyonlar belirlenmeli •    Mutlaka alınan kararları, işlerin sorumluları ve son tarihlerini belirten bir toplantı notu yayınlanmalı •    Mail ya da telefon yolu ile çözülebilecek konular için toplantı yapılmamalı. Projelerde Toplantı Proje yönetirken de toplantılar önemli bir iletişim, yürütme ve takip aracı.  Özellikle aynı ofiste bir arada çalışmayan proje ekipleri için, bir araya geldikleri bu kısıtlı zamanlar çok değerli. Yine de kaynakların ve proje yöneticisi olarak sizlerin zamanının çok değerli olduğunu unutmamak gerek. Projeler planlanırken; iletişim yönetimi ve entegrasyon yönetimi başlıkları altında toplantı ihtiyacı analiz edilmeli. Bu ihtiyaç projenin kapsamına, işin niteliğine, süresine, proje ekibinin büyüklüğüne, paydaşların ihtiyaçlarına vs vs. bağlı olarak farklılıklar gösterebilir. Eğer kurumun bir proje yönetimi prosedürü varsa standart olarak yapılması gereken proje toplantıları bu dokümanda belirtilmeli. Çalıştığım büyük bir projede, şirketin IT departmanı ile tedarikçimizin teknik ekibi arasında bir iletişim sorunu yaşanıyordu. Performans, kurulum, sistem hataları gibi konularla ilgili sorunlar gittikçe uzayan ve zaman zaman çirkinleşen mail zincirleri ile yürütülüyor ve çözümsüz kalıyordu. Herkes topu birbirine atıp duruyordu. IT koordinatörü olarak atandıktan sonra bu ekiplerin haftada bir yarım saatlik toplantılarla bir araya gelmesini ve işleri bir liste üzerinden takip etmesini sağladıktan sonra süreç daha sorunsuz yürümeye başladı. Bir masa etrafında oturup konuşurken insanlar maillerindeki gibi sert olamıyordu. Doğru toplantıları planladıktan sonra sıra toplantıları doğru yönetmeye geliyor. PMI’ın ekip yönetimi ile ilgili sunduğu önerilerden biri projeye başlarken proje yöneticisinin saha kurallarını (ground rules) belirlemesi. Bu kuralların bir bölümü toplantı adabı ile ilişkili olabilir; örneğin toplantıya mutlaka zamanında gelinmeli, konu ile ilgili hazırlık yapılmalı, toplantı sırasında cep telefonları kullanılmamalı, katılımcılar kesinlikle kendi aralarında konuşmamalı  gibi. Proje yöneticisi aynı zamanda iyi bir moderatör de olmalı, toplantıları başarıyla yönetebilmeli. •    Özellikle çok katılımcının olduğu uzun toplantılar bağımsız konuları içeriyorsa birden...

Read More

DOĞRU PROJE, DOĞRU YÖNETİM

Gün geçtikçe rekabet şartları zorlaşıyor. Teknoloji geliştikçe iş yapış şekilleri ve ürünler de hızla değişiyor, şirketler ayakta kalmak için sürekli bir değişim çabasında. Üst düzey yöneticiler de stratejik hedeflerini gerçekleştirmek için doğru projelerin başarıyla tamamlanması gerektiğinin farkına varıyorlar. Yani artık sadece bir projeyi planlanan bütçe, takvim ve kapsam dahilinde başarıyla tamamlamak değil,  doğru projeyi yapmak da önemli. Hangi Proje “Doğru Proje”? Yürütülecek projelerin seçimi önemli. Kurumlar stratejileri doğrultusunda beklenen değerleri yaratan projeleri seçmek ve başarıyla tamamlamak zorunda. Hatta uzmanlar, yürütülen projelerin belli periyotlarla gözden geçirilip, hala stratejilerle uyumlu olup olmadığının izlenmesi gerektiğini belirtiyor ve hızla değişen şartlar sonucu artış stratejileri desteklemeyen bir proje varsa iptal edilmesini öneriyor. Kısıtlı kaynakları, en çok değeri yaratacak şekilde yönlendireceği “projeler portföyü”nü oluşturmak ve yönetmek “Portföy Yönetimi” yaklaşımı ihtiyacını daha belirgin hale getiriyor. Bu kararı vermek üst yönetimin en zorlu görevlerinden biri. Öncelikle aday projelerin stratejilere sağlayacağı katkıların yani –beklenen getirilerin- belirlenmesi gerekiyor. Bu katkı oranı mümkün olduğu kadar spesifik olmalı. Yüksek, orta ve düşük etkinin strateji bazında değerleri tanımlanmalı. Proje portföy seçimine destek olan yazılım araçları artık bu süreci oldukça kolaylaştırıyor.  Bazı araçlar, şirketin iş hedefleri önem sırası belirtilerek tanımlanabilmesine ve aday projelerin bu hedeflere katkısı ve kaynak ihtiyacı (bütçe ve efor) doğrultusunda analiz edilerek portföy seçiminin yapılmasına olanak sağlıyor. Projeleri Doğru Yönetmek Seçilen projelerin genel kabul görmüş süreçler, metod ve araçlar kullanılarak başarıyla yönetilmesi, harcanan eforların doğru sonuçları üretmesi için bir zorunluluk haline geldi.  Şirketler proje ve portföy yönetimi olgunluk düzeylerini artıracak şekilde süreçlerini ve organizasyonlarını yeniden düzenlemek zorundalar. Yakın geçmişe kadar bir “lüks” olarak görülürken, her geçen gün daha çok şirket proje ve program ofisleri kuruyor. “Doğru” Sonuçların Takibi Doğru proje seçimi ve doğru yönetim de beklenen sonucu elde etmek için yeterli değil. Proje yönetimi olgunluğunun ileri düzeyde olmasının en önemli göstergelerinden biri, projeler bittikten sonra da takibi bırakmamak. Stratejilerle uyumlu olduğu varsayımıyla portföye alınan ve başarıyla tamamlanan bir proje düşünelim. Hayata geçirilen projenin beklenen zamanda beklenen faydaları gerçekleştirip gerçekleştirmediği; yani iş sonuçları da takip edilmeli. Proje yönetimi olgunluk düzeyi yüksek şirketler, iş birimlerinin yürüttüğü projeler tamamlandıktan sonra da performansını takip edip ölçmeye başladı. Bu yaklaşımın sağladığı faydalardan biri de,  projeleri talep eden birimlerini taleplerini daha bilinçli ele almaya yönlendirmesi. Artık üst düzey yöneticiler bu yaklaşımı benimsemeye daha açık ve bu eğilim biz proje yönetim profesyonelleri için ileriye dönük fırsatları artırıyor. Siz de şirketinizde bu değişim rüzgarlarını başlatmak istiyorsanız,  ilk adımları atmak için doğru bir zaman olabilir. Saadet TEKEL, PMP Şubat...

Read More

AFET KOORDİNASYON PROJELERİ

23 Ekim’de Van’da yaşanan depremle hepimiz sarsıldık. Çok kısa sürede kurtarma ekipleri yardımlar afet bölgesine ulaşmaya başladı. Hatta yardımlar yağmaya başladı dersek daha doğru olur. Bir yanda evini yakınlarını kaybeden, yaralanan, kurtarılmayı bekleyen depremzedeler, bir yanda bölgeye akın eden yardım kuruluşları, gönüllüler ve yardım kamyonları, kargolarla iletilen tonlarca yardım malzemesi toplanan yüklü para yardımları. Medyadan takip ettiğim kadarı ile tüm resmi kurumlar, sivil toplum kuruluşları seferber olarak deprem mağdurlarına yardım için büyük bir gayret gösterdi. Ancak bu gayretler ne kadar etkili oldu? Bölgeye giden basın mensupları ve sivil gönüllülerin demeçlerinde ortak olarak belirttikleri nokta çalışmalarla ilgili organizasyon eksiklikleriydi. Yağmalanan yardım kamyonları, depolarda bozulan gıda malzemeleriyle ilgili haberleri üzüntüyle izledik. Bütün bu para, malzeme, emek yardımlarının en etkin şekilde amacına ulaşması  ve afet bölgesinde hayat eskisi gibi olmasa da halkın temel ihtiyaçlarının medeni bir şekilde karşılanarak yaşamın devam etmesi için ne yapılmalı?  Gelişmeleri takip ederken aklıma hemen bu soru takıldı ve bu durumun nasıl yönetilmesi gerektiğini düşündüm. Kurumsal Yapılanma Halihazırda resmi kurumlar afet yönetimi için önemli aksiyonlar almış durumda.  Başbakanlığa bağlı faaliyet gösteren bir Afet ve Acil Durum Yönetimi Başkanlığı (AFAD) var. Ayrıca belediyelere bağlı Afet Koordinasyon Merkezleri de görev yapıyor. Hatta Van depreminden sonra,  Türkiye Belediyeler Birliği bünyesinde bir afet koordinasyon merkezinin kurulması ve bu merkezin afet durumunda AFAD ile ve Kızılay gibi kurumlarla işbirliği yapması kararlaştırılmış. Bir proje yöneticisi olarak ben bu tür büyük afetler sonrasında yapılan çalışmaların bir proje gibi ele alınıp proje metodolojisine uygun şekilde yönetilmesi gerektiğini düşünüyorum. Yıkım ve can kaybına neden olacak büyüklükteki deprem felaketlerinin ardından yapılacak çalışmalar için bir proje planı oluşturulmalı. Afet Sonrası Koordinasyon “Projesi” Böyle bir projenin yönetimi sırasında en zorlu konular Bütçe Yönetimi, İletişim Yönetimi ( Paydaşların Yönetimi), Satın Alma Yönetimi. Öyle çok paydaş var ki:  Vatandaşlar, belediyeler, afet koordinasyon merkezleri, basın, sivil toplum kuruluşları, yardım ulaştırmak isteyen özel kuruluşlar ve dış ülkeler ve tabii depremzedeler.  Üstelik hem kurtarma çalışmalarında hem de günlük yaşamın sürmesi için yapılacak çalışmalarda zamana karşı yarışmak gerekiyor. Belki projenin en önemli kısıtı zaman. Bu kısıtlı zaman içinde hızla organize olabilmek için proje sponsoru ve yöneticileri, hangi işi kimin ne zaman nasıl ve hatta nerede yapması gerektiği her bir il için ayrı ayrı planlanmalı.  Yaşanan afetin türüne hatta yaşandığı mevsime göre değişik aksiyonları içeren proje planları yapılması gerekebilir. Hatta bu büyük proje alt projelere ayrılarak farklı proje yöneticileri atanmalı (Arama-kurtarma projesi, yardım koordinasyon, saha çalışmaları, sağlık yardımları gibi). • İletişim planı • Bütçe yönetim planı • Yardım toplama ve dağıtım planı *Deprem çadırlarının nerede kim tarafından kurulacağı, *Yardım malzemelerinin nereye iletileceği *Nerede depolanacağı ve nasıl sınıflandırılacağı, *İhtiyaç sahiplerinin nasıl tespit edileceği, depremzedelerin yardım başvurularının kim tarafından nasıl alınacağı ve hatta yardımın dağıtımının nasıl yapılacağı *Paydaşlarla nasıl...

Read More

HALE ETKİSİ (Halo Effect) – PROJE YÖNETİCİSİNİN SEÇİMİ

Sizce kimler proje yönetebilir?   Bir şirketin üst yönetiminde yer aldığınızı ve şirketinizde stratejik önem taşıyan yeni bir projenin yapılacağını hayal edin. Diyelim ki proje yönetimi sürecine önem veriyor, metodolojisini de uyguluyorsunuz. Nasıl bir proje yöneticisi atarsınız? Seçim yaparken hangi kriterleri dikkate alırsınız? (Bu soruyu sorarken fonksiyonel veya matris organizasyonda görev aldığınızı varsayıyorum. Proje bazlı bir organizasyonda zaten proje ofisi bulunacağından, projeyi yönetecek adaylar muhtemelen proje deneyimi ve bilgisi olan profesyoneller olacaktır. Dikkat ederseniz bulunduğunuz sektörü veya projenin ne tür bir proje olduğunu da dikkate almadım.  Çünkü vurgulamak istediğim özellikler bunlardan bağımsız.) Bu kararı verirken çoğu zaman o konuyla ilgili fonksiyonel bir yönetici ya da üst yönetimin gözüne girmiş parlak yeteneklerden biri projenin başına getirilir.  Örneğin, bu kişi teknik bir departmanın yöneticisi veya iyi bir yazılımcı olabilir. Seçilen adayın proje yönetimi ile ilgili bilgisi, proje yöneticisinin sahip olması gereken kişilik özellikleri ve yönetim becerilerine sahip olup olmadığına pek bakılmaz. Mevcut görevinde yaptıkları yapacaklarının da teminatıdır. Bu tutumun psikolojide bir adı var: “Hale Etkisi” (Halo Effect).  Hale Etkisi,  ‘kişinin bir özelliğinden yola çıkıp, kişinin diğer özellikleri hakkında genel bir yargıya varmak’ olarak tanımlanıyor ve en sıklıkla bir kişinin diğer bir kişiyle ilgili değerlendirme yapmakla sorumlu olduğu durumlarda ortaya çıkıyor. Bu etki altında, bir kişinin iyi bir özelliği veya geçmişteki bir başarısı diğer özellikleri veya işleri için de önyargılı bir algılamaya neden olur. Yani yaptığı bir işte başarılı olduysa uzmanlık alanıyla ilgisi olmasa bile proje yönetiminde de başarılı olacağı fikri doğar. Bu tür atamalar, özellikle birden fazla birimi ilglendiren büyük projelerde yapıldığında, proje için bir risk oluşturur. Bütün projenin proje yöneticisi olduğu halde sadece kendi fonksiyonu ile ilgili çalışmaları yürütüp diğer ana paydaşlarla iletişimi sağlamayan, bu paydaşlarla ilgili işler aksadığında konunun kendi sorumluluğunda olmadığını idda eden proje yöneticilerine şahit oldum.  Ya da proje yönetiminin yukarıda oturup diğerlerine hesap sorarak yapılacağını düşünen, proje başarısız olduğunda bunu başarı ile ekibe mal edebilen donanımsız ve deneyimsiz proje yöneticilerine…  Bir proje yöneticisinin görevlerinin kimse farkında olmadığı için bu yaklaşımlar da anormal karşılanmıyor, hatta  ‘sıkı yönetici’lik olarak görülebiliyor. Bu tür senaryoların, herkesin birbirini suçladığı başarısız projelerle sonuçlanması sürpriz olmamalı… Proje yönetimi de ayrı bir uzmanlık ve beceri alanıdır. Proje ofisiniz ve proje yöneticisi unvanını taşıyan uzmanlar olmasa da projeleri yönetecek kişilerin belli eğitimlerden geçirilmesi ve iletişim başta olmak üzere gereken becerilere sahip olmasına dikkat edilmesi projelerin akıbetini etkileyecektir. Saadet TEKEL, PMP Ekim...

Read More

PROJENİZİ NASIL ALIRDINIZ, HIZLI? İYİ PİŞMİŞ?

Yazılım Projelerinde Hızlı Kazanımlar “Bu kadar beklemeye zamanımız yok”, “rakipler bu işi çoktan yaptı”  gibi cümleler tüm yazılım proje yöneticilerinin aşina olduğu replikler. Ya hemen hayata geçirilmesi gereken yasal yükümlülükler, ya hızla pazara çıkarılması gereken yeni ürünler, acil yapılması gereken kampanyalar, çözülmesi gereken sistem sorunları vs vs  projeleri hızlıca hayata geçirmeyi gerektiriyor. Ne de olsa artık web çağındayız, her şey çok hızlı ve beklemeye tahammülümüz yok. Bu ortamda taleplerin fırsatları kaçırmadan karşılanması için son dönemde oldukça popüler olan “hızlı kazanım” (quick win) çözümleri uygulanıyor.  Proje yöneticileri olarak bizler de ‘çabuk ve kalitesiz’ (popüler İngilizce deyimiyle quick&dirty)  çözümlerle sağlam bir çözümü gerçekleştirmek arasında bocalıyoruz. Hız ve esneklik günümüzün en önemli gerçeklerinden biri olduğuna göre ihtiyaçlara basit, en hızlı ve sağlıklı şekilde cevap vermek konusunda proje yöneticileri olarak bizim de ‘hızlı ve temiz’ çözümler üretmenin yollarına bakmamız gerekiyor. Hızlı kazanım projelerinde “bir başlayalım da bakarız” en sık duyduğumuz ifade. Atalarımızın ifadesiyle kervan yolda diziliyor. Hatta analiz bile yapılmadan sözlü anlatılan taleplere göre yazılım geliştirme aşamasına bile geçilebiliyor. Daha sonraki süreçlerde en sık duyacağımız diyaloglar ise muhtemelen  “Ben …..  olacağını düşünmüştüm” ,“Ben böyle anlamıştım”, “Benim istediğim …di”  gibi hayal kırıklığı cümleleri oluyor. Hızlı kazanımlarda başarıyı yakalamak için, deneyimlerime dayanarak sizlere bazı önerilerde bulunmak istiyorum: • Öncelikle projenin amacının netleştirilmesi gerekir. Sorulması gereken soru: Ortaya çıkan ürün hangi amaca hizmet edecek? • Tanımlanan hedefe ulaşılmasını (hızlı kazanımı) sağlayacak ürünün kapsamı ne olmalıdır?  Burada kritik olan konu belirtilen tarihe yetişmek için kapsamı mümkün olduğu kadar basit tutmak. • Amaçları ve kapsamı görüşürken sponsordan teyit almak mutlaka yapılması gerken işlerden biri. “Anladığım kadarıyla ihtiyacınız …’dır, doğru mu?”, “ Bunu söylerken… mi kastediyorsunuz?” sorularını sponsor ve diğer paydaşlara yöneltin. • Hedefe ulaşmak için mümkün olan en sade ve basit kapsamı oluşturmak başarı için anahtar yoldur. Yapılabiliyorsa ertelenebilen fonksiyonları fazlara ayırın. Ancak hızlı kazanım elde etmek için hayati fonksiyonlardan (yani kazanımlardan) vazgeçmeyin.  Sağlam olmayan bir yapı oluşturulursa gelecek fazlarda sağlıklı büyümek mümkün olmayacak, hatalı işleri düzeltmek için harcanan efor hızlı kazanımı alıp götürecektir. • Sıkı zaman planına uymak için gerçekleştirebilecğiniz ve gerçekleştiremeyeceğiniz talepleri açıkça belirtmek gerekir. Tutamayacağınız sözleri verip daha sonra bahaneler üretmeyin. • Kapsamı yazılı hale getirin. Kapsama dahil edilmeyen fonksiyonları da özellikle belirtin. Sponsor ve diğer paydaşların onayını alın. • Kapsamın sadeleştirmesinin veya hızlı çözümlerin getireceği dezavantajları/maliyetleri açıkça raporlayın ve kabul edildiğini teyit edin. • Bu proje gerçekten beklenen kazanımları sağlayacak mı? Yoksa “kazanım”ı uçup “hızlı”sı mı kalacak? Gerekirse projenin getireceği kazanımların, uzun vadeli maliyetlerle karşılaştırılmasını isteyin, şirketinizin bir teknoloji / strateji v.b. komitesi varsa onaya sunun. • Proje belirlenen maliyetlere katlanmaya değer görüldüyse, doğal olarak planı yürütmeye başlayacaksınız. Paydaşlarla iletişime özen gösterin, projenin durmu ile ilgili düzenli olarak bilgilendirin. Çevik hareket etmemiz gereken bir...

Read More

YAZILIM PROJELERİ NEDEN BAŞARILI/BAŞARISIZ OLUR?

Harvard Business Okulu’nda  yapılan bir araştırmada başarılı yazılım projelerinin şu 4 özelliğe sahip oldukları görülmüştür.  Başarılı projeler iterative şekilde yazılım geliştirirler.Yani,yazılımın müşteri için önemli ve anlamlı bir parçası erken bir yayımla teslim edilir ve yazılım teslimi diğer geliştirmeler ile devam eder. Gerçek ortama yapılan yayımlar sonrası müşteriden sürekli olarak  geri beslenim alınır. Yazılım genel olarak  bir evrim süreci sonucunda oluşur.  Yapılan değişiklikler sonrası günlük tümleştirme yapılır. Tümleştirme sonucu yazılımın durumu hakkında bağlanım (regression) testleri sayesinde hızlı bir şekilde geri beslenim alınır.  Yazılım geliştirme ekibi deneyimli kişilerden oluşur.  Projenin başından itibaren yazılım mimarisine ve sistemin birbirinden bağımsız bileşenlerden oluşturulmasına dikkat edilir (MacCormack, 2001). Yazılım projelerinin başarısızlık nedenleri  ise;Teknik, Yönetimsel, Sosyal, Kullanıcı Kaynaklı, Analiz Kaynaklı  olarak sıralanabilir. Bu projelerin  neden başarısız oldukları aşağıda yer alan başlıklar altında şu şekilde açıklanabilir: a.) Eksik Proje Yönetimi Metodolojisi: Proje yönetim metodolojisinin baştan sona eksiksiz bir şekilde uygulanmaması yazılım projelerini tehlikeye sokmaktadır. –  Proje Yöneticileri kullanıcı ihtiyaçlarını anlamamaktadırlar. –  Proje kapsamı doğru tanımlanmamaktadır. –  Proje değişiklikleri yeterli düzeyde yönetilmemektedir. –  Projenin ihtiyaçları değişmektedir. –  Proje bitiş tarihi gerçekçi değildir. –  Kullanıcılar direnç göstermektedir. –  Sponsorlar destek vermekten vazgeçmiştir. – Yöneticiler en iyi uygulamalara ve alınması gereken derslere önem  vermemektedirler. b.) Müşterinin İhtiyacını Doğru Belirleyememesi: Gereksinim analizi  aşamasındaki   en temel madde,  müşterilerin ihtiyaçlarının mutlak bir şekilde tanımlanmasıdır. Projeye ve müşterinin gereksinimlerine ilişkin doğru soruları sormak ve analizi bu belirsizlikten kurtarıp formal bir şekilde dokümante edip, proje planı ile mühendislik altyapısına temel teşkil edecek bir yazılım gereksinim dokümanı (Software Requirements Spesification- SRS) haline getirme, ihtiyacın çerçevesinin çizilmesini sağlayacak ve müşteriye kendi ihtiyaçlarını sorgulama fırsatı verecektir. Müşterinin ihtiyacını doğru belirlemesine yardımcı olmak için, projenin hedefi-çıktıları ve kapsamını anlamak için, proje planlama aşamasına yeteri kadar zaman ayrılmalıdır. Müşterilerin kullandığı varsayımlar göz önüne serilmeli ve son kullanıcıya yönelik faydaları ve proje risklerini değerlendirilmelidir. Beklentileri sıralamak ve tüm ekiplerin nihai ürünü açık bir şekilde anlamalarını sağlamak için müşterinin tamamlanmış yazılım gereksinim dokümanını okuması, doküman hakkında düşünmesi ve onaylaması sağlanmalıdır.Yanlış ve eksik belirlenmiş olan ihtiyaçlar yazılım yaşam döngüsünün son evrelerinde ortaya çıktığı takdirde projenin başarısızlıkla sonuçlanması kaçınılmazdır. c.) Gereksinimlerin Sürekli Değişmesi: Yazılım projelerinde en sık karşılaşılan problemlerden bir diğeri de ,projenin ilk fazında tanımlanan gereksinimlerin  proje devam ederken değişmesidir. Yazılım devam edip prototipler geliştirildikçe müşteriler plandaki problemleri daha net görürler ve projede gerekli değişiklik taleplerinde bulunurlar.Değişiklik talepleri analiz edilip proje kapsamına alınması için bir süreçten geçirilmeli ve müşterilerin bu sürecin farkında olmaları sağlanmalıdır. Gereksinimler analiz edilmeden ve süreç gözetmeksizin projeye dahil edilirse proje yaşam döngüsünden kopulur ve proje maliyeti giderek artarak başarısızlığa sürüklenir.Örneğin projenin %75’i tamamlanmış ve müşteri tarafından major bir değişiklik yapılması isteniyor ve değişiklik talebi analiz edilmeden kabul ediliyorsa başarısızlık kaçınılmazdır. Değişim taleplerinin tüm paydaşlar...

Read More