Bütçeyi artırarak bir projenin başarılı olmasını nasıl sağlarsınız?
Bu yüzden bu Cevabı okuyordum ve aklıma bir süredir beklediğim ama sormaya hiç fırsat bulamadığım bir soruyu getirdi.
Sabit kapsamı, programı ve kalitesi olan geç bir projeniz varsa, bütçenizi artırarak bunu düzeltebilmeniz gerekir, ancak ... nasıl?
Kapsamı kaldırmanın veya zamanlamayı artırmanın başarısız bir projeyi nasıl kurtaracağı açıktır. Ancak The Mythical Man-Month'a göre (ve kendi deneyimlerime göre), çoktan geç kalmış bir projeye insanları eklemek projeyi daha da ileriye taşıyacak.
Öyleyse ... sabit bir kapsam / zamanlama / kalite projesini kaydetmek için sonsuz para tam olarak nasıl kullanılabilir?
Yanıtlar
Cevap, bireysel projeye özgü olacaktır. Wallace'ın proje yönetimi yasası, Proje Yöneticisinin birincil görevi, paydaşları Kapsam, Zamanlama ve Kalite üzerindeki herhangi bir değişikliğin etkisi hakkında bilgilendirmektir.
Sorunuz anlayışlı - bir PM işe almalarının nedeni budur. İyi bir Başbakan'ın her zaman bir yanıtı olacaktır "Size fazladan% N'lik bir bütçe verseydim, bunu nasıl harcardınız? Ek parayla kapsamı, programı veya kaliteyi nasıl iyileştirirsiniz?"
Cevaplardan bazıları proje planınızda - kritik zinciri ve proje planındaki alternatif kritik yolları hesapladınız - bu alternatiflerden hangisi ek bütçe ile daha makul?
Cevaplardan bazıları, daha önce geliştirdiğiniz diğer sorularda. Kısıtlamalarınız neler? Bütçe artırılırsa değişecek olan bütçe seçimleri nedeniyle hangi seçimleri yapmak zorunda kaldınız?
cevabın çoğu risk / sorun günlüğünüzdedir. Ek bütçeniz olsaydı hangi riskler / sorunlar fırsatlar olabilirdi?
küçük kelime oyunu; bütçe bir projenin başarılı olmasını sağlayamaz. Sonsuz bütçe, sonsuz bir başarı olasılığı yaratmaz. Bütçe bir kısıtlamadır ve projenin başarı olasılığı her zaman en çok en kısıtlayıcı kısıtlamayla belirlenir. Bütçe sonsuzsa, kapsam veya program projeyi yönetecektir. Benzin deposu boşsa araba gidemez, ancak benzin deposu aşırı doldurulursa daha hızlı gitmez. Bütçe projeyi kısıtlayacak kadar düşükse, bütçe artışının başarı olasılığını nasıl artıracağını tahmin etmek kolaydır; bütçe yeterince yüksekse, ek bütçenin proje başarısını nasıl etkileyeceğini tahmin etmek zordur. Sorunun ifade şekli, gerçek konulardan biraz uzaklaşıyor. "Bütçeyi yükselterek bir projenin başarılı olmasını nasıl sağlarsınız?" Yapamayacağınız zamanın 2 / 3'ü - çünkü proje bütçeyle sınırlı değildir. Ancak bu, sorunun ifade edilmesiyle ilgili bir kelime oyunu.
Sınırsız Kısıtlama Olarak Bütçe
Batık bir maliyetle para atmak, başarısız bir projeyi "kurtarmaz", ancak diğer proje kısıtlamalarınızı karşılamak için yeterli kaynakları tahsis etmezseniz, o zaman bir proje ilk etapta başarılı olamaz. Örneğin, yedi kişi alan bir süreci yöneten üç geliştiriciniz varsa, projenin zamanında bitmesi olası değildir. Projenin piyasaya sürülmesinden bir hafta önce dört geliştiricinin daha eklenmesi yardımcı olmayacaktır ( Brooks Yasasına bakınız ), ancak son sorumlu anda yeterli kaynak eklemek - ekipmanı, süreçleri ve personeli hızlandırmak için zaman tanımak - zaman veya kapsam kısıtlamalarını karşılayan bir proje.
Bütçeyi önceden doğru boyutlandırmanız daha iyidir. Daha büyük bir bütçe, iyi insanlara, çerçeveye ve beceri eğitimine, verimliliği artıran araçlara, daha yüksek kaliteli malzeme ve ekipmanlara vb. Yatırım yapmanıza olanak tanır. Bir projeye yetersiz finansman sağlanması bir kısıtlama yaratır, ancak bir bütçe (tek başına) genellikle yeterli değildir. etkinleştirici.
Aşağıdaki örneği düşünün:
- Projenin şu andan itibaren 6 aylık zorlu bir son teslim tarihi olduğu göz önüne alındığında (sabit program),
- Ve pazarlık konusu olmayan (sabit kapsam) bir özellik seti,
- Ne zaman proje planlanmıştır
- Daha sonra bütçe (maliyet) kapsam ve programa uyacak şekilde ayarlanmalıdır.
Başka bir deyişle, birbirini etkileyen üç kaydırıcınız var. İkisinden fazlasını kilitleyemezsiniz, örneğin "Hız, maliyet veya özellikler; herhangi ikisini seçin!" Diğer kaydırıcılarınız ne kadar kısıtlıysa, sınırsız boyutta ihtiyacınız olan esneklik o kadar artar.
Eğer varsa yok sabit koşe gereksinimlerini karşılamak için bütçe köşe noktasını ayarlamak, bir ile bitirmek değil üçgeni-Sık sık bir fonlanmayan (veya underfunded) Yönetim hedefi ile bitirmek. Bu gerçekleştiğinde, proje vizyonunuzu hemen şu şekilde gözden geçirmelisiniz: "Büyülü düşünme yoluyla başarısızlık yaratıyoruz."
Maliyet, kapsam, zaman şeklindeki demir üçgeni, yalnızca ikisini seçin , proje kısıtlamalarının bir modelidir. Bu iyi bir model, ancak bazen diğer ikisini sabit tutarken yalnızca bir boyutta çalışabileceğini düşünen insanların kafasını karıştırır. Projenin zamanı ve kapsamı, hiçbir paranın onları karşılayamayacağı kadar kısıtlıysa, projeniz bütçeyi artırarak başarılı olmaz. Yarın öğleden sonraya kadar aya başka bir adam koymanız için size bir katrilyon trilyon dolar verirsem, bunu yapamazsınız. Yazılım projelerinde de durum aynı.
Sorunlara çok geç para atarsanız veya ondan çok şey beklerseniz, yine de sorun yaşarsınız . Projeniz gecikirse ve çok geç para getirirseniz, projenizi kurtarmaz. Todd'un cevabı bunu çok iyi kapsıyor, bu yüzden daha fazla ısrar etmeyeceğim. Yine de belirtmek istediğim şey, paranın bir kolaylaştırıcı olduğu gerçeğidir . "Düzeltilen" şeyler artık birden bire düzeltilemeyebilir.
Örneğin, projenizin bir uygulamayı küçük sanal makinelerde verimli bir şekilde çalışacak şekilde optimize etmek, donanım kaynaklarını verimli bir şekilde kullanmak, böylece bulut maliyetlerini düşük tutmak ve gelecekte daha verimli yatay taramaya izin vermek olduğunu varsayalım. Yapılması gereken işi belirlediniz ve bunu yapmak için iki ayınız var (herhangi bir nedenle). Bir ay sonra ekip, büyük olasılıkla son teslim tarihini kaçıracağını anlar. Kapsamı daraltamazlar çünkü burada tanımlanan her şey, her şeyin çalışması için gereklidir. Ve son teslim tarihini değiştiremezler çünkü bu sabittir. Yani parayı getiriyorsun. Onun çoğu.
Daha fazla insan getirebilirsiniz, ancak bunu yaparak Brooks yasasının geçerli olduğunu keşfedersiniz ve şimdi takım daha da geç olacağını düşünüyor. Ancak zaman ve kapsam hala sabittir. Yoksa onlar mı?
Parayı alır ve bulabileceğiniz en büyük sanal makinelere koyarsanız, bulabildiğiniz kadar çok, projenin kapsamıyla artık ilgilenmezsiniz. Sabit kapsamınız aniden tamamen kaybolur. Sonuçta o kadar da düzeltilmedi. Uygulamanız artık bulutta bir kaynak olabilir ve faturaları ödeyecek paranız olduğu için umursamıyorsunuz.
Sonuç olarak :
- bu üç kısıtlama değil, sadece ikisini seçin. Aslında bu hepsinin dengesidir ve birindeki değişiklikler diğerlerini başka bir şekilde etkiler.
- Bütçe artışı projenizi kurtarabilir, ancak yalnızca doğru zamanda ve doğru şeylere uygulanırsa .
Kapsam, Zamanlama ve Kalite projenin "Ne" sunması gerektiğini tanımlar, ancak "Nasıl" sunacağını tanımlamazlar. Diğer yanıtlarda belirtildiği gibi, daha fazla bütçe "Nasıl" ın esnetilmesine izin verebilir. Aklımda, "Altın Üçgen" i daha çok bir "Altın Piramit" gibi görüyorum, burada temel üçgenin "Maliyet, Zaman, Kapsam" kısıtlamalarından oluştuğu ve piramidin yüksekliğinin "Kaliteyi" tanımladığı. Dolayısıyla dördü de birbiriyle bağlantılıdır.
Bir projeye ayrım gözetmeksizin kaynak atmanın nadiren etkili olduğu doğrudur, ancak zamanlama doğruysa, daha fazla kaynak bir projeyi zamanında ve kaliteli hale getirebilir. Nasıl? - Pekala, tek bir doğru cevap yoktur, ancak projeyi daha yönetilebilir parçalara ayırmak ve doğru kaynakları projenin doğru öğelerine tahsis etmek, genellikle projeyi bunları barındıracak şekilde yeniden yapılandırmadan daha fazla geliştiriciyi karışıma atmaktan daha iyi olacaktır.
Alternatif olarak, daha fazla fon tamamen farklı bir yaklaşıma da izin verebilir. Örneğin, pahalı ancak ticari olarak mevcut bir çözümü satın alma maliyetinden kaçınmak için şirket içinde bir çözüm oluşturmak yerine, fazladan para bu kararı değiştirebilir. Yine de beklenen sonucu sağlayacaksınız - ancak çözümü oluşturmak yerine satın alacaksınız. Ancak bir kez daha, projede çok geç beklerseniz başarısız olursunuz.
Demek istediğim, sorunları yeterince erken tespit ederseniz, projeyi gerçekleştirmek için daha etkili bir şekilde para harcamak için adımlar atabilirsiniz. Anahtar bu: zamanlama her şeydir. Parmaklarınızı çaprazlamak ve olmayacağı netleşene kadar "gece iyi olacağını" ummak, felaket için bir reçetedir. Doğru proje yönetimi, izleme, izleme, risk analizi, planlama ve proje sponsorunuzla yapılan görüşmeler her zaman kar payı ödeyecek ve sorunları mümkün olan en erken noktada belirleyip ardından gerekli parayı harcayarak etkili olacak kadar erken değişiklikler yapmanıza olanak sağlayacaktır. (veya yaklaşımınızın diğer yönlerini değiştirmek) ortaya çıkan sorunları ele almak için.
Evet, "nasıl para toplanır" sorusuna evrensel bir cevaba sahip olmak harika olurdu :) Ama seçim yapmak zorunda kalırsanız, bence çoğu zaman yüksek kaliteli vuruşlar zamanında oluyor.
Elbette, çoğu zaman programın gerisindeyiz ve yukarıdan biri baskı yapmaya başlıyor ve pes edip hızlanıyoruz. Ama kötü bir ürünle sonuçlanırsak, her zaman (!) Kötü programcılar olarak hatırlanacağız. İnsanların yıllar önce biten ürünlerin kalitesinden şikayet ettiğini duydum - kullanıcılar hala bu geliştiricilerden nefret ediyorlar çünkü uygunsuz araçlar kullanmaya devam ediyorlar (gerçekte geliştiriciler fena değildi).
Aynı zamanda , bazı önemli özellikleri bitirmezsek - bir süre köpek evinde olacağız, ancak o zaman projenin iş talepleri nedeniyle daha fazla finanse edilmesi mümkündür .
Ancak çok fazla sorunu olan bir projeye katıldıysanız - büyük olasılıkla bazı sorunları çözebilir ve hızlandırabilirsiniz.
Brooks Yasasına inanıyorum, ancak projelerin% 100'ünde% 100 doğru% 100 olduğu fikrine katılmıyorum. Farklı görevler, sonuçları etkileyen bir dizi bilinen ve bilinmeyen değişkene bağlı olarak, mevcut çalışma malzemelerine bağlı olarak, göreve bağlı olarak, göreve bağlı olarak hem zamanlama hem de kalitede farklı sonuçlara sahip olacak şekilde farklı görevlerin kaynak esnekliği derecelerine sahiptir.
Bu yüzden, bence sonsuz bir bütçe, eğer böyle bir şey gerçek olsaydı, belirli türdeki temel neden sorunları için bazı projelerde, bazı projelerde zamanlama veya kalite sorunları ile karşılaşan bir sorun projesini olumlu etkileyebilir ve etkileyebilirdi. Bunun bir proje yöneticisi ve ekibin vaka bazında değerlendirmesi gereken bir şey olduğuna inanıyorum ve sonuçlarımızı etkileyen diğer rastgele değişkenlerle bazen kazanıp, başka zamanlarda kaybedeceğinizi düşünüyorum.
Cevabımın belirsiz ve belirsiz olduğunu hissediyorum; ancak, karmaşık ortamlarda karmaşık insanlarla ilgilenen karmaşık projelerin de aynı derecede belirsiz ve belirsiz olduğunu düşünüyorum. Analiz, yenilik, deneyler ve risk almayı gerektirir.