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+

5.2.2.11 Belge Analizi

Gereksinim Toplama sürecinde kullanılsı önerilen araç ve tekniklerden birisidir. Kilit paydaşların ihtiyaçlarını belirlemek amacıyla ortaya çıkarılmış pek çok belge (doküman) gözden geçirilebilir.

Analiz edilebilecek belgelerden bazıları şunlardır:

  • iş planları,
  • pazarlama broşürleri,
  • antlaşmalar,
  • teklif talebi,
  • güncel süreç akışları,
  • mantıksal veri modelleri,
  • iş kuralları havuzu,
  • uygulama yazılımı dokümantasyonu,
  • iş süreci ya da ara yüz dokümantasyonu,
  • kullanım durumları,
  • diğer gereksinimlerin dokümantasyonu,
  • sorun kayıtları,
  • politikalar,
  • prosedürler ve
  • kanunlar, tüzükler, kurallar gibi düzenleyici dokümantasyon, vb.

Kapsamın Kontrolü – PMBOK

complete_puzzle_green1Kapsamın Kontrolü, proje ve ürün kapsamının durumunun izlenmesi ve kapsam temel çizgisi esas alınarak değişikliklerin yönetilmesi sürecidir.

İş Kırılım Yapısı ile ortaya çıkan kapsam temel çizgisi ile mevcut kapsam arasındaki farklar, Kapsamın Kontrolü süreci işletilerek, ortaya çıkarılır.

Kapsamda değişikliklerden dolayı projenin süresi uzamış veya maliyetleri değişmiş olabilir. Üst Yönetim, projenin süresinin veya maliyetinin neden artığını sorgulayacaktır; İşte bu noktada proje yöneticisi Kapsamın Kontrolü sürecini gerçekleştirerek, süre veya maliyet artış sebebini kapsamdaki hangi değişikliten dolayı gerçekleştiğini açık ve net olarak anlatabilecektir.

Bu sürecin sonunda İş Kırılım Yapısı ile mutabık kalınan kapsama göre nelerin değiştiği Proje Sponsoruna, Müşteriye veya Üst Yönetime raporlanır fakat rapor matematiksel içerğie sahip olmayacaktır. Sadece başta anlaşılan teslimatlara ek olarak nelerin girdiği veya nelerin çıkarıldığı üzerine bir rapor olacaktır.

Kapsam Kontrolü ile Kapsam Doğrulama süreçleri birbirinden çok farklıdır. PMP sınavında bu iki süreç arasındaki farklar da soru olarak gelebilmektedir.

Kapsamın Doğrulanması – PMBOK

verify-12Kapsamın Doğrulanması, tamamlanan proje teslimatlarının kabulünü resmileştirme sürecidir. Kapsamı doğrulamak, teslimatları müşteri ya da sponsorla birlikte gözden geçirmek ve müşteri ya da sponsor tarafından resmi kabulünün sağlanmasını içerir.

Kapsamın Doğrulanması, kalite kontrolünden sonra gerçekleştirlir.

Kapsamın doğrulanması birincil olarak teslimatların kabulüyle ilgiliyken, kalite kontrolü birincil olarak teslimatların doğruluğu ve teslimatlar için belirlenen kalite gereksinimlerinin karşılanmasıyla ilgilidir.

Kapsamın Doğrulanması ile bir aşamanın teslimatı ortaya çıkacak ve müşteri tarafından da kabul edilecektir. Bu yüzden, projenin ya da bir fazın kapanış süreçleri başlatılabilir. Eğer Kapsam Doğrulanması süreci olumsuz tamamlanırsa (müşteri ürünü kabul etmesse) bu durumda Entegre Değişiklik Kontrolü süreci başlayacak ve proje yönetim planları tekrar güncellenecektir.

Kapsamın Doğrulama sürecinin tek bir araç ve tekniği vardır: O da “Tetkik”‘tir (Gözden geçirme, adım adım doğrulama, denetim ifadeleri de aynı anlama gelmektedir.)

PMP sınavı için Kapsam Kontrolü, Kapsamın Doğrulanması ve Kalite Kontrolü süreçlerinin detayları hakkında zorlayıcı sorular çıkmaktadır. Bu üç sürecin detaylarını iyi anlamak gerekir.

Müşteri Projenin Başarısından Sorumlu mudur?

Müşteri, projedeki bütün sorumlulukları tamamen proje ekibine devrederek ve yeterince proje yönetimi süreçlerine dahil olmayarak, projenin başarısını riske atabilir.

İşte bu yazımda, müşteri durumunda olan paydaşların da proje yönetimi sürecindeki görevlerini ve tutumlarını ele almak istedim.

Projenin en başı (başlangıç süreci); Müşteri, proje yöneticisinden bir şey ister fakat ne istediğini aslında kendisi de tam bilmez, veya anlatamaz. İşte bu süreç en sancılı olan ve projelerde de belirsizliklerin sayısının en fazla olduğu döneme karşılık gelir. Bu süreçte proje yöneticisinin ihtiyaçları ortaya çıkarabilmesi için hem çok soru sorması, hem de geçmişteki (kurumsal/bireysel) deneyimlerden yararlanması gerekir. İhtiyaçların netleşmesi, detaylı planın güvenilir olmasını sağlayacaktır.

