Başarısız Proje: Ne zaman arayacaksınız?

Birkaç ay önce şirketim kendini bir projenin beyaz-sıcak acil durumunun etrafında elleriyle buldu ve altı kişilik ekibimin tamamı temelde beş hafta süren "crunch week" i çekti. Yayına başlamadan 48 saat önce, iki gece boyunca arka arkaya 41 kişi çalıştım. Bunun ortasında, şu ana kadarki en başarılı sorumun ne olduğunu sordum .

Bunca zaman boyunca hiçbir zaman “başarısızlık” lafı olmadı. Her zaman "acısından bağımsız olarak yap" oldu.

Artık her şey bitti ve bir organizasyon olarak arkamıza yaslanıp öğrendiklerimizin stoklarını almak için biraz zamanımız oldu, bana bir soru geldi. "Başarısız" olduğunu söylediğim bir projede yer aldığımı söyleyemem. Bol miktarda, bütçenin çok üstünde veya üzerinde kaldı, bazıları çok fena halde, ama ben her zaman SOMETHING'i teslim ettim.

Yine de her zaman "başarısız BT projeleri" hakkında bir şeyler duyuyorum. İnsanların bu konudaki deneyimlerini merak ediyorum. "Başarısızlık" olarak tanımlanan parametreler nelerdi? Bağlam neydi? Bizim durumumuzda, dış müşterileri olan bir yazılım mağazamız. Büyük bir şirkete dahil olan bir projede "başarısız" olmak için daha fazla alan var mı? Bu aramayı ne zaman yaparsın? Ne zaman yaparsın?

Yaptığımız şeyi yapmanın akıllıca bir iş hamlesi olduğuna ikna olmadım. Benim çağrım değildi (ben sadece bir kod maymunuyım) ama kayıplarımızı kesmek, teslim etmediğimizi söylemek ve devam etmek için daha iyi olabilir mi diye merak ediyorum. Sadece uzun saatler süren acı yüzünden - şirketin şahsen projedeki gömleğini kaybettiğini, ayrıca çalışanın moral ve sadakati açısından maddi olmayan maliyetlerinin çok büyük olduğunu söylemiyorum . PR'a karşı, bunun gibi yüksek profilli bir projeyi teslim etmemeyi etkileyen faktör oldu ... ve doğru cevabın ne olduğunu bilmiyorum.

Başarısızlık kavramı gerçekten işle ilgili bir çağrıdır. Ticari bir projenin getirdiği paradan daha pahalı olması durumunda, bu projenin bir başarısızlık olduğu düşünülür. Bir açık kaynak projesi sürdürmek ve bakımını sağlamak için kod etrafında bir topluluk oluşturamazsa, açık kaynak projesi başarısız oldu.

Projelerde yer aldım, her şeyi zamanında ve bütçe dahilinde teslim ettik, ancak iş geliştirme ekibi iş takibinde başarısız oldu. İş açısından bakıldığında proje, teslim ettiklerimiz iyi karşılanıp beğenilse de başarısız oldu.

Sizinki gibi durumlarda, şirket zor kararlar vermek zorundadır. Projenin başarılı olmasını istiyorlarsa, bazı dersler öğrenmeleri gerekir:

• Uygun bir şekilde planlanmamak, ekibinizde istenmeyen bir strese neden olacak ve sonuçta başarısız bir projeye yol açacaktır.
• Stresli bir ekip yüksek ciro ile misilleme yapacak - ve sonunda iyi insanların şirkete katılmalarını sağlayamayacaksınız.
• Acil durumlar olur, ancak acil duruma neyin yol açtığını bulun ve gelecekte bu acil durumdan kaçınmak için uygulamalarınızı değiştirin.

Hatalarından ders almayan herhangi bir şirket, tarihi sıklıkla tekrarlar. Bunu başka bir şirket bulmanın zamanının geldiğinin işareti olarak alırdım.

Başarısızlık, ulaşılmayan bir hedefi tanımlayabilecek herhangi bir şeydir.

