Parmakla Göstermekten Vazgeçin—Bir RACI Şeması Kullanın (Suze Haworth ile)

Deşifre Metnini Okuyun:

Podcast yayınlarımızı bir yazılım programı kullanarak yazıya dökmeyi deniyoruz. Bot her zaman yüzde 100 doğru çalışmadığından lütfen olası yazım hatalarını mazur görün.

Ben Aston:

Proje yönetimiyle ilgili en zor şeylerden biri, insanlarla çalışmak zorunda olmamızdır ve insanlar inanılmaz derecede değişkendir. Tutarsızız, ego sahibiyiz, güvenilmeziz ve son derece değişkeniz; üstelik şu anda yalnızca kendimden bahsediyorum. Bu yüzden projelerinizin benimkiler gibi olup olmadığını merak ediyorum. Projeler ters gittiğinde —ki elbette bir noktada bu da olur— durum kısa sürede herkesin bir başkasını işini düzgün yapmamakla suçladığı korkunç bir suçlama ve parmakla gösterme döngüsüne dönüşebilir. Peki tüm bunlarla başa çıkmamız gerekirken bir projeyi nasıl yönetebiliriz? Bugün bunu öğreneceksiniz.

Dinlediğiniz için teşekkürler. Ben Ben Aston ve bu, The Digital Project Manager Podcast. Bu podcast size kurumsal proje ve portföy yönetimi yazılımlarında lider olan Clarizen tarafından sunuluyor. Daha fazla bilgi edinmek için Clarizen.com adresini ziyaret edin. Bugün Digital Project Manager bünyesindeki yerleşik DPM uzmanlarımızdan biri olan Suze Haworth ile birlikteyim. Suze, programa katıldığın için çok teşekkürler.

Suze Haworth:

Teşekkürler Ben, beni davet ettiğin için teşekkürler.

Ben Aston:

Suze’yi düzgün bir şekilde tanıtayım; çünkü kendisi yeni. Sanırım bu, birlikte yaptığımız ilk podcast.

Suze Haworth:

Evet.

Ben Aston:

Suze, Londra’da serbest çalışan bir dijital proje direktörü. Sektörde 13 yılı aşkın deneyimi var. Tıpkı benim gibi hesap yönetimiyle başlamış, ardından proje yönetimine geçmiş. Ancak biyografini okumak yerine, şu anda ne tür projeler üzerinde çalıştığını bize biraz anlatabilir misin?

Suze Haworth:

Şu anda mı? Aslında geçen yıl serbest çalışmaya başladım. Söylediğin gibi, birkaç yıl boyunca çeşitli ajanslarda çalıştım, ancak geçen yıl serbest çalışmaya geçtim. Şu anda Londra’daki bir ajansta görev yapıyorum ve iki büyük proje yürütüyorum. Bunlardan biri oldukça büyük bir perakende markası için tasarım sistemi, diğeri ise başka bir perakende markası için bir çalışma programını yönetmek. Hepsi oldukça ilginç işler.

Ben Aston:

Yani perakende senin uzmanlık alanın mı?

Suze Haworth:

Aslında her alanda çalışıyorum. Çok sayıda perakende projesi, bir yayın kuruluşu, bir hayır kurumu ve daha pek çok şey var. Ancak şu anda bahsettiğim hesaplarda perakende odağı oldukça güçlü; yani öyle diyebilirsin.

Ben Aston:

Harika. Serbest çalışan rolünde neyi daha zor buluyorsun? Şu anda uğraştığın daha büyük zorluklardan bazıları neler?

Suze Haworth:

Sanırım en büyük zorluk —ve bunun proje yöneticileri için her zaman geçerli olduğunu düşünüyorum— deneyimlerime dayanarak söyleyebilirim ki yönetmeniz ve yapmanız gereken o kadar çok farklı şey var ki. Yalnızca bir projeyi başarıyla teslim etmeye çalışmıyor; zamanlamaları, bütçeyi, ekip çıktısını, ekip üyelerini ve ekip içindeki sorunları da yönetiyorsunuz. Bunun yanı sıra elbette müşteri iletişimini de yürütüyorsunuz. Bu yüzden sahip olduğunuz süre içinde pek çok şeyi dengelemek gerçekten zor. Çoğu zaman her şeyi tek bir güne sığdırmak için sürekli mücadele ediyormuşum gibi hissediyorum.