Müşteri açısından baktığımızda da;

  • Gereksinimler hakkında detay bilgi vermeme. Eğer, müşteri gereksinimlerini başlangıçta plana tam yansıt(a)madıysa, en tehlikeli sonuca hazır olun: KAPSAM KAYMASI
  • Gözden geçirme çalışmalarına müşteriden son sözü söyleyeceklerin olabildiğince proje yürütme sürecinde katılımlarını sağlamak. Yetkisi yeteri düzeyde olmayan müşteri temsilcileri proje ekibiyle uzun süre çalışırlar, belirli noktaya projeyi getirirler. Tam o sırada yukarıdan daha yetkili birisi o saate kadar konuşulanların tam zıttı bir istekte bulunur.  Herşeyi sil baştan düşünmek gerekir.
  • Genellikle işi en iyi bilen işi yapan kişinin kendisidir. Bu yüzden, ortaya çıkacak ürünü kullanacak olanın da fikirlerini almak gerekir. İşi yapan kişiler, genellikle yetki açısından düşük seviyede olduklarından çoğu zaman proje yöneticisi veya müşteriyi temsil eden yönetici bu detayı görmez ve son kullanıcı düşünmeden bir ürün ortaya çıkarırlar. Sonuçta ne yazık ki ortaya çıkan ürün ihtiyaçlara karşılık vermemektedir.
  • Müşteriyi de proje planlamaya, takip süreçlerine dahil etmek çok önemlidir. Bir proje ekibinin planı tek başına yapması yerine müşterinin desteğini alarak, yapması, projenin daha fazla sahiplenilmesini sağlar, katılımı artırır.
  • Projenin başarısı sadece projeyi yürüten ekibin başarısı olarak değil, müşterinin de başarısı olarak lanse edilmelidir. Yine ortaya çıkan ürünün müşteri tarafından sahiplenilmesi ve hatta etkin olarak kullanlımasını sağlar.

——————-o————————

Cumhuriyet Bayramınız Kutlu Olsun.

İş Kırılım Yapısı Yoksa…

Bir projede İş Kırılım Yapısı hazırlanmamış ise aşağıdaki sorunları yaşarsınız.

● Sürekli projeye yeni eklemelerin gelmesi ve bunun sonunun kestirilememesi

● Tanımlanamayan görev atamaları, tanımlanamayan hedefler ve teslimatlar

● Projede kapsam kayması veya yönetilemeyen ve çok sık değişen kapsam

● Bütçe aşımları

● Beklenen teslimatlar için hedeflenen zamanın sürekli kayması

● Kapsamdaki sapma miktarının raporlanamaması

● Paydaşlar arasında rol ve sorumlulukların tam olarak anlaşılamaması ve işlerin havada kalması

● Proje ekibinde motivasyon düşüşü

● Paydaşlar arasında çatışmanın artması

PMBOK'ta Yer Alan “Yönetim Planları” Nedir? – 1

Kapsam Yönetim Planı

Proje kapsamının nasıl tanımlanacağını, geliştirileceğini, doğrulanacağını ve iş kırılım yapısının nasıl oluşturulacağını ve tanımlanacağını açıklayan ve proje kapsamının proje yönetim ekibi tarafından nasıl yönetileceği ve kontrol edileceği konularında yol gösteren bir belgedir. Proje yönetimi planının bir parçası ya da alt planıdır.

Örnek İfadeler:

  • İş kırılım yapısı Proje Yöneticisi ve çekirdek ekip tarafından oluşturulur.
  • İş kırılım yapısı Müşteri Temsilcisine ve Proje Sponsoruna onayı alınarak, geçerlilik kazanır.
  • Kapsam değişiklik önerileri, yazılı olarak, Proje Yöneticisine sunulmalıdır.
  • Kapsam değişiklikleri için Değişikik Onay Komitesi üyelerinin ortak mutabakatı gerekmektedir.
  • ….

Zaman Çizelgesi Yönetimi Planı

Proje zaman çizelgesini geliştirmek ve kontrol etmek için kriterleri ve aktiviteleri belirleyen belge. Proje yönetimi planının bir parçası ya da alt planıdır.

  • Projenin zaman planı MS Project üzerinden takip edilecektir.
  • Zaman Planı her hafta sonu gelen veriler ışığında güncellenir.
  • Zaman planındaki sapmalar sebepleriyle Proje Sponsoruna raporlanır.

Maliyet Yönetimi Planı

Proje maliyederini planlamak, yapılandırmak ve kontrol ermek için gerekli biçimi ortaya koyan ve aktiviteleri ve krirerleri belirleyen belgedir. Maliyet yönetimi planı, proje yönetimi planının bir parçası ya da alt planıdır.

  • Projenin parasal ihtiyacı aylık dönemler şeklinde Proje Yöneticisi tarafından çıkartılır.
  • Proje maliyet tahminleri 3’er aylık dilimler şeklinde detaylandırılır ve 3’er aylık dilimlerde güncellenir.
  • 5.000 TL altındaki ödemeler, faturaya istinaden Proje Yöneticisi tarafından gerçekleştirilebilir. Daha yüksek meblağlı ödemelerde Proje Sponsorunun onayı alınmalıdır.
  • Bütçe ile gerçekleşen arasındaki farklar Proje Yöneticisi ve Proje Sponsoru arasında aylık yapıalcak toplantılarla ele alınır ve sapma sebepleri raporlanır.