Ideallyfree

Kimse İtiraz Etmediyse Proje Neden Battı?

Toplantı masasında çalışan ekip

Dijital projeler çoğu zaman yazılım yüzünden değil, toplantıda söylenen bir “tamamdır” yüzünden batar. BBC’nin 98 milyon sterlinlik dersi bunu iyi anlatıyor.

Beş Yıl, 98 Milyon Sterlin

Mayıs 2013. BBC’nin yeni Genel Müdürü Tony Hall, Digital Media Initiative (DMI) adlı projeyi kapattığını açıkladı. Fikir basit ve çekiciydi: kaset dönemini bitirmek, çekimden arşive kadar her şeyi tek bir dijital sistemde toplamak. Muhabir görüntüye masasından ulaşacak, editör arşivi saniyeler içinde tarayabilecekti.

Proje 2008’de başladı. Bir yıl sonra dış yükleniciden alınıp kurum içine taşındı. Toplantılar yapıldı, raporlar yazıldı, takvimler güncellendi. Ama beş yılın sonunda program yapanlar hâlâ eski sistemlerle çalışıyordu.

Birleşik Krallık’ın kamu denetim kurumu National Audit Office (NAO) hesabı çıkardı. İşe yarayabilecek parçalar düşüldükten sonra bile BBC’nin kaybı yaklaşık 98,4 milyon sterlindi. Parlamentonun Kamu Hesapları Komitesi, yani Public Accounts Committee (PAC), projeyi tek cümleyle özetledi: “Tam bir başarısızlık.”

Asıl şaşırtıcı olan kaybın büyüklüğü değil, bu kadar uzun süre kimsenin masaya yumruğunu vurmamış olması.

Pazartesi, Saat 10.00

Pazartesi, saat 10.00.

Şimdi aynı hikâyeyi bugünün sıradan bir şirket toplantısına taşıyalım.

Ekranda yeni ERP sisteminin geçiş takvimi var. Proje yöneticisi soruyor: “Herkes için uygun mu?”

Satış müdürü telefonuna bakıyor. Depo sorumlusu bir şey söyleyecek gibi oluyor, sonra vazgeçiyor. Finanstan biri “tamamdır” diyor. Toplantı on dakika erken bitiyor.

Üç ay sonra depo hâlâ eski Excel dosyalarıyla çalışıyor. Satış ekibi sisteme veri girmiyor. Finansın raporları birbirini tutmuyor. Yönetim kurulu sunumunda tek bir açıklama var: “Kullanıcılar değişime direnç gösterdi.”

Oysa o odadaki “tamamdır” bir onay değildi. “Şu an tartışmak istemiyorum” demenin kibar bir yoluydu.

Tamamdır Meselesi

Harvard Business Review Türkiye’nin ekiplerin aynı kararı neden farklı anladığını soran Doğukan Odabaş imzalı yazısı tam bu noktaya dokunuyor. Aynı odada aynı slaytı izleyen insanlar, dışarı çıktıklarında farklı şeyler anlamış olabilir. Kimse yalan söylemiyor. Herkes kendi işine göre bir anlam çıkarıyor ve kimse bunu yüksek sesle kontrol etmiyor.

Sahte uzlaşı böyle doğar. Masada itiraz yoksa sorun da yok sanılır. Ama itiraz çoğu zaman toplantıdan sonra, koridorda, kahve makinesinin başında yapılır ve proje planına hiç girmez.

Project Management Institute (PMI) bünyesinde yayımlanan Silence Fails çalışması tam olarak bu koridora bakıyor. 2.200’den fazla projeyi inceleyen araştırmacılara göre projelerin çoğu, herkesin gördüğü ama kimsenin açıkça konuşmadığı sorunlar yüzünden batıyor. İyi haber de aynı çalışmada: bu sorunlar masaya düzgün biçimde konduğunda proje performansı yüzde 50 ila 70 oranında iyileşebiliyor.

Peki bu konuşma nerede yapılmalı? McKinsey’nin toplantılar ve karar kalitesi üzerine yazısı cevabı veriyor: iyi karar, iyi hazırlanmış bir tartışmadan çıkar. Gündemi belirsiz, kimin karar verdiği net olmayan bir toplantı en sessiz itirazı bile yutar.

Suç Gerçekten Yazılımda Mı?

Proje batınca ilk bakılan yer teknoloji olur. Yazılım yavaştır, ekranlar karışıktır, entegrasyon eksiktir. Bunlar doğru olabilir ama çoğu zaman hikâyenin sadece yarısıdır.

Boston Consulting Group (BCG) araştırmasına göre dijital dönüşümlerin yalnızca yaklaşık yüzde 30’u hedefine ulaşıyor. Ernst & Young (EY) ile Oxford Üniversitesi Saïd İşletme Okulu’nun ortak çalışması ise insan tarafını iyi yöneten dönüşümlerde başarı ihtimalinin yüzde 28’den yüzde 73’e çıkabildiğini gösteriyor. Bu fark daha iyi yazılımdan gelmiyor. Liderlerin dinlemesinden, rollerin netleşmesinden ve insanların neden değişmeleri gerektiğini anlamasından geliyor.

