Projedeki Yanlışları
Doğru Yönetme
Kılavuzu
Yazılım Geliştirmede temel safhalar hemen her yazılım tarafından aşağı yukarı bilinir.Ancak acaba bunlara uygun hareket ediliyor mu ? Birçok projede bu sorunun cevabı malesef ki hayır! Sürecin hatalı yürütülmesinin sebepleri paydaşların hemen bir şeyler görme arzusu,maliyeti düşürme isteği,aşırı iyimserlik, metotlu çalışma alışkanlığı olmaması ve gerçekçi olmayan beklentiler olarak sayılabilir.
Gerek Müşteri gerek üst yönetimin hemen birşeyler görme arzusu ve ekibin tecrübe eksikliği, yazılım
geliştirme sürecinde birçok yanlışa
Sorun veya neden oluyor.Plan ve analiz
yapmadan kodlamaya
güçlük başlanıyor.Analiz ve tasarım bileştiriliyor.Bu her ne kadar maliyeti
düşürsede istenmeyen
tecrübesizliği getirdiği hatalara neden oluyor.
En az Olabilecekler
Projedeki planlama, analiz gibi çalışmalar en az emek ile en fazla fayda nasıl sağlanabilir ? kişi sayısı,belgeleme ve planlamada alt sınırlar nedir? bu soruların cevapları kısıtlı imkanlarla proje yaparken yol göstericidir.
Kişiler
Teoride yazılım proje ekibinde proje yöneticisi,takım lideri , yazılım mimarı,sistem analist,ara yüz geliştirici gibi on üzerinde unvan olmalıdır.Ancak mevcut projelerde bir çok örneği olmakla beraber bir projeye ayrılan kişi sayısı unvan sayısına göre çok daha azdır.Ekibin sayısının az olması birçok rölün birleştirilmesini zorunlu hale getirir.”Full Stack “ kavramı, örneğin arayüz geliştiricisinin mangoDb veri tabanına hakim olmayıp geliştirdiği yapılar kısa vadede olmasada uzun vadede veri tabanın getirdiği hatalara mahkumdur.
Belgeler
Yazılım geliştirirken proje planı,analiz ve tasarım
belgesi,yapılacak iş listesi ve kodun teknik açıklaması gibi belgeler ortaya çıkması beklenir.
Belgeler içerisinde proje planı ve ihtiyaç analiz belgesi olmazsa olmazdır.Plan ve analiz belgesi müşteri ile yazılım ekibi arasındaki mutabakatı gösterir.Diğer belgeler yazılım ekibinin kendi iç işlerine dönük olduğundan farklı yönetimlerle karşılabilir. Örneğin UML şeması tasarım belgesi yerine kullanabilir veya kodların anlaşılır yazılması tasarımı belli ölçüde açıklayabilir.
Çözümler
Eğer bir projenin yönetim tarafınca veya ürün tarafınca çözümler belgelenmiyorsa talepler edilmelidir.
Belgeleme ve belgelerin güncel tutulması oldukça zorlayıcı bir süreçtir.Birçok kurum “Çalışan yazılım en iyi belgedir” şeklinde bir mazaretle belgelemelerden kaçmaktadır.Bu yaklaşım belli ölçüde kabul edilebilir.Ancak en azından hemen yapılmayacak değişiklik istekleri,karar verilemeyen konular ve çözülemeyen sorunlar belgelenmelidir.Çözümün belgelenmesi ayrıntılı analizler gerektirdiğinden daha uzun sürer.Talepler ise kısaca kaydedilebilir.Talep ve hata bildirimlerini kaydetmek için birkaç dakika ayrılmadığı durumlarda, kimin ne istediği belli olmaz.Müşteri “Bu işi ta analiz aşamasında istemiştim” dediğinde yazılım ekibi verecek cevap bulamaz.Çıkan çatışmalarla günler ve haftalar kaybedebilme ihtimali çok yüksektir.
Proje Bitince Analiz ve Tasarım Belgesi Yazılması
Analiz atlandı ve proje her nasılsa bitmek üzere ise bu durumda hiç belge olmama tehlikesi ortaya çıkar sonradan da olsa analiz ve tasarım belgesi yazılmalıdır.Belgeler özellikle dış kaynak kullanılan projelerde hayati öneme sahiptir.Proje bittiğinde belgeleme yapmak yanlış olsa da bilgiler taze olacağından kısmen mümkündür.Yazılan belge en azından bakım sürecinde projeye dahil olanların işine yarar.Bu bilgiler proje ve ürün üzerinde sonradan yapılacak değişimlerde de kullanılabilir.Proje bitiminden zaman geçince yazılmayan bilgiler unutulacak ve sonradan başvurulacak yazılı bir kaynak olmayacaktır..
En Az Plan
En Az Plan
Bazı projelerde plan hiç olmayanbilir.Plan olsa da ayrıntılı ayrıntılar yetersiz olabilir.Plandaki sapmalar da planı hükümsüz hale getirebilir.Neticede ne yapılacağı belirsiz hale gelir.Plan ayrıntılı değilse en azından projede yapılacakları alt alta yazmak ve herbirine son tarih koymak gerekir.Bu tarih küçük de olsa yazılım ekibini motive edecektir.Projedeki belirsizlikler ne kadar çok olursa olsun zaman kavramı kaybedilmemelidir.
Plana dönülüp bakılmıyor ve plana göre hareket edilmiyorsa plan geçerliliğini kaybeder.
En az Yönetim ve İzleme
Projenin izlenmesi için farklı birçok gözden geçirme tekniği kullanılmaktadır.Ancak bazı firmalarda bunların adı bile anılmayabilir.Resmi bir gözden geçirme yönetmeliği olmasada projenin kontrol edilmesi gerekir.Proje yöneticisi en azından yapılanların değerlendirildiği haftalık toplantılar planlayarak işlerin durumunu çıkan sorunları ve çözüm yönetmlerini tartışmaya açmalıdır.Bu toplantılar ekip içi yapılarak teknik konularda
değerlendirilebilir.Toplantı tutanaklarına her iş için bitiş tarihi eklenerek işler takip edilmelidir.
Yapıyormuş gibi yapmamak.
Birçok projede analiz için uzun bir zaman ayrılıyor, toplantı yapılıyor ve belgeler yazılıyor.Neticede ortaya proje geliştitirken hiç kullanılmayan kifayetsiz bir belge çıkıyor.Bir yıllık bir projede iki ay analize ayrılıyor ve sonuçta kimsenin bakmadığı birkaç sayfalık bir analiz belgesi çıkıyorsa, analizi kısa tutup doğrudan prototip geliştirmek daha uygundur.Temel fonksiyonları içeren bir prototip kullanıcıya birçok şeyi anlatır.Böylece analiz yapıyormuş gibi iki ay harcanacağına bir kaç haftada tasarıma başlanabilir.Aynı şeyler planlama, tasarım,test gibi aşamalar içinde geçerlidir.
Proje Başarısızlığı
Projenin başarısızlığı hiç istenmeyen bir netice
olmakla birlikte ihtimallerden birisidir.Tüm
alternatifler denenmesine rağmen başar,ihtimali
kalmazsa yeni hedef en az zararla kurtulmak
olmalıdır.Başarısız projede ısrar,kurumu iflasa
sürükleyebilir.
Bazen yenilgiyi kabullenmek,ekip ve şirketi daha büyük kayıplardan kurtarır!
Başarısızlığın En Kısa Sürede Belli Olması
Planlama,analiz ve tasarım olmadan bir yazılım projesi başarılı olamaz.Üst yönetim desteği olamayan hedef ve standartlar belirsiz projelerin akıbeti de aynıdır.Böylesi projelerde çözüm,projeyi hızlandırıp prototip veya ürünün son halini hemen son kullanıcıya göstermektir.Son kullanıcı hemen projeyi görmeli ki analizdeki hatalar ortaya çıksın.Belki proje tekrar baştan analiz edilsin.Kurum üst yönetimi de analizin önemini ancak bu şekilde anlayabilir.
Eğer proje duvara toslayacaksa ne kadar çabuk toslarsa o kadar iyi.Çünkü tamirat ancak kazadan sonra başlayacaktır.
Proje Vazgeçme Planı
Başarısızlığın temel sebeplerinden birisi plansız
çalışmaktır. Bu sebeple başarısız olmuş bir projede başarısızlık
planı yapmak yeni bir bakış açısı gerektirir.
Proje kapsamı sürekli değişiyorsa, yeterli kadro tahsis edilemiyorsa, planlanan zamanın iki katı harcanmasına rağmen istenilenlerin ancak yarısı yapılabilmişse, maliyet artıyor ancak satın alan firma istekleri karşılanmadığını bahane edip ödeme yapmıyorsa, projeden vazgeçme zamanı gelmiş olabilir. Bir projeden vazgeçilmesi dahi planlanabilecek konulardandır. Bu kapsamda yapılacaklar:
- Projeden vazgeçildiğinin tüm ilgililere bildirilmesi
- Projeye ayrılan kaynakların tekrar planlanması
- Başarısızlığın sebepleri ile ilgili araştırma yapmak, ders çıkarmak
Başarılı Kısımlara Odaklanmak
Bir proje, iç içe geçmiş birçok alt projeden oluşabilir. Örneğin bir kurum için geliştirilen kurumsal kaynaklar planlama yazılımı ele alınsın. Proje, kurumda tümüyle devreye giremese dahi personel ve muhasebe biriminde kullanılabilir. Bu tür durumlarda müşterilerle mutabakat yapılarak hedefleri azaltmak veya belli özelliklerden vazgeçmek bir çözüm olacaktır. Böylece tüm kaynaklar, başarılı bitebilecek kısımlara harcanarak tamamen başarısızlık engellenir.
Plansız Proje Başarısız Olsa Daha İyi Olabilir
Yanlış yöntemle doğru netice alınmaz. Yanlış bir yöntemin başarılı olması sanki bu yöntem doğruymuş izlenimi uyandırır. Hemen her şirketin hayatında aciliyet dolayısla ayrıntılı planlanmamış, ancak her nasılsa başarılı olmuş birkaç proje örneği vardır. Özellikle küçük projeler, kod odaklı geliştirilse de başarılı olabilir. Bunlar kesinlikle ölçü olmamalıdır!
Birkaç tane küçük ölçekli yazılım projesini kod eksenli ve yoğun çalışarak tamamlamış bir şirket için ilk büyük proje, önemli bir eşiktir. Eğer bu şirket yeni büyük projede de aynı yöntemi uygulamaya kalkarsa, eşiği geçemez. Plansız programsız başarılı olan bir yazılım projesi başka projelere kötü örnek olacak ve belki sonraki daha büyük projeyi başarısızlığa sürükleyecektir.
Ürün Sağlıklı Çalışmıyorsa Yeni Yerlere Kurulmaması
Eğer bir şey çalışmıyorsa, ondan daha fazla yapın!
Jerry Weinberg, Kötü yönetiminin ilk kuralı
Hataları düzeltmeden, olgunlaşmamış bir yazılım ürünün yeni müşterilere satılması halinde mevcuttaki sorunlar katlanarak büyüyecektir. Birçok yazılım şirketi tek bir şikette sorunlu da olsa çalışan bir yazılım ürününü ticari kaygılarla başka firmalara üretmeye neredeyse zaman kalmaz. Müşteriler de bir süre sonra memnuniyetsiz olarak bu tür firmalarla çalışmaktan vazgeçer.
18.4. Devreye Alma
Projelerin devreye alınma noktasına gelip gelmediğinin tespit edilmesi zordur.
Kullanıcı, genellikle isteklerinin bitip bitmediğinden tam olarak emin olamaz. Bazı kullanıcılar da eğer proje devreye alınırsa yeni istek yapamayacaklarından çekinerek projeyi sürekli uzatabilir. Devreye alma tarihi bir türlü gelmez.
Sürekli yeni isteklerle uzayan projeler için çözüm, kabul edilebilir olgunuğa erişen projeyi devreye almaktır. Bu çözüm devereye almayı yeni isteklerin engellediği ortamlarda etkindir. Devreyi almayı hata ve eksiklikler engelliyorsa önce bunlar giderilmelidir. Hataları çözmeden projeyi devreye almanın sonu hüsrandır.
Devreye alma proje için milattır. Tüm bakış açılar değişir. Son kullanıcı ve müşteri, yeni soyut istekler yerine öncelikle hatalara ve sonrasında kullanım kolaylığı sağlayacak alanlara yoğunlaşır. Yazılım firmasının üst yöntemi de artık kendi yazılım ekibiyle değil hizmet verdiği kurumdaki kullanıcıyla muhatap olmaya başlar. Böylece yazılım ekinde idari kademelerden gelen afaki talepler de azalır.
Proje Kapsamı Sürekli Değişiyorsa
Proje kapsamı sürekli değişiyorsa, projeyi hemen devreye almak gerekir. Kapsamı tartışmadan, müşterinin tüm istekleri alıp, müşteriden bunları yapana kadar yeni istekte bulunmayacağı bir zaman aralığı istenmelidir. Proje devreye girince kullanıcılar birçok istekten feragat edecektir. Tabi istekler her şeye rağmen hiç kesilmiyorsa oturup ağlamak da iyi bir alternatif olabilir!
Proje Eğitimleri Yerine Doğrudan Devreye Alma
Kurumsal projelerde eğitimden verim alınamıyorsa, proje doğrudan devreye alınabilir. Kullanıcılar bir haftalık eğitimde öğrenemedikleri bilgileri, proje devreye alındığında birkaç saate kavrayacaktır. bu durumda kullanıcılar yerinde eğitim(!) sırasında, gerçek sistemde yaptıkları hatalı kayıtrları temizlemek için ek işlemler gerekir.
18.5 Planlamaya Önem Vermeyen Üst Yönetim
İhtiyaç analizi ve planma olmadan, yazılım gelişmek mümkün değildir. Hemen bir şeyler görmek isteyen üst yönetimi talebi, yazılım ekibini buna zorlayabilir. Çözüm için asıl olan samimiyet ve karşılıklı güvenin tesis edilmesidir. Üst yönetime olması gereken teknik özellikler ve izlenmesi gereken yöntem ayrıntılı gerekçelerle açıkça anlatılmalı, hayalci ver aşırı beklentiler önlenmeye çalışılmalıdır
Planlamak ve Mevcut Durumu İyi Bilmek
Üst yönetime açıklanmasa da plan ve tahminler mevcut durumu yansıtmalıdır. Bazı ekipler sadece üst yönetimin taleplerine yoğunlaşır ve üst yönetim talep etmediği sürece plan yapmaz. Bu yaklaşım, projede önemli bir sorun ortaya çıkana kadar geçici bir rahatlama sağlar. Ancak neredeyse her proje sorun çıkar. Yazılım ekibi sorunun neden çıktığını izah edecek ön hazırlığı yapmadığı için sorumluluk üstüne kalır ve sadece kendisine söylenenleri yapmasına rağmen neden suçlandığını da çözemez.
Üst Yönetimi Eğitmek
Planlama, analiz ve tasarımın önemi konusunda üst yönetim eğitilmelidir. Benzer proje ve önemli yazılım şirketlerinin çalışma şekillerinden verilecek örneklerle zengin bir eğitim programı hazırlanmalıdır. Gerekirse mizahi öğelere de yer veren, kısa süreli, görsel ve sıkıcı olmayan sunumlar bilgilendirme için idealdir.
Ekip Olarak Hareket Etmek
Plansızlığı başta proje yöneticisi, ekibin tüm üyeleri kabul etmemelidir. Üst yönetim proje yöneticisini plana ikna edemediği durumlarda, genellikle ekibin işini kendi dağıtmaya başlar. Bu işleri ekibin bir kısmı kabul eder, bir kısmı çekincelerini belirtir, bir kısmı ise reddeder.
Genellikle pasif ve sessiz bir ret şekli tercih edilir. Reddeden kişiler de yine kendilerine verilen işleri istemeye istemeye yapmaya çalışır. Proje, ekip yapısı paramparça olumsuz noktalar konusunda ortak hareket etmelidir. Teknik olarak yapılması mümkün olmayan istekler hakkında uygun dille üst yönetim bilgilendirmelidir.
Kısmen Geliştirip Planlamaya Zaman Ayırmaya Çalışmak
Proje ekibi üst yönetimin söylediklerini uygularmış gibi yaparken kendi teknik ihtiyaçlarına zaman ayırabilir. Bu genellikle başarısız bir yöntemdir. Ancak üst yönetimin projesiyle fazla ilgilenme vakti yoksa uygulanabilir. Örneğin üst yönetim desteği olmadan tekrar kullanılabilir altyapılar geliştirmek çok zordur. Çünkü bunlara zaman ayırmak gerekir ve dolayısıyla çalışan ürünün ortaya çıkışı gecikebilir. Üst de yarım kalacaktır. Zaman alan bu tür işler, üst yönetimin bilgisi dahilinde ayrı projeler olarak yürütülmelidir.
Yazılım Araçları Kullanmak
Teknik gösterilimler bazen çok ikna edici olabilir. Üst yönetimi ikna için yazılım araçları kullanılarak oluşturulan kişiler üzerindeki iş yoğunluğu grafiği, tahmin çıkıntısı ve benzer projeler yapılan benzetimler kullanılabilir.
Teknik gösterimden kastedilen, meseleyi daha iyi anlatmak için teknik araçların çıktılarından istifade etmenin önemlidir. Yoksa müşteri ve üst yönetimi yanıltmak için karmaşık teknik gerekçe ve raporlar gösterilmesi asla önerilmez!
18.6. Büyük Hedefleri Mevcudu Analiz Ederek Koymak
Projelerin çoğunun çıkış noktası mevcut ortamı iyileştirmektir. Ancak bu yapılırken öncelikle mevcut ortamı doğru tespit etmek gerekir. Projelerin başarısını büyük göstermek için mevcudu kötü göstermek, en büyük hatalardan birisidir. Çünkü bu durum, kurumun veya ürünün mevcut potansiyelini, mevcut verilerini ve çalışma şeklini anlamayı zorlaştırmakta hatta imkansız hale getirmektedir.
Yazılımlar kurumsal süreçleri kolaylaştıran ve hızlandıran yardımcı araçlardır. Her araç gibi etkinlikleri kendilerini kullanan kişilere bağlıdır. Bu yüzden kurumsal otomasyon projelerinden yalnız başına kurumu dönüştürmesi veya kurumu sıfırdan inşa etmesi beklenmemelidir. Bu sistemler sadece çalışma sisteminde önemli iyileşmelere yardım edebilir. Yazılım sistemlerini tedarik etmek yanında kurumun çalışma sisteminde iyileştirme yapacak idari kararlar da alınmalıdır.
18.7. Ekibe Uygun Yazılım Geliştirme Ortamı Seçmek
Proje yöneticisi ve hatta bilgi işlem idari yöneticisi istedikleri uzmanlık ve sayıda kişiyi seçme yetkisine nadiren sahiptir. Yazılım teknolojisine göre ekip temin edilemiyorsa, ekibin yapısına göre teknoloji seçilmelidir.
Hızlı uygulama gelişitirme araçları rutin işleri hızla yapmayı sağlayan ve birçok yazılım ekibi için uygun geliştirme ortamlarıdır. Altyapı ile uğraşmak yerine veri ve fonksiyonel modelden hızlıca ekranlar oluşturulur. Böylece analizi ve tasarım kolaylaşır. Proje ekibi bu ürünleri kullanarak hızlıca prototip de hazırlayabilir
Hazır Standartlar
Ekibin tecrübesi çok fazla değilse, standart belirleme, sadece teknik bilgi sahibi yöneticilerin başlattığı teorik bir tartışma olarak kalabilmektedir. Bu yüzden karmaşık standartlar yerine daha basit ve kısa standartlar oluşturulmalıdır. Örneğin milletlerarası kabul görmüş bir kodlama standardı basitleştirilip, kısa zamanda kuruma uyarlanabilir. Standart belirlemek de bir projedir ve fayda maliyet analizi yapılarak uygulanmalıdır.
18.8. Öğrenerek Yapmak Yerine Yaparak Öğrenme
Teknoloji yüzeyde o kadar hızlı değişiyor ki yazılım ekipleri her gün yeni bir şeyler öğrenmek zorunda kalıyor. Yani projeler yeni teknoloji ihtiyaçlarıyla birlikte geliyor. Öğrenmek için zaman harcamak güçleşiyor. Bu duruma çözüm olarak özellikle yeni teknoloji projelerinde bir ön araştırmadan sorna hemen çalışmalara başlamak tavsiye edilebilir. Ayrıntı ilerleyen süreçte öğrenilebilir.
Yaparak öğrenmek temel bilgilerin çok sağlam olmasını gerektirir. Bu yöntemi uygulayabilmek için ekin yazılım geliştirme kültürü, analiz ve tasarım yeteneği üst düzeyde olmalıdır. Ne yapacağını bilen bir kişi için nasıl yapacağını yani yazılım geliştirme aracını öğrenmek çok zor olmayacaktır. Yeni bi araçla yapılan ilk işlerde genellikle tecrübe eksikliği olur. Bu işlerin uzmanla birlikte yapılması en azından kontrolünden geçmesi uygun olacaktır.
18.9. Büyük Proje, Başarılı Proje
Süre ve planlanan özellikler gibi konularda sıkıntı yaşanmasına rağmen devreye alınan büyük yazılım projeleri vardır. Bu tür projelerde taraflar, en azında bir değerlendirme yaparak olumsuz kısımları ele almalı ve kendilerini geliştirme fırsatını kaçırmamalıdır. “Nasıl olsa bitti, başarılar” anlayışı projeden ders çıkarmayı önler.
İlk anda 12 ayda bitirilecek şekilde planlanan bir kurumsal otomasyon projesi düşünülsün. Bu proje 20 ayda bitsin. Projenin tarafları bu süre uzamasını göz ardı edip “Kuruma büyük bir otomasyon projesi” kazandırdık diyebilir. Elbette önemli bir otomasyonun kuruma kazandırılması bir başarıdır. Ancak projenin süresinin uzaması bu başarıyı gölgeler
18.10. Moda Yöntemler ve Mucize Çözümler
Yazılım geliştirme alanında başarı; nesne tabanlı tasarım, süreç iyileştirme, süreç odaklı yönetim, 6 Sigma ve yalın yönetim gibi birçok yöntemden bekleniyor. Ancak bu yöntemleri uygulamak her zaman başarıyı garanti etmez. Bir yöntem ancak üzerine her yönüyle ayrıntılı düşünüldüğü, şirket kültürüne dahil edildiği, kuruma özelleştirdiği ve uygulamada dikkatli kullanıldığı takdirde fayda sağlar. Bu fayda da ayrıntılı bir analiz ve değerlendirme neticesinde anlaşılır
Senaryo: Faydasız Yöntem Değişikleri
Proje analizin ve planlanma sürceininde önemli eksiklikler olan bir yazılım şirketinde genel müdür çalışanları toplantıda bir araya getirir.
“Bundan sonra proje geliştirme yöntemi olarak çevik yöntemleri kullanacağız. Bu konunun sorumlusu da yine mevcut proje yöneticisidir.” şeklinde bir açıklama yapar. Başarı, sadece yöntem değişiminden beklendiğinden olanma ve analiz eksikliği olduğu gibi kalır. Oysa çevik yöntemde de yineleme ve artımları özellikleri belirlenmelidir.
Söylemeye bile gerek yok ama elbette hiçbir şey değişmez ve proje başarısız olur!
Mühendislik projeleri, bilimsel hakikatlerden yola çıkarak sosyal hayata ve iş hayatına yönelik faydalı uygulamalar geliştirmeye dayanır. Bu açıdan bakıldığında herhangi bir yöntemi mevcut yapı, uygulama şekli ve sağlanacak pratik yararlar üzerine düşünmeden bir şirkette körü körüne uygulanmaya çalışılmasının başarı şansı yoktur.
Yazılım geliştirmede mucize yöntem yoktur. Önümüzdeki on yıllarda da olmayacaktır.
18.11. Özet
Yazılım geliştirme ekibi projeye geliştirme sürecinde çeşitli imkansızlık ve belirsizliklerle karşılaşabilir. Diğer mühendislik dallarına göre neticelerin görünmesinin zorluğu ve değişikliklerin daha kolay yapılabileceğinin farz edilmesi, sorunların altında yatan temel sebeptir. Bu sorunların etkilerini tamamen ortadan kaldırmak zor olsa da azaltmak ve projeyi başarıyla tamamlamak mümkündür
Proje ekibinde için en az geliştirici, analist ve yönetici bulunmalıdır. Projede en az plan ve analiz belgesi olmalıdır. Planlama belgesinde kişilerin yapacakları ve süre tahminleri bulunmalıdır. Analiz belgesi de kapsamı belirlemelidir.
Çözümler yazılmıyorsa, sorun ve istekler kaydedilmelidir.
Proje başarısız olabilir. Bu kabullenilmelidir. Projeden vazgeçme de bir plan dahilinde gerçekleştirilmelidir. Başarı kısımlara odaklanmak kısmen de olsa projeyi kurtarabilir. Plansız projelerin başarılı olması istisna kabul edilmeli ve kesinlikle örnek alınmamalıdır. Ürün sağlıklı çalışmıyorsa yeni yerlere kurulmamalıdır.
Proje kalitesine zaman ayrılması üst yönetim desteğine bağlıdır. Proje ekibi üst yönetimi bilgilendirerek kalite için gerekli zaman ve kaynağın teminine çalışmalıdır. Çok kısa süreli bir planı kabul etmek, kaliteden ödün vermektir.
Büyük hedefler mevcut durumu analiz ettikten sonra konulmalıdır. Yazılım ekibinin yapısı değiştirilemiyorsa proje ve teknoloji seçimi ekibe göre yapılabilir. Biten her proje başarılı kabul edilmemeli ve tüm projelerin başarılı-sorunlu yönleri değerlendirilmelidir.
Yazılım geliştirmede mucize yöntemler yoktur! Popüler yöntemler başarıyı garanti edemez. yöntemin ismi değil kurumda uygulanma şekli ve etkinliği önemlidir.