Proje Değişimini Yönetmek
Proje Değişimini Yönetmek
Çoğu yazılım geliştirme projesi, geliştirmeleri sırasında bir noktada değişimin yönetimini içerir. Değişiklik ihtiyacı, proje ortamından (örneğin, değişen gereksinimler) veya proje çalışma sisteminin kendisinden (örneğin, hastalık) veya proje çalışmasındaki ilerleme durumundan (örneğin, gecikmeler) kaynaklanır.
Değişimin nasıl yönetileceğine karar verilmeden önce cevaplanması gereken sorulardan bazıları, değişim ihtiyacının nedeni ile ilgilidir.
Örneğin, önerilen sorun bazı görevlerde yerel değişiklikle mi çözülüyor (yani geç kaldılar) yoksa tüm projeyi mi etkiliyor (yani tüm pmject geç kaldı)? Değişim ihtiyacı, belirli personelle ilgili motivasyon problemlerinden mi yoksa atandıkları görevlerde yer alan iş miktarı hakkında yapılan yanlış tahminlerden mi kaynaklanıyor?
Çoğu zaman, değişiklik ihtiyacı, projenin ilk planlandığı zamandaki proje hakkında bilgi eksikliğinin (örneğin, iyimser tahminler olarak ifade edilir) ve onu taşırken proje hakkındaki bilgi miktarındaki artışın doğal bir sonucudur.
İkinci durumda, yönetici, çeşitli kaynaklara ve görevlere uygulanabilir gerçek parametreler hakkında daha iyi bir fikre sahiptir (örneğin, bir ekip üyesi beklenenden daha az etkilidir, bazı görevler beklenenden daha kolay veya daha zor olmuştur).
Bu artan bilgiyi yansıtabilecek yeni, revize edilmiş bir plan, tanımı gereği, eldeki proje için daha gerçekçi olacaktır. Bununla birlikte, her yeni, revize edilmiş plana her zaman şu soru sorulmalıdır: “Bir önceki plan başarısız olurken veya başarısız olacakken bu planın başarılı olmasına neden olacak farklı şekilde ne yapılıyor?
Bununla birlikte, revize edilmiş bir plana geçmek, proje çalışma sistemi ve proje ortamının gerçekliğinde rahatsızlıklara neden olabilir. Gözden geçirilmiş bir planın ekibin çalışması üzerinde etkileri olması muhtemeldir ve bu nedenle ekip üyeleriyle kendilerine dağıtılacak görevlerdeki değişiklikler hakkında müzakere etmek gerekli olabilir.
Bu, yeni işe geçişle ilgili zorlukların, artık imkansız olan bir görev programı kurgusunu canlı tutmaya çalışmanın getirdiği zorluklardan daha az algılandığı durumlarda memnuniyetle karşılanabilir. Öte yandan, bir planı bir projenin mevcut gerçekliğine yaklaştırmak, gelecekteki kaynak gereksinimlerinin, kilometre taşlarının ve pratik olarak ulaşılabilir teslimatların zamanlamasında ve doğasında değişiklikler gerektirebilir.
Bu tür değişikliklerin, proje yöneticisinin acil sorumluluklarıyla ilgili olarak proje ortamında (müşterinin ve yüklenici kuruluşun dünyasında) yansımaları olması muhtemeldir. Bu nedenle, proje yöneticisi yeni planı tek başına çağırma ve projenin plana göre çalıştığını bildirme özgürlüğüne sahip değildir.
Değişim yönetimi aşamaları
Değişim yönetimi uygulamaları
Değişim Yönetimi modelleri
Değişim yönetimi Örnekleri
Değişim Yönetimi PDF
Değişim yönetimi Nedir
Galpin in değişim yönetimi süreç modelinin ilk aşaması Nedir
Galpin değişim Yönetimi süreç Modeli
Önerilen proje değişikliklerinin dış etkilerinin tahminleri öncelikle yapılmalı ve proje yöneticisinin raporlarına dahil edilmelidir. Bu değişikliklerin daha sonra, etkiledikleri paydaşlarla, genellikle proje yöneticisinin rapor verdiği yönetim seviyesinde (veya ciddi durumlarda daha da yüksek seviyelerde) müzakere edilmesi gerekir.
Bu değişikliklerin yansımaları büyük olduğunda, genellikle proje oluşturulurken başlangıçta dikkate alınan ve çözülen sorunlar, yeni proje planının uygulamalarının kabul edilip edilmeyeceğine karar verilirken yeniden ele alınmak zorunda kalabilir ve böylece proje yöneticisinin etkin olmasını sağlayabilir. sorumluluklarını yerine getirmeye devam etmektir.
Çoğu zaman, proje planındaki değişiklikler yerel değişikliklerdir. Yani, projenin yürütülmesi sırasında keşfedilen belirli bir sorunu çözmek veya hafifletmek amacıyla planın bazı bölümlerinde yapılırlar. Örneğin, belirli bir kaynağın, belirli bir görev üzerinde çalışmak için kendisine halihazırda tahsis edilen kaynaktan daha fazla gerekli bilgiye sahip olduğunu keşfettiğinde, yönetici kaynakları görevler arasında değiştirebilir.
Bu, genellikle proje yöneticisinin ayrıntılı planlamasında bir değişiklik teşkil eder, ancak bu değişiklik, genellikle makro planı üzerinde herhangi bir etkiye sahip değildir. Alternatif olarak, kaynakların diğer görevlerden kolayca elde edilebileceği yeni bir görevin plana dahil edilmesi gerekli görülebilir.
Yerel değişikliklerin müşteriye iletilmesine nadiren ihtiyaç duyulur, ancak bunlar genellikle yöneticinin üstlerine verdiği repolarda sunulur. Her halükarda, yerel değişikliklerin bile yerel düzeyde hafifletmeyi amaçladıkları sorunların yanı sıra bir bütün olarak proje için dikkate alınması gerekir.
Örneğin, bir kaynağın daha fazla bilgi sahibi olduğu bir görevde kullanılması, o görevdeki performansı artırabilir ancak yeniden tahsis nedeniyle kaynağın çekildiği görev için sorun yaratabilir.
Projeyi Sonlandırmak
Tipik olarak, bir yazılım geliştirme projesini kapatmak, ürünü müşteriye teslim etmeyi, kabul ettirmeyi, gelecekteki bakımı için düzenlemeyi ve proje ve sonuçları hakkında kendi organizasyonuna nihai raporlamayı içerir. Projeyle kazanılan deneyimden, bir şekilde dahil olan kişilerin zihninde henüz tazeyken yararlanmak iyi bir fikirdir.
Proje otopsileri, ekibin yazılım geliştirme sürecini ve uygulamalarını nasıl geliştirebileceklerini daha iyi anlamasını sağlamanın yanı sıra, yöneticinin proje yönetim sürecini ve kendi sürecini nasıl geliştireceğini daha iyi anlamasını sağlamada önemlidir. pratik. Bu nedenle, proje ekibine bilgi vermek, proje (örneğin plan) hakkındaki bilgileri arşivlemek ve projenin gelecekteki kullanımını tahmin etmek de arzu edilen proje kapanış yönetimi faaliyetleridir.
Bununla birlikte, tüm kuruluşlar bu tür faaliyetlerin proje yöneticilerinden istendiği konusunda ısrarcı değildir ve bu nedenle yöneticiler bunların ne kadar önemli olduğunu takdir etmelerine rağmen nadiren bunları gerçekleştirirler. Bunun ana nedeni, bu tür faaliyetler için bir finansman kaynağının olmamasıdır (kuruluşun kendisinin bu tür girişimleri finanse etme politikası yoksa).
Projeler, ürünün teslimatı ve kabulü dahil olmak üzere (sözleşmeye bakımı da dahil etmedikçe) müşteriye aittir; bu yapıldıktan sonra, proje yöneticisinin bu ekstra faaliyetleri yürütmek için ihtiyaç duyduğu zaman, projeye değil, yüklenicinin iç bütçesine yansıtılır.
Ayrıca, yazılım geliştirme projeleri pratikte geç kaldığından, yöneticinin projeler arasındaki boş zamanını tüketme eğilimindedir. Bu nedenle, belirli bir proje yöneticisi, bu tür faaliyetlere ayıracak zamanı olmadığı için, kapanış projesi bittiğinde bir sonraki projesi üzerinde çalışmaya başlamış olabilir.
Bununla birlikte, geçmiş projeler hakkında bilgi tutmak ve belirli bir projeden kazanılan deneyimden yararlanmak, kendi gelişimi üzerinde uzun vadeli bir perspektif benimseyen herhangi bir kuruluş için bir gereklilik olmalıdır.
Boşa harcanan potansiyel proje yönetimi zamanı yerine bir yatırım olarak görülmelidir. Bu tür bilgiler, kuruluşa başarılı projeler için gelecekteki ihaleler için güvenilir ve sağlam bir temel ve bir projeden diğerine değerli bilgilerin aktarılması için bir temel sağlayabilir.
Değişim yönetimi aşamaları Değişim yönetimi modelleri Değişim yönetimi Nedir Değişim yönetimi örnekleri Değişim Yönetimi PDF Değişim yönetimi uygulamaları Galpin değişim Yönetimi süreç Modeli Galpin in değişim yönetimi süreç modelinin ilk aşaması Nedir