Ben Aston:

Evet. Daha önce kadrolu çalıştığın ve şimdi yüklenici rolünde olduğun için bunun daha zor olduğunu düşünüyor musun? Farklı mı geliyor, yoksa senin için nasıl işliyor?

Suze Haworth:

Evet, biraz farklı. Serbest çalışan olarak, özellikle zamanını ajansa faturalandırma açısından, kendi zamanından daha fazla sorumlu oluyorsun. Her şeye hayır diyemeyeceğini düşündüğün bir duruma düşmemelisin. Daha iyi yapmayı öğrendiğim şeylerden biri şu: Önünde çok fazla iş varsa yalnızca belirli bir miktarını yapabilirsin ve bunu düzgün yapman gerekir. Bu nedenle her şeye evet demek yerine sınırlarını belirleyebilmen ve gerektiğinde hayır diyebilmen daha iyi.

Ben Aston:

Evet. Ben yüklenici olarak çalışırken bunun doğru olduğunu gördüm. Yüklenici olmanın gerçekten güzel bir yanı var; çünkü terfi almaya çalışmıyorsun. Elbette sözleşmeni korumak ve onlarla çalışmaya devam etmek istiyorsun, fakat kadrolu bir çalışan olduğundaki gibi insanları etkilemeye çalışmıyorsun. Kadrolu çalışırken “Evet desem iyi olur, yoksa bu kötü görünecek” diye düşünüyorsun.

Suze Haworth:

Evet, kesinlikle. Elbette yine de iyi bir izlenim bırakmak istiyorsun. Sektör küçük; herkes birbirini tanıyor. Ancak günün sonunda biraz daha geri çekilip “Tamam, çalışma saatlerim bitti” diyebilmek bazen kadrolu çalışmaya göre daha kolay.

Ben Aston:

Yüklenici olarak çalışmaya başladığından beri kaç farklı yerde çalıştın?

Suze Haworth:

Aslında şu ana kadar yalnızca birkaç yerde; çünkü bunu uzun zamandır yapmıyorum. Bunun bir açıdan iyi bir yanı oldu, çünkü şu anda çalıştığım ajansta biraz zaman geçirdim ve insanları oldukça iyi tanıyorum. Müşterileri daha iyi tanıyorum; çünkü projelerde ve hesaplarda daha uzun süre çalışabiliyorsun.

Ben Aston:

Ofiste mi çalışıyorsun, yoksa ağırlıklı olarak uzaktan mı?

Suze Haworth:

Ofiste. Aslında uzaktan çalışmanın faydalarını bu konuda konuştuğum herkese anlatıyorum; çünkü bunun gerçekten önemli olduğunu ve birçok kişi için çok daha üretken olabileceğini düşünüyorum. Ancak çalıştığım ajansların çoğu, özellikle de Londra’dakiler, ağırlıklı olarak ofiste çalışıyor.

Ben Aston:

Evet, ilginç. Serbest çalışmanın ve sözleşmeli işlerini yürütmenin yanı sıra yazdığını da biliyorum. DPM için yazılar yazdın ve yılın ilerleyen dönemlerinde DPM Zirvesi’nde de yer alacaksın. Bize bundan biraz söz eder misin?

Suze Haworth:

Evet, memnuniyetle. Bunun için gerçekten heyecanlıyım. Geçen yıl Las Vegas’taki DPM Zirvesi’nde konuşma yaptım; bu yıl ise bir atölye çalışması yürüteceğim. Oldukça ilginç bir konu, çünkü proje yöneticileri olarak hepimizin metodolojilere, özellikle de Çevik metodolojilere biraz takıntılı olduğunu düşünüyorum. Bu nedenle, farklı yaklaşımları birleştirmek üzerine bir atölye gerçekleştireceğim. Özellikle şu anda üzerinde çalıştığım bir programda uyguladığım Çift İz yaklaşımından bahsedeceğim. Bu yaklaşım Çevik yöntemlerin bazı yönlerini kullanıyor, ancak onları biraz birleştiriyor. Ayrıca Kanban, Yalın ve farklı yaklaşımları projelerinize nasıl uyarlayabileceğinizden söz edeceğim. Yani mutlaka tamamen Çevik ya da tek bir saf metodoloji kullanmanız gerekmiyor; mevcut metodolojileri uyarlayabilirsiniz.