Kısacası, amacınızı tanımladığınızda, bu bağlamda başarısızlığın ne olduğunu da tanımlarsınız.

Bahsettiğiniz literatürde bir başarısızlık bütçenin üzerinde olan ve / veya son teslim tarihine uymayan bir projedir .

Bu, ürünün kullanılmayacağı anlamına gelmez. Bu, beklenenden çok daha fazla acı, para ve zaman geliştirici olduğu anlamına gelir.

When you should cancel a project? Herhangi bir yeni saniye harcamasının, maliyetinden daha az değer sağlayacağından emin olduğunuzda.

Buna batık maliyet ikilemi denir .

Konuyla ilgileniyorsanız , Edward Yourdon'dan Death March'ı öneririm . Gerçekten harika bir kitap.

Bir projenin “başarısız olabileceği” birçok farklı yol vardır. Ve üzerinde çalıştığım birkaç kişi başarısız oldu:

1. Shrink wrap yazılımının yeni yasal / düzenleyici kuralları karşılaması için yeniden yazılması gerekiyordu. Kötü niyetli kişiler, iş yüküne ve özellikle de hepimizin sahip olamadığı becerilere yardımcı olmak için yeni insanlarla çalışmaktan kaçınmayı seçti. Ürün gerekli yeni özelliklere sahip değildi (elektronik dosyalamanın belirli bir şekilde yapılması gerekiyordu) ve piyasadan çekilmesi gerekiyordu. Bu ürün ofisimizin gelirlerinin yaklaşık% 5'ini oluştururken, gelirlerimizin% 60'ını üreten ürünü etkileyen benzer bir düzenleyici değişiklik geliyordu. Geliştiriciler ihtiyaç duydukları becerileri öğrenmeyi kendi başlarına üstlendiler, ancak kötü niyetli kişiler gerekli değişiklikleri uygulamaya başlamak için neredeyse çok geç olana kadar beklemeyi seçtiler. Bu yasal değişikliğin sunucu tarafında teklif vermeye çalıştığımızda bu değişikliklerin geldiğine dair 3 yıllık bir uyarı aldık - ve kurumsal olarak teklifimizi vermemiz haklı olarak yasaklandı. Kötü niyetli yöneticilerimiz, üzerinde çalışmamıza izin verilmeden önce değişmeden 8 ay öncesine kadar bizi bekletmeyi seçti.

2. Proje bitmesine yardımcı olmak için devreye alındığımda zaten bütçenin üzerinde kaldı ve vadesi geçmiş. Birkaç kat daha yüksek yöneticiler, batık maliyetlerin, proje için gerekli yatırım getirisini elde etmek için zaten çok yüksek olduğuna karar verdi, böylece proje iptal edildi ve katılan herkes işten çıkarıldı. Grubun işten çıkarılmasından 1 hafta önce orada çalışmak (beni de dahil olmak üzere) bir yerde çalıştığım en kısa zamandı.

3. Dahili proje tamamlandı ve proje sponsoru hazır yazılım satın aldı (bu durumda Microsoft Office) ve işlerini yapmak için kendi VBA'lerini yazdı. Geliştirme ekibi lideri aya söz vermeyi sürdürdü ve yönetim toplantılarında projenin zaten iptal edildiğini dinlemeyi reddetti. 6 yıl boyunca hiç kullanılmayacak bir sistemi tamamlayan bir yıl boyunca çalıştı.

Programcı olarak ya da Başbakanlık ekibinin bir parçası olarak katıldığım tek proje Metricom'un iflasına karışan Ricochet oldu . Ülkede tam anlamıyla üzerinde çalışan binlerce müteahhit vardı. CFO'ları istifa ettiğinde, proje tam anlamıyla durdu. Tasfiye görevlileri alçalırken mobilya ofislerden kaldırılmaya başladı.

Birçoğumuz için geçerli terim 'işsizlik' idi, ancak Lame Duck yeterli bir açıklama olurdu. Genelde, kilit kişilerin, halefleri gelmeden önce görev sürelerini tamamlamak için birkaç ay görevde kalan bazı politikacılar gibi otopsi / tasfiye süreci tamamlanıncaya kadar devam etmesi gerekecektir.