MIT Sloan Management Review’da bu hafta yayımlanan bir yazı bir adım daha ileri gidiyor. Duke Üniversitesi’nden Curtis Merriweather Jr.’a göre yöneticiler başarısız projeleri incelerken iki ayrı sorunu tek bir sorunmuş gibi ele alıyor: verinin kalitesi ve sistemin kullanışlılığı. Biri düzeldiğinde öteki kendiliğinden düzelmiyor. Teşhis yanlış olunca çözüm de yanlış oluyor: önce yeni bir eğitim, sonra yeni bir sistem, en sonunda yeni bir hayal kırıklığı.

Pazartesi toplantısındaki depo sorumlusu belki tam da bunu söyleyecekti: “Ekran güzel ama içindeki stok verisi yanlış.” O cümle hiç kurulmadı. Sonra herkes “direnç” dedi.

BBC’ye Geri Dönelim

NAO’nun bulgularında teknik ayrıntılardan çok bir yönetim ve iletişim sorunu öne çıkıyor. Raporlar teknik risklere odaklanıyor, işin yapılış biçiminin gerçekten değişip değişmediği ise geri planda kalıyordu. Durum kötüleştikten aylar sonra risk üst yönetime açıkça ulaşabildi. Bu arada kullanıcılar sisteme güvenini yitirdi, bazı ekipler kendi çözümlerini kurdu. Sorunu bilenler vardı ama bu bilgi karar verenlere zamanında ve açıkça ulaşmadı.

Silence Fails çalışması bu oyuna bir ad veriyor: Project Chicken (proje tavuğu). Herkes geride kaldığını bilir ama kötü haberi ilk kimin vereceğini bekler; ilk konuşan ya da itiraf eden suçlanacağı korkusuyla sessiz kalır, sessiz kalanlar zaman kazanır. Yani BBC’de de bir “tamamdır” vardı. Sadece toplantı odası çok daha büyüktü ve faturası 98 milyon sterlini buldu.

Pazartesi Toplantısını Değiştirmek

Büyük bir yöntem gerekmiyor. Birkaç küçük alışkanlık yeter:

  • “Uygun mu?” diye sormayın. “Bu plan sizin ekibinizde nerede tıkanır?” diye sorun. Evet ya da hayırla cevaplanan sorular sessizliği ödüllendirir.
  • Sözü önce en kıdemsiz kişiye verin. Yönetici önce konuşursa geri kalanlar genellikle ona katılır.
  • Kararı ve aksiyonu yazıya dökün. Toplantı notu tutma alışkanlığı burada işe yarar: ne karar verildi, her aksiyonun sahibi kim, bitiş tarihi ne? Son birkaç dakikayı bunu doğrulamaya ayırın; notu mümkünse 24 saat içinde paylaşın. Bu alışkanlığın pratik şablonları için toplantı gündemi ve toplantı notu araçlarına bakabilirsiniz. Farklı anlayan varsa o anda ortaya çıkar.
  • Veriyi ve ekranı ayrı ayrı test edin. Kullanıcı sistemi sevmiyorsa önce sorunun ekranda mı yoksa verinin içinde mi olduğunu bulun.
  • Küçük başlayın. Sistemi önce tek bir ekipte, Minimum Uygulanabilir Ürün (MVP) mantığıyla deneyin.

    Çünkü PowerPoint’te herkes sistemi sever. Gerçek itirazlar ise sistem gerçekten kullanılmaya başladığında ortaya çıkar.

Projeler nadiren tek bir büyük hatayla batar. Çoğu zaman söylenmemiş küçük cümleler birikir. Bir dahaki toplantıda biri “tamamdır” dediğinde durun ve bir soru daha sorun: “Peki sizi en çok ne endişelendiriyor?”

Funda Tabak

İstanbul Üniversitesi Siyasal Bilgiler Fakültesi Uluslararası İlişkiler bölümünden mezun olduktan sonra kariyerine saha satış, dijital pazarlama ve online itibar yönetimi alanlarında başladı. Farklı sektörlerde pazarlama, sosyal medya yönetimi ve işveren markası projelerinde görev aldı. Sa-ba, Döksan, İleri Group ve Araymond gibi üretim firmalarının yanı sıra; müşterileri arasında Coca-Cola İçecek, Turkcell, Mercedes-Benz, Novartis, Pfizer ve Yapı Kredi Bankası bulunan danışmanlık odaklı firmalarda B2B ve B2C projelerinde çalıştı.

2010 yılından bu yana ideallyfree.com’un içerik süreçlerini koordine etmektedir. 2018-2021 yılları arasında Katar, Umman, Suudi Arabistan ve ağırlıklı olarak Orta Doğu bölgesinde C-level yöneticilere yönelik eğitim organizasyonları ve projeler geliştirdi. 2023 yılında Yönetim Bilişim Sistemleri eğitimini tamamladı. Halen Dubai merkezli bir şirkette proje yöneticisi olarak çalışmaktadır.

Yorum ekle