"proje yönetimi" etiketli yazılar:

15 Ekim 2023 Pazar

Çevik veya Şelale mi olmalı?

Değerli arkadaşım Dr. Murat Unanoğlu‘nun Linkedin’de dikkatimi çeken bir aktarımı sayesinde Harvard Business Review’nun [HBR] “Çevik ve Şelale yöntemleri arasındaki savaşı bitirmenin zamanı” (It’s Time to End the Battle Between Waterfall and Agile) isimli makalesini okudum.

İlk bakışta, “Eeee, elbette öyle olmalı. Başka türlü olamaz ki… Zaten bildiğimiz bir şey. Bunun için biz makale yazsak yayınlamazlar” diye yorumladığımı itiraf edeyim. Sonra, bu yazının neden HBR’da yer aldığını düşündüm.

Agile’ın ortaya çıkarılma gerekçelerini çevremdeki birçok arkadaşla paylaşmışımdır. Hatırladığım kadarıyla 2001 (yanılıyorsam 2002) yılıydı. CRM kavramlarını çalıştığım bankanın üst yönetimine anlatmaya, onları ikna etmeye çalışıyordum. CIO, Türkiye’de en uzun süre banka GMY’liği yapmış bir kişiydi. Mesleki tecrübesi nedeniyle herkesin duayen kabul ettiği CIO “ne derse o doğrudur” kabul ediliyordu.

IT ekibi, “Anlattığınız proje başında her şeyi, tüm iş isteklerini en ayrıntılı biçimde yazacaksınız. Sonra proje bitene kadar hiçbir değişiklik yapmayacağınıza garanti vereceksiniz. Ancak öyle başlarız” demişti.

İlginçtir ki o günü, dün gibi hatırlıyorum. Çıldırmış gibiydim. “CRM projemizi 3 yılda yaptık, çok hızlıyız” diye başarı öyküsü anlatanların olduğu bir dünyada, “asgari 3-4 sene boyunca değişmeyecek iş isteklerinin en baştan verilmesinin akla aykırı olduğunu” bas bas bağırıyordum.

Beni ikna etmek için, bizzat duayen CIO’nun seçtiği danışman, “IT büyük projelerde nasıl çalışılacağını bilmiyor” diyene kadar yaptıklarının doğru olduğuna inanıyorlardı.

1970-80’lerden kalan IT bakış açısının değişmesi gerekiyordu. Hemen her teknolojik olgunun büyük hızla değiştiği bir dünyada, yazılım ekiplerinin “iş isteğini bir kere verin ve sonra 3 yıl boyunca hiç değiştiremezsiniz” diye tutturması, elbette – yazı konusu olan makalede de anlatılan – büyük maddi zararlara ve yıllarca tamamlanmayan projelere neden oldu. Dünyada birçok kurum çözüm aradı. Sonuçta bir yöntem olarak “Agile” ortaya çıktı.

Bazen eğitimlerde “O yıllarda ben, bizzat zarar gören kişi – mutazarrır – olarak olay mahallindeydim” diye anlatıyorum.

😀

Açıkçası, Agile‘ın ortaya çıkmasını ve Waterfall fanatiklerinin devrinin kapanmasına yardım etmesini hoş karşıladım ama… Sonra, hızla moda olan her kavramın içinin boşaltılması süreci başladı. Agile her yere yapıştı.

İşveren markası konferansında “60’a yakın agile team kurduk” diyen IK yöneticileri dinledik.

Türkiye’de agile = acil diye algılanıyor. Oysa çok daha köklü sorunlar var” diye örnekleriyle yazdım. Bir agile fanatiği yorum yaptı. “Kardeşi Scrum master ve agile koçluğu yapan, kendisi agile felsefe ile bir süredir ilgilenen ve bu konuda blogunda yazı yayınlayan” (cümleler bana ait değil, bizzat kendisinden alıntıdır) bu agile fanatiğinin mantık ve terbiye sınırlarını zorlayan yorumunu da bloga taşıdım.  😮 (Okunmasını öneririm.)

Bir proje yönetimi metodunun felsefe diye adlandırılması da ayrı konu… Fanatiklik böyle bir şey.

