Neden Ekip Olamıyoruz?
Proje Örneği – Gereksinim İzlenebilirlik Matrisi ve Kapsam Yönetimi
Organizasyon: Veri yönetimi firması
Sektör: BT
Sorun: Kapsam kayması herhangi bir projede büyük tehdit olabilir ve belirli bir özelliğin neden bu kadar uzun sürdüğünü anlayamayan paydaşlar için belirsizlikler sinir bozucu olabilir. Projeyi kapsam dahilinde tutmak ve paydaşları bilgilendirmek için proje yöneticisinin izlenebilirliği şeffaflaştırması gerekir.
Arka plan: Bir veri yönetimi firmasındaki satış ekibi, mevcut veya potansiyel müşterilerle buluşurken mevcut ürünleri sergilemek için etkin bir çözümden yoksundu. Bu nedenle, departman liderleri, satış toplantılarında ürünlerin teşhir edilmesini kolaylaştıracak bir web ve mobil çözüm talep etti.
Nasıl Çözüldü: Gereksinim başlangıç toplantısında, proje lideri olarak görev yapan Bay Viswanadha, gereksinimleri ortaya çıkarmak için bir soru listesi paylaştı. Daha sonra yanıtları düzenledi ve listeyi bir elektronik tabloda önceliklendirdi. Bay Viswanadha, “Gereksinimlerin izlenmesine yönelik beklentileri belirlemek için WBS kodunu gereksinimlere göre ilişkilendirdim” diyor.
İkinci izlenebilirlik düzeyi için, proje görev kimliklerini gereksinimlere göre eşleştirdi. Ve üçüncü seviye için, kaynak adları da aynı şekilde gereksinimlerle eşleştirildi. Bay Viswanadha, bu ayrıntılı belgeyi tüm paydaşların başvurabileceği hale getirmek için ortak bir klasörde paylaştığını belirtiyor. Bu belgeye nasıl ulaşılacağını, nasıl güncelleneceğini ve nasıl okunması gerektiğine dair de paydaşlara bilgi aktardığını vurguluyor, Bay Viswanadha.
Sonuç: “Bu süreç, kapsam kaymasını en aza indirmeyi ve sağlanan değeri daha doğru bir şekilde müşteriye iletmeyi kolaylaştırdı,” diyor Bay Viswanadha. Gereksinim izlenebilirlik matrisi ile paydaşların kafasını karıştırmadan ve şeffaflık ile proje ile üretilen değerin daha iyi hissedildiği bir projeyi bitirdiklerini vurguluyor.
Alınan Dersler: NetApp, Sunnyvale, NetApp, Uygulama Güvenliği Mimarı Bhanu Viswanadha, “Gereksinim İzlenebilirlik Matrisi, inanılmaz derecede değerli olabilir, ancak paydaşları bu belgeyi nasıl görüntüleyecekleri ve okuyacakları konusunda eğittiğinizden emin olmanız gerekir” diyor.
Kaynak: PMIStandard+
Proje Örneği – Meraklı ve Şüpheci Olmak
Organizasyon: Superintendencia de Banca
Sektör: Devlet
Arka plan:
Peru’daki finans kuruluşları, her gün, kredi kartı başvuruları ve kredi işlemleri de dahil olmak üzere, merkezi bir devlet dairesine ayrıntılı bir işlem raporu gönderir. Ofis, bu verileri faiz oranları ve ekonomik raporlar hakkındaki kararları oluşturmak için kullanır. Emek yoğun bu iş, bir finans uzmanının gününün dört saatini kolayca alabilir. Departman yöneticisi ekibini bu görevden kurtarmak istiyordu.
Sorun: Eski süreç, günlük elektronik tablolar oluşturmak için bir istemci-sunucu uygulamasının çalıştırılmasını içeriyordu. Finansal analistler daha sonra daha fazla elektronik tablo oluşturarak karşılaştırmalı hesaplamalar yapmaktaydı. Çok fazla manuel işlem vardı ve hata yapma olasılığı çok fazlaydı. Ve işlemler en az bir kişinin fiziksel olarak ofisteyken yapılabildiğinden, bir çalışanın günlük raporu oluşturmak için genellikle geç saatlere kadar kalması gerekiyordu.
Departman yöneticisinin aklında tek bir soru vardı: Manuel veri girişi ve elle tablo oluşturma yöntemini otomatikleştirmek mümkün müydü?
Proje yöneticisi Bay Jimenez, müşterinin bu ihtiyacını dinledikten sonra şöyle diyor, “Gerekli iyileştirmeler olarak tanımladığı şeyi kabul etseydim, ekibin gerçek sorununu çözemezdim.”
Nasıl Çözüldü:
Proje Yöneticisi Bay Jimenez, talebi açık bir görev olarak almak yerine, hangi çözümün takıma en iyi şekilde hizmet edeceğini bulmak için tam bir ihtiyaç değerlendirmesi yaptı. Sorun noktalarını ortaya çıkarmak için departman yöneticisi ve ekip üyeleriyle görüştü ama sonrasında daha fazla öngörü toplamak için pasif bir gözlem tekniğine karar verdi. Tüm çalışma yapısını anlamak için süreçleri videolara kaydetti ve ardından videoları kapsamlı bir şekilde ekibiyle inceledi.
Sonunda, müşteri birimin müdürü ve kilit kullanıcılarla bir toplantı ayarladı. Bay Jimenez, mevcut sürecin en yoğun zaman alan unsurlarını çıkarmak yerine, tüm veri raporlama sürecini kapsayacak bir web uygulaması oluşturmayı önerdi. “Uzak istemci-sunucu uygulamasından, makrolardan, elektronik tablolardan ve eski rapor yayıncısından kurtulacak ve bunun yerine tek, kullanıcı dostu bir sistem oluşturacaktı.
Sonuç:
Departman yöneticisi, daha geniş bir çözüm önerisinin amacını anladı ve projeye başlandı. Web tabanlı uygulama, raporlama görevi için harcanan süreyi dört saatten 30 dakikaya indirdi. Yeni uygulama ile uzaktan çalışma, raporların otomatik oluşturulması, bunlara uzaktan ve mobil erişmek mümkün oldu. Bu da, ekibin operasyonel görevler yerine, analitik görevlere odaklanmalarına olanak tanıdı.
Alınan Dersler:
Superintendencia de Banca, Proje Yöneticisi Nestor Jimenez, “İlk fikri körü körüne kabul ederseniz, esas sorununu çözemeyebilirsiniz” diyor ve ekliyor “Meraklı ve şüpheci olmak çok önemlidir. Unutmayın, proje yöneticisinin sorumluluğu farklı bakış açılarının temsilcisi olarak hareket etmektir.”
Kaynak: PMI Standart +