Ben Aston:

Evet, bu harika. Bunun ne kadar önemli olduğunu düşünüyorum. Suze aynı zamanda DPM Uzmanlarımızdan biri ve Dijital Proje Yönetiminde Uzmanlaşma kursumuzda yer alacak. Eğer ne olduğundan emin değilseniz-

Suze Haworth:

Evet, ben yer alacağım.

Ben Aston:

Bu cuma başlıyor ve Suze’nin ilk katılımı olacak. Kursta konuştuğumuz şeylerden biri, metodolojinin adına ya da-

Suze Haworth:

Evet, aynen öyle.

Ben Aston:

Sonuçta mesele iş teslim etmek ve ekip, proje ve müşteri için işe yarayan bir şekilde işi daha iyi teslim etmenin yollarını bulmak. Dogmatik davranmak yerine pragmatik olmak gerekiyor. “Bu Scrum değil, bunu Scrum şeklinde yapmalıyız” demek yerine işimizi teslim etmemiz gerekiyor.

Suze Haworth:

Kesinlikle. Benim de her zaman gördüğüm şey şu: İnsanlar sürece ve belirli bir sürece uymaya fazlasıyla takılıyor. Oysa projelerinize veya ürettiğiniz ürüne bakıp “Bunun için ne işe yarar?” diye düşünmeniz gerekiyor. Farklı projelerde bu çok değişebilir; dolayısıyla uyarlamak veya birleştirmek gerekir.

Ben Aston:

Evet, tamamen katılıyorum. Bazı insanlar metodolojilerin saflığını sulandırmayı küçümseyebilir, ancak ben onların saf hâlleriyle çalıştığını hiç görmedim.

Suze Haworth:

Hayır, kesinlikle. Favori yaklaşımlar konusunda çok fazla kibir olduğunu biliyorum, ancak ben bunları kullanmaya açığım. Özellikle ajans dünyasında, içinde bulunduğunuz koşullar nedeniyle saf bir yöntem yerine birleşik bir süreç kullanmanız gerektiğini düşünüyorum.

Ben Aston:

Kesinlikle. Konferans turuna katılmak, makale yazmak ve çalışmak dışında, bu yıl kendine koyduğun ve üzerinde çalıştığın ya da geliştirmeye çalıştığın hedefler var mı?

Suze Haworth:

Bu zor bir soru. Şu anda hem işte hem de iş dışında yaptığım şeylere odaklanmış durumdayım; bu yüzden uzun vadeyi düşünmek bazen zor oluyor. Ancak daha önce konuştuğumuz önemli konulardan biri hayır demeyi öğrenmekti. Yetki devretme ve sorumluluğu biraz bırakma konusunda daha iyi olmaya çalışıyorum; bunu her zaman zor bulmuşumdur. Proje yöneticisi olarak olayları kontrol etmeye biraz fazla düşkün hâle gelebiliyorsunuz. Bu yüzden bu benim için kesinlikle uzun vadeli bir hedef.

Ben Aston:

Evet, yetki devretmek zor. Özellikle yüklenici olduğunda, yetki verdiğin kişinin seni ciddiye alıp almayacağından emin olamıyorsun; çünkü sen yalnızca bir yüklenicisin. Ayrıca onunla çalışma geçmişin de yok, bu nedenle devretmeye çalıştığın işi gerçekten yapıp yapamayacağını bilmiyorsun.

Suze Haworth:

Kesinlikle.

Ben Aston:

Biraz da araçlardan söz edelim. Farklı yerlerde çalıştığın için farklı şeylerle karşılaşıyorsun. Son zamanlarda hayatını kolaylaştıran ya da “Herkes bunu bilmeli” dediğin bir şey buldun mu?

Suze Haworth:

