Projeler, şirketlerin iş ihtiyaçlarının karşılanmasına ve hedeflere ulaşılmasına yol açan cevaplar sağlamak ve çözümler oluşturmak için kullandıkları temel bir araç olarak doğar. Bu nedenle bir proje, bir ihtiyacı karşılamak, bir iş hedefine ulaşılmasına katkıda bulunmak, bir tehdidi ortadan kaldırmak, bir fırsattan yararlanmak, bir zayıflığı güce dönüştürmek, becerileri geliştirmek, genişletmek için tanımlanan bir iş senaryosuyla ilişkilendirilmelidir. Ürünleriniz ve hizmetleriniz için pazarlar ve sonuçta daha yüksek satış ve kar anlamına gelen müşterilerinizin tercihini kazanır.
Ancak, atılan projeleri yürütmek için önemli finansal kaynaklara yatırım yapan veya ürünleri ve teslimatları uyarlamak için yeniden yapmak, uyarlamak ve yeniden çalışmak için birçok kaynak harcamak zorunda kalan kuruluşların hayal kırıklıklarını kaç kez duyduk ve okuduk. Söz konusu projelerin, formüle edildikleri Kullanıcıların iş ihtiyaçlarını ve beklentilerini karşılamaması nedeniyle.
Bu projelerin çoğu, ihtiyaçların tanımlanması ve doğrulanmasında, Paydaşların seçiminde ve KOBİ'nin (Konu-Konu Uzmanı) taahhüdünü ve katılımını sağlamada yeterince zaman harcamadıkları için baştan başarısız olmaya mahkum edilmiştir. Anket, gereksinimlerin tanımlanması ve doğrulanması sırasında temel parçaları oluşturan İngilizce kısaltması için).
KOBİ'lerin, kuruluşlarının işleri, süreçleri ve ürünleri konusunda yüksek düzeyde uzmanlığa, bilgiye ve ustalığa sahip çalışanlar olduklarını hatırlayalım. Benzer şekilde, Paydaşlar, projenin geliştirilmesiyle ilgisi olan kişiler, kullanıcılar veya kuruluşlar olarak tanımlanır.
Projenin uygulama aşaması başladıktan sonra ihtiyaçların eksikliklerini ve belirsizliklerini düzeltmek, yeniden çalışma, çözümlerin, ürünlerin ve teslimatların yeniden tasarlanmasını gerektirdiğinden son derece pahalıdır; Planın ve bütçede planlanmayan veya öngörülmeyen mali, insan ve zaman kaynaklarının tüketilmesine yol açan tüm proje belgelerinin güncellenmesi.
Şelale metodolojisine yönelik projelerde etki daha büyüktür çünkü Metodoloji Gereksinimlerin baştan açıkça tanımlandığını ve proje yarışmasına kadar sabit kaldığını varsayar ve proje başladığında değişiklikler kontrol edilir, azaltılır ve mümkün olduğunca önlenir. mümkün.
Bir Gereksinim, birçok nedenden dolayı belirsiz veya yetersiz tanımlanmış olabilir:
- Paydaşların yanlış tanımlanması, yani liste eksikti, hepsi değil, hepsi değil Paydaşların yeterlilik seviyesi, bilgi birikimi, organizasyonlarının iş süreçlerindeki ustalık uygun. Paydaşların projeyle uyum ve bağlılık eksikliği, çünkü kendi süreçleri veya organizasyonlarının yararının çok az veya neredeyse hiç olmadığını düşünüyorlar. Ait oldukları kuruluşun üyelerinin bağlılığını sağlamak için kuruluş üzerinde çok az etki. İş Analisti ve Gereksinim Analistinin Deneyimsizliği. Proje Müdürünün Geç AtanmasıBaşlatma sürecinde Proje Yönetmeliğinde adı ve yetkilendirilmesi gereken, İş Analisti (mevcut olduğu durumlarda) ve Gereksinim Analisti ile birlikte İş İnceleme Belgelerini inceleyebilecek şekilde, Projenin gerekçelendirme aşamasında gerçekleştirilen ve Planlama aşamasında girdi görevi görecek çözümün fizibilite analizi ve tanımı.
Bununla birlikte, daha önce bahsedilen tüm durumlarda, sorumluluk, gereksinimlerin doğru olduğundan emin olmak için özel dikkat göstermesi gereken Proje Yöneticisine aittir, proje ekibinin gereksinimleri onaylayan tek bir yorumu vardır. KOBİ'ler, Kullanıcılar ve Paydaşlar ve aralarındaki herhangi bir çatışmayı tespit etmek için çaprazlanmışlar ve eğer öyleyse, çatışmayı çözmek için diğer Paydaşlar ve KOBİ ile sorunu netleştirin.
Ek olarak, Proje Yöneticisi, proje tarafından üretilecek çözüm, ürün ve çıktılarda her bir gereksinimin tanımlanabilmesini sağlamalıdır. Yani, her bir gereksinimin ve onu içeren ürün veya çıktıların "izlenmesine" veya izlenmesine izin veren bir mekanizma vardır.
Agile veya Scrum metodolojisinde, bir gereksinimi (Kullanıcı Hikayeleri) değiştirmek veya yeniden tanımlamak daha kolaydır çünkü gereksinimlerin değişebileceğini, statik olmadıklarını, baştan iyi tanımlanmalarını gerektirmez, Sprint döngüleri daha fazladır. kısa (2 ila 4 hafta), her Sprint İş Listesi için birkaç gereksinim (Sprint'in sonuna kadar tam olarak uygulanabilecek tüm hikayeler) ve belirsiz bir gereksinim, Sprint planlama toplantısı sırasında (Sprint) sonraki bir Sprint için ertelenebilir Planlama Toplantısı).
Bununla birlikte, her iki metodolojide de Paydaşların ve KOBİ'lerin oynadığı rol hala esastır ve bunların yanlış tanımlanması ve düşük taahhütleri, kullanılan metodolojiden bağımsız olarak projelerin performansını etkileyebilir, çünkü daha basit görünse bile Gereksinimlerdeki belirsizlikleri çözmek için Çevik veya Scrum metodolojisi, Paydaşların ve KOBİ'nin gereksinimleri veya hikayeleri tanımlamak ve açıklığa kavuşturmak için gerekli zamanı, bilgiyi ve iş bilgisini sağlama taahhüdüne bağlı olacaktır; ve Ürün sahibinin (Proje Yöneticisi) organizasyon ve Paydaşlar üzerindeki etki düzeyi.
