3 Adımda Proje Başarısızlığından Nasıl Kaçınılır + 4 Vaka Çalışması

Proje Başarısızlığı Nedir?

Tam olarak kulağa geldiği gibidir—bir projenin, ekibin başlangıçta belirlediği proje hedeflerini karşılamaması, müşterinin veya temel paydaşların beklentilerini karşılamaması ya da zamanında, bütçe dahilinde veya belirlenen kapsamda tamamlanmaması.

Projeler Neden Başarısız Olur?

Giriş bölümünde de değindiğim gibi, projelerin başarısız olmasının yaygın nedenleri çeşitlidir. Genellikle bunun nedeni, bir riskin gerektiği gibi değerlendirilmemesi ve/veya ekibin (proje yöneticisi de dahil) riske doğru şekilde karşılık vermemesidir.

Proje başarısızlığının diğer yaygın nedenleri arasında durum, sorunlar veya risklerle ilgili yetersiz iletişim; ekip üyelerinin proje kapsamına, proje teslimatlarına (ör. kapsam kayması) veya zaman çerçevesine uymaması (ya da bunları doğru şekilde anlamaması); kaynak eksikliği veya belirlenmiş süreçlere ya da metodolojilere uyulmaması yer alabilir.

Proje Başarısızlığından Nasıl Kaçınılır: 3 Adım

Risk yönetimi, önemli bir proje yönetimi faaliyetidir. O kadar önemlidir ki riski yönetememek çoğu zaman proje yönetiminin başarısızlığı anlamına gelir. Risk yönetiminin üç önemli bileşeni vardır:

1. Riskleri belirleyin.
2. Belirlediklerinizi değerlendirin: Gerçekleşme olasılığı nedir ve gerçekleşirse işler ne kadar kötüleşir? Olasılık ve etki nedir?
3. Aksi takdirde başarılı olacak projenizi sekteye uğratabilecek riskler için azaltma ve acil durum planları hazırlayın. Risk kayıtları, yaptıklarınızı takip etmek için kullanışlıdır.

1. Riskleri Belirleyin

Öncelikle riskleri belirleyin. Bunu iyi yapmak, proje başarısı şansınızı büyük ölçüde artırır. Hepsini fark etmek zor olsa da projeye sistematik bir şekilde bakarsanız genellikle en büyük riskleri belirleyebilirsiniz. Bu genellikle bir proje planı oluşturma sürecinin bir parçasıdır.

Geçmişim, hem ürün hem de BT alanında yazılım geliştirme ve bunlarla ilişkili süreçlere dayanıyor. Yazılım projeleri karmaşık ve kırılgandır; birkaç nadir durum dışında, inşaat veya tıbbi cihaz üretimi gibi alanlarda bulunan türden hata önleme mekanizmaları ve denetimler bünyelerinde yerleşik değildir.

Dört göstergenin her biri için proje hedefleriniz olmalıdır:

1. Takvim
2. İçerik
3. Maliyet
4. Kalite

Bunların ne olduğunu bilmiyorsanız başlangıç noktanız burasıdır. Genellikle dördünden ikisinin biraz değişeceğini düşünüyorum; ancak nereye gittiğinizi ne kadar iyi anlarsanız engelleri belirlemeniz de o kadar kolay olur.

Dört göstergeden hangisinin en yüksek önceliğe sahip olduğunu anlamak, küçük ölçekte uygun ödünleşimler yaparak riski azaltmanıza yardımcı olur.

Proje takvimi göstergesine kendinizi kaptırıp diğer göstergeleri etkileyebilecek riskleri gözden kaçırmak kolaydır; ancak hepsi birbiriyle ilişkilidir ve hepsinin belirlenmesi önemlidir.

Hatalarla dolu bir ürünle takvim hedeflerinizi karşılamak genellikle iyi bir seçenek değildir—hatta ürünü piyasaya sürseniz bile, sorunu en başta ele almış olmanızın gerektireceğinden daha uzun süre boyunca takvimi ileriye iten düzeltme sürümleri yayınlamak zorunda kalırsınız.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

4 Göstergenin Ötesinde

Dört göstergenin yanı sıra projenizin dengelemeniz gereken üç yönü vardır:

1. Genellikle göstergelerle ele alınan ürün
2. Süreç
3. İnsanlar

Süreç riskleri iki türde ortaya çıkar: projenizin ihtiyaçlarını karşılamayan mevcut bir süreç yetersizliği ve ekibinizin yaptığı işler açısından kritik olan bir konu için süreç bulunmaması. Süreci oluşturarak veya düzelterek süreç risklerini azaltmak oldukça kolaydır.