Dürüst olmak gerekirse, serbest çalışan biri olarak ve yıllar boyunca pek çok farklı ajansta, hatta kadrolu pozisyonlarda çalıştığım için çok sayıda farklı araçla karşılaşıyorsun ve genellikle şirketin kullandığı aracı kullanmak zorunda kalıyorsun. Bu yüzden her şeyi yapabilen, ideal ya da mükemmel bir araç bulduğumu söyleyemem. Her aracın uğraşmanız gereken bazı zorlukları veya sorunları oluyor. Bu nedenle kullandığım tek bir ideal araç olduğunu söyleyemem. Zaman çizelgeleri ve kaynak planlaması için kullanılan kaynak yönetimi araçları da dâhil olmak üzere çok geniş bir yelpaze kullandım. Her birinin iyi ve kötü yanları vardı. Araç olarak adlandırabilirseniz, gerçekten sevdiğim tek şey Google e-tabloları. Çünkü bunları her şey için veya pek çok farklı şey için kullanabiliyorsunuz.

Ben Aston:

Monday.com’u denedin mi?

Suze Haworth:

Hayır, henüz denemedim.

Ben Aston:

E- tablolarla iş yönetmeyi seven biri için Monday tam sana göre olabilir.

Suze Haworth:

Ne kadar da meraklısın.

Ben Aston:

E-tabloların harika yanı ücretsiz olmaları —en azından Google E-Tablolar ücretsiz— ve inanılmaz derecede esnek olmaları. Ancak Monday’in otomasyon, filtreleme ve kontrol konusunda ek bir güç kattığını düşünüyorum. Bir göz atmalısın. Belki hoşuna gider. E-tabloların güçlendirilmiş hâli gibi.

Suze Haworth:

O hâlde kesinlikle bakacağım. Tam bana göreymiş.

Ben Aston:

Harika. Şimdi makalene geçelim. Yazalı epey zaman oldu, ancak konuşmaya başladığımız yere dönersek, bir projeyi ele geçirmeye çalışan ya da hiçbir sorumluluk almak istemeyen insanları nasıl yönetebiliriz? Suze’nin makalesi, bunu yapmak için RACI şemasını nasıl kullandığımızla ilgili. Makaleyi henüz okumayanlar için RACI şemalarını anlatır mısın? “RACI” ne anlama geliyor?

Suze Haworth:

RACI; sorumlu, hesap verebilir, danışılan ve bilgilendirilen anlamına gelir. Temel olarak bir projedeki görevleri veya teslimatları, projenin paydaşları ya da iç ekip üyeleriyle eşleştirdiğiniz ve her role ve göreve bu dört harften birini atadığınız oldukça basit bir şemadır. Yani biri görevi yapmaktan sorumludur, biri hesap verebilirdir, biri projeye danışmanlık sağlar ve biri bilgilendirilir. Her görev veya teslimat için sorumluluk atamak, her karara çok fazla kişinin dâhil olmasını önlemek ve proje boyunca kimin ne üzerinde çalışacağına dair net bir anlayış oluşturmak için harika bir yöntemdir.

Ben Aston:

Harika. İnsanların genellikle en fazla kafa karışıklığı yaşadığı konu, kimin bilgilendirileceği veya kime danışılacağı değil. Bunlar genellikle oldukça açık. Asıl karışıklık, sorumluluk ile hesap verebilirlik arasındaki farkta ortaya çıkıyor. Peki bunu nasıl ayırt ediyorsun? İnsanların sorumlu olmak isteyip hesap vermek istemediği durumları nasıl yönetiyorsun?

Suze Haworth:

Bence RACI’nin en zor kısmı bu ve geçmişte benim de çok zorlandığım bir konu. Bu nedenle RACI oluşturmak bazen büyük bir işe dönüşüyor; çünkü “Bu aslında ne anlama geliyor ve bu role atanacak kişi açısından ne ifade ediyor?” sorularını düşünmek için çok zaman harcıyorsunuz. Basitçe ifade etmek gerekirse, sorumlu kişi görevi fiilen yapan kişidir; teslimatı oluşturan veya süreci yöneten kişi odur. Hesap verebilir kişi ise görevi onaylamaktan ve gözetmekten sorumludur; görevi fiilen yapan kişi değildir.
R ve A arasındaki bir başka zorluk da şudur: Ekibinizde bir proje yöneticisi veya ürün sahibi varsa, projeyi yürüten ve merkezde bulunan kişi o olduğu için hesap verebilirliği ona atama eğilimine girebilirsiniz. Ancak proje yöneticisinin her şeyden sorumlu olmasını engellemek ve bu görev ya da teslimat açısından kimin daha kıdemli olduğunu düşünmek gerekir. Örneğin konu tasarımsa, yaratıcı direktör kim olabilir? Sizin tarafınızdaki mi, müşterinin tarafındaki mi? Bu nedenle hesap verebilirlik rolünü sürekli olarak proje yöneticisine veya ürün sahibine yüklememek gerekir.