Daha sonraki zamanlarda, agile koçu diye sıfatlananların büyük çoğunluğunun belki birkaç küçük proje yönetmiş ama hiçbir büyük proje yönetmemiş olduğunu ve “tek aleti çekiç olunca her sorunu çivi zannettiklerini” defalarca gözlemledim. Araçları amaç zannetmek, çok yaygın bir hastalık.

Sayın Günseli Özen‘in (çok haklı bulduğum) “İtibarını yitirmiş kavramların müsebbibi, o kavrama ilişkin derinlikli bilgisi olmadan fikirleri olup konuşanlartanımlamasını buraya ekleyeyim. Bir kavrama ilişkin derinlikli bilgi, o kavramın nerede ve ne zaman işe yaramadığını da içeriyor.

🙂

Tüm bunları hatırlayınca, HBR’ın o yazıyı yayınlamak zorunda kaldığını düşündüm. Yazı aslında kapsamlı projeler yönetenlerin zaten bildiği bir konuya açıklık getirmiş. Dr. Murat Unanoğlu‘nun yazdığı gibi, “bir akımın / yöntemin kölesi” olanlara artı ve eksileriyle yöntemleri anlatmış ve bir rehber sunmuş.

Bence proje yöneticileri mutlaka okumalı.

😉

08 Mart 2021 Pazartesi

Algoritma ile Düşünmek – 2

CRM projelerine başlamadan önceki zamanlardan, IT ile pazarlamanın ikiz kardeş gibi çalışmaya başladığı 1980’lerden beri birlikte çalıştığım ekiplere “algoritma ile düşünmeyi” öneririm. Bunun bir nedeni (kimin söylediğini hatırlamıyorum ama bence çok doğru olan) “IT’ye pazarlamacı gibi düşünmeyi öğretmek, pazarlamacılara IT gibi düşünmeyi öğretmekten zordur” saptaması.

Profesyonel iş hayatımın son yıllarında “tecrübeli” değil mümkün olduğunca “yeni mezun” işe almaya çalıştım. İlk iş deneyimlerini doğrudan benimle yaşamalarını istedim, bildiklerimi şahsen aktarmaya çalıştım. Yıllar önce, 2000’lerin başında ilk yöneticisi olduğum bir iş arkadaşım geçenlerde bir bankanın Dijital Kanallar ve Ürünler İş Geliştirme Direktörü oldu. Gururlandım ve kutlama mesajı gönderdim. Bana

Kariyerimin başında IT’nin dilinden iyi anlamak, süreçlerin detaylarına hakim olmak, trend’leri takip etmek gibi birçok konuda bana çok güzel vizyon kattınız ve bana güzel kapılar araladınız. Üzerimde emeğiniz büyük, sevgiler

diye yanıt verdi. Var ya… O günüm çok güzel geçti. Ayaklarım yere değmedi.

Her zaman işe yarar ama “IT’nin dilinden anlamak” için algoritmayla düşünmek, en azından algoritmayla IT’ye anlatmak gerekir. Algoritma ile düşünmek deyince “Çok zor değil, iyi bir yemek tarifi veya iyi bir adres tarifi de algoritmadır” diye söylüyorum. Özetle yaklaşık 20 yıldan beri ben de “Algoritma ile Düşünmek” diyorum (hatta 6 sene önce yayınlamıştım bile). Ayrıca “herkes kodlama öğrenmeli” diyenlere “Hayır, herkes algoritma ile düşünmeyi öğrenmeli[1] ve [2]  diyorum.

Bu hafta gelen mesajlar içinde Harvard Business Review (HBR) Türkiye’nin web sitesinde bu konuda bir yazı olduğunu gördüm.  Güzel bir tesadüf, yazıda da örnek olarak bir yemek tarifi yazılmış.

CRM derslerimizde [a] , [b] , [c] , [d]   işbaşı eğitimi gibi çalışıyoruz. MBA katılımcıları birer sektör seçiyorlar ve dönem boyunca o sektörde CRM projesi yapar gibi ilerliyorlar. Süreç tasarımı aşamasına geldiğimizde “müşteriye en çok dokunan süreçlerden birini ideal olması gereken duruma getirin ve IT’ye bir algoritma ile nasıl bir süreç istediğinizi anlatın” diye ödev veriyorum.