İnsanlar kısmı genellikle göz ardı edilir; ancak ekibiniz ve etkileşimde bulunduğunuz ekipler projenizin başarısını veya başarısızlığını belirler. Zorlayıcı ya da ilgisiz proje paydaşları, ilerlemek için ihtiyaç duyduğunuz şeyleri elde etmenizi zorlaştırır.

Aşırı çalışan, stresli veya mutsuz ekip üyeleri işi tamamlayamaz. Ortaya çıkarabileceğiniz olası insan kaynaklı sorunların bazılarını herkesin önünde belirleyebilir, bazılarını ise özel olarak ele almak isteyebilirsiniz; ancak bunları görmezden gelme hatasına düşmeyin.

2. Belirlediğiniz Riskleri Değerlendirin

Riskleri belirledikten sonra, bunların gerçekleşme olasılığını tespit edin. Ben genellikle bir yüzde kullanırım; %100, gerçekleşeceğinden emin olduğum anlamına gelir. Risk gerçekleşirse sonuçlarının ne kadar kötü olacağını belirlemek de önemlidir. Bunu yapmanın en kolay yolu, riskleri yüksek, orta veya düşük risk olarak kategorilere ayırmaktır.

Bu analizi yaptıktan sonra ekibinizi sürece dahil etme zamanı gelir. Her bir proje ekibinden veya katkı sağlayan kişiden ne konuda endişe duyduğunu öğrenin, bunları riskler listesine ekleyin ve değerlendirmeye sunun:

• Ekip, ele almadığınız başka riskler düşünebilir mi?
• Olasılık ve etki analizi hakkında ne düşünüyorlar?

Bu toplantıya dayanarak risk planınızda düzenlemeler yapabilirsiniz. Birinci ve ikinci bölümler şimdilik tamamlandı. Yeni risklerin ortaya çıkıp çıkmadığını, artık geçerli olmayan riskler bulunup bulunmadığını ve herhangi bir olasılık ya da etkinin değişip değişmediğini görmek için riskleri en az haftada bir gözden geçirmeniz gerekir.

3. Risk Azaltma ve Acil Durum Planları Hazırlayın

Son olarak, herhangi bir riskin olasılığı ve etkisinin birleşimi projenizi rayından çıkarma potansiyeline sahipse, risk azaltma ve acil durum için yazılı planlar oluşturmak üzere ekibinizle birlikte çalışın.

Risk azaltma, riskin gerçekleşme olasılığını düşürmeyi veya gerçekleşmesi durumunda etkisini azaltmayı içerir. Acil durum planlaması ise risk kaçınılmaz olduğunda ve gerçekleştiğinde atacağınız adımlara odaklanır.

Planların yazılı olduğundan ve herkesin bunlardan haberdar olduğundan emin olun. Dört kadran ve süreçlerin yanı sıra olası insan kaynaklı sorunlar için de plan yapmak iyi bir fikirdir; ancak muhtemelen analizi kendiniz yapmak ve gizli tutmak istersiniz.

Proje Başarısızlığından Nasıl Kurtulunur?

Proje yönetimindeki başarısızlıkların ikinci nedeni, öngörülmüş olsun ya da olmasın, bir proje riskinin gerçekleşmesine yeterince iyi yanıt verilememesidir.  Bu durum tamamen proje yöneticisi olarak size bağlıdır. Aşağıdaki adımlardan herhangi birini uygulamadan önce şu 2 ipucuyla başlayın:

• Paniğe kapılmayın. Nefes almayı unutmayın.
• Suçlayacak kişi aramayın ve başkalarının da suçlama yoluna girmesine izin vermeyin.

1. Acil Durum Planınıza Başvurun

Hazırda bir acil durum planınız varsa hemen bir toplantı düzenleyin veya en azından acil durum planını devreye sokan bir e-posta gönderin. İnsanlara planın ne olduğunu hatırlatın ve durumun ne zaman ve nasıl bildirileceğini herkese açıklayın.

Bunu atlarsanız veya ertelerseniz, yardım etmeye hevesli kişilerin panik içinde işe koyulduğunu görürsünüz; bu gerçekleştiğinde neler yapıldığını takip edemezsiniz ve çoğu zaman sorun daha da kötüleşir.

Bir acil durum planınız yoksa, hemen bir toplantı duyurusuyla ve toplantı sona erene kadar BAŞKA HİÇBİR ŞEY YAPILMAMASI yönündeki kesin talimatlarla ekibi toplayın.

Aksi takdirde herkes yardım etmeye çalışır ve neler yapıldığını bilemezsiniz. Toplantıda sorunu açıkça ifade edin; insanların sorunun ne olduğu hakkında ne kadar farklı fikirlere sahip olabildiği her zaman şaşırtıcıdır.

Sorunun kökenine inmek ve toparlanmak için kim, ne ve nasıl sorularını yanıtlayan bir plan oluşturmak üzere bütünleşik bir kök neden analizi yapın. Kök neden analizi üzerinde çalışırken soruna yol açan süreçte kimin ne yaptığını anlamanız gerekir; ancak tartışmayı bu düzeyde tutun.

Başka bir deyişle, yalnızca gerçeklere odaklanın. Suçlamada bulunmayın; çünkü suçlayıcı yaklaşım dikkat dağıtır. Ekibiniz çözümü bulamıyorsa bazı seçenekleriniz vardır.

İlk seçenek, genel konu hakkında bilgisi olan ancak bu özel projede yer almayan birini sürece dahil etmektir; örneğin sorun veritabanıyla ilgili görünüyorsa, farklı bir bakış açısı elde etmek için şu anda projede yer almayan bir veritabanı yöneticisini davet edin.

Bir başka yöntem, proje hakkında hiçbir uygulamalı bilgisi olmayan birini sürece dahil etmektir. Bazen her adımı açıkça açıklamak zorunda kalmak, hatalı varsayımları veya insanların gözden kaçırdığı bir noktayı ortaya çıkarır.

2. Sorunu Çözün

Herkesin izlenecek yol üzerinde hemfikir olmasını sağlayın ve görevleri dağıtın. İlerlemeyi size bildirmelerini isteyin ve ilerleme raporlarını ne sıklıkta göndereceklerini belirtin: saatlik olarak, bir görevi tamamladıklarında, gün sonunda veya durumun gerektirdiği başka bir zamanda.

Raporlama size apaçık görünebilir, ancak herkes için öyle olmayacaktır. Düzenli güncellemeler ekibin duruma hakim olmasına yardımcı olur. Birleştirilmiş ilerleme durumunu tüm ekibe düzenli olarak bildirin.

Ekibin acil bir görevi olmayan üyeleri, onlara durum güncellemeleri ve diğer bilgileri sağlamadığınız sürece huzursuzlanacak ve sonunda işe dahil olup yardım etmeye çalışacaktır.

Yönetimi de süreçten haberdar etmek çok önemlidir. Hangi kişilerin hangi aşamada güncellemeye ihtiyaç duyduğunu değerlendirmek için kararınızı kullanın; ancak birleştirilmiş ilerleme durumunu tüm ekibe düzenli olarak bildirin.

3. Tamamlandığını İlan Edin

Gerçekten tamamlandığında, elbette. Son bir rapor hazırlayın ve bir sonraki adıma geçin. Ekibe toparlanması için biraz zaman tanıyın.

4. Ölüm Sonrası Değerlendirme veya Retrospektif Gerçekleştirin

Öğrenilen dersleri toplamak için bir proje değerlendirmesini tamamlamak önemlidir. Yapıyı şu şekilde oluşturabilirsiniz:

• Sorunu, herkesin aynı anlayışta olması için açıkça ifade edin
• İyi giden şeylerle başlayın. En zor durumda bile bir şeyler doğru gitmiştir. Bu, toplantının tamamen farklı bir havayla başlamasını sağlar.
• Nelerin iyileştirilmesi gerektiğini konuşun. Zaman varsa iyileştirmeleri gerçekleştirme yolları üzerine beyin fırtınası yapın; aksi takdirde görevleri ve teslim tarihlerini belirleyip bu tarihlerde takip gerçekleştirin.

Eğer gerçekten birinin hatasıysa, bu konuyu o kişiyle özel olarak ele alın. Bunu herkesin içinde yaparsanız, tüm ekibiniz bir sonraki sefer kimin herkesin içinde küçük düşürüleceğini merak edecektir.

Bu süreci tamamen atlarsanız ekibiniz, birinin bir şeyden paçayı kurtardığını ve sorunun çözülmediğini düşünecektir. Konuya duygusal davranmadan yaklaşın ve birinin gerçekleştirmesi gereken kişisel süreç değişikliklerini takip edin. Önemli olan hesap verebilirlik ve iyileştirmedir; suçlayacak birini bulmak değil.

Gerçek Hayattan 3 Proje Başarısızlığı Örneği

BT projelerinde benim de payıma düşen başarısızlıklar oldu; neyse ki acı verici olsa da bu projeler toparlandı.

İşte başarısız olan birkaç kendi BT ve geliştirme projemin yanı sıra ünlü bir başarısız projeye dair bir örnek.

Bu proje başarısızlığı örnekleri ve başarısız proje vaka çalışmaları, projelerin başarısız olabileceği yollar ve bunun nasıl ele alınabileceği konusunda size somut bir fikir vermelidir.

1. Muhasebe Sistemi

Kariyerimin başlarında IBM'de çalıştım. İlk gerçek işim, kurumsal muhasebe sistemlerine veri aktaran oldukça küçük bir sistemi devralmaktı. IBM içinden biri bu sistemi, küçük bir bilgisayarda RPG adı verilen, çok bilinmeyen bir programlama diliyle yazmıştı.

Sadece projeyi yönetmiyordum; bir yöneticisi olmasına rağmen, proje gereksinimlerinin toplanması, sorun giderme ve programlama da dahil olmak üzere tüm sistemi yönetiyordum.

Güzel bir gün yeni bir programı sisteme ekleyip çalıştırdım ve bir hata buldum. Hatayı düzelttim ve programı yeniden çalıştırdım. Ertesi sabah Muhasebe departmanından, çift kayıtlar oluştuğuna dair bir telefon aldım (muhasebe dünyasında bu çok kötü bir haberdir).

İlk olarak, hiç kimse çalışmamı incelememişti. İkinci olarak, kayıtlar sistemlerden geçmeden önce kontrol edilmeleri için sonraki sistemlerden sorumlu kişilerle iletişime geçmemiştim. Üçüncü olarak da hâlâ çalışmakta olan ve çift kayıtlar oluşturan eski programlardan bazılarını analiz etmek için yeterli zaman ayırmamıştım. Ayrıca, anlık olarak kendi oluşturduğum süreç dışında herhangi bir süreç yoktu.

Ardından verdiğim tepki panik oldu. Aman Tanrım, üniversiteden henüz mezun olmuşken IBM'in muhasebe sistemini mahvediyordum. Doğru kişilerle iletişime geçmemiştim; yönetici neler olup bittiğini bilmiyordu ve farkında olmadan bir dizi kayıt daha oluşturdu. Sonunda temel nedeni bulmak, sorunu düzeltmek ve muhasebe hatalarını giderecek programları yazıp çalıştırmak için aralıksız 48 saat çalıştım.

Ve dersimi aldım: dikkatlice inceleyin, değerlendirmeler alın, neyin yanlış gidebileceğini düşünün ve bir şeyleri düzeltmeye girişmeden önce durup düşünün (muhasebe proje yönetimi yazılımları tüm bunlarda yardımcı olabilir). Şimdi 10 kişilik bir ekibi yönettiğimi ve herkesin sorunu çözmeye çalışırken aynı şeyi yaptığını düşünün. IBM'in muhasebe sistemlerini çözüme ulaşmak için devre dışı bırakmadan bu durum gerçekten kurtarılamazdı.

More Articles

• Proje Yöneticileri İçin Tasarım Odaklı Düşünme: Eksiksiz Rehber
• Proje Yönetiminin Değerini Kuruluşunuza Satmanın 7 Yolu
• Projelerin Başarısız Olmasının 6 Yaygın Nedeni: Örnekler ve Alınan Dersler

2. Yeni Dahili Ürün

Danışman olarak, gereksinimler konusunda çok sayıda kişinin söz sahibi olduğu ve işlevsel önceliklerin hiç bitmeyen değişikliklere uğradığı, büyük ve yeni bir proje yürütüyordum. Şirketin daha önce kullanmadığı bir çevik proje yönetimi süreci yürütüyorduk. QA test konusunda çok iyiydi ancak son kullanıcı bakış açısını ve iş akışını henüz anlamıyordu.

Tüm bunları biliyor ve zaman zaman dile getiriyordum; ancak bir risk kaydım, etki/olasılık değerlendirmem, acil durum planım veya risk azaltma planım yoktu. Ayrıca proje sponsoruna bilgi aktaran temel kişi de ben değildim; yine de sponsorla zaman zaman görüşüyordum.

Bir sprint ekledik. Sonra bir tane daha. Ardından, beta testi yapabilmek için gereken noktaya henüz tam olarak ulaşmadığımız netleşince üçüncü bir sprint ekledik.

Proje sponsoruna bilgi veren kişi ben olmadığım için, onun tüm bunlardan haberdar olmadığını bilmiyordum. Sorumlu kişi, projeyi başarıyla tamamlayabileceğimizi umarak sponsora bilgi vermeme gibi kritik bir hata yaptı.

Adil olmak gerekirse, risk hakkında konuşmuş olsam da sponsorun takvimin sarkma ihtimaline hazırlanması için kendisine sunabileceği somut bir risk listesi vermemiştim.

Tüm bunların ortasında sponsorla bir toplantı yaptım ve ekleyeceğimiz son sprintten gelişigüzel bahsettim. Sözümü kesti. Bu konu hakkında hiçbir şey bilmiyordu ve hiç memnun olmadı.

Sonuç olarak, takvimin sarkmasından çok bu sürprize öfkelendi. Kamuya açık tepkiler yaşandı ve sonunda proje sorumlusu, güven ortadan kalktığı için şirket içinde başka bir bölüme geçti.

Bir kez daha başarısızlıktan önemli dersler çıkardım. Riskleri bilmek yeterli değil; onları bir araya getirmeniz, değerlendirmeniz, azaltma ve beklenmedik durum planlarına sahip olmanız, bunları kamuya açık hale getirmeniz ve sürekli görünür tutmanız gerekir.

Riskleri ve sorunları gizleyen biri olmadım; ancak proje şeffaflığının önemi tartışmasız şekilde ortaya çıktı.

3. OS2'yi hatırladınız mı?

Hayır, kimse hatırlamıyor. Bu, başarısız sistem geliştirme projelerinden yalnızca biri. Windows'a rakip olan ilk OS2 çıktığında IBM'de çalışıyordum. O ilk sürümü denemedim bile; çünkü IBM'de hepimiz onun gerçekten hatalarla dolu olduğunu biliyorduk. Dünyanın geri kalanı da uğraşmaya değmeyecek kadar çok hata içerdiğini hemen fark etti.

O kadar çok hata içeriyordu ki proje ekibinin onun tamamen hazır olduğunu düşünmüş olması mümkün değildi; ancak nedense doğru ödünleşimi yapamadılar ve sürümü ertelemediler. İnsan unsurunu göz ardı etmek, hem ekibinizin hem de müşterilerinizin güzel bir planı kısa sürede mahvetmesine yol açar.

Yazılımda bu duruma yönelik çok sayıda alternatif vardır: yeni ve en ileri düzey yazılıma sahip olmak için hatalara katlanacak kişilere sınırlı bir sürüm sunmak, güvenilirliği yüksek standartlarınıza ulaştırmayı beklediğinizi kamuoyuna duyurmak ve benzeri yöntemler.

Kariyerimde henüz yeterince erken bir dönemdi; bu nedenle sevdiğim bir ürünün ikinci sürümde çıkmaza girmesinden değerli dersler çıkarabildim.

Öncelikleriniz konusunda net olun; belirli bir tarihte sürüm yayınlamanın ürün kalitesinden daha önemli olduğu birkaç durum vardır, ancak bunlar çok fazla değildir.

4 kadranınızı kullanın, hatalarınızı kabul edin ve insanların sorunu anladığınıza ve aynı hatayı iki kez yapmayacağınıza güvenebilmesi için düzeltmeleri görünür hale getirin.

İnsan unsurunu dikkate alın; bu unsur teknoloji kadar kritiktir. O zamandan itibaren bu dersleri yazılım ve BT projelerine taşıdım ve son derece değerli olduklarını gördüm.

Sonuç

Genel olarak, sorumluluk nihayetinde size ait olsa da tüm işi sizin yapmanız gerekmediğini unutmayın. Hatta kesinlikle bunu tek başınıza yapmaya çalışmamalısınız. Ekibinizin geniş deneyim ve bilgi yelpazesinden yararlanabilirsiniz. Lider sizsiniz, ancak ekibin tamamı olmak zorunda değilsiniz.

Proje yönetimi yazılımı ve diğer proje yönetimi araçları, riskleri, kilometre taşlarını, kaynak tahsisini ve başarılı bir projeye doğru ilerleyip ilerlemediğinizi gösteren diğer kritik göstergeleri izlemenize yardımcı olabilir.