Ben Aston:

Evet, bu çok önemli. Çünkü kolayca düştüğümüz hata, yalnızca proje yöneticisini değil herkesi sorumlu ve hesap verebilir yapmak. “Herkes bundan sorumlu olmalı; ortak sorumluluk ya da ortak hesap verebilirlik gerekir” diyoruz.

Suze Haworth:

Evet, aynen öyle. Çünkü ekip üyelerinin de bu işi yapacağını düşünerek beş kişinin aynı görevi yapacağını ve hepsinin sorumlu olduğunu söylemek kolay. Ancak rolleri daraltmaya ve sadeleştirmeye çalışmalısınız. Rolleri herkese dağıtırsanız RACI’nin asıl amacına ulaşamazsınız. RACI’nin en güçlü yanı, genellikle tek bir iletişim veya onay noktası belirleyerek kimin neyi onaylayacağını netleştirmesidir.

Ben Aston:

Evet. Kimin sorumlu olduğunu, yani işi kimin yaptığını belirlemek genellikle zor değil. Ancak danışılan ve bilgilendirilen kişiler arasındaki farkı anlamak bazen zor olabiliyor. Asıl kafa karışıklığı hesap verebilir kişi ile danışılan kişi arasında yaşanıyor. Söylediğin gibi, nihai kararın doğru olup olmadığı konusunda son sözü söyleyecek tek bir hesap verebilir kişi olmalı. Bu bir tür kalite kontrolü gibi. Buna karşılık danışılan kişi sayısı daha fazla olabilir; bilgilendirilen kişi sayısı ise daha da fazla olabilir. Bilgilendirilenler yalnızca “Bu arada, arkadaşlar, ortaya çıkardığımız şey bu” denilerek bilgi verilen kişilerdir.
Ancak danışılan kişiler projeyi rayından çıkarabilir. Çünkü bir kişiye danışılması gerektiğini söylediğinizde, o kişinin söz hakkı olur. Teslimatın zamanında veya doğru yapılmasından sorumlu değildir, ancak görüşü vardır. Bu nedenle hesap verebilirlik ile danışılma arasındaki hassasiyet ve konumunu, yetkisini ya da fikrini ortaya koymak isteyen kişilerin güç mücadelesi önemlidir. Bu kişiler, işin doğru teslim edilmesinden nihai olarak sorumlu değildir.

Suze Haworth:

Evet. Buradaki diğer gerilim de şu: Danışılan kişi, danışılan kişi olduğunu bildiği için doğal olarak söz hakkına sahip olmak isteyecektir. Bu yüzden hesap verebilirlik rolünü kime atadığınız çok önemli. Bu kişi teslimatın veya görevin sahibi olmalı; danışılan kişilerin katkı sunmasını sağlamalı, ancak onların geri bildirimlerle tüm projeyi rayından çıkarmasını engellemelidir.

Ben Aston:

Dürüst olalım: RACI şeması açısından, “Yüzüklerin Efendisi”nin bir RACI şeması olsaydı nasıl görüneceğine dair harika bir örnek verdin. Ancak bu belgeyi her projede kullanıyor musun? Hafif ve pratik kalmasını nasıl sağlıyorsun? Çok fazla ayrıntı düzeyine inerseniz oluşturmak uzun sürebilir. Bunun insanların isimlerinin yanına yazıldığı başka bir iş kırılım yapısına dönüşmesini nasıl önlüyorsun?

Suze Haworth:

Sırf belge oluşturmuş olmak için gereğinden fazla belge hazırlamamak konusunda çok hassasım. Sonuçta kullanılmayacak belgeler önermek istemem. Ancak RACI hazırlıyorsanız onu faydalı hâle getirmeli ve gerçekten kullanmalısınız. Projenin başında oluşturup sonra sunucuda unutulmamalı. Teslimatlar üzerinde çalışırken ona başvurmalı ve kullanmalısınız. Projenin sonunda da proje değerlendirmesinde nasıl kullandığınızı incelemelisiniz. Başarılı oldu mu? Başlangıçta belirlediğiniz yapı doğru muydu? Belgeyi faydalı kılmanın yolu onu gerçekten kullanmaktır.

Ben Aston:

RACI’yi hangi durumlarda gündeme getirdiğini anlatır mısın? Durum toplantılarında, önümüzdeki hafta şunları yapıyoruz derken, RACI şemamıza bakıp bu kişilerin hesap verebilir, şu kişilerin sorumlu olduğunu ve süreç boyunca bu kişilere danışıp onları bilgilendireceğimizi mi söylüyorsun? Haftalık çalışma düzeninde bunu nasıl kullanıyorsun?

Suze Haworth:

Onu mutlaka durum toplantılarında kullanmıyorum. Elbette kime gitmeniz, kimi sürece dâhil etmeniz, teslimatları kiminle paylaşmanız veya görevleri kime vermeniz gerektiğini gösteriyor. Ancak benim için daha çok bir iç referans noktası. Bir teslimata kimin dâhil olduğunu, geri bildirim için kime göndermem gerektiğini ve teslim edildiğinde kimin bilgilendirileceğini hatırlamak için ona dönüyorum. Yani daha çok dahili bir başvuru aracı. Elbette işler bu şekilde ilerlemiyorsa bunu gündeme getiriyorum.
Örneğin bir görev veya teslimat için danışılan rolünü atadıysanız ve birdenbire müşteri tarafındaki herkes ya da paydaşlar sürece dâhil olmak istiyorsa, doğrudan müşteri iletişim kişisine veya projede en çok görüştüğünüz kişiye gidip şunu söyleyebilirsiniz: “Bakın, başlangıçta bunu birlikte oluşturduk. Buna uymamız gerekiyor; çünkü bu yapı verimlilik sağlamak, iletişimi sadeleştirmek ve projeye gereksiz katmanlar ve zaman eklememek için tasarlandı.”

Ben Aston:

Anladığım kadarıyla RACI’lerin ajans ve müşteri taraflarını kapsayan ortak bir RACI mi, yoksa iki ayrı RACI mi oluşturuyorsun?

Suze Haworth:

Daha önce farklı yaklaşımlar kullandım. Bu gerçekten projeye bağlı. Sizin tarafınızda ve müşteri tarafında iki büyük ekip varsa iki ayrı şema oluşturmak daha iyi olabilir. Son zamanlarda müşterinin çok sayıda paydaşı olduğunda daha çok müşteri tarafına ait bir şema oluşturuyorum; çünkü önemli olan, onların tarafında kimi ne zaman sürece dâhil edeceğinizi bilmektir. Bizim tarafımızda ise daha sade bir ekip vardı. Bu nedenle ajansımızı tek bir ekip olarak ele aldım. Sorumlu olduğumuz görevlerde sorumluluğu biz üstlendik, ancak sorumluluğun büyük kısmı onların tarafındaydı. Bu yüzden onların tarafında daha kapsamlı bir şema hazırladım. Projeye göre değişiyor. Her şey için kullanılan klasik cevap bu, biliyorum; ancak yapıyı projenize uyarlamalısınız.
RACI’nin temel amacı faydalı bir şey ortaya koymaktır. Projenizin mutlaka bir RACI’ye ihtiyacı olmayabilir. Birkaç ekip üyesi ve tek müşteriden oluşan küçük, yalın bir projeniz varsa RACI kullanmak gereksiz olabilir. Önce ihtiyacı ve neyi amaçladığınızı değerlendirmelisiniz. Müşteri tarafında veya kurum içinde çok sayıda paydaş varsa ve kimlerin dâhil olduğunu netleştirmeniz gerekiyorsa RACI oluşturabilirsiniz. Yapıyı projenize göre uyarlamalısınız.

Ben Aston:

RACI’nin güçlü olduğu nokta, işlerin gözden kaçmasını ve insanların projenin ya da teslimatın sonunda “Neden bu konuda geri bildirim verme fırsatım olmadı?” demesini önlemesi. Ya da birinin “Tasarım ekibinin tel kafesleri açıklayacağını sanıyordum” demesini engellemesi.
Ancak deneyimlerime göre müşteriye içeride olan bitenin tamamını, kimin ne yaptığını, kimin sorumlu veya hesap verebilir olduğunu ve kime danışıldığını göstermemiz gerekmiyor. Bu genellikle gerekli değil; hatta kafa karışıklığı yaratabilir. Ancak müşteri tarafında, özellikle büyük bir ekip varsa veya karar almakta zorlanan politik bir organizasyon söz konusuysa, müşteriyi süreç boyunca nasıl yöneteceğimizi belirlemek çok yararlı.
Hesap verebilir kişiyi bulup “Projenin başında bu kişinin hesap verebilir olacağını söylemiştik. Hâlâ durum böyle mi? Değilse sürecimizi değiştirmemiz, süreyi uzatmamız ve işler karmaşıklaşacaksa bütçeyi artırmamız gerekebilir” diyebilmek önemlidir.

Suze Haworth:

Evet, kesinlikle. Bu nedenle müşterilerle çalışıyorsanız, sorumluluk, hesap verebilirlik veya danışılma rolü atadığınız müşterileri ya da iç ekip üyelerini sürece dâhil etmeniz çok önemli. RACI’yi sizinle birlikte oluşturmalarına izin vermelisiniz. Bu, tek başınıza hazırlayıp onay için gönderebileceğiniz bir belge değil. İnsanlar üzerinde yeterince düşünmeyebilir ve “Evet, uygun, projeye devam edelim” diyebilirler. Ancak başlangıçta bu kararları birlikte alırsanız sorumlulukları netleştirir, projeyi ilerletir ve herkesin kimin ne yaptığını anlamasını sağlarsınız.

Ben Aston:

Deneyimlerine göre RACI ne zaman çalışmayı bırakıyor? Ne zaman dağılıyor? Başta belgeyi oluşturdunuz ve her konuda anlaşmaya çalıştınız; ancak deneyimlerine göre işler ne zaman çözülmeye başlıyor? İnsanların dikkat etmesi gereken uyarı işaretleri neler?

Suze Haworth:

Bence burada daha önce değindiğim üç temel nokta var. Öncelikle herkesin en başta anlaşmasını sağlamazsanız RACI çalışmaz. Belgeyi tek başınıza oluşturur, bir ekip üyesine sorumluluk atar ve onun bundan haberi olmaz ya da bunu kabul etmezse sorun yaşarsınız. Müşteriler hakkında varsayım yapıp “Bence onlar hesap verebilir, bence sorumlu olan onlar” derseniz ve belgeyi böyle oluşturursanız da sorun çıkar. Herkesin, özellikle de bir şeylerden sorumlu veya hesap verebilir olacak kişilerin onayını almalısınız.
Ayrıca onu kullanmak çok önemli. Proje boyunca ona başvurduğunuzdan emin olun. İşlerin yolunda olup olmadığını ve doğru kişilerin dâhil olup olmadığını kontrol edin. Belgeyi bir kenarda bırakırsanız, başlangıçta tamamlanan bir kontrol kutusundan ibaret kalır. Projenin sonunda da faydalı olup olmadığını, doğru olup olmadığını ve görevleri doğru şekilde eşleştirip eşleştirmediğinizi gözden geçirin. Bu, gelecekte oluşturacağınız RACI’ler için yararlı olacaktır.

Ben Aston:

RACI dağıldığında —çünkü projelerin gerçeği bu, değil mi? Rolleri tanımladığımızı ve herkesin ne yapması gerektiğini bildiğini düşünüyoruz; hatta bunu belgeliyoruz. Ancak sonra parmakla suçlama başlıyor, işler arada kayboluyor ve insanlar üzülüyor— işleri yeniden sıkılaştırmak için ne yaparsın? Bizi bu süreçten geçirir misin?

Suze Haworth:

İşler ters gittiğinde veya beklemediğiniz kişiler müşteri tarafında sürece fazla dâhil olduğunda, RACI’yi önlerine tutup “Başlangıçta bunu kabul etmiştiniz” demek cazip gelebilir. Ancak RACI bu şekilde, yani “Bakın, neyi kabul ettiğinize bakın; buna uymuyorsunuz” demek için kullanılmamalı. Daha çok şöyle konuşmalısınız: “Bakın, başlangıçta hepimizin üzerinde uzlaştığı yapı bu. Başta proje verimliliği sağlamak ve beklentileri belirlemek için bunu oluşturduk. Bazı kişiler buna uymuyor ve yaptıkları projeye daha fazla zaman ve emek ekliyor.”
Projeyi rayından çıkaran kişilerle veya onlarla birlikte çalışanlarla sonuçları konuşun. Bunun proje üzerindeki etkilerini ve bu yapıyı neden kurduğunuzu açıklayın. Belirli kişilerin neden dâhil edildiğini veya sorumlu yapıldığını anlatın. Bu şekilde devam edilirse neler olabileceğini anlamalarını sağlamanız önemli.

Ben Aston:

İnsanlara, şeylerin neden bu şekilde olduğunu veya projenin başında neden böyle tanımlandığını hatırlatmak, bazen insanların kendi rollerine geri dönmesine yardımcı oluyor. “Evet, bundan sorumlu olmamamın bir nedeni var; bunun nedeni bu konuda yorum yapacak uzmanlığa sahip olmamam” diyebiliyorlar.

Suze Haworth:

Bu da RACI’yi gerçekten faydalı bir belge hâline getirmeye geri dönüyor. Belgenin bir amacı olmalı. Projede sınırlı zamanınız veya sınırlı bütçeniz olduğu için verimlilik oluşturmanız gerekir; yani bunu yapmanızın bir nedeni vardır. RACI’yi belirli bir amaç olmadan hazırlarsanız, dönüp ilişkilendirebileceğiniz bir şey olmaz ve belge neredeyse değersiz hâle gelir. Bu nedenle onu hazırlamanın net faydaları olduğundan ve verimlilik sağladığından emin olmalısınız.

Ben Aston:

Zor bir konu. Bir RACI şablonu indirmek isterseniz, Suze bizim için bir şablon oluşturdu. Ayrıca bunun nasıl bir projeye uygulanabileceğini açıklamak için “Yüzüklerin Efendisi”ni kullandığı gerçekten yararlı bir örnek de hazırladı. İlginç bir bilgi paylaşayım: “Suze bu makaleyi yazdı ve ‘Yüzüklerin Efendisi’ temelli bir örneğimiz var” diyen e-postayı gönderdiğimizde biri bana “Herkesin zamanını bununla harcadığınıza inanamıyorum” diye yanıt verdi. Gerçekten alaycı bir e-posta yazmıştı. Sanırım yanıt vermedim, ancak şaşırdım. Bir gün sonra tekrar yazıp “Makaleyi okudum, harikaymış. Ben sadece ‘Yüzüklerin Efendisi’ni sevmiyorum” dedi.

Suze Haworth:

Biliyorum. Oldukça özel bir konu. Ayrıca “Yüzüklerin Efendisi” için o matrisi oluşturduğumda “Bunların bazılarını yanlış yapacağımdan eminim” diye düşünmüştüm. Yani kendi söylediklerimin tam tersini yapıyordum. Ancak bunu ilişkilendirilebilir bir şekilde somutlaştırmak istedim.

Ben Aston:

İyi olan kısmı, en azından bazı insanların Yüzük’ü almak için yürütülen projeyi anlamasıydı. Evet, biraz bölücü olabilir. Ancak bence harika. Suze, bize katıldığın için çok teşekkürler. Seninle birlikte olmak harikaydı.

Suze Haworth:

Teşekkür ederim.

Ben Aston:

Sohbete katkıda bulunmak isterseniz gönderiye yorum yapabilir veya TheDigitalProjectManager.com’un Kaynaklar bölümüne giderek Slack ekibimize katılabilirsiniz. Burada her türden ilginç konuşma bulacaksınız. Suze’yi daha fazla dinlemek isterseniz TheDigitalProjectManager.com’un Eğitim bölümüne giderek Suze’nin yer alacağı bir sonraki dijital proje yönetiminde uzmanlaşma kursuna kaydolabilirsiniz. Bir sonraki programa kadar dinlediğiniz için teşekkürler.