HBR Türkiye web sayfasında yazıyı okuyunca, MBA katılımcılarına mesaj gönderdim. “Lütfen o yazıyı okuyun, hatta basılı alıp saklayın. Bu konuda bir ödevimiz olacak” diye bildirdim.

😉

07 Şubat 2020 Cuma

Danışmanlık ve Geri Bildirim

Yakın geçmişte yayımladığım Danışmanlık #.0 ve Danışmanlıkta Dönüşüm Sancıları yazılarında, değişim ve/veya dönüşüm önerilerinde bulunan danışmanlık şirketlerine ayna tutmaya çalıştım. Danışman ve çoban veya danışman kedi fıkralarının doğmasına neden olan danışmanlık yöntemlerinin eskidiğini anlatmak istedim.

Bilginin serbest dolaşımda olduğu bugünlerde, danışmanın temel faydası bilgiyi değil yöntemi öğretmek oluyor. Bizzat uygulama deneyimine sahip olmayanlar bocalıyor. Onların bocalaması, tüm danışmanlık sistemine zarar veriyor. Özellikle, temel uğraşılarına odaklanan ve diğer konuları dış kaynak kullanarak çözmeye çalışan kurumlara hizmet verenler, eski danışman algısından zarar görüyor.

😉

Sadece danışmanları suçlamak doğru değil. Danışmandan ne istemesi gerektiğini bilmeyen yöneticiler de var. Kendisinin ne kadar doğru düşündüğünü önaylaması için danışman tutan mı ararsınız, “sizi ne kadar iyi iş ürettiğimizi diğer iş birimlerine anlatmanız için tuttuk” diyen mi?

Elbette yazdıklarım tüm danışmanlık sistemini kapsamıyor. Kendisini bu kısır döngüden kurtarmak isteyen bir danışmanlık kurumuyla, müşteri geri bildirimi almak konusunda sohbet etmiştim. Bu sohbette konuştuklarımızı yazıya döktüm. Hem danışmanlık kurumlarına, hem de müşterilerine  yararlı olmasını umarak paylaşıyorum. [Değiştirme ve düzeltme önermek serbesttir. Böylece, en iyiye hep birlikte yaklaşabiliriz.]

😉

Danışmanlık süreci genelde 3 ana aşamadan oluşuyor:

  1. Satış
  2. Proje
  3. Proje Sonrası

Bu aşamaları sırayla inceleyelim:

SATIŞ

Satışlar genelde, 2 şekilde gerçekleşiyor:

a) Yeni müşteri: Çoğunlukla müşteri adayından talep gelir. Danışmanlar hazırlık yapar. Müşteriye sorulacaklar belirlenir. Birkaç toplantı ve biraz yazışma sonrasında, teklif ve bütçesi sunulur.

b) Mevcut müşteri: Danışmanlar, eski müşterilerini ziyaret eder ve “Size şöyle bir proje yapalım. Şunlara yarar. Maliyetleri azaltır ve gelirleri arttırır; bilançoya faydası şudur” diyerek ikna eder ve proje kararı verilmesini sağlar.

Bu aşamada nasıl geri bildirim alınabilir:

  • Sürecin başında, ilk toplantıda müşteriye tüm süreç anlatılır ve aksayan her noktada geri bildirimi özendiren bir ortam sağlanır.
  • Ortada bir Teklif Talebi (Request for Proposal – RfP) varsa, bu talebi hazırlayanların beklentilerinin ne kadar karşılandığı (yöntem ve bütçeyi içeren son teklifin sunulmasından önce) her toplantı sonrasında ölçülür.
  • Eğer müşteriye uygun olduğu düşünülerek sıfırdan proje geliştirilmişse, projenin yaratacağı etki ve katma değerin şirketin gündemi, stratejisi, ihtiyaçları vs ile ilgili uyumu sorgulanır.

Böylece “İstemiyoruz. Gündemimize uygun değil” yanıtını bu aşamanın son adımında duymak zorunda kalınmaz. Müşterinin hedefleri ve stratejisi öğrenilir, uygun ürün ve projeler geliştirilir.

Devamı gelecek yazılarda