As Otávio Décio belirtilen, bir proje nokta com patlamasının beri terk edilme noktasına başarısız görmedim.

Bu, proje yönetimi ile ilgili bazı kitaplarda da belirtilen yaygın bir sorundur. Hiçbir proje “bir daha başarısız” değil, bir bütün olarak bir “bir sonraki seferde kaçınılması gereken” bir deneyim olsa bile.

IMO, bir proje yapmazsa daha ucuz olurdu bir başarısızlıktır. Örneğin, ürün 5 yıl beklenen bir ömre sahipse ve şirketi 100 K pa tasarruf ederse, bunu yapmak 500 K'dan fazla sürerse bir başarısızlıktır. (Daha basit hale getirmek için burada faiz oranları ile hile yapıyorum). Bazı insanlar maliyet ve / veya zaman aşımına uğramış her projenin bir başarısızlık olduğunu iddia ediyor, ancak IMO bu tanımın doğru tahminlere ve planlamaya çok fazla odaklandığından çok az anlam ifade ediyor.

Ayrıca hiçbir zaman "başarısız" olan projelere de katılmamıştım - ancak fazla zaman ve masraf aşan projeler. Meselenin ne taraf ne de - müşteri veya yüklenici - herhangi bir projenin sorumluluk da dahil olmak üzere tüm nedenlerden dolayı bir başarısızlık olarak değerlendirilmesini istememesi olduğuna inanıyorum.

Bu yüzden, gerçekte “başarısız BT projelerini” duyduğunuzda, bunlar “zaman içerisinde veya bütçede sınırlarının dışına çıkmış projeler” olduğunu düşünüyorum.

Ne de olsa - tanıdığınız kaç kişi ya da şirket temiz gelir ve “başarısız” deriz?

Yine de her zaman "başarısız BT projeleri" hakkında bir şeyler duyuyorum.

"Başarısızlık" olarak tanımlanan parametreler nelerdi?

Proje değiştiğinde sıkça kullanılan aşağılayıcı bir terimdir. Birçok kişi değişimi "başarısızlık" olarak etiketlemeyi sever. Nedenini bilmiyorum, ama bir şekilde bir başarısızlık tespit etmeleri onları bir şekilde daha güçlü veya önemli kılıyor.

Bazı projeler gerçekten para kaybedilir ve değer yaratmaz. Ancak bunlar nadirdir.

Hiç çalışma yazılımı sağlamayan bir proje bile ne yapılmaması gerektiği konusunda bir öğrenme deneyimidir . Bu değer yarattı. Beklenmeyen bir değer yarattı, bu yüzden insanların onu etiketlemek istediği herhangi bir şekilde etiketlenebilir. "Başarısızlık" bazı çevrelerde "Ne yapmamasını öğrendi" kadar iyidir.

Asıl soru "değer maliyetle orantılı mıydı"? Ve o zaman bile, değerin cevabın tamamen politik ya da öznel olduğunu ölçmek çok zor olabilir.

Büyük bir şirkete dahil olan bir projede "başarısız" olmak için daha fazla alan var mı?

Belki. "başarısızlık" politik bir terimdir. Program, bütçe veya kapsamda yapılan herhangi bir değişiklik "değişiklik" veya "başarısızlık" olarak etiketlenebilir. Ayrıca "ekibimizin bir web sunucusu yazamaması konusunda önemli bir şey öğrendi" olarak da etiketlenebilirler. Veya daha da olumlu bir şekilde, "bunu tekrar denemeden önce hangi becerilere ihtiyacımız olduğunu öğrendik."

Dış projeler genellikle satış ve teslimat temsilcileri, muhasebeciler ve proje yönetimi konularında daha fazla denetime sahiptir. İç projeler genellikle daha az gözetim altındadır.

Bu aramayı ne zaman yaparsın? Ne zaman yaparsın?

