Mühendislik

Bilgi Teknolojileri (BT) Projelerinde Kapsam Yönetimi

Proje yönetimi, sektörler üstü bir yaklaşım ile, ürün veya hizmetin kendisinden bağımsız olarak bir rehberlik sağlar. Kapsam yönetimi ise, projenin zaman, maliyet, kalite, kaynak, risk gibi tüm bileşenlerinin yönetimini etkilediğinden ayrıca önemlidir. Bu makalemde bahsedeceğim konular, tüm projelerde kapsam yönetimi konusunda hassas olmakla birlikte, bilgi teknolojileri konusunda bizlerin sürekli karşımıza çıkan temel konulara daha fazla vurgu yapmayı tercih ettim.

Proje ve proje yönetimine, tanımları ile göz atacak olursak:

Proje, özgün bir ürün, hizmet ya da bir sonuç ortaya koymak için yürütülen geçici bir girişimdir. Projenin bir başlangıç ve bitiş tarihi vardır, bu süre zarfında yürütülecek faaliyetler bulunur ve bu faaliyetler neticesinde projenin hedeflediği özgün hizmet, ürün ya da sonuca ulaşılır. (PMI® – PMBOK® 5. Baskı’dan alınmıştır.)

Proje Yönetimi, bilgilerin, becerilerin, araçların ve tekniklerin, projenin gereksinimlerini yerine getirmek amacıyla proje faaliyetlerine uygulanmasıdır. (PMI® – PMBOK® 5. Baskı’dan alınmıştır.)

Bu bilgiler ışığında yazılım projelerinde çok sık karşımıza çıkan kapsam yönetimi sorunlarını irdeleyelim. Maalesef dünyada BT projelerinin başarıyla sonuçlanma oranı oldukça düşüktür, ülkemizdeki durumun da farklı olduğunu söyleyemeyiz. Chaos raporuna göre, yıllık olarak başarılı, kusurlu ve başarısız olarak tamamlanmış proje oranları Şekil 1’de verilmiştir. Görüldüğü gibi, başarılı proje oranının %50’nin üzerine çıktığı bir yıl bulunmamaktadır.

Kâğıt üzerinde “başarılı” görünen bazı yazılım projelerini, aşağıda bir kısmını paylaşacağım nedenlerle başarılı saymamız pek doğru olmaz:

  • Gereksinimlerin faydalanıcıdan doğru toplanamaması ve ortaya çıkan nihai ürünün faydalanıcının beklentisi ile örtüşmemesi
  • Gerçekçi olmayan gereksinimlerin toplanması ve bunların yönetilemeyerek ortaya çıkan ürün ve hizmete katkıdan ziyade zarar vermesi
  • Teklif edilen proje kapsamından çok daha fazla çalışma yapılarak, yüklenici firmanın cezai şartlara düşmemek için zarara uğrayarak projeyi tamamlaması
  • Teknik şartnamelerde yer alan ucu açık/net sınırları belli olmayan ifadelerden dolayı ek gereksinimlerin bu maddelere dayandırılarak faydalanıcı kurum tarafından talep edilmesi
  • Doğru planlama yapılmamasından ötürü, düşük rakamlarla alınan projelerde kapsamın daraltılarak daha küçük bir proje tanımı içinde projenin kapatılması
  • Hatalı planlama sonucu projenin zamanında tamamlanması için proje ekibinin fazla mesailerle sürekli çalıştırılması
  • Gerekli proje belgelemesinin yapılmamasından dolayı, gereksinimlerin izlenebilir olmaması ve kabul komisyonlarında ciddi anlaşmazlıkların ortaya çıkması
  • Zaman ve maliyet kısıtından dolayı, proje kalite kontrollerinin yapılmamış olması
  • Paydaşların eksik tespit edilmesinden ötürü, gereksinimlerin eksik belirlenmiş olması

Şekil 1 Chaos raporuna göre BT projelerinin başarı durumları

Projelerin başarılı olması için temelde, gerçekleştirilmesi hedeflenen kapsamın, planlanmış zaman ve maliyet çerçevesinde, müşterinin projeden beklentisini içerecek kalite unsurlarını barındırarak ortaya konması gerekmektedir. Proje zamanının daraltılması durumunda, kapsam sabit kalırsa maliyetler artacaktır çünkü birim zamanda çalışması gereken personelimiz artacaktır. Kullanacağımız kaynağı artırmamız gerekmektedir. Hem zamanı daraltıp hem de maliyeti düşürmek istediğimizde, doğal olarak ortaya koyacağımız proje kapsamı da daralacaktır. Yazılım projelerinde, gereksinimlerin faydalanıcı kurumdan doğru alınamaması ve ortaya çıkartılan nihai ürünün beklentiyi karşılamaması en sık karşılaşılan sorunlar arasındadır. Kapsam/gereksinim yönetimi proje yönetiminin en önemli bilgi alanlarından birisidir ve artık günümüzde iş analistleri (business analysts) tarafından yürütülmektedir. İş analistleri;

  • gereksinimlerin doğru tanımlanması,
  • gereksinimlerin detaylarının ve sınırlarının belirlenmesi,
  • gereksinimlerin yazılım ekibine aktarılması ve beklentilerin ekip tarafından doğru anlaşılmasının sağlanması,
  • test süreçlerinin takibi ve tanımlanmış gereksinimlerin ortaya konulan üründe beklentiyi karşılayacak şekilde var olduğunun test edilmesi ya da test ekibi koordinasyonunun yapılması,
  • faydalanıcı beklenti yönetiminin yapılması,
  • değişiklik ve konfigürasyon yönetimlerinin yapılması

görevlerinde yer alarak, özellikle proje kabul süreçlerinde etkin ve yetkin rol üstlenmelidirler.

Kapsamdan bahsederken iki kavramı daha irdelememizde fayda var:

Kapsam Kayması (Scope Creep), zaman, maliyet ve kaynaklarda ayarlama yapmadan ürün ya da proje kapsamındaki kontrolsüz genişleme/daralma olarak ifade edilir. (PMI® – PMBOK® 5. Baskı’dan alınmıştır.)

Altın kaplama (Gold Plating), faydalanıcının bizden talep etmediği, kapsamımızda yer almayan özellikleri ürünümüze ya da sunduğumuz hizmete dahil etmemiz olarak ifade edilir. (PMI® – PMBOK® 5. Baskı’dan alınmıştır.)

Her iki durum da, doğru proje yönetimi içerisinde yer almamalıdır. Altın kaplama daha çok, müşterinin gözünü boyamak için ortaya çıkarken, kapsam kayması, gereksinimlerin ekip tarafından çok iyi anlaşılmadığı veya kapsamın ve değişikliklerin düzenli izlenip kontrol edilmediği durumlarda ortaya çıkabilir. Edward V. Berard’nın  komik bir söylemini paylaşmak istiyorum “Walking on water and developing software from a specification are easy if both are frozen.” – “Su üzerinde yürümek ve gereksinimlere göre yazılım geliştirmek ancak her ikisi de donmuş ise kolaydır”. Yazılım projelerinde gereksinimlerin dondurulması, gelişen teknolojiler ve beklentiler düşünüldüğünde çok mümkün gözükmemektedir. Özellikle zaman olarak uzun süreli projelerde, projenin başlangıç aşamasında tanımlanmış olan gereksinim zaman aşımına uğrayarak değişebilmektedir. Projelerimizde gereksinimleri doğru tanımlamak ve tanımlanmış gereksinimleri doğru yönetebilmek, ön plana çıkan proje yönetim adımları arasında olmalıdır. Kapsamı kaydırmadan, değişen şartlara göre değişiklik yönetimi (change management) süreçlerini uygulayarak gereksinimlerimizi yönetebilmeli, altın kaplamaya izin vermeden belirlenmiş gereksinimleri içeren ürün ve hizmeti ortaya koymalıyız.

Gereksinim/kapsam yönetiminde en önemli unsurlardan birisi de paydaş yönetimidir. Paydaş, projeden etkilenen ve projeyi etkileyen herkes olarak tanımlanır. Gereksinimler paydaşlardan temin edileceği için, projenin paydaşlarının eksiksiz tespit edilmesi ve doğru yönetilerek paydaşların projeyi destekleyici şekilde projeye katılımlarının sağlanması çok önemlidir. Bir paydaşın eksik tespit edilmesinden ötürü, projenin ilerleyen fazlarında paydaşın beklentilerinin projenin belirlenmiş kapsamı ile örtüşmemesi ciddi sorunlara yol açacaktır. Projenin ortaya koyacağı ürün ya da hizmete karşı direnç gösteren paydaşların varlığı durumunda, bu paydaşların iyi yönetilmesi ve direnç gerekçelerinin tespit edilerek, doğru ve zamanlı bilgilendirmeler ile paydaşın projeye katılımının sağlanması önem arz etmektedir.

Selda Düzgünoğlu

Kaydet

Kaydet

Kaydet