Organizasyondan birisinin baskı yapması uygun olduğunda, onlarla aynı fikirde değilsin. Projelerini "başarısız" olarak etiketlediniz ve farklı kişilere sahip olabilmeniz için yeniden atanmasını sağladınız.

Bir projenin tamamen başarısız olabileceği tek yol , ceza sahtekarlığıdır - öğrenilen ders alınmadığı, hiçbir şey geliştirilemediği ve suçluların görevden alındığı ve cezaevine alındığı ve organizasyonun ne olduğu konusunda ipucu olmadığı söylenebilir.

Aksi takdirde, her zaman bir değer vardır.

Asıl soru "değer maliyetle orantılı mıydı?"

Yani, bu işi yapan şirketiniz, 5 hafta boyunca sizinle ve diğer 5 kişiyle birlikte çalıştı. Hala karlarını çalışkanlıktan kazanıyorlar. Umarım bir şeylerin vardır, çünkü iş güvenliği bugünlerde hiçbir şey değildir ve çok fazla iş vardır. (Utanmaz fiş, işe ihtiyacınız varsa ve yetkin bir programcıysanız benimle iletişime geçin, umutsuzca yardıma ihtiyacı olan birkaç yer biliyorum.)

Bu, eğer şirket gerçekten bütün bu işler ve canlı yayına girmeden 41 saat önce ödemek zorunda olsaydı, o zaman KAYBETE paraları olacaktı.

Yönetiminizin oturması ve bir daha ortaya çıkarsa size ödeme yapılması gerektiği konusunda bir açıklama yapmanız gerekir. Fişi ne zaman çekeceğine dair daha iyi karar vermeleri gerekir.

Ben de, buradaki birçok yanıtlayıcı gibi, zaman ve bütçeyle geçen birkaç büyük projede yer aldım - bir buçuk yılda bir. En kötü senaryo (onbeşinci yıl), epik bir kapsamın sürünmesinin yanı sıra, bazı mistik Man Ay çılgınlığı için dehşet vericiydi. Bu, asla terk edilmediğini ve şimdi bazı müşterileri ele geçirmeye başladıklarını söyledi. Ancak ilk beklentiler (eski, eski bir sistem için temiz, iyi tasarlanmış bir değiştirme) ve nispeten mütevazı bir bütçe ve zaman çizelgesi - uzun zamandan beri paramparça oldu.

Ayrıca, buradaki çoğu insandan farklı olarak, tamamen terkedilmiş bir noktada, tamamen başarısız bir proje gördüm . Tabuttaki son çivi 2010 başında geldi. Senaryo:

Küçük ölçekli şirket (yaklaşık 30 kişi), orta ölçekli işletmeler için özel ERP çözümleri yapıyor. Avustralya madencilik şirketleri ile göreceli olarak kazançlı lojistik kurulumları ve ABD'de birkaç taşınma kıyafetleri vardı. Platform, J2EE üzerine inşa edilmiş özel bir şirket içi çerçeve idi. Aslında nispeten özelleştirilebilir ve iyi durumda - basit yeni kurulumlar oldukça hızlı bir şekilde oluşturulabilir, ancak gereken kişiselleştirme seviyesi çok karmaşık olduğunda (en büyük müşterilerinden bazılarında olduğu gibi) çok iyi ölçeklenmedi.

Uzun lafın kısası: en büyük, en yüksek profilli kurulumlarının bazıları zaman ve bütçeyle geçti, ve pazar bunu takdir etmedi, bu yüzden daha fazla müşteri alamadılar. Şirket temelde bu ERP sisteminden biraz daha fazlasını yapan tek bir midilli idi, bu yüzden kuruduktan sonra nakit akışı bir kez işsiz kaldı ve sistem terk edildi (GFC de bunun içinde bir rol oynamış olabilir) .

(Ben sadece orada 9 ay çalıştım - 2004/2005'te. Temel olarak kiraladılar ve iş yükü gelince yeni tesislerle birlikte çalışmaya başladılar - işe alım müteahhitleri yerine - oldukça tehlikeli olan bu iş çok fazla tehlikeliti. lapa lapa bir iş modeli ile teknolojiden daha.)

Proje, asıl isteğin yerine getirileceği şekilde konuşlandırılmışsa, projeyi başarılı bir şekilde çağırırdım. Bana göre bir başarısızlık, daha sonra evrensel olarak son kullanıcılar tarafından reddedilen bir uygulamayı ortaya çıkarmak olacaktır, çünkü onların ihtiyaçlarını karşılamadı. Ya da, daha kötüsü, bir ürün aslında kullanıcılara dağıtılmadan ve ihtiyaçları karşılanmadan proje sonlandırılıyor.

Genel olarak, bir şirket harici bir müşteri için çalışıyorsa, sözleşmeyle ilgili konular (örneğin sözleşme ödemelerinin ihlali) veya belirttiğiniz gibi büyük bir PR çarpması olabileceğinden, proje çekme kararı verilmez. Bazı durumlarda, sözleşmede herhangi bir ceza ihlali varsa, sözleşmeyi bitirme maliyeti sözleşmeyi ihlal etmekten birkaç kat daha düşüktür ve bir miktar para kaybetmek tercih edilen seçenektir.

Uzun vadede, bir şirket, bir proje sırasında sıkıntıya maruz kalmak için telafi etmek için çalışanların moralini iyileştirmek için çalışabilir ya da zorlanmaları nedeniyle işten ayrılan çalışanları değiştirebilir, ancak bazen büyük proje başarısızlıklarından kurtulmaları imkansız olabilir (bazen yani zamanında iflas etmiş ürünleri teslim etmeyen oyun şirketlerine bakın).

İş vakası artık dayanmadığında.

Prince2'nin (Proje Yönetimi Metodolojisi) kullandığı ölçü bu ve benim için çok anlamlı.

Esasen, projenin her aşamasının sonunda veya bir projenin belirli alanlarda belirli toleransların dışında kalması durumunda (zamanlama, maliyet, kalite), iş vakasının gözden geçirilmesi gerektiğini söylüyor. Bu noktada, şimdi bildiklerinize dayanarak beklenen toplam maliyetler ve gerçekleştirilebilir faydalar üzerinden geçiyorsunuz ve proje artık birikmezse, o zaman öldürülüyor.

Bunu gördüğüm birçok proje için mesele, daha önce elde etmeye çalıştıkları şeyi ortaya koymamış olmaları. Bu, (a) hala gerçekçi olup olmadığını değerlendirmeyi çok zorlaştırıyor. ) oraya ulaşmak için harcayacağınız maliyetlerin buna değip değmeyeceği. Bu gibi durumlarda yapabileceğiniz en iyi şey, şüphelerinizin doğru olup olmadığını anlamanıza izin vermek için şüpheli olduğunuz noktada bir iş vakası oluşturmaktır.

Bir iş vakasını bir araya getirmek büyük bir girişim olmak zorunda değildir, A4’ün iki tarafı da öyle olacaktır. Maliyetler nispeten kolaydır (kaba bir ölçüm olarak bir programcının maliyeti: (yıllık maaş * 2) / Avrupa için günde 250, muhtemelen ABD için faydalar düşük ve ortalama iş günü sayısı buradaki girdilerden daha yüksektir. ).

Avantajları daha zordur, ancak karamsar olarak mümkün olduğunca doğru tahmin ederseniz, o zaman iş vakası yığılmazsa (normalde X'in% 50 olması muhtemel olduğu 3 yıl boyunca maliyetlerinin% x üzerinde bir geri dönüş yapması gerektiği için ölçülür) Böylece) daha ayrıntılı olarak bakabilirsiniz. Lisans ve donanım maliyetlerini (mevcut donanımı kullanıyor olsanız bile, kullandıktan sonra başka bir şey için kullanılamayacağınız anlamına gelir) ve sürekli destek almayı unutmayın.

Ancak bunun çoğu programcı olayı değil, Başbakan ve işin tüm proje ekibinin katkısıyla yapması gereken